Moose specs: Revision 0!

[Francois-Rene Rideau]

 Hello, happy MOOSERS (or whatever we are) !
 Here are my 


>> 	Here it is.  After many weeks of waiting, I can finally send to you
>> the specifications for the Moose operating system project...revision 0, of
>> course!  Actually, this is more of a revision -72, as it has *tons* of work
>> left to be done on it. [...]
 I agree with revision -72.

>> -------------------------------------------------------------------------------
>> 
>>                      Moose Operating System
>>                      Initial Specifications
>>                        Revision 0, 2/8/93
>> 
>> 
>> I. General Specifications

 Well, I've read your first specifications. I must agree with most of it, as
you explained how to take the best from the intel 386 processor to build an
operating system. But I think your mixing up the 386 implementation with the
system itself.
 If we are to rewrite a system (and moreover, if it is to be ported to many
platforms, including 680x0 based computers), we musn't define it frome
its particular implementation on machines we have mainly because of economical
issues. I think we must define the system from high-level, and then use the
hardware the best we can to implement it; else, we will have a DOS-like
hardware-level system, which we will have either to abandon or to be
compatible with when we will want to improve it.
 DOS is directly programmed with 8088 assmebly language; Unix is programmed
with C; MacOS is OO styled programmed with Pascal. In every case, the system
and the language are thought together, and each adapted to the other.
 It will be the same with MOOSE. Whatever language you choose to program
with (I mean high-level stuff, not the Kernel, which is bound to be mainly
done in assembly), it with shape your system. If you don't choose any
language, the default will be assembly, and you'll be as unportable and
unimprovable as DOS. If you choose C, you won't do better than U*ix. Perhaps
C++ can do better, but it inherits much from C low-level philosophy, and
won't give you a clean high-level OO system.
 What I mean is you must conceive your language (or at least, define how to
use existing language in a clean way) if you want to create a truly new
system (please tell me if I am mistaken). To me, if the system is really to
be the first truely OO based system, object managing should be included in
the kernel itself (see HP28, HP48 calculators, with the which many and I
discovered objects); if you let the user choose to apply or not OO philosophy,
then your system won't really be OO'ed. It's up to us to define what this
language should be like (I have my own ideas), what it should allow, or
forbid (except for device driver programmers). The system will then be
portable at this programming language level; whatever machine will support the
programming language (whether interpreted or compiled, or semi-compiled) and
have a sufficient (little) kernel for I/O will automatically be able to run
the system; I should even suggest a standard intermediate object code for
compiling, which would enable systematic separation of front end and back end
of compilers under the system (but the feasability of this must still be
studied).

 To conclude, I think we mustn't rush doing what would be the kernel of a
system whose features aren't defined yet. Let's define the high-level object
orientation of the system before we write the kernel (more precisely, let's
not write something in the kernel we should have to change completely because
it will not fit high-level system requirements).

		   ,
		Fare
	(rideau@clipper.ens.fr)