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 #282303] Sun, 19 January 1986 02:15 Go to next message
dillon is currently offline  dillon
Messages: 81
Registered: November 1985
Karma: 0
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


	
Re: Amiga OS [message #282329 is a reply to message #282303] Mon, 20 January 1986 16:00 Go to previous messageGo to next message
perry is currently offline  perry
Messages: 37
Registered: November 1985
Karma: 0
Member
Article-I.D.: atux01.142
Posted: Mon Jan 20 16:00:33 1986
Date-Received: Wed, 22-Jan-86 05:33:13 EST
References: <11448@ucbvax.BERKELEY.EDU>
Organization: CSEd, AT&T Communications, Piscataway, N.J.
Lines: 28
Summary: unix > amigados, amigados > unix arguments do not make sense

Matt  Dillion  thinks  AmigaDos   is ``total shit'' and believes that Unix
is  the god which all o.s.  must  emulate. Basing his opinions on the that
he professes to be an expert kernel  hacker he thinks all should be thrown
out (except for a few graphics routines)  and we should start again.

Well, Matt, I don't know if you are a Unix expert  and, in fact, your exp-
ertise in operating system X doesn't really bear upon the argument at hand.
Unix is not Tripos.  And  similarly, Tripos is not Unix. I think your views
are too restrictive  (read that  narrow minded).  The  answer to statements
like ``Unix is  great   because...and  AmigaDos  is  shit  because...'' are
senseless and without worth. The two  operating  systems  address different
needs.

Maybe you are a UNIX  expert,  Matt, but you definately are not an AmigaDos
expert. In many ways,  the  kernel  underlying  the  nifty imagery, possess
truely state-of-the-art concepts in operating system design. You'd see that
too if you'd not look through Unix colored glasses.

---------------

No personal aspersions intended here nor do I believe any were cast.

And, I don't know why you couldn't get in a disk access while other processes
were going on - but I'd suggest it was something you were doing wrong since
examples of doing just that abound - like running musicraft while copying
or formatting disks.

Perry S. Kivolowitz
Re: Amiga OS [message #282337 is a reply to message #282303] Mon, 20 January 1986 16:00 Go to previous messageGo to next message
fnf is currently offline  fnf
Messages: 39
Registered: May 1985
Karma: 0
Member
Article-I.D.: unisoft.9
Posted: Mon Jan 20 16:00:23 1986
Date-Received: Thu, 23-Jan-86 08:43:04 EST
References: <11448@ucbvax.BERKELEY.EDU>
Reply-To: fnf@unisoft.UUCP (Fred Fish)
Organization: UniSoft Systems; Berkeley, CA
Lines: 20

In article <11448@ucbvax.BERKELEY.EDU> dillon@ucbvax.BERKELEY.EDU (Matt Dillon) writes:
 > 
 > with the base standard I/O and execute functions built into the OS rather
						  ^^^^^^^^^^^^^^^^^
 > theoretically have your own RAM: device, but they would have best
 > been placed in the kernal rather than as separate processes.  The
      ^^^^^^^^^^^^^^^^^^^^
 > 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()
           ^^^^^^^^^^^^

Caution, your Berkeley orientation is showing through.

ls -l /vmunix
-rwxr-xr-x  1 root       308224 Jan 13 20:03 /vmunix*

Lets not shovel everything into the kernel just because it's there.

-Fred
Re: Amiga OS [message #282350 is a reply to message #282303] Tue, 21 January 1986 13:45 Go to previous messageGo to next message
mykes is currently offline  mykes
Messages: 45
Registered: January 1986
Karma: 0
Member
Article-I.D.: 3comvax.366
Posted: Tue Jan 21 13:45:47 1986
Date-Received: Thu, 23-Jan-86 21:28:37 EST
References: <11448@ucbvax.BERKELEY.EDU>
Reply-To: mykes@3comvax.UUCP (Mike Schwartz)
Organization: 3Com Corp; Mountain View, CA
Lines: 64


As someone relatively new to both Unix and AmigaDos, I have found that
the similarities are very strong.  However, at deeper levels, Unix and its
10+ years of maturity is better polished.  However, Unix programs require
MUCH MORE TIME to learn because the source programs have ZERO comments,
and the function names are very short and not very mnemonic.  AmigaDos
has some of the best written documentation I have ever seen, although it
is not always accurate (I expect the documentation will be more accurate
in later versions).

The source code and header files for AmigaDos are excellent, although
verbose.  My opinion is that I would rather read the comments, then strip
them away, then to not have them at all.  The names of all the Amiga
functions are very descriptive of their function.  

I see the Amiga as an attempt to set a new standard in Personal Computers,
not as some compromise between old technology and new.  The hardware is
so unique (no other PC has the same standard features), that the operating
system was required to use all of the features of the hardware (something
that UNIX does not do due to its generality).  

The ROM KERNEL seems to contain the proper components to create excellent
video games and simulations.  The device drivers seem to be a combination
of two designs that not all drivers seem to adhere to.  For example,
I have used CreatePort() to create message ports for serial IO, but not
for the Narrator device.

AmigaDos is a 68K operating system that was written by MetaComco.  It
consists of a library, the CLI, and all the other misc. programs that
run under it.  99% of the criticism seems to revolve around this piece
of code.  However, on a large machine (8MB, Hard Disk), I imagine that
things will be quite tolerable.  However, on a 512K machine, I think we
all feel a need for some elbow room.  Also, the floppies are just too
slow to use with Lattice 'C' in a friendly manner.

I agree that there is a lot to learn from an OS like Unix, but I don't
care if the Amiga software has nothing in common with it.  People keep
saying "I wish it were more like Unix..." or "I wish it were more like
OS-9...", which immediately indicates some amount of bias towards Unix
or OS-9 (to me) and not a constructive point toward the Amiga stuff.  Don't
forget that all the boys at Amiga have Sun Workstations running Unix, and they
write some gorgeous looking 'C' code, and they are not blind to the operating
system that drives the Sun!

My approach to dealing with the inconsistencies of the operating system was
to build an interface to it more to my liking.  I have built a library that
has routines like rs232_open, rs232_getc, scr_open (open window), scr_putc,
etc., which are simpler to call and reduces the number of header files and
initialization code (very lengthy stuff) required from program to program.
This solution also makes my programs a little more portable, since I am
only required to rewrite these routines instead of writing OpenWindow, et al.

I view the Amiga and its software as being immature.  Given a chance, the
machine will be a new standard.  AmigaDos sure beats the heck out of MS-DOS
(as far as programming it goes), and its multi-tasking gives it a unique
look in the PC market.  In a couple of years, the best of Unix will be ported,
and the worst of AmigaDos will be improved and people will rave about it like
they do OS-9 and Unix.

I do not have any direct experience with the Mac or ST, but I don't imagine
that their programatic interfaces are anywhere near as easy to use as the
Amiga's.  I see very little technical information (yet alone programs)
being posted to net.micro.atari, and the Mac has long had a reputation as
being a tough machine to learn.
Re: Amiga OS [message #282351 is a reply to message #282303] Tue, 21 January 1986 15:32 Go to previous message
hamilton is currently offline  hamilton
Messages: 57
Registered: May 2013
Karma: 0
Member
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
  Switch to threaded view of this topic Create a new topic Submit Reply
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: Wed May 18 08:55:06 EDT 2022

Total time taken to generate the page: 0.00754 seconds