Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!microsoft!w-colinp From: w-colinp@microsoft.UUCP (Colin Plumb) Newsgroups: comp.sys.amiga.tech Subject: Re: Unix V7 functionality under (or along with) AmigaDOS? (*LONG*) Message-ID: <12361@microsoft.UUCP> Date: 17 Mar 89 09:16:38 GMT References: <6157@cbmvax.UUCP> <6185@cbmvax.UUCP> <6237@cbmvax.UUCP> Reply-To: w-colinp@microsoft.uucp (Colin Plumb) Distribution: comp Organization: very little Lines: 59 jesup@cbmvax.UUCP (Randell Jesup) wrote: >> A big problem with CLI processes is that they are (quite arbitrarily) >> limited to 20. > > Agreed, it is too few. This may change. This isn't that hard to enlarge, but you want to get rid of the restriction completely. Arrgh! If someone would give me a complete spec for dos.library (basically, a list of BCPL kludges that need supporting), I could give you a rewrite in a month. The silly thing doesn't *do* dick all. >> Of course, the only real way to break from the BCPL crap is to rewrite >> the file system, or at least the interface to it. > > (suppressed giggle) it ain't as easy as it looks. Just ask Steve > Beats (Mr FFS). Actually, the interface isn't that bad. A few BPTRs raise their heads, and there are such idiocies as ExNext(), but it's bearable. Still, I wouldn't mind a nicer one, especially when dealing with the DevInfo list. >> I'd much rather have the binary identifiable. The idea I had to >> identify it which seems most workable is to have a special startup >> module which begins with a branch past a magic number (longword) which >> the shell's loader could check against. Sound reasonable? > > I've seen it done. Check the arp programmers docs. My preference is to define a new & improved executable format, preferably an IFF FORM. Then you can stick in all sorts of magic information and not break anyone's loader. But this would require one grand change to LoadSeg() (and at least one conversion utility for producing executables in this form, eventually to give way to direct linkers). >> No way to dup a filehandle? Why couldn't two programs use the same >> filehandle? Can two non-BCPL programs share a file handle? It is >> lack of mutual exclusion or something else? > > Two non-BCPL programs can right now. BCPL programs use the buffering > fields in the file-handle, and would clash over them. You have to handle the reference-counting manually, but you can have multiple processes all sharing the same filehandle without problems. The BCPL stuff is disgusting, and I hope it gets fixed in 1.4, 'cause owing to a lack of documentation, my FS is going to ignore that completely. If someone tries to jump through one of those fields, boom! But there's no way a handler can tell that two processes talking to it over the same filehandle aren't really one, that just has a strange prediliction for asynchronous I/O using multiple return message ports. (BTW, does anyone know what AN_AsyncPkt is caused by? Who sends an unexpected packet to whom?) -- -Colin (uunet!microsoft!w-colinp) "Don't listen to me. I never do." - The Doctor