MOOSE Project -- new OS ?

Jecel Mattos de Assumpcao Jr.
Thu, 27 Oct 94 17:14:44 EDT

Sorry about the previous attempt to send this message: it got
truncated along the way :-(

> > I am also writting my own OS. You can read about it in the WWW as:
> >
> I've read it. Re-mail me when you update it.

Ok. I should add actual information to these pages by next week. Right
now they are a bit too vague...

> >>  [ The project is called MOOSE ]
> > So, why can't you change it now?
> Who said I couldn't ? I told the name just for the few who know it.

Right. I thought you didn't sound too pleased with it. While I like
my project's name fine, there are too many Merlins around so I may
be forced to change it.

> > I agree. But any language can have persistence added to it ( see
> > the Texas system in )
> Nope. C can't. You need scoping.

I was thinking about heap allocated objects only, as C already treats
stack based objects differently. ( The Texas project and Sony's Apertos
are both written in C++ ).

> > Smalltalk/Self bytecodes are also a good choice.
> Yes, I've thought about that. Where can I have self *implementations* ?
> There are also lots of papers. Which to read ?

You can FTP the current implementation ( SPARC machines only ) from You can get it via WWW from

Though the paper "Self: the Power of Simplicity" is very obsolete, I
think it is still the best introduction. Then I would read "Organizing
Objects without Classes". The current release's manuals would be
the best thing to read after that. Most of the other papers are about
implementation techniques.

> > I don't think you can get rid of a nanokernel-like system. Something
> > must field the interrupts.
> The interrupts are for device drivers, not for the kernel. Really, I see
> nothing that really belongs to the kernel. Messaging protocols belong to
> messaging objects. We really should detach the high-level specifications
> from its low-level implementation. Everything in the OS should be
> reimplementable.

As you mentioned multiusers earlier ( I think ), there should be some
protection of the very low level objects from the application level.

> In my system, everything is "user object" somehow.
> But everything shouldn't be left to nomal human users, especially if money is
> involved. The problem is I can't imagine a system where one could read a
> document, but not copy it and produce another document identical but for the
> signature. As long as the problem is "Is the document written by the author",
> everything is ok; now, if the problem is "Has the author written the document"
> it becomes much harder.

You might want to apply some kind of digital signature system here.
This ties the author identification to the document's content so that
neither can be altered independently.

By "user objects", I meant objects which represent a user ( like a user
account in Unix ). Every application involves three "users": an
application viewer pseudo user, an application editor pseudo user and
a programmer user. When you get an object created with the application,
the viewer user is added to your system. If you want to change the
object you received, the editor user must be installed, be doing so
required that you register and pay for the software. The programmer
user tells you how to pay the program's author. I am using these
pseudo users roughly like some kind of module system.

> > I use Self. It is very good and getting much better!
> Where can I contact the SELF community ?

There is a mailing list at "" which
you can subscribe to by mailing to "".
It has been rather quiet, lately, as they have been preparing to
show the next generation Self system at OOPSLA'94 this week. If
you want the email addresses of some Self group members, I can look
them up for you.

> > Feel free to write me if you want more details about my work.
> Yes I do.

I also found the description of the Pios project interesting. And
in France, the Moostrap language ( while not what you want ) is very
interesting - it is a simpler and more reflective version of Self.

Good luck with you project!
-- Jecel