Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!amdcad!lll-crg!caip!daemon From: mwm%ucbopal@BERKELEY.EDU@caip.RUTGERS.EDU Newsgroups: net.micro.amiga Subject: Re: Amiga OS Message-ID: <1144@caip.RUTGERS.EDU> Date: Fri, 31-Jan-86 20:40:00 EST Article-I.D.: caip.1144 Posted: Fri Jan 31 20:40:00 1986 Date-Received: Sat, 1-Feb-86 21:39:42 EST Sender: daemon@caip.RUTGERS.EDU Organization: Rutgers Univ., New Brunswick, N.J. Lines: 126 From: Mike (I'll be mellow when I'm dead) Meyer rb@ccivax says: >A simple unix application may require say, 8 lines of code to say >"hello world". An operating system that requires 10 includes, 200 lines, >and 60 parameters, reguardless of how they are structured, to open a >file, and print a string to it, will cost more to maintain than in an >operating system that requires six lines like: > >main() >{ > char *message="hello world"; > fd=open("window1",1); > write(fd,message,sizeof(message)); >} Ok, here, for your edification, is a simple program that opens a window, prints "hello world", and then waits for you to hit return and exits. I used the text above with the following changes: 1) Declared fd. 2) Declare message as an array, instead of a pointer. That way, sizeof will report the length of the string, instead of the length of the pointer. 3) Made message static, so that it could be initialized. 4) Changed the open call to use AmigaDOS names & numbers. 5) Added a read so the window didn't disappear. char message[]="hello world"; main() { int fd ; fd=open("CON:10/10/200/100/Window1",1006); write(fd,message,sizeof(message)); read(fd,message,sizeof(message)); } Note that it takes 8 lines, 0 includes, and exactly as many parameters as the Unix version above. Also note that this is *not* code to emulate when writing C. The second flag to open should be picked up from an include file, the open and write calls should have their return values checked, and fd should be declared as a type from an include file somewhere. It does, however, resemble much of the code to be found in Unix utilities. Now, about Unix device drivers: > The ability to add new DEVICE DRIVERS to a running system. With Unix, >you have to re-link the entire operating system kernal to add a new type >of device. You can mount any number of iterations of that device type >via the mount command but you can't mount a new device. Intuition? This reminds me of dBase-II, being that which bilge pumps suck. Each Unix device type has a driver, and those drivers have some data elements that are allocated at compile time, one per iteration of the device. Hence, the maximum number of copies of the device that can be added is fixed at compile time for the driver. The mount command has nothing to do with adding devices to a system. It's used to add a file system on a random-access device to the file system tree. AmigaDOS doesn't have such a beast, since it has a forest instead of a tree (this is a win). Now, on to AmigaDOS: >Only what you need is in core. Unix has drivers for things that haven't >even been invented yet just to take up kernal space. Outside of the >file manager, you only mount what you really need. What about intuition? AmigaDOS looks in a known directory for drivers, and loads them when you access the device. Unix, on the other hand, chews up the same amount of memory for each device, whether it's physically attached to the system or not (exception: some Eunices crash if a device configured in the kernel isn't on the system). I should explain what the mount() call really does, but suffice to say that mounting a file system doesn't change the amount of kernel space used one wit. >Matt's article was actually quite useful and valuable. I believe his primary >point was that AmigaDos is not what he considers a "Programmer Friendly" >operating system. This is a very legitimate concern, because it is very >hard to get a lot of applications software written for a system which >requires "wizard level knowledge" of the interface. I disagree. Applications don't appear on a machine because it is easy to write software for it; applications appear on a machine because people think there are going to be a lot of those machines. Witness the IBM-PC and MSDOS. Are you going to argue that that's a "programmer friendly" environment? On the other hand, consider Unix. Almost any non-trivial application requires "wizard level knowledge" of the interface (assuming you're writing in C - other languages can't get to that interface at all). But Unix is a primitive OS, so it has a simple interface, meaning that applications are easy to write. Oddly enough, no applications showed up on it for the first 10 or more years of it's life - because there wasn't a market for them. The people who developed Unix were working on a system for their own private use, and had no concerns other than making it easy to write programs for it. The people who developed AmigaDOS were developing an OS for a system that they were planning on selling to make money off of. There first concern shouldn't be making it programmer friendly, it should be making it *user* friendly. I think they did a good job. If you go back over Matt's complaints, you'll find that most of the accurate ones have to deal with the interface between C and the libraries it uses. This interface should be fixed in later releases. For the early releases, worrying about it instead of the user interface is silly; what percentage of Amiga's are going to be sold to programmers if it's going to succeed? To summarize: yes, the Intuition interface is hard to program. However, if you stay inside the CLI interface, it's about the same as Unix v7. On the other hand, Intuition is user friendly, and AmigaDOS itself is easier for naive users than any "standard" Unix shell (csh, sh, or ksh). I've been saying for over 5 years that Unix should be trashed in favor of something else. AmigaDOS provides the same level of expert-friendlyness as the Eunices that existed then. It also shows *much* more user-friendlyness for non-expert users. AmigaDOS wouldn't be a great successor for Unix. But it's adequate.