PLEASE READ THIS ONE

[Dennis Marer]

Hi Moosers,

> The reason, I think, is that we don't have a common conceptual image of
> what the system should end up being.
> 
> Different people's proposals suggest different systems -- everything from 
> an OO based application sharing layer sitting above a conventional hardware
> abstractor through a small single user Unix to a distributed multi user 
> system.
> 
> Can we drop detailed issues and talk about conceptual models for the moment?

But its much more fun to talk details... :-)

> I'd like everyone to stop and think about what type of system they'd invisage
> MOOSE as -- how would you summarise it's ESSENCE?
> 
> Then try to explain your view to everyone else.
>
> 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
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.

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.

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

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

Dennis