Path: utzoo!attcan!uunet!lll-winken!csd4.milw.wisc.edu!leah!rpi!rpi.edu!shadow From: shadow@pawl.rpi.edu (Deven T. Corzine) Newsgroups: comp.sys.amiga.tech Subject: RFC: Amigix (was Re: Unix V7 functionality ...) Summary: Unix V7 on top of Exec, alongside AmigaDOS, probably with certain SysV and BSD and Amiga extensions, later with its own file system... Keywords: RFC -- Request For Comments Message-ID: Date: 19 Mar 89 15:48:57 GMT References: <0776.AA0776@julie> <6275@cbmvax.UUCP> <6299@cbmvax.UUCP> Sender: usenet@rpi.edu Reply-To: shadow@pawl.rpi.edu (Deven Thomas Corzine) Organization: RPI Public Access Workstation Lab, Troy NY Lines: 61 In-reply-to: shadow@pawl.rpi.edu's message of 19 Mar 89 13:22:54 GMT 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.