🚀 go-pugleaf

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.