Test ...

[winikoff@cs.mu.oz.au]

> 
> > Hi!
> > 
> > Test.
> > 
> > Did people get my earlier mail? (the long one)
> 
> I fear not.
> 
> > Michael
> 
> --    ,        	                                ,           _ v    ~  ^  --
> -- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
> --                                      '                   / .          --
> MOOSE project member. OSL developper.                     |   |   /
> Dreams about The Universal (Distributed) Database.       --- --- //
> Snail mail: 6, rue Augustin Thierry 75019 PARIS FRANCE   /|\ /|\ //
> Phone: 033 1 42026735                                    /|\ /|\ /
> 

------ CUT HERE -------

Hi all!

Contents:

(1) Comments on Fare
(2) Organisation matters
	(2.1) Reuse
(3) Objectives
(4) Role of OO
(5) Suggested starting point for a design

-------------------------

(1) Comments on Fare
I agree with Fare's comments on why Moose didn't work first time around.
I hate the formatting used for the message -- it made it very hard to read.
You can easily refer to a message number and a line number without having
to label each line.
Re irc, (a) I can't make the 7th (I'm on a camp) but can make the 14th.
	(b) How does one irc?
> [4.1]           The system should include features never gathered in any
>                existing system made available, else we'd better switch to
>               the system that already gathers those features.
> 

I would prefer to have the questionthe other way around -- are there 
existing systems that we can build on?

(see section (3)XXX)

> [4.3.3.2.1]     This does not at all mean that we have a source of unsecurity
>                 in the system, as the compiler ensures that all checks
>                 removed are checks that prove always ok. This means the
>                 high-level language to low-level translator (and even the
>                 annotated low-level) provides full checking (i.e. we really
>                 have a high-level language, not a low-level hack like "C++").

If you want to be able to run C programs (which is a useful thing to be able
to do as there's a lot of useful software (eg. TeX, numerous programming
languages) in C) you have to provide some form of hardware protection.

-------------------------

(2) Organisation matters

	* What happenned to the replies to Dennis' original post?
		(the ``what would you put in a dream OS?'')
	* We should put another call for people on comp.os.whatever
	* Communication *is* our weakness -- unfortunately mails
		aren't effective -- long messages are hard to read
		and short messages don't explain well.
		I don't know how well irc/talk will help.
		One possibility is making use of documents -- when you want
		to propose something write a document (and mail the 
		postscript) that explains it well with examples.
	* The role of prototyping -- it will help a *LOT* if we knock
		up prototypes of proposed ideas before spending the time
		implementing them properly. Use of VHLL is suggested here.
		Prototype code could be included in documents.
	* REUSE EXISTING WORK -- we don't have the resources to create
		everything. We should reuse existing work -- I'll 
		expand on this below.
	* As Fare says, we should maintain a history of our work and 
		design decisions.

(2.1) Reuse

	Why are we writing an OS from scratch?
	If it is possible we could save a lot of time by taking an existing
	OS as a basis.
	One option that may or may not be possible is to provide objects
	by adding a library or a server to an existing OS.
	Another option is to get source code for a curent free OS and use 
	that as a starting point -- if nothing else we save having to 
	write low level device drivers (boring stuff)

	BTW, have people heard of VSTa? It's a copylefted microkernel that's
	small and runs on 386s it provides multiprocessing and virtual memory.
	Source is available and is fairly short.
	(2700 lines of portable C, 750 lines of 386 specific C, 400 lines
		of assembler)


	A third possibility for MOOSE is to design a language, a programming
	environment and a sharred library so that programs written in our
	language would be nice and have all the facilities the OS should be 
	providing. This implementation wouldn't need to worry about
	(eg) handling other languages and could be relatively portable.

	If we decide that the language is not central to our project we should
	try hard to use an existing language.
	At a guess I'd say that designing a language would take longer then
	learning an existing one.

-------------------------

(3) Objectives
	Agreed upon:
	* Portable but initially concentrate on 386/486 with view to 
		later porting
	* Free
	* Multitasking
	* Virtual memory and memory protection
	* Object Oriented (see section 4)

	To be able to reuse existing software we want software compatability.
	Unix compatability can be provided with a library that maps unix
	calls to Moose system calls. 
	DOS compability requires simulating a DOS machine hardware since
	DOS programs will make hardware access.
	I'd suggest just doing (limited) UNix compatability since it's simpler.

	NOTE: The set of system calls offered isn't that important since
		(a) A programming language should offer it's own calls and
			let the implementation map them to the OS calls
		(b) One can provide libraries that give different 
			personalities
	      Likewise the UI isn't important since it can easily be replaced.
	      [Note: when I say not important here I mean not important to 
	       the design of the kernel and the essential OOness of the system]

	What is our audience? This will dictate whether we aim for multiuser 
		and security.

	BTW, just as asides... 
	(1) a small efficient unix compatibl OS *would* be useful.
	(2) We are not building another Xinu/Minix so simplicity is not 
		the most important thing
		(This is one thing I was wrong about earlier)

-------------------------

(4) Role of OO

There are a number of definitions of an OO OS.
	(a) OS is viewed as a running program in an OO language
	(b) replace the notion of a process and file by objects -- so we 
		have data and code toghether. This is examplified
		(at the UI level) by the Mac.
	(c) The OS is internally written in an OO language making maintenance
		simpler but not changing the interface --- this is NOT what
		we're after.

Suggstions:
	* Look at Self (OOPSLA '87, Sigplan 22:12 -- I think it's FTPable)
		Self is an OO language that uses a simpler alternative to
		inheritance.
	* How does adding classes/objects to the system work? 
		What kind of interface and functionality do we want/need?


-------------------------

(5) Suggested starting point for a design

We need memory management and memory protection.
We want multitasking.

A simple kernel would support these standard things and in addition would
recognize ``objects'' and ``classes''

What is an class? From the point of view of the kernel it's a piece of code
with 
	(a) multiple entry points
	(b) An attached description of these entry points and their types.
	(c) An indication of inheritance (more thought needed on this one)

What is an object? From the point of view of the kernel it's a data region
with an associated class.

The kernel lets us install new classes into the inheritance hierarchy.
The kernel lets us create objects (instances of classes)
The kernel lets us call the methods of objects.

I suggest we start with an existing OS (possibly VSTa) and add class/object 
support either at the kernel level or as a server.


-------------
References:
Self papers are available from 
	self.stanford.edu:pub/papers
VSTa is available from
	ftp.cygnus.com
	

Michael
winikoff@cs.mu.oz.au (mail to mulga still works, if you want to talk 
			to me try winikoff@munta.cs.mu.oz.au)