------------------------------------------------------------------------------
[MOOSE pre-Specifications]

Agreed:	(not contradicted, defended by both Michael and I)
======	(must be voted again in next meeting to become official)

Destination Platform:
--------------------
	* Portable,
	* but initially concentrate on 386/486 with view to later porting.
	* A virtual memory protection mechanism is assumed
	 (or will be software emulated _yeech_)

Copyright policy:
----------------
	* Copyrighted, but Free
	 (well at least to any not-for-profit person or institution; we may
	 delay our choice about distributing MOOSE to companies).

Features:
--------
	See the MOOSE Manifesto

Compatibility:
-------------
	* To be able to reuse existing software we want software compatability.
	* Any compatibility is wishful for a wide acceptancy by the public;
	 but it should NOT be a priority by any means.
	* 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.
	* If any compatibility is to be implemented, we should begin with
	 limited Unix compatibility (perhaps the same part as used by
	 documented no-hacking DOS, so that using roughly the same call
	 mapping will serve us in using DOS no-IO programs like TASM !).
	* In any way, multiple libraries and/or compiler modules can later
	 provide compatibility with any OS (which is now called
	 "personalities").

Security:
--------
	* Not yet discussed

User Interface:
--------------
	* Not deemed important for the moment;
	* can be designed later.


Proposed:	(not contradicted, will be agreed after next meeting)
========



REUSE EXISTING WORK:
-------------------
Idea [mike-001]:
	 At least for a first implementation,
	"I suggest we start with an existing OS (possibly VSTa) and add
	class/object support either at the kernel level or as a server."

PROs:
	* we don't have the resources to create	everything.
	 We should reuse existing work -- I'll
 		expand on this below.
(I just add)
	* And even if we have, it's stupid not to concentrate
	 on the essential, i.e. the MOOSE semantics, not device drivers.



discussed:	(multiple options are proposed, we'll have to choose
=========	 or delay choice on next meeting)

Existing OS to use as a basis to our work:	(NOT cross-devlpt platform)
-----------------------------------------
Options:

(I)	Use plain DOS and use a DPMI DOS extender
Status:	None for, all against. Will be rejected.
PROs:	* widely available platform
	* easy to convince people trying it.
CONs:	* Unix is more available.
	* living together with DOS is a pain in the a*s.

(II)	Use plain BIOS and use real mode for I/O.
Status:	None for, all against. Will be rejected.
PROs:	* we don't rewrite the most basic I/O.
	* No DOS to let live as with (I)
	* We can choose our own memory model, not pure unprotected flat.
CONs:	* We rewrite all specific I/O but disk I/O.
	* We must live with the BIOS (easier than the DOS, though).
	* no local I/O drivers as with (I).
	* (III) seems easier and better.

(III)	Modify VSTa
Status:	not discussed enough (only I -- Fare -- saw it)
PROs:	* It's already up and running, and support primary PC harware
	(timers, IDE harddisks, floppies, screen).
	* It's quite fast. Perhaps even real time is possible with little
	kernel hacking.
	* It offers a plan9-like filesystem-like interface to objects,
	so we can test it using existing unix ported tools.
	* C is enough to program VSTa.
CONs:	* Not much hardware and software is currently supported.
	* That unhappily does not seem to be about to change, as most VSTa
	supporters have gone to plain Linux or the Linux porting to MACH, so
	there's not much people left.
	* Particularly networking is not currently supported by VSTa.
	* Currently, C is used as a both development and user language.
	* Fine grained objects cannot be achieved in VSTa at system level.

(IV)	Modify Linux
Status:	not discussed enough.
PROs:	* Absolutely no I/O to rewrite.
	* It's already up and running.
	* TheIt's quite fast. Perhaps even real time is possible with little
	kernel hacking.
	* If need be, a plan9-like filesystem-like interface to user-defined
	objects is possible (userfs already does it).
	* Linux supports 
CONs:	* The semantics of Linux are 
Not much hardware and software is currently supported. That
	unhappily does not seem to be about to change, as most VSTa
	supporters have gone to plain Linux or the Linux porting to MACH.
	* Particularly networking is not currently supported by VSTa.
	* Currently, C is used as a both development and user language.
	* Fine grained objects cannot be achieved in VSTa at system level.

(V)	Using MACH
Status:	just suggested
PROs:	* Many people already use MACH, so the techniques are well known,
	and support is ensured.
	* MACH is meant to be fairly portable -- it's being developped by
	the BSD people.
CONs:	* Do anyone know MACH ?


(VI)	Use POSIX-compliant software (i.e. Linux, SunOS, etc) as a platform
Status:	not discussed enough
PROs:	* Most widely available platform (on the PC's, use Linux or perhaps
	 BSD)
CONs:	* we must REinterface all the huge U**x C library for our needs.
	 particularly the terminal and/or (later) graphical library; and
	 all these have VERY complicated semantics.
	* we must abide by C's semantics (especially the flat unprotected
	 memory model -- or can you handle page faults resulting from
	 mmap() ???)

Object file format:
------------------
Requirements:
	* Our object file format must be full-featured for saving
	 persistent object-oriented stuff in a hardware independent
	 way.
Options:
	* Using SOM (IBM's OO specification stuff) as an OO interface and
	 object file format.
	 [find the specifications by ftp on cil.org]
	* Use Meme as an object file format. Meme is a hardware
	 independant FORTH-based file format originally designed for
	 networking real-time Virtual Reality (4D graphics) software.
	 The 4D-graphics is copyrighted, but the object file format may
	 not be. Contact the author on comp.lang.forth (I have his address
	 somewhere).

