PLEASE READ THIS ONE far18

[Francois-Rene Rideau]

>> Hi Moosers,
(bis)
">>" is Dennis, quoting ">> >" Michael.

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

I think Michael hit the spot again: we grouped because each of us sought
something new that lacked in existing systems; something that is deeper than
just how systems are implemented; something that touches system philosophy.
If not, the solution would just be "buy a new, more powerful, computer", and/or
switch to unix (there's linux and BSD available on cheap 386 PCs).

>> :-)  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...
(That may be a valid definition of the kernel; then our micro-kernel/no kernel
discussion may be about the kernel's kernel :-)

>> 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. :-)
 Hey ! libraries are collections of modules, modules are collection of objects.
Why have this cumbersome terminology ? Let's have only objects as system
basic idea. Modules will naturally arise, and the simplest is the system base
concept, the better, and the more beautiful and intellectually satisfying
(again, remember to follow the Tao of Progamming).
 But for that, I agree objects can't come alone, and heavily linked objects
will be grouped in modules, then libraries and so on; be even libraries are
linked to external programs, etc; for unlinked objects are of no use (even
unix terminology use the link/unlink scheme).

>> 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.
 Why create this arbitrary library ? Let's group objects as they are programmed:
when strong links appear, group the objects. Grouping should again arise
naturally.

>> (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.
I totally agree; however, standardization in UI's would be very nice, and
a system without application is unusable.

>> >> 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...)
No book at all would be great. For example I love Borland programs' internal
help, and I learned Pascal without a book, only with help and examples; I
had to look only once in a book to learn C (for function pointer declaration),
and sometimes for C++ (but this was before Borland C++).

>> 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,
I wouldn't say that: you can't do anything. It's an interface to nothingness !

>> 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.
It's so complicated no one even at Microsoft can understand it all, and
why it was implemented that way. It's only bad stuff added on bad stuff, etc,
each time to go round bugs and misses in previous versions.
To avoid such things, the system should be naturally extensible; it should
provide high-level as well as low-level standards, but not horribly mixed
together; there should be a standard extensible description for generic objects
so that we won't need a hack to add a feature to the system.
If it is well done, the basic system will never have to be written again, but
to optimize it on a new hardware implementation.

>> 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
   ,
Fare