🚀 go-pugleaf

Just a quick summary of the current state of a project of mine
tentatively named "Amigix".  I am in an information and idea gathering
stage now, and welcome input from any and all, about what I should do,
what I shouldn't, etc.  Flames to /dev/null.

Oh, yes.  If you think of a better name than "Amigix", tell me.  (I
prefer Amix, but C-A took it...  :-)

The idea is to implement an environment which provides Unix V7
compatibility at the source code level, with SysV, BSD and amiga
extensions as appropriate.  This includes functions such as alarm(),
dup(), fork(), exec(), read(), write(), open(), close(), etc.  I also
hope to implement shared text segments (resident programs, though not
necessarily loaded if not in use at all) and if I get really sick I
may take a stab at dynamic linking.  (I'll hold off on that one quite
a while, likely.)

One important design goal is the same as for Exec: keep everything as
dynamic as possibly and use dynamically allocated nodes in Exec lists
for system structures instead of a static table.  That way, you are
limited only by the hardware capabilities of your machine, not by
arbitrary choices in the operating system.

The basic design is to have a run-time library (opened with
OpenLibrary()) which implements the Amigix functions and utilizes a
system task for coordination purposes.

The system task will be an AmigaDOS process which coordinates the
Amigix system and also makes calls to AmigaDOS for file system
requests made by any Amigix process.  (An Amigix process will NOT be
an AmigaDOS process, and as such will be unable to directly use the
dos.library routines.)

The system task will also be responsible for (Amigix) process creation
and termination, including full cleanup of allocated resources.  It
will coordinate communication with AmigaDOS and its own file system
task (eventually) via Exec message passing.  At that level, the
message passing will be completely internal and transparent to the
user.  (Similar to AmigaDOS's packets.)

An initialization program would create the system task and make the
library, both from its own data (or maybe) code segment, and exit when
the initialization is done, not having modified itself with, say, a
seglist split...

The allocation tracking routines will probably track for regular tasks
and AmigaDOS processes, but do no automatic deallocation.

Well, that's a quick summary, for now.  Send any commants and ideas to
shadow@pawl.rpi.edu, NOT deven@pawl.rpi.edu.  Keep in mind that this
project may or may not dissolve into Vaporix [:-)] due to time
constraints, etc.  So I'm not making any promises, but I hope to do
it, sooner or later.  When/if I do, I'll tell folks.

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.