🚀 go-pugleaf

In article <6185@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes:
>Distribution: comp
?

>In article <something@daniel.pawl.rpi.edu> shadow@pawl.rpi.edu writes:
>>In article <6157@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes:
>>>In article <DEVEN.89Mar6082649@daniel.pawl.rpi.edu> shadow@pawl.rpi.edu writes:
>	I'd advise using an extended CLI structure if you want any sort
>of compatibility.  This may break in 1.4, but it will at least work (please
>note in your docs that this may well break in 1.4 in that case).

That's one possibility, but I'd like to avoid using the CLI
structures, as they use noxious things like BPTRs and BSTRs...  I look
at it as having two ways to run programs - in a CLI environment, and
in this Unix-like environment.  New programs could be written to run
under the Unix-type environment, and CLI-type programs could be run as
a CLI process.

A big problem with CLI processes is that they are (quite arbitrarily)
limited to 20.  That is too few; I want to implement concurrent pipes
and simple backgrounding, and I don't want to have them all as CLI
processes.

Of course, the only real way to break from the BCPL crap is to rewrite
the file system, or at least the interface to it.  I wouldn't mind
doing so, and have considered it a number of times, but don't have the
time to do so just yet.  Maybe in a couple months.

Say I were to replace the interface to the file system?  (and rewrite
it later sometime. :-) )  Have open(), close(), read(), write(),
lseek(), pipe(), etc. and have most of them call AmigaDOS routines and
store things in internal tables...  If I do that, I could have a
single DOS Process to coordinate things and call the AmigaDOS
routines, and have the read(), etc. routines send messages to that
process.  Then I could replace the process structure altogether...
but have provisions to create a new CLI environment to run programs
which need it...  (or take the cheap way out and use Execute()...)

Another possibility would be to patch the OpenLibrary call (seems
preferable to patching ALL the DOS library calls) to catch any
OpenLibrary("dos.library",v) calls and check if it was one of the
non-DOS processes I created, and if so, have it open a compatibility
library instead...

Speaking of Execute(), I have a gripe with it.  V1.3 Execute() does
NOT use run if it is in the DOS Resident list, but still insists to
run c:run...  which is a BIG pain if the system disk isn't in the
drive.  (assigning c: to ram:c or rad:c isn't much help; then you
can't be asked for the system disk back to run programs in sys:c which
aren't resident...)

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?

>>So, is there any legitimate way to identify the binaries as "I don't
>>need a CLI environment"?  Essentially, is there a way to tag the
>>binaries with a "magic number"?  Such that it won't interfere with
>>LoadSeg() or the code itself?  Can you set a hunk name on the
>>hunk_header hunk?
>>
>>(The answer looks like it should be "yes", but I don't have any blink
>>docs onhand; only this AmigaDOS manual.)
>
>	No.

Argh.

>	I advise against modifying binaries.  Use one of the user
>protection bits.

Not such a good system.  user protection bits are all too easily lost.
I'd much rather have the binary identifiable.  The idea I had to
identify it which seems most workable is to have a special startup
module which begins with a branch past a magic number (longword) which
the shell's loader could check against.  Sound reasonable?

>>>	Tannenbaum has two students doing a port.

Tanenbaum, actually.  (glanced at his OpSys design book's cover.)

>>Nice to hear.  I wouldn't relish the task.  At least, replacing the
>>REAL low-level stuff, like Exec and the device handlers, I really
>>don't feel like messing with.  Rewriting the file system is as
>>low-level as I want to get at this point, on such a scale.  (And
>>that's no small project either.)
>
>	That's why I suggested a long time ago that Amiga-Minix be implemented
>on top of Exec/Graphics/Intuition/etc.  This also means you get your
>expansion hardware to work without having to hack the kernal for your
>specific configuration, and plead for driver source from the HD makers.

Yes, when I looked into it, I decided that it would be better
implemented on top of Exec and such.  However, there are some
low-level changes that would be valuable, like sending a signal to a
process when it goofs up, instead of GURUing and bringing down the
entire system...

But Exec is better designed in some ways than Unix.  Most notably, it
is far more dynamic, with everything in linked lists instead of static
arrays.  Then there's AmigaDOS, with its 20 CLI limit...  *sigh*

>>>	VERY hard to do without an MMU, since you MUST duplicate the stack
>>>and data, and those contain absolute pointers.  There is no way to know
>>>where these pointers are.  The ST/Amiga-Minix gets around this by copying
>>>the data/stack of the two processes to save areas,  and "swapping" in the
>>>data/stack to the original position whenever one needs to run.  Luckily,
>>>almost all fork() calls are followed almost immediately by exec(), so the
>>>overhead isn't too horrible.
>>
>>Oh, icky.  My, I had overlooked that aspect.  *sigh*  It's a kludge,
>>but I guess it'll work.  Can the tc_Switch and tc_Launch fields in the
>>task structure be used to handle this?  Or are they already used or
>>not usable as such?
>
>	yes, but respect any values already there (grab the old value, stuff
>yours, and after you're called call the old value).  An example of stuff
>that might use this would be saving '881 registers.

That's fine by me.  (expected to do so anyhow.)  What state do those
functions run in?  Supervisor or User mode?  Can they be interrupted
by the timer clock, and end up with Exec trying to switch out when it
already was?  Or, will they not be interrupted?  (i.e. if those
functions took 10 seconds to execute, would it break anything other
than system performance?)

How about using the tc_UserData field to point to an extended
structure?  Is it used for anything?  Or maybe using the name filed in
the task's node structure as an extended structure pointer?  Or are
both these out, too?

>>>	there is no way to dup a filehandle.
>>
>>It would be duping handles to a table entry holding the file handle.
>>(along with the count.)
>
>	Fine, but watch out: if two BCPL programs try to use the same
>filehandle, fireworks will erupt.

No way to dup a filehandle?  Why couldn't two programs use the same
filehandle?  Can two non-BCPL programs share a file handle?  It is
lack of mutual exclusion or something else?
--
------- 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.