Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles $Revision: 1.7.0.10 $; site uiucuxc
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!inuxc!pur-ee!uiucdcs!uiucuxc!hamilton
From: hamilton@uiucuxc.CSO.UIUC.EDU
Newsgroups: net.micro.amiga
Subject: Re: Amiga OS
Message-ID: <148600037@uiucuxc>
Date: Tue, 21-Jan-86 15:32:00 EST
Article-I.D.: uiucuxc.148600037
Posted: Tue Jan 21 15:32:00 1986
Date-Received: Thu, 23-Jan-86 21:50:59 EST
References: <11448@ucbvax.BERKELEY.EDU>
Lines: 130
Nf-ID: #R:ucbvax.BERKELEY.EDU:11448:uiucuxc:148600037:000:6920
Nf-From: uiucuxc.CSO.UIUC.EDU!hamilton    Jan 21 14:32:00 1986


>	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.
>The generalized I/O concept on the Amiga is too complex.
	back in the early days of unix, the only i/o you had was read()
and write().  in order to do buffered, "stream", i/o, you needed GOBS of
code.  so somebody invented the portable i/o library out of the existing
primitives.  compare this to pascal which gives you high-level i/o, but
no chance to roll your own.

>	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.
	ioctl()?  elegant?!

>The programmer is required to delve deep into the Operating
>system to do a simple 'Change Directory',
	Lock() and CurrentDir() are no "deeper" that open() and chdir().
it's true that you need to do a Lock() followed by a CurrentDir() to
effect a chdir(), but compare what you have to do to find the name of
the current directory!

>	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.
	why?  what difference does it really make whether the devices
are distinct processes or interruptable co-routines of a single kernel
process?  elsewhere you complain that devices and libraries don't do
what you want; the way things are set up, _you can write your own_.
you can even switch in mid-stream without re-booting!

>The
>Amiga OS is NOT a real-time operating system. (I'm sorry, it just
>isn't).
	how do you figger that?  what does a realtime OS have to have
that exec doesn't?

>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...
	??? so what does this have to do with the amiga?  amiga devices
(at least, the serial device i've studied most) are also interrupt
driven.  it's almost SCARY how interrupt-driven the amiga is.  have you
looked closely at the "interrupt server" concept?

>File
>operations should be considered 'non blocking'. This is what UNIX does.
	no, this is what some unixes let you do; i used unix for years
without non-blocking i/o.  typical file processing doesn't need to be
asynchronous; unless you're going to the trouble of multiple-buffering,
it doesn't do any good.  but, if you really want it, it looks to me like
it's there, it's just not handed to you on a platter.
	[later] upon re-reading this, it occurs to me you may be thinking
amigados/exec itself is doing i/o synchronously?  that while a disk block
transfer is in progress _everything_ else comes to a halt?  well, not on _my_
machine.

>	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.
	Wait() is not generalized, but select() is?!  c'mon!  select()
works ONLY on file descriptors; Wait() works for any event that posts a
signal, and since you can post those signals yourself, it's open to your
imagination what you can Wait() for.  Wait() combines the functions of:
select(), signal()/setjmp(), wait(), pause() and probably a couple others.
i can't think of a _more_ general function.

>	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?
	they do; "/" is "..".  i admit to not liking the way the amigados
inverts a lot of my (unix) habits.  sometimes i wonder if they deliberately
sowed landmines for unix freaks.  the COMMENT capability is actually a
useful touch.  besides the canonical describe-the-file, i can see using it
to contain arbitrary out-of-band data about a file.  for instance, i miss
having BOTH creation and modification timestamps.  think of it as a
programmer-accessible part of the "inode".

>	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.
	i completely disagree.  i think the library concept is very
nice.  it's interesting that you say this after expressing your preference
for unix, since many of us unix users have wanted a dynamic library
capability for years.  as for the inconvenience, if you hate it that much,
write your own library interface that opens and closes libraries on the
fly (the way getpwuid() opens /etc/passwd).

>	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.
	that's the price of flexibility.

	most of your comments boil down to "dammit, they didn't do it
like unix".  i've been using unix for 10 years, and much as i like it,
i'm willing to try other approaches.  the priority given to message
passing over procedure calls, for example, is still very new to me.
it'll take some time to adjust.  i do miss a lot of features of unix,
particularly with respect to the file system.  however, it seems to me
that the file system has been seperated from the rest of the OS to the
extent that you can have more that one.  if it becomes important enough
to me, i'll try writing my own file-handler task.  by the way, i notice
i have more trouble with amigados than with exec.  the one thing i will
unreservedly pan is this damn BPTR/BSTR nonsense.

	wayne hamilton
	U of Il and US Army Corps of Engineers CERL
UUCP:	{ihnp4,pur-ee,convex}!uiucdcs!uiucuxc!hamilton
ARPA:	hamilton@uiucuxc.cso.uiuc.edu
CSNET:	hamilton%uiucuxc@uiuc.csnet
USMail:	Box 476, Urbana, IL 61801
Phone:	(217)333-8703