🚀 go-pugleaf

 In article <6298@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes:
 >In article <DEVEN.89Mar15143212@daniel.pawl.rpi.edu> deven@pawl.rpi.edu (Deven Corzine) writes:
 >>>>Say, if I replaced that Command Dir lock that's in the CLI structure
 >>>>for that one CLI process, would it look there without having to
 >>>>assign c: elsewhere?
 >>
 >>>        You believed the name of the field, didn't you?  Poor naive boy. :-)
 >>>It's really the BPTR to the path list.
 >>
 >>Figures.  What form is this path list in?  BCPL array of BSTRs?  BCPL
 >>array of locks?  Something else?

 >        BPTR to a linked (BPTR) list of locks. (as in: {BPTR next;
 >BPTR lock;}).  (Note all locks are BPTRs to filelock structure (or
 >things bigger than filelock structures)).

Ok.  I understand...

 >>In other words, there would be a program which would be run (from the
 >>CLI or Workbench) which would initialize the Unix-type system, install
 >>the run-time library as permanently ram-resident,  You can do this
 >>easily, can you not?  I mean, without dealing with LIBS: and
 >>disk-based libraries and all that?  I want the library to be part of
 >>the data (and/or code) of this executable program, and have it use
 >>that to install it as a permanently ram-resident Exec Library, without
 >>any such library in LIBS:...  I haven't looked closely at the Library
 >>routines, but as I recall, it seemed doable enough.

 >        Sure, just make sure it isn't unloaded (cli_module = NULL), and
 >do a MakeLibrary exec call.

cli_module?  That's the seglist for the loaded program in the CLI
structure, isn't it?  I intended to use AllocMem (or AllocEntry,
maybe) and copy the data, allowing the CLI/Workbench to unload it, or
whatever.  Either way, I guess.

 >>The original program would return to caller after completing
 >>initialization and starting the separate system process, so as to
 >>avoid any hassles with having to RUN the program, etc.

 >        Will work fine.

I have a significant question as to the operation of AddTask(),
RemTask() and the relationships between them, memory allocation and
task termination.  The Exec RKM (V1.1) is rather unclear, I'm
afraid...

First, AddTask(task,initialPC,finalPC).  I understand that task is a
pointer to an initialized task structure and initialPC is the entry
point of the task.  That's straightforward enough.  My question
concerns the finalPC argument.

If finalPC is 0, does it simply cause a RemTask(), or will it follow
the list in the tc_MemEntry field and FreeEntry() for each entry in
the list?  (Or does RemTask() do this?)  Does it free the memory
associated with the task structure itself, or the tc_MemEntry list?
Does it try to?  If you can, would you post the actual code it uses
when you specify 0 for finalPC?  It would make things much clearer.

As for RemTask(), does it ONLY remove the task from the Exec task
ready/waiting queue, (between a Disable()/Enable() pair, of course) or
does it try to do any memory or resource deallocation as per above??
It makes a big difference...

 >>One more thing.  I need a name.  "Unix" is clearly out.  "Amix" I
 >>rather like and would use, but now it's taken, too.  "Minix" I don't
 >>especially like and would give the wrong impression, as this would not
 >>be a Minix port.
 >...
 >>I'm pretty much at a loss for what to call it.  It would probably be
 >>nice to have it end in "ix", just for consistency.  (everyone ELSE
 >>does it!!) :-)  So...  have you (or anyone) ANY suggestions what this
 >>could be called?

 >        Well, if it takes forever to finish, you could call it Vaporix. :-)
 >How about Maxix?  Micrix?  Amigix? (AIX is out)  Fooix, Barix, FooBarix?
 >Fix?  Trix (maybe GNU or some such grabbed this) Vix (visual Unix)?

It make take awhile, but hopefully not forever.  Amigix seems the best
of those...  FooBarix is amusing, though...  :-)

 >>p.s. I saw your old address in shell.doc on that shell 1.03 beta
 >>disk...  2340 15th Street???  I live at 2346!!  Hey, we're neighbors!

 >        Yup, used to live there around 2 years back.  Had friends that lived
 >at 2348 (the "O-den").  Isn't the circularity of the world suprising?

2348?  (like, on the corner?)  All I know is there's a doctor's office
there...  (and they don't ike us parking in the lot...)

 >-- 
 >Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup

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.