Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!batcomputer!rpi!rpi.edu!deven From: deven@pawl.rpi.edu (Deven Corzine) Newsgroups: comp.sys.amiga.tech Subject: Re: Resident, Exit() and UnLoadSeg()... (long) Keywords: CATS? Message-ID: Date: 3 Mar 89 05:21:18 GMT References: <6124@cbmvax.UUCP> Sender: usenet@rpi.edu Reply-To: shadow@pawl.rpi.edu Organization: RPI Public Access Workstation Lab, Troy NY Lines: 114 In-reply-to: andy@cbmvax.UUCP's message of 2 Mar 89 18:12:46 GMT In article <6124@cbmvax.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: >In article shadow@pawl.rpi.edu (Deven Thomas Corzine) writes: >>I working on writing a shell and a support library, and would like to >>be able to use seglists in the 1.3 Resident list. I DON'T want to >>have to use the V1.3 run command, or the DOS Execute() function. I >>want to be able to get at the list of resident seglists, usecounts and >>names, and to be able to modify said list. Therefore, I'm looking for >>both the data structures used by the Resident command (and how to find >>them) and any mutual exclusion conventions needed to modify the list. >> > >I'm planning to have some extensive revisions of the way resident >works for 1.4. Therefore, please don't use the DOS resident list. >Right now we're the only ones using it, so we can be fairly >free with changes. (well, MCC uses it, but they hang aliases >off it, which is incorrect anyway :-) ) So I'd prefer to >keep quiet about the data structures, locking conventions, and >internal workings of the shell on this. Instead I suggest >you set up a resident list for your shell, and hang it either >off a public message port, or a resource. Phooey. I just wanted to support DOS Resident lists for compatibility purposes. *sigh* >>Also, when you run a resident command from the CLI or run, does Exit() >>have a check for a resident seglist to decide whether or not to >>UnLoadSeg() the seglist, or does it pass control back to the CLI or > >C programs should not be using Exit() which never matches the >exit things your compiler startup wants you to clean up. 1. Some programs still use Exit(); it's Amiga specific, not compiler specific. 2. Some programs are simply naughty and use it. 3. The compiler exit() calls the compiler _exit() which calls Exit(). Regardless, I'm interested in the point where Exit() is called, not where exit() is called. I could use Lattice's onexit() function, but I don't want to tie it to any single compiler and I don't want to use the one onexit() available. Also, I still want to catch it even if Exit() is called by the program... (plus, I recall someone mentioning a lack of onexit() in Aztec...) >The shell has the responsibility of unloading (or not unloading >in the case of resident segments) the programs. But does this hold true when the shell is NOT running under the CLI? It will be running as a DOS Process, but NOT as a CLI process. The manuals imply that Exit() frees the seglist for a DOS process but not for a CLI process. I want Exit() to leave it alone and let the shell handle the seglist. Under exactly what circumstances will Exit() release memory? (Or ANY resources...) Also, where can I safely store extra an extra data structure for the process, without conflicting with anything? Several possibilities come to mind. One, put CLI process number 0 in the dos Process structure (i.e. not a CLI process) and then use the CLI structure pointer field to point to my structure. Would this cause any incompatability problems? Two, make an extended structure with a process structure as its first element, and add fields after it for my own use. Three, add a segment to the end of the segment list as follows: BPTR addseg(seglist,segsize) BPTR seglist; ULONG segsize; { BPTR *segment, newsegment; APTR AllocMem(); segment=(BPTR *) BADDR(seglist); while(*segment) segment=(BPTR *) BADDR(*segment); newsegment=(BPTR *) AllocMem(segsize+8L,MEMF_PUBLIC|MEMF_CLEAR); *newsegment++=(BPTR) segsize; *segment=(BPTR) newsegment>>2; return(*segment); } This is somewhat kludgy, to be sure, but it seems it should work. On a related point, is this an equivalent function for UnLoadSeg(), or does UnLoadSeg() do something else/more? VOID UnLoadSeg(seglist); /* can't remember what it returns */ BPTR seglist; { BPTR *segment, *nextsegment; VOID FreeMem(); /* again, can't remember */ segment=(BPTR *) BADDR(seglist); while(segment && *segment) { nextsegment=(BPTR *) BADDR(*segment); FreeMem(--segment,(ULONG) *segment); segment=nextsegment; } } >I have this vision of a resident handler ... :-) Well? Describe this vision... How would it work? 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.