Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Archive » net.micro.amiga » Amiga OS
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Amiga OS [message #282354] Wed, 22 January 1986 09:56
mwm%ucbopal is currently offline  mwm%ucbopal
Messages: 5
Registered: January 1986
Karma: 0
Junior Member
Article-I.D.: caip.1063
Posted: Wed Jan 22 09:56:54 1986
Date-Received: Thu, 23-Jan-86 22:05:35 EST
Sender: daemon@caip.RUTGERS.EDU
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 264

From: Mike (I'll be mellow when I'm dead) Meyer 

Seems that whenever people start discussing OS's, and what's good
and/or bad about them, they forget that they are talking about at
*least* three different things: the OS proper, as seen by systems
hackers and sysadmins, the interface for programming language X, and
the user interface.

For example, when Matt Dillon complains about the following:

 >  From: dillon@ucbvax (Matt Dillon)
 >  	One should not need so many include files for simple programs.  Why
 >  weren't the generic Read() and Write() routines given these options?  Also,
 >  I am quite sick an tired of having to write 40 lines of code just to simply
 >  read all the character's currently in the serial buffer, and NOT block when
 >  there aren't any (or the buffer isn't full... yucc)
 > 
 > 	Further gripes:  The signalling was done wrong,
 > 			 The Screen/Window routines are not generic enough,
 > 			 The Wait(), message, and packet protocols are all
 > 				wrong.
 > 
 > 	P.S. generic: On the Amiga it takes 40 lines of code to do things
 > 	(Like non-blocking I/O) which takes 2 lines of code (an open() and
 > 	an ioctl()) on UNIX systems.
 > 
 > 	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.
 > 
 > 	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.

He's actually complaining about the C language interface. Since
TRIPOS/AmigaDos wasn't writtin in/for C, it's only to be expected that
that interface won't be as nice as the Unix/C interface. Then again,
it's nicer than the Unix/non-C interface for most languages on Unix.
At least you can do non-blocking I/O in C on the Amiga.

Since TRIPOS is written in/for BCPL, I suspect that the BCPL interface
is *much* nicer than then C interface. Given that BCPL has an easy,
natural way of using library-like facilities, the code should be
smaller (the BCPL stdio equivalent should be in a library). Commodore
should release the BCPL compiler so that people who want to do systems
work can use it.

I haven't been fighting the Amiga long enough to really comment on the
C/AmigaDOS interface. I will note that the problem with the include
files appears to be something broken in the C compiler. A program that
uses nothing but the things in intuition.h has to have other things
included to work.

On the other hand, the following things are "problems" with the OS
proper.  These, I'll comment on seperately.

 > 	Calls like Open, Close, Rename, Delete file, etc... should be syscalls.
 > 	Ports, Device driver calls, and specific device I/O calls should NOT.
 > 	They should have been implimented through Open.  Now you know why UNIX
 > 	is based on "The File Descriptor"; you've screwed yourself by not
 > 	taking that into consideration.

Nope, TRIPOS is built around processes, not files. This is actually
*better* than using files, as you get IPC, remote file systems, and
other things that people have been kluding into Unix for the last five
years for free. In fact, they were in the original PDP-11 TRIPOS.

 > 			 The multi-tasking was done all wrong.  Not only are
 > 			  tasks defined fuzzily (and this goes along with
 > 			  the signal structure), but the OS does not have the
 > 			  ability to kill a task and release it's resources.
 > 			  Additionaly, most of the devices should NOT have been
 > 			  done as tasks.

The inability to kill a task is a real problem. Tasks being fuzzy is a
minor problem, related to the way pieces of processes interact. It
could have been done better (witness OS/9). The device drivers *most
definitely* should have been done as tasks. Since you don't have
files, but tasks, there really isn't any other way to do them. And the
win from making them tasks is enormous - dynamic system
reconfiguration, remote device access, etc.

 > 	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 - you mean that BSD-specific system call that takes arguments
that change meaning with different devices? Not exactly elegant. Of
course, you can't be sure that something like ioctl (only better, one
would hope) exists in the interface for the systems language for
TRIPOS (BCPL).

 > There is no truncate() (or did I
 > miss something??), nor is there an easy way to pass file structures
 > around.

You truncate files just like you do on all Eunices except 4.[23]BSD.
And of course, you don't want to pass file structures around, you wou
want to nt to pass ports around.

 > and the standard input/output devices are the exception rather than
 > the rule.

Huh? Most eunices don't have /dev/stdin or /dev/stdout, either. Or do
you mean the ability to redirect stdin and stdout?  That's a problem
with the user interface, *not* the OS.

 > 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.

CLI does have problems. I'd prefer ksh myself, but tastes differ. At
least it isn't tied into the OS, like so many systems are wont to do.

 > 	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.

But then you couldn't even theoretically write your own - at least not
without being able to relink the kernel. Nor could you put it on a
seperate TRIPOS system over a high-speed link.

 > 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.

So? Aren't many multi-tasking OS's that run on micro's that *are*.
'Bout the only one I can think of is OS/9, and that's because someone
worked real hard to make it one. Of course, your example makes it seem
like you mean TRIPOS isn't multi-tasking, which is false.

 > 	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.
 > 
 > 	That is the way I would have liked to see the Amiga kernal, but
 > Alas, it was not to be.

And if they'd done that, AmigaDOS would have looked like 4.3: two
large, ugly, monolithic monitors with lots of screwy interactions,
both internally and with each other. As it is, you should have a
collection of processes that communicate over clean interfaces, and
little or no unexpected interactions. The monolithic monitor vs.
communicating processes for the kernel is a religious issue on
uniprocessor systems. Of course, since I have the "right" religion, I
*do* appreciate what has been accomplished with TRIPOS :-).

 > --Going back to the filesystem--
 > 	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.

I think you're once again tripping over ports vs. file descriptors.
From what I recall (manuals not handy), you select on *ports*. Since
these fill the place of Unix file selectors (except better), this is
correct.

 > 	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?

Much of the niceness associated with the ':' base comes from having a
forest instead of a tree. I still haven't decided if the convenience
of being able to say ':' to get to root of the current device outwieghs
having yet another magic character in filenames.

Also (once again, unless I'm mistaken), those aren't *directory*
entries, they are file headers. I haven't delved to deeply into them,
but I suspect that I can find usefull things to do with the COMMENT
entry. Think of it like the user bits in the CP/M dir structure.

 > 	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.

I get the feeling that you're wrong. I get the feeling that whoever
did the C interface to everything didn't etc. Then again, C is a
high-level PDP-11/Unix assembler, so that's not unexpected.

 > 	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?

Since AmigaDos is TRIPOS underneath, it dates back to *at least* '79,
and I think it actually dates back to the early '70s (I couldn't find
the paper I *wanted* on TRIPOS). Most of your complaints are actually
with TRIPOS, not AmigaDos (of course, I still haven't figured out what
Amiga changed in TRIPOS), which, like Unix, came out of a research
environment. I suspect that it went through as much development as
early Unix, and the developers were probably quite happy with it. Me,
I'm glad to see TRIPOS out in the real world. Maybe we *won't* be
stuck with Unix on micros through the '90s.

 > 	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.

You're right, libraries aren't new. They predate Unix. On the other
hand, you couldn't be more wrong about wanting them in the library.
Unless your operating system is so primitive as to *not* have
something like libraries (shared library code, that is), the *only*
reason to put something in as a set of kernel calls instead of a
library is because it's got to be in place for the system to run
anyway.

You're right that a programmer shouldn't have to OpenLibrary() things.
The problem there is with C (maybe just the Lattice implementation),
not TRIPOS. If C supported dynamic linking in a reasonable way, this
problem would go away.

 > 	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.

You're now facing the problem of wanting either high-level semantics,
or lots of control. For instance, consider the problem of getting a
raw interface to the console. On AmigaDos, you can do it with the
open(), no pain involved. On Unix, you have to "know about and use"
magic structures (whose name depends on which Unix you got). On the
other hand, Unix gives you more control than the AmigaDos Open.

Me, I don't find dealing with windows on AmigaDos any worse than
dealing with sockets on Unix - actually a little nicer, because I have
fewer structures to fool with.

 > 	Solutions, anybody?   I think I'm going to re-write the OS.
 > 
 > 					-Matt

Unless you're going to redo the whole package (intuition and graphics
library), I wouldn't bother. In either case, I'd wait to see what the
OS/9 port to the Amiga looks like. Since OS/9 combines the best
features of TRIPOS and Unix, it could be a real winner.

Last random comment: Someone was considering hacking up a version of
libraries that were executeable, ala OS/9. As they said, this is *far*
better than the ram: device. Even better would be to make use of the
track-at-a-time disk driver, and tweak the disk device to grab as much
buffer space as it can get to use a a LRU track cache. It would have
to catch memory request to free the stuff as needed, of course.

	  

		
		
		
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: Re: (Orphan) Re: New Amiga Basic
Next Topic: Mandelb 2.01 Problem?
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Fri Mar 29 09:59:28 EDT 2024

Total time taken to generate the page: 0.00312 seconds