2/16/92 Moose Update

[Dennis Marer]

Howdy all!

	Well, it's me again - sorry I haven't put too much input into the
discussions this last week, but I've been busy with work, plus moving into a
brand new office!  My workstation is *finally* working, and I have waded
through the almost 45 messages I've received since last week....

	Sounds like we've got some great discussion going!  Let me just say
one thing to get started - for now, the name of this project is "Moose", and
will remain that until *much* further down the road.  We're all familiar with
it, it catches people's attention, and there's no reason to change yet.
No more discussion worrying about what it'll be called, since we haven't even
specified what it will do yet!  We can always pick a better name later.

	I did some research about the Motorola processors to see which one
should be used as our 'base' processor.  It appears as if the 68020 is the
idea choice, with good usage in PCs and other platforms.  There are some
pitfalls to beware of though - some of the MMU functions obtainable with the
68851 math coprocessor are *not* available in the 68030 (which has a built-in
math coprocessor), plus there is one instruction which has been omitted.  Not
a problem, as I understand most people didn't use this instruction anyway.
It supports full 32-bit addressing and data path, *nearly* equivalent to the
capability of the 386, IMHO.  We should have little trouble implementing
something on one chip which can't be easily duplicated on the other.  Looking
at the history of things, it seems Motorola included some of the more complex
stuff (memory management units, math copros) in their chips earlier on... :-)

	Many apologies about the first revision of the specs - there were a
lot of omissions and a lot of stuff which shouldn't have been there!  We'll
fill in the blanks later...I do want to clarify one thing: anything that
looked like an 'object' in that document was not intended to be part of the
kernel.  Eg, the 'timer' object and the 'semaphore' object were intended to
be *extensions* to the kernel, and not part of the kernel itself.  In the
next revision I'll separate the two more clearly, keeping the kernel as clean
and as pure as possible.

	One thing I've heard many of you mention is to make this less of an
object oriented operating system - I agree, the kernel should not be object
oriented.  There is even little benefit from making, for example, a task an
object within the system - however, I'd like to see the kernel to be able to
recognize objects though!  If, for instance, virtual memory were implemented,
the kernel might be provided with a hard drive object to swap to and from.
It can use objects in the system, but does not have to.  Seem like a good idea?

	I've been doing a little research into distributed processing also -
the idea of being able to use objects existing on other systems really
appeals to me.  In particular, display devices should be sharable among
networked systems (like X-Windows) so I'll propose a method of doing this
in the next revision of the specs.  (Just thought I'd tease you with that!)

	Another point of concern is whether or not this OS is going to be a
graphics based system or a text based system - that's a simple answer: neither!
The operating system should be written as if there are *no* devices connected
to the CPU, as if the entire machine were memory, basic interrupt and control
hardware, and the CPU.  Everything else, I mean *everything* else, is an
extension to the operating system.  This way the OS could be used for a server,
an embedded controller application, a run-of-the-mill PC, or the most
elaborate and complicated hardware setup without changing the kernel.  This
is the most practical design approach, and will also help porting to other
platforms.  If we want to make a GUI (which we probably will) this will be
as an extension.  We'll also want to make a text-based interface (either a
windowed interface like DesqView or a standard "terminal"-like interface) for
use in less interactive platforms, like servers, remote dialup, etc.

	Personal note: I can *guarantee* this system will work better and
have less bugs if we make this sort of distinction between kernel and 
extensions.  This is (IMHO) a major failing of OS/2 and Windows.  I also think
Windows NT would have benefited from being designed in this way, and would
gain more acceptance as the "universal" operating system for all platforms.
To be honest, I wouldn't be working on *this* project if it were. :-)

	I've been working on the next revision of the specifications, including
stuff I left out last time, adding all of your suggestions, and restructuring.
I'm also writing everything in the present tense (instead of the future tense)
so that when complete, these specs will also double as a programmers guide.
It will be nice to have a good portion of the documentation done before
anything else! :-]

	Thanx for the organization suggestions for the FTP site - still no
offers on free sites, so I've taken the liberty of setting up a site at a local
company which offers those services.  It costs only about $20/month to me, so I
don't mind paying this.  I'll act as the administrator, setting up the
directories and stuff, and there will be another FTPable account (with a
password) for each of you to log on with.  You'll be able to read info from
everywhere, but able to write only to limited areas.  There are some storage
charges ($0.04/kilobyte/month) so it's to my advantage to be the only person
with full access.  I'll let you all know when it's ready for use!

	One more thing - so far most of what I've written in the specs is the
programming interface to the kernel and basic extensions.  I think many of
you feel a more general overview needs to be included.  I need your input for
this portion, as I work better with the nuts and bolts, the actual functions
and calling interfaces of software.  Give me your suggestions of what to write,
and I'll write it - or, if you wish to write a portion of the specs, let me
know.  I'm content doing it myself with your input, but your writing skills
are also appreciated.  If you just want to write notes, I'll also transcribe
those into a "document" if you wish.  As you'll find out, I'm a real freak
about proper documentation - have I mentioned how much you'll need to comment
your source code...? :-(

	I expect it'll take about the next two weeks until the next revision
of the specs are done.  Let's talk more about what you expect they should
include, and when they're finished I'll upload them to the FTP site.  I'll be
keeping *three* copies of everything (on the FTP site, on my PC, and on floppy)
so there is little chance of losing everything!  We should also have an
'official' mailing list very soon.... (Rob, how is that coming? :-)

	Take care all, and keep those ideas flowing!

				Dennis