deven@pawl.rpi.edu (Deven Corzine) (03/03/89)
In article <6124@cbmvax.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: >In article <DEVEN.89Mar1180622@daniel.pawl.rpi.edu> 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.
jesup@cbmvax.UUCP (Randell Jesup) (03/04/89)
In article <DEVEN.89Mar3002118@daniel.pawl.rpi.edu> 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