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 
Return to the default flat view Create a new topic Submit Reply
Amiga OS [message #282303] Sun, 19 January 1986 02:15 Go to previous message
dillon is currently offline  dillon
Messages: 81
Registered: November 1985
Karma:
Member
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


	
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Re: 1) BASIC bug and Commodore / Response (~100 lines long)
Next Topic: Re: COMSPEC ... Warning: Somewhat commercial
Goto Forum:
  

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

Current Time: Thu Mar 28 07:26:29 EDT 2024

Total time taken to generate the page: 0.02766 seconds