Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!um-math!sharkey!shadooby!eecae!tank!uxc!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: 31 Mar 89 07:51:49 GMT References: <6406@cbmvax.UUCP> <6464@cbmvax.UUCP> Sender: usenet@rpi.edu Reply-To: shadow@pawl.rpi.edu (Deven T. Corzine) Organization: RPI Public Access Workstation Lab, Troy NY Lines: 90 In-reply-to: jesup@cbmvax.UUCP's message of 30 Mar 89 22:18:30 GMT In article <6464@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: >In article shadow@pawl.rpi.edu (Deven T. Corzine) writes: >>That is another option. Will #pragma's override older duplicate (but >>different) declarations? [also, is there any other valid type than >>"libcall" and "syscall"?] > I think not. Doesn't matter, since they all use SysBase, >which is set up in the c.a startup code. All you need to do is put >your exec.amigix.library pointer in SysBase instead of the contents >of AbsExecBase. Oh... if that is the case, then that would be an acceptable option, methinks... I already have to replace the startup code... Of course, the other option is not to allow Amigix processes to *directly* call Amiga libraries, only indirectly through Amiga-specific amigix.library function calls... >>> 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. > The comments should still be there. They're not. I checked quite carefully. It notes that the current granularity is 8, but you can not depend on that size in future revisions of the operating system. And it noted that you CAN count on longword alignment. >>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.] > Recompile. Better yet, don't _depend_ on a given granularity. But, you see, the dependency would be in writing a ReallocMem function... I do NOT want to force enough memory for the old AND new memory blocks, so I must depend on the internal memory structure and the granularity that Exec uses, as Exec does not provide a ReallocMem function, and it is a pretty basic function... Now, if C-A will add a ReallocMem to Exec V1.4+, it won't be a problem, for nowhere else do I expect to have any dependency on the granularity. (Things WILL depend on a ReallocMem, however.) >>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... > They cost $20 from CATS. Well, I just started working again, so maybe I'll be able to spare the money... [little free time, now. :-(] >>I don't suppose it might be possible [or legal?] for you [or someone] >>to email me [aCk] the V1.3 Autodocs, might it? > Not legal (they're copyrighted). Sorry. I expected as much. Worth a try. :-) >>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? > Mind restating that in english? I'll give it a try. Say you've got 2 processes, each sending messages to the other. Is there or is there not a need to separate reply ports from message ports [as receiving points, not reply-receiving points] or can you have a single message port for each process, using it as the destination port for the messages the other process sends, and as the reply port for any messages the process spends. That book implied you'd need one port for the other process to send messages to, and another to receive the reply messages for messages you send to the other process... What's the actuality? 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.