Is Tunes too much? (fwd)

[Fare Rideau]

Forwarded message:
>From POPmail Mon May 19 09:14:34 1997
Message-ID: <337FE11D.3C28@unm.edu>
Date: Sun, 18 May 1997 23:11:57 -0600
From: Daniel Robbins <drobbins@unm.edu>
X-Mailer: Mozilla 3.01 (Win95; I)
MIME-Version: 1.0
To: rideau@nef.ens.fr
Subject: Is Tunes too much?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-UIDL: a4b57254597cb67cc0d05e3f2e90ce4e
Lines: 95
Xref: Kadath.ens.fr received:250
X-Gnus-Article-Number: 250   Mon May 19 09:24:09 1997

I have looked a bit at your Tunes project and I think it may be too
ambitious a project, and I don't mean to discourage you by saying that.
Only Microsoft and a few others have the resources to develop an OS and
tons of related APIs from scratch.  Focus on the bare essentials, design
something that is useful to other developers.  Let them design their own
APIs.  That's my philosophy for OS design.

I want to repeat that I'm not saying this to discourage you, but rather
to help you-- I know from my own experiences that by taking on too heavy
a load you can be crushed by its weight, and your project can either
fail or never gain momentum (it may never "get off the ground" ).  I
hope that my advice will help you to gain the critical momentum you need
to make your project a success.  If you do not agree with the specific
decisions I suggest below, at least consider the underlying principle:
Help others and they will help you.  Design something to help others do
what they need to do and they will provide you with a great reward - the
fruit of their efforts, the result of their hard work. 

I have thought about developing my own operating system and have arrived
at the following steps to do so, if and when I feel called to undertake
such a task.  All of these decisions stem from a goal of providing as
many people as possible with as many solutions as possible.  In other
words, make it easy to use and code, and make it easy to extend.  Do not
force any abstractions on the user which are not required.  Any
abstractions may be a hindrance rather than a benefit.  Of course,
abstractions will be needed, and will be provided in the form of modules
which can be loaded and can be used to provide an API for programmers
that do not want to code to the PC hardware directly.

First, I would target a specific architecture.  My choice would
initially be 32-bit x86 based systems.  Secondly, I would choose a
"host" operating system.  This OS would be DOS.  DOS would be chosen as
the OS which would be required to run all of the installation,
development and possibly maintenance tools for the OS.  By providing a
solid base of DOS programs to load, install, develop for and configure
your OS, you will make the user's transition to your new OS a relatively
easy and unintimidating process.  I would begin the development process
by developing something that could be used as a DOS extender.  It would
set up a 32-bit environment and not force any abstractions on the user -
the "OS" functions would perform the task of keeping track of who
allocated what hardware resource, rather than actually manage the
resources themselves, which is the "ExoKernel" concept which MIT
Researchers seem so fond of these days.  (I guess they finally got sick
of UNIX! ;-).  One note is that I wouldn't worry about "multiplexing"
resources at this time (multitasking and virtual memory)-- some
developers (such as game developers) will not need these "features" so
they should not be forced to use them.  Remember, make it as
general-purpose as possible, the specific APIs come later.

The OS, in its first stages, could be used as a 32-bit DOS extender for
whatever purpose the user wished.

Second stage would be to do design a powerful way of extending the
functions available to the programmer, by loading external library
modules.  This would involve choosing an elegant, fast way of having one
code module "call" another module, and adding a messaging module which
could be loaded to provide the basic building blocks for stage 3.  Note
that none of these modules would be required.  A user could use your
extender to simply set up a 32-bit environment, execute some 32-bit
code, and fall back to DOS, without using these additional modules which
will serve as a basis for your OS.

The third phase will hopefully gain momentum on its own.  Having
designed a high-quality DOS extender, and a basic yet powerful loading
and message passing module, your DOS extender is in use by a number of
people around the globe, who are using it for a variety of purposes.  As
they develop applications and products using the extender, they begin to
release the modules they have developed to the development community, so
that they can be used by others.  At this point, the abstractions being
set forth by these new modules will serve as a basis for a new
generation of tools for your "extender".  These new modules provide
features to handle high-resolution video modes, play sounds and provide
virtual memory and multitask if and when necessary.  Eventually, this
grass-roots project will reach a point where there will be a GUI, and it
will have high-level-enough features for the average user.

The key to this strategy is this:  It is difficult to do everything
yourself.  Solve this problem by developing a versatile OS which will be
so useful that it will become popular and others will develop versatile
modules for this OS.  The way in that you can make your OS useful is: Do
not force the user to do things one particular way, it probably isn't
the *best* way.  And make it easy to use, fast and include lots of
documentation.

Remember, good OS design doesn't happen in a day.  It happens over time,
with the help of many people.  The earlier you get people involved in
your project, the better.  The best way to get them involved is to help
them by providing them with something they already need.

Best Regards,

Daniel Robbins
drobbins@unm.edu




== Fare' -- rideau@ens.fr -- Franc,ois-Rene' Rideau -- DDa(.ng-Vu~ Ba^n ==
Join the TUNES project for a computing system based on computing freedom !
                TUNES is a Useful, Not Expedient System
URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"