Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!swrinde!ucsd!ucbvax!pasteur!cory.Berkeley.EDU!navas
From: navas@cory.Berkeley.EDU (David C. Navas)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: Amiga OS *IS* state of the art
Message-ID: <12390@pasteur.Berkeley.EDU>
Date: 2 Apr 91 17:52:17 GMT
References: <1003@cbmger.UUCP>
Sender: news@pasteur.Berkeley.EDU
Reply-To: navas@cory.Berkeley.EDU
Lines: 74

In article <1003@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes:
>And talking about such similar operating systems, another parallel
>comes to my mind: Geoworks Ensemble for PCs. You know, this stems
>from the people who made GEOS for the C64 which already in those
>times provided tremendous performance when considering the
>underlying platform. Now the same has obviously happened to the

Well, I helped write that package and no longer work for them, so perhaps I can
give you a good but impartial opinion.  Fat chance, but...

Ensemble is faster because it is smaller.  IE -- the thing doesn't page to disk
every half a second.  Also because it doesn't have to cozy up to DOS for *any*
of it's internal programs, except for disk access...

Ensemble is smaller because it has an extremely well thought out kernel that has
everything from DOS interfaces (which the Amiga has) to general fast WYSIWYG-
capable string "gadgets" (which the Amiga doesn't have).  As an example, open
up those HELP boxes -- the multiple style'ed text inside a scrolling region
is *one* text object.  The system takes care of the scrolling, text display,
etc.  It is sad, but true, that the interface is better defined than the
corresponding Amiga interface.  It's loads richer too... :(

>similar principles as the Amiga OS, mainly the object-oriented
>data structures and system calls.

GEOS is written in an object-oriented assembly language.  We're not just
talking about a quais-object-oriented system like the Amiga.  

>As GEOS is of nearly the same
>age as Amiga OS, you cannot say they took ideas from Amiga OS,
>but they followed the same ideas as our guys.

There are some very good ideas in GEOS that can't be found in the Amiga.
Device independence comes to mind.  There are others I'm probably not allowed
to discuss.

>This all leads me to the conclusion that examples of this kind
>demonstrate that Amiga OS is well up with the current state of
>the art in OS design. Ok, there also exist newer developments,

The Amiga's OS has serious defficiencies, and serious advantages.  However,
there is far too much redundant, multiple-interface stuff which leads not
only to a horrible programmer-interface, but to a huge kernel as well.
Fortunately most of it's in ROM...

As an example, think of how you'd develop a CLI utility, and then develop the
same utility for workbench.  Question, why are they different?  Because they
reach different audiences or because dealing with workbench and tooltypes is
so vastly different than dealing with CLI line arguments?

Even 2.0, which is at least advancing the idea of TAGS seems to have a bunch
of parsing code duplicated in commodities and DOS, etc. etc.
Why do we have THREE separate ways to create gadgets -- Gadget/boopsi/GadTools?
Why can't we have ONE call that creates/destroys ANY system structure?

   IE: rastport = CreateSysStruct(CSS_RASTER);

I know why Exec *didn't* have it's structures protected by semaphores -- why
doesn't it now?  Stick the Semaphores in the Library structure for crying out
loud if you have to.  Of course, some structures you just *don't* want to
use Semaphores for... :).


And the beat goes on.

>but I'm confident that the open
>design will leave enough room for further development and
>keeping track with new ideas.

Let us all sincerely hope so :)

David Navas                                   navas@cory.berkeley.edu
	2.0 :: "You can't have your cake and eat it too."
Also try c186br@holden, c260-ay@ara and c184-ap@torus