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: Re: Unix V7 functionality under (or along with) AmigaDOS? (*LONG*) Message-ID: Date: 19 Mar 89 13:38:53 GMT References: <6157@cbmvax.UUCP> <6185@cbmvax.UUCP> <6237@cbmvax.UUCP> <1292@dukeac.UUCP> <6278@cbmvax.UUCP> <6303@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: 85 In-reply-to: andy@cbmvax.UUCP's message of 16 Mar 89 15:51:38 GMT In article <6303@cbmvax.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: >In article shadow@pawl.rpi.edu (Deven Thomas Corzine) writes: >>In article <6278@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: >>>>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 >The standard Status command will ignore any process with a process >number of 0. Of course, you realize that the CLI process number is >an index to the task table. Other programs that play with the >task table may not have the error check that status does. >So it is a risk of memory corruption, depending on what other >programs the end user has. >>as being in the billions or so (many digits anyhow) after something >>crashes... very incongrous.) >That's what happens when memory is corrupted. You took a hit in your >process structure. That's what I figured. >>> 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? >Though it may seem like a clean solution at first, you'll find that >a packet forwarder won't ever be able to just put the sender >in touch with the real receiver, but must stay in the loop, forwarding >each packet. Now why is that? Ah, well. No matter, I'm already going to have a system task for coordination which will be an AmigaDOS process, though I think I'll just have it use function calls to dos.library instead of using packets directly, though I may change my mind... I may well patch dos.library also so Amigix processes can call them directly and have the patch send a message to the system task to do the actual call if the caller is an Amigix process instead of a dos process. >You might want to take a look at the path handler (with source) >that came by comp.amiga.sources as well. A path handler came across comp.sources.amiga? I don't recall one, at least not source... There was PathAss (gee, what a name) but I thought that was a binary-only post. Besides, that one is poorly written and crashes under stressful conditions regularly. (e.g. using it for c: sucked. "DOS Library general error: Unexpected packet received."... *sigh*) >>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... >There are only 8 user-defined protection bits; as you surmised, the >upper 8 bits are the user bits. The 1.3 Copy command preserves >protection bits by default. The next version of ZOO will preserve >all protection bits as well. >Granted, magic numbers are never in danger of being lost, and may be >a better solution thab protection bits. Hmmm, I wonder if romtags >could be adapted...nah :-) Exactly what are romtags, hmm? Actually, it's sorta tempting to try to write a loader which could load object modules directly and link them dynamically... SunOS 4.0 does this, and it's a real neat trick. Also a bitch to implement, I imagine... Maybe I won't. :-) 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.