Path: utzoo!attcan!uunet!cs.utexas.edu!sun-barr!texsun!texbell!sugar!peter From: peter@sugar.hackercorp.com (Peter da Silva) Newsgroups: comp.sys.amiga.tech Subject: Re: Minix, Unix on the Amiga, and flames on AmigaDOS braindamage... Message-ID: <4098@sugar.hackercorp.com> Date: 10 Aug 89 11:59:37 GMT References: <1610@uw-entropy.ms.washington.edu> <195@VAX1.CC.UAKRON.EDU> <7570@cbmvax.UUCP> Organization: Sugar Land Unix - Houston Lines: 105 In article <7570@cbmvax.UUCP>, jesup@cbmvax.UUCP (Randell Jesup) writes: > In article <4084@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: > >Because unlike you he understands that AmigaDOS is the name of the Tripos > >derived file system. The rest of the system, the Exec, drivers, etc..., are > >together called AmigaOS. > There's more than just the filesystem. It includes a load of BCPL > library routines used by the dos calls and bcpl programs (and filesystems). (dismissively waves hands) comes down to the same thing. The DOS is in BCPL. > >> AmigaDOS (among other OSs) got it right, and chose tasks for basic IO > >> objects. > >Actually, every part of AmigaOS *except* AmigaDOS uses tasks as the basic > >object. AmigaDOS uses a task interface, but the basic object is the lock or > >file handle. Mixing models like this is a bad idea, and the main reason > >people get frustrated with AmigaDOS. > > Actually, the filehandle is not the basic object: the coroutine is > (for OFS/FFS). The filehandle is a handle on the coroutine in the FS. Programmer interface is what's important here. What goes on on the other side of dos.library is irrelevant. A program talks to DOS by making library calls using a filehandle as the basic object. There are a few programs that explicitly pass messages to handlers (browser is one of them), but unless you do it strictyly synchronously this way is fraught with danger. Locks and file handles are the basic objects in DOS. Messages and message ports are the basic objects in the rest of the system. > Many requests for what people call "resource tracking" are actually > requests for memory protection. I consider any program on ANY os that doesn't > free what it allocates (memory, file locks, whatever) to be at best poorly > written. What I'm talking about is resource tracking. My buddy Karl has written a nice tracking library that tattles on you if you foul up. It's kind of hard to track everything, though... you have to put a wrapper around just about every call you make... The biggest problem with the lack of resource tracking is that you can't easily do a standard UNIX-type shell, because you HAVE to watch all your children so you can close (or not close) their standard input and output file handles when they exit. It's a royal pain. If these were properly tracked, it would not be a problem. > Not to say some resource tracking wouldn't be a bad idea. However, > in a multitasking, lightweight process machine you have to be careful: many > programs pass off resources (permanently) to other processes (or to no one: > public structures, for example.) One can't merely add freeing of resources > on program exit to current programs; they'll break. No, it has to be in the system from the start. If there had been a "release" call, that programs used to let the system know they weren't using a given resource, a lot of things would be easier now. I'm not asking for enhancements, just pointing out some advantages to UNIX. Listening to some people here you'd think there weren't any. > >But in UNIX the program doesn't have to *know* what goes on inside the kernel. > >You have to dig around in internal AmigaDOS data structures to do all sorts of > >vitally important things... like getting a list of devices, an operation that > >comes for free with UNIX. > Hmm, ps seems to know a lot..., and what's the purpose of /dev/kmem, > eh? :-) PS is a special case, which is highlighted by the fact that it's setuid. User programs don't need to mess around in kmem, and in fact don't have permission to. > >Unless you want to port reasonably sophisticated UNIX software, such as > >ASH. > Suprise! AmigaDos is not Unix! It doesn't claim to be. No, but to hear Mike talk all you need is a fancy library. 'tain't so. Mild gritch: > (the fork() and exec() > calls were not given to DMR on a stone tablet). You mean KT, no? > I also don't mean to say all the functionality that should be is > in the current DOS. It isn't. I'm working to correct this; I think you'll > like what you see. :-) Details, details! > Spoken like a true portable Unix application writer. :-) That's me. It's NOT that hard to write programs that run on a wide variety of UNIX systems without a mass of #ifdef spaghetti. > Seriously, most Uni are still using the ancient 'monolithic monitor' model > for their kernel. There are some _small_, hesitant steps away from it, but > not very fast, and not mainstream. Mach isn't mainstream? Ah, just you wait... there are more things in heaven and earth than a dreamt of in your philosophy. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U`