discussion: goals: compatability?

[Mike Prince]

On Mon, 14 Nov 1994, Gary D. Duzan wrote:
>    Ah, but this brings me to the real point: intertia. People like
> going in the same direction they have been going. If mass acceptance
> of the system is a goal, binary compatability with, say, NT or
> Win95 (hopefully DOS will be out of fashion by then) will be a big
> boost. Naturally, this only makes sense on nodes with a particular
> architecture. For an example, take {Free,Net}BSD vs. Linux. Both
> BSD's were more stable than Linux in many ways for a long time,
> but Linux had DOS capability (among other friendly things) so it
> is more popular, and now you can even get DOOM for it. :-)
>    Just some random thoughts. I like stirring things up. :-)

Too many efforts have been put into sliding MY OS under YOUR OS in 
efforts to steal your market.  And I have yet to see it be done. On the 
flip side, even though MS had the DOS market it put Windows on top of 
DOS.  Simple wisdom for the end user, when you buy windows you are adding 
functionality not losing DOS compatibility (for the most part, you can 
always go back to the command line).

I think we should try the same thing.  Make ours a real OS, but really 
small and with some functionality that theirs doesn't have.  Run it on 
top of theirs for now.  Make it free and available everywhere.  Create a 
tight and good interactive environment for writing code and encourage 
people to start developing applications for our environment.  MAKE SURE 
our OS does not depend in any way on the OS which it overlays.  When the 
time comes you can dump the old OS and put ours in its place, no compromises.

Here's one little idea I was playing with over the weekend.  e-mail goes 
everywhere (for the most part).  Make our OS bundle up messages and send 
them to other systems as e-mail.  The .forward file in SunOS for instance 
can invoke a program to process these messages.  We then simply make our 
OS program process the messages.  Voila, cheaper Telescript!

Idea #2.  Have the OS manage medium sized "objects".  Each object being 
given a name and when addresed as such providing information about 
itself.  Instead of directories, we would have lists of names.  When 
asked to show this list, all the objects named in the list would be 
polled for information (and icon, and maybe some descriptive text, state, 
etc..), and this represented in the standard "window" of the UI.  Object 
references can be moved between lists, copied, or deleted.  To execute an 
object simply call it.  There would be no loose data per se.  Data would 
be encapsulated in objects.  If it was wordprocessing data, the object 
surrounding the data would call the appropriate object to edit the data ( 
I believe that's like Apples resource fork, is it?)  I could go on, but, 
does it sound interesting?

Idea #3: How to program.  I've thought about having interactive 
programming, whereas the program you are working on can be executing at 
the same time.  Here's my suggestion for a development environment.

The user never actually touches the object being worked on, instead the 
user is typing away, interacting with a UI object which is sending 
messages to the object under development.

The object under development receives these messages and integrates them 
into itself using some development components temporarily infused into 
itself.

When development is done, those development components are removed and 
the pure object is left to go on its merry way.

In this way development can be incremental.

The other side of the coin is to have all the source listings in one 
object, and have the entire object compiled at once.  This is the 
traditional way.

What do you guys think?

Mike