PLEASE READ THIS ONE

[Michael David WINIKOFF]

> 
> Hi Moosers,
> > Can we drop detailed issues and talk about conceptual models for the moment?
> 
> But its much more fun to talk details... :-)

But not as productive ... :-)

> > I'd particularly like Dennis (who has been rather quiet lately) to try
> > and get across his conceptual model.
> 
> :-)  Yep, this is true.  Forgive the silence, I've got some rather stressful
> situations upon me at the moment.  Still working, thinking, eating, and
> breathing Moose, just not being very vocal.
> 
> Here's my ideas: (from the ground up)
> 
> I envision Moose as a flexible operating system.  The heart of it is the
> kernel which takes care of all that stuff kernels are good at: memory and
> device handling, task handling, and nothing more.  This is a pure interface
> to the machine and it must support the concept of an object.  It will not

How exactly? What does supporting the concept of an object mean at this level?

> be all that much different than other kernels except in the way it handles
> the objects...
> 
> The kernel needs to understand what I call modules and libraries.  These are
> identical in definition to Unix modules and libraries: a module contains a
> collection of related functions, data, and objects.  What is different about
> Moose modules is the interface.  All "external" functions, data, and objects
> are included in the interface in exact detail - this includes data types and
> sizes of all function parameters, heirarchy of objects, and so on.  The
> private objects not included in the interface are not directly accessible,
> but everything in the interface is described in enough detail such that
> load-time or run-time linking to a module is possible.

Why do we need to have all the types declared?
The argument here is that an application using a library has to be aware
of the semantics of the object it's using anyway -- if someone wants to
use a different library it'll have to have the same semantics anyway.

(The Amiga's libraries are just collections of functions. The data types
they take and the number of arguments (and which registers to pass them in)
is documented in manuals. 
Usage looks a little like: [Psuedo code]

baseptr_for_somelibrray = open_library("somelibrary.library")
librarycall(arg1, arg2)
/* Typically the C compiler recognises library calls and patches them to use
** the libraryptr and makes use of the right registers.
** One would have to use various data types that are defined in include files
*/

BTW, I'm just raising a point -- in practice you really need the includes
(and to be programming in a C like language) to do things easily ...

[Disclaimer -- I'm not really an Amiga programmer -- yet ...]


> 
> A library is just a collection of modules...nothing special there. :-)
> Maybe an entire library is loaded into memory at once with all references
> between modules predetermined, or maybe modules are loaded one at a time
> and dependencies cause other modules to be loaded.  I don't know - maybe
> this is something which should fall under the next category...
> 
> The most important library in our system will be the system library.  This
> will include functions and objects to make the system useful.  For example,
> a semaphore object might be included here.  Objects to perform IPC would
> also be found here, not in the kernel.  Disk drive object prototypes,
> file system object prototypes, keyboard object implementation, mouse
> object prototypes, memory management objects, and on and on and on.  Not
> all of this has to be done using objects, but why not?  ;-)  This library
> defines the operating system, the kernel is there only to support it.

Yes. I'd argue though for splitting this up.
Have a separate library for (eg.) semaphores , disk, memory management
etc.

> 
> (Some of the above were listed as prototypes, where we would define only
>  "pure" objects with no implementation.  I don't want XXX video device
>   driver in the operating system library even if there's a good chance
>   I'd use it.  Each video device could be implemented as an object in
>   its own library as a descendant of the pure video object.)
> 
> On top of the operating system, most definitely, absolutely, positively
> *not* within the operating system, exists things such as the user
> interface.  Be default, the operating system includes *no* interface!
> Most of us will want one though :-] and I'd prefer to see both text and
> graphics.
> 
> >> Ideally, I'd like to see a well enough designed interface such that
>    a program written for a GUI using buttons, scroll bars, windows, and
>    other GUI concepts could be run without modification and without
>    recompiling under a windowing Text User Interface (TUI).  As long
>    as the GUI version does not use the primitive graphics functions
>    this is entirely possible.
> 
> Overall, I envision a system which is logical and uncomplicated to use.
> The interface to every layer of software is *simple* and *flexible*,
> not requiring (in the case of, for example, X Windows) seven or eight
> books open on my desk at all times to write software with.  Seriously!
> (I do write X software, and I do have this many books to reference...)

Yes -- I agree with this goal .. let's do it! 

> 
> I believe this should be the software designer's operating system not
> the end-user's operating system.  Windows is *great* as far as the
> end-user is concerned, and O/2 2.1 is *even better*.  Really!  But,
> have you ever tried to write a Windows Application?  From my point of
> view, it's not a good programmers interface.  The user interface is
> simple to duplicate and well defined enough that we ought to be
> more concerned with the software interface, which affects issues in
> software development such as development time and frustration.
> 
> Have I said enough?  I could go on for a while yet...
> 
> Hope this has gotten my ideas across - I'll try to be more active
> in discussion now, but I think Michael has gotten an important point
> across which I think we were missing.  The concept is important,
> the details are the easy part...

Once you have the concepts that is ... :-)


The part that I find is still unclear is the role of "objects" in the system.
The rest is a fairly conventional OS -- I'm not saying this is bad, if it 
designed properly (ie. to be simple) it can (and will) be exactly what we want
-- something that's a pleasure to write applics under.

Most of the problems we've had have been with the role of objects.


> 
> Dennis
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.