Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!dillon From: dillon@ucbvax.BERKELEY.EDU (Matt Dillon) Newsgroups: net.micro.amiga Subject: Amiga OS Message-ID: <11448@ucbvax.BERKELEY.EDU> Date: Sun, 19-Jan-86 02:15:22 EST Article-I.D.: ucbvax.11448 Posted: Sun Jan 19 02:15:22 1986 Date-Received: Mon, 20-Jan-86 05:24:21 EST Organization: University of California at Berkeley Lines: 125 Time to start a new discussion. What do all you C programmers think about the OS? Now that I have had a chance to get into it, I have some comments I would like to make. First of all, for programming ease, the Amiga OS is total shit when compared with UNIX. Not only are no checks made on input parameters, but the OS itself isn't very robust. I have noticed, for instance, that if you give DoIO() bad parameters, or even simply call BeginIO() without doing an AbortIO() (mainly the serial port) when there was something else going on, the Serial port device driver gets lost and crashes the system. The OS doesn't keep track of what your process is doing, and thus you must FreeMem, CloseLibrary... etc... everything you opened before you exit, or those resources will be lost forever. This means, of course, that the Amiga cannot simply KILL a process (as someone suggested as an improvement). Many simple operations on the Amiga take many more lines of code than they should. For instance, openning windows, screens, or simply attempting to get SOME control over the serial port takes mucho code which goes very deep into the OS. This coupled with the instability and lack of error recoverability in the OS makes for quite a few machine crashes. The generalized I/O concept on the Amiga is too complex. To have any control over a resource (screens, windows, serial port), you are required to include GOBS of files, make innumerable system calls; and although these give you full control over the resource in question, they are generally very slow, and not fully implimented. The filesystem (basis for quite a lot), is a good example. The lack of IOCTL()s is very apparent. It looks as though the generalized Port() replaces that elegant call. There is no truncate() (or did I miss something??), nor is there an easy way to pass file structures around. The Execute() utility requires c:run to exist (a definate no-no), and the standard input/output devices are the exception rather than the rule. The programmer is required to delve deep into the Operating system to do a simple 'Change Directory', and even processes have distinct special cases. In my opinion, the CLI should have been more like CSH, with the base standard I/O and execute functions built into the OS rather than the CLI. Having easily changeable devices is nice, and you could theoretically have your own RAM: device, but they would have best been placed in the kernal rather than as separate processes. The Amiga OS is NOT a real-time operating system. (I'm sorry, it just isn't). I had one process running continuously, doing lots of system calls, and a seek on the disk took... well, to put it bluntly, it didn't happen until I killed the process. Such things as disk and serial I/O should have been completely interrupt driven. Not only would everything speed up, you would get a cleaner system. For those of you who have knowlege of the 4.2BSD kernal, or another UNIX like kernal, you would appreciate what has been accomplished. The basic idea is 'multi tasking user proceses, single tasking kernal', with everything interrupt or timer driven. As an example, the 4.2 kernal's device drivers may request they be called in 30 seconds, or 1/30 of a second (device driver's aren't seperate processes, but they can get service at time intervals). The reason you get much better throughput with this scheme, is that there is no idle time wasted. If something in the kernal blocks, the OS simply sleeps itself (allowing other processes to run) until the resource is freed. Thus, the device driver is driven both by low-level interrupts, and by calls to it by the kernal requesting read's, write's, ioctl's, etc... That is the way I would have liked to see the Amiga kernal, but Alas, it was not to be. --Going back to the filesystem-- What I miss most in the Amiga is the lack of a SELECT() system call, and easily implimented NON-BLOCKING I/O, plus a slight enhancement of the Read() system call. The call should return whatever is available rather than wait till the entire buffer you specify is full. File operations should be considered 'non blocking'. This is what UNIX does. I realize there is a comparable Wait() call for the Amiga, but it isn't generalized AT ALL. SELECT() is. You select on file descriptors, period. with Wait(), you have to dig into the OS. The ':' base (in addition to file path's) are a nice combination, but the directories should have implimented '.' and '..'. Additionaly, the directory entries are way too large. I tend to guess that almost no thought was given to them... tell me, a COMMENT entry??? say what? -------- ICONS ----- Graphics in general Of course, the HARDWARE is fantastic, and in fact the one major reason I bought my Amiga. The graphics support routines are excellent too. However, they are not generalized enough at the programmer's end, and check almost nothing about the validity of the data they are processing. I get the feeling that who-ever designed the Amiga OS didn't have much experience with multi-tasking or High Level languages. Apart from the PASCAL like style of all the include files, and the PASCAL like style of the basic Open() function, I would tend to want to throw every .H file away and re-write them. ---- But the Amiga people are to good to have created some of the things I have seen. What happened??? By the look of it, somebody but the bolt on the entire system... not allowing any major design changes after the first prototype was got working (and I'm talking internal prototype's... with release still years away). Could somebody shed some light on this? --- LIBRARIES, etc... The concept of libraries is not new. My complaint on their usage on the Amiga is simple: The intuition library should not be a library. The graphics library should not be a library. They should have been system calls. The programmer should not have to OpenLibrary() them, period. There are way too many programmer-"required to know about and use" structures. The system calls should have been implimented on a much higher level. Welcome to the world of OS-design, -Matthew Dillon