Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!apple!oliveb!amiga!cbmvax!jesup From: jesup@cbmvax.UUCP (Randell Jesup) Newsgroups: comp.sys.amiga.tech Subject: Re: Resident, Exit() and UnLoadSeg()... (long) Keywords: CATS? Message-ID: <6140@cbmvax.UUCP> Date: 3 Mar 89 20:43:56 GMT References: <6124@cbmvax.UUCP> Reply-To: jesup@cbmvax.UUCP (Randell Jesup) Organization: Commodore Technology, West Chester, PA Lines: 100 In article shadow@pawl.rpi.edu writes: I remember these problems well, I wrote a csh clone, SeaShell, before I came to commodore. >>>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. Yup. >3. The compiler exit() calls the compiler _exit() which calls Exit(). Not Lattice. >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... Lattice pops the stack back to the starting point, then does an RTS. The trick to making Exit() work is in the setting of pr_ReturnAddr. Note this is somewhat magic. >>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...) Shells are shells, period. The Workbench is a visual shell. Exit() itself does almost nothing, except return control to the "shell" as if the program had exited. >Also, where can I safely store extra an extra data structure for the >process, without conflicting with anything? Several possibilities >come to mind. Nowhere, unless (a) you're willing to use AddTask for everything, and therefor are willing to reimplement the functionality of CreateProc (fully, including endcode for cleaning up things like directory locks, pr_SegList pointer (which is bizarre), etc). >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? I'd bet yes. >Two, make an extended structure with a process structure as its first >element, and add fields after it for my own use. See above. >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. Programs that seglist-split may be confused by this, as well as BCPL programs. >On a related point, is this an equivalent function for UnLoadSeg(), or >does UnLoadSeg() do something else/more? Much more. First there's overlaid programs. Releasing them is somewhat tricky, since they have open filehandles, and tables to be freed. Plus UnloadSeg must work for a NULL seglist. And then there are "resident libraries" (yech). Another ex-RPI student... -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup