Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!leah!rpi!rpi.edu!deven From: deven@pawl.rpi.edu (Deven Corzine) Newsgroups: comp.sys.amiga.tech Subject: Re: Unix V7 functionality under (or along with) AmigaDOS? (*LONG*) Message-ID: Date: 30 Mar 89 10:20:14 GMT References: <6389@cbmvax.UUCP> <6406@cbmvax.UUCP> Sender: usenet@rpi.edu Reply-To: shadow@pawl.rpi.edu (Deven T. Corzine) Organization: RPI Public Access Workstation Lab, Troy NY Lines: 121 In-reply-to: jesup@cbmvax.UUCP's message of 28 Mar 89 19:24:59 GMT In article <6406@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: >In article 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. That is another option. Will #pragma's override older duplicate (but different) declarations? [also, is there any other valid type than "libcall" and "syscall"?] >>>>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. Ah... there's the discrepency. You have a different manual than I. Time to be specific [and verbose] I suppose: Amiga ROM Kernal Reference Manual: Exec Authors: Carl Sassenrath, Rob Peck, and Susan Deyl Program examples by Carl Sassenrath Published 1986, Addison-Wesley. -------------------------------------------------------- Library of Congress Cataloging-in-Publication Data Amiga ROM kernal reference manual. (Amiga technical reference series) Includes index. 1. Amiga (Computer)-Programming. 2. Read-only storage. I.. Commodore Business Machines. QA76.8.A177A655 1986 005.4'46 86-10887 ISBN 0-201-11099-7 -------------------------------------------------------- Now... what is the most concise, yet unambiguous way to refer to this version of the RKM: Exec Manual? There is no page "1-64"... and page "64" is the blank page between Chapter 5, Interrupts, and Chapter 6, Memory Allocation. Clearly it is a different version. I believe it is V1.1, but perhaps not. Anyway, you can deallocate partial blocks... fine. Is there any place you can look up the MEM_BLOCKSIZE at run-time, or must you recompile when the granularity changes? [recompiling would be a nuisance.] > I said it was in the chapter.... In YOUR copy of the RKM's, perhaps... :-) >>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. Any place I can get the 1.3 Autodocs? I don't have the money right now to buy the developer's disk yet, or the 1.3 Includes & Autodocs RKM... [not that I've actually seen [or looked for] it, but...] I can handle making a printout of them myself, [;-)] and I prefer to print them myself so I can have them loose-leaf, one-up. [as I have the Includes printed...] I don't suppose it might be possible [or legal?] for you [or someone] to email me [aCk] the V1.3 Autodocs, might it? I would be most appreciative... >> 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. Presumably the question of message vs. reply port would be if you had to use a different port to receive the reply to a message you sent to some other port from a port you could receive (via PutMsg()) a message on. Hence, not the same message -- one with the port as destination, another with it as reply port. No need to separate them, is there? [apart from logical design?] Deven -- ------- shadow@pawl.rpi.edu ------- Deven Thomas Corzine --------------------- Cogito shadow@acm.rpi.edu 2346 15th Street Pi-Rho America ergo userfxb6@rpitsmts.bitnet Troy, NY 12180-2306 (518) 272-5847 sum... In the immortal words of Socrates: "I drank what?" ...I think.