Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!leah!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: 15 Mar 89 21:31:12 GMT References: <6157@cbmvax.UUCP> <6185@cbmvax.UUCP> <6237@cbmvax.UUCP> <1292@dukeac.UUCP> <6278@cbmvax.UUCP> Sender: usenet@rpi.edu Reply-To: shadow@pawl.rpi.edu (Deven Thomas Corzine) Distribution: comp Organization: RPI Public Access Workstation Lab, Troy NY Lines: 52 In-reply-to: jesup@cbmvax.UUCP's message of 15 Mar 89 04:00:05 GMT In article <6278@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: >In article <1292@dukeac.UUCP> rsb@dukeac.UUCP (R. Scott Bartlett) writes: >>In article <6237@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: >>> Agreed, it is too few. This may change. >> >>What about setting the CLI proc number to 0? Will some cli things choke on >>this? Lattice's forkv() uses proc number 0. (What do workbench programs do?) > Not normally a good idea. It removes the ability to Break the >program, or to have Status return anything reasonable. Isn't really too >dangerous, though. Wouldn't Status simply ignore any process that has a CLI process number of 0? (Strangely, sometimes Status will show a process number as being in the billions or so (many digits anyhow) after something crashes... very incongrous.) >>Let me know how you want to eliminate the BCPL stuff. I plan on >>writing a ROOT: to allow other filesystems to be mounted onto it. It >>would be a great place to eliminate some BCPL garbage (or at least >>hide it from those that are in the know). > Talk to Bill Hawes. He wrote a PATH: that does similar sorts >of things. Warning: packet-forwarding can get tricky. I still gotta track down that PATH: device sometime. Yeah, I could see packet-forwarding getting tricky... Any particular caveats you have in mind? >>> I've seen it done. Check the arp programmers docs. >> >>Please use the magic number. I think using the file protection bits >>is a BIG kludge. If we go ahead and implement magic numbers, programs >>that depend on the MMU for different memory setups, etc. can be >>identified and dealt with accordingly. For instance programs that are >>very time sensitive can be labled > Well, I don't really approve too much of magic number headers. >This really is exactly what the "protection" bits were designed for. >There are even 16 user-defined bits you could use. Be that as it may, it remains a fact that protection bits are easily lost in distribution and simple copying. What are these 16 user-defined bits? I assume the upper 16 bits, but I've never seen mention of them... 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.