Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!batcomputer!rpi!rpi.edu!deven From: deven@pawl.rpi.edu (Deven Corzine) Newsgroups: comp.sys.amiga.tech Subject: Re: Unix V7 functionality under (or along with) AmigaDOS? (*LONG*) Message-ID: Date: 5 Apr 89 12:23:56 GMT References: <6406@cbmvax.UUCP> <6464@cbmvax.UUCP> <3689@sugar.hackercorp.com> Sender: usenet@rpi.edu Reply-To: shadow@pawl.rpi.edu (Deven T. Corzine) Organization: RPI Public Access Workstation Lab, Troy NY Lines: 42 In-reply-to: peter@sugar.hackercorp.com's message of 4 Apr 89 12:35:43 GMT In article <3689@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >Why do you want the Amigix programs to be able to call a patched exec.library? >I thought the idea was to provide an environment for programs to run in that >has UNIX semantics. So your program is not gonna be making AmigaDOS calls in >any case. AmigaDOS calls (dos.library) are certainly out; Amigix processes will NOT be AmigaDOS processes. Only the Amigix system task will be. The idea behind allowing Amigix processes to call patched Amiga libraries would be to simplify porting existing Amiga programs to the environment. I haven't decided if this is the way I want to go, however. >Just let them use the regular exec.library long enough to open unix.library. >Unix.library will have Unix system calls and semantics. They should never >reference exec.library again, unless they need to go below unix.library. I'll probably use "amigix.library" just so I'm not using "Unix" anywhere. :-) As far as the process using exec.library to open amigix.library, it won't have to; part of the process handling code will take care of opening it and closing it when processes are created and die. The process should be able to forget about it... >In fact, you shouldn't be patching *any* libraries, since they're not relevant >to the Amigix environment, but AmigaOS software will still need to access >them... I don't intend to affect regular Amiga programs, except that it would be handy to port them, for consistency, job control (which I *do* intend to implement, probably for a beta release) signal handling, etc. I just don't know how much to facilitate the process... [making everything work directly is complicated and may make people less likely to write code FOR the environment, so perhaps it's not a good idea...] 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.