🚀 go-pugleaf

In article <DEVEN.89Mar25023341@daniel.pawl.rpi.edu> shadow@pawl.rpi.edu (Deven T. Corzine) writes:
>In article <6389@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes:
>>        No, the _only_ thing he has to do is open amiga.foo.library
>>instead of foo.library.  Since all the offsets are the same, nothing
>>else need be done, and amigix.foo.library will get all calls that
>>would otherwise go to foo.library.

>Sure, changing the library opened will work for all libraries, EXCEPT
>for the exec.library...  Exec.library is accessed through ABSEXECBASE
>at memory location 4, not from a return from the OpenLibrary call.  It
>doesn't make sense to change that pointer (at ABSEXECBASE) as it would
>likely cause big troubles, so I'm left with patching all the
>exec.library functions,

	Just write your stubs/pragmas to use something other than SysBase,
then.  Note that most programs stash execbase in a variable SysBase.  This
lessens reliance on accessing chip memory in a fast-mem system.  Look at the
lattice startup code and pragmas.

>>>Also, is it legal to FreeMem a different sized block than you
>>>AllocMem()'d?  If so, how can you keep it from depending on the
>>>granularity of the memory allocators?
>
>>        Check the exec memory chapter.
>
>Didn't want to look it up yourself, huh?  :-)  Well, the Exec memory
>chapter doesn't say anything clear about it, except that you can't
>depend on the granularity being 8; only a multiple of 4.  Nowhere does
>it say anything about whether or not you can legitimately free a
>different sized memory block than you originally allocated.

	Page 1-64, White 1.1 RKMs: Partial blocks may be deallocated, but
note again that FreeMem() rounds your address down to the nearest even multiple
of MEM_BLOCKSIZE and the size up to the nearest multiple before the FreeMem()
request is performed.

	I said it was in the chapter....

>About the autodocs...  Are they the "man" type pages in Appendix A of
>the (1.1) RKM L&D manual?  Or am I missing it altogether?

	Yes, autodocs are equivalent to man pages.

> I was scanning
>that Amiga Programmer's Handbook, and it says something about every
>task having a message port an associated but separate reply port.  I
>don't understand.  I thought the same port was used to send AND
>receive the replies to a message?  Also, why would all tasks have to
>have message ports?  In short, is this true?

	A port is never "used" to send a message, only to recieve one (or
recieve a reply).  All _Processes_ have a port (pr_MsgPort) for recieving
(a) the inital WB startup message, and (b) replies to filesystem packets.
_Tasks_ do not have associated ports unless the application creating it
does so.

-- 
Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup