Words of Advice
Mon, 12 May 1997 13:54:26 -0400 (EDT)
.. and bits of history:
I designed a LogoMachine back in 1983 (didn't finish it because
I moved on to better things) and have been doing "exotic OSes"
A key to success is to be able to separate reasonable suggestions
from plain nagging. An example of the latter is all those people
who kept complaining about the Macintosh when it came out
because it had no slots. When they released a machine with slots
(nicer ones than the PC had, I might add) none of those people
were interested - they just moved on to other complaints! So
the proper response is to pay close attention to potential and
current users, but simply point the nags to an alternative
solution: "sorry, we don't have that. Try the store down the
road..." Of course, this doesn't apply to LispOS until it is
Similar to plain nagging is the ephemeral requirements. It
can be fatal to ignore those, as I found out when I sensibly
answered "no! that is silly" when my partner asked "can you
write a Unix OS in Smalltalk?" The proper response is to say
"of course" (and maybe even prove it is possible) and assign
it to some future, unspecified release. *Then* you can ignore
it, and you will find that as time passes and things change
that people will simply forget about it. Remember how Win NT was
going to have DOS, Windows, OS/2 and Posix personalities all
running in the same kernel? So there are some things you have
to promise to survive, but there is no need to deliver (am
I becoming a politician??).
Here are some decisions I made for my OS that may, or may
not, be relevant for LispOS:
- There will be two versions - one will run directly on
hardware (PCs, initially) and the other will run on top
of existing OSes (Linux and Win32 are my first targets).
Sharing the machine lowers performance a lot, but also
greatly reduces the "cost" of people trying it out. If
they don't try it (and take a good look at how many neat
things out there most people, including you, have never
tried) they will never adopt it.
- Backwards compatibility is simply too costly. If they
ever want to run something from the old days, then they
have to boot an old OS (they can run my system on top
of that, side by side with their old app).
- "Snarfing" drivers and other parts from working systems
is so tempting, but I won't do it. If the only things
I can get working in the first releases are VGA video
and IDE drives and you need something more exotic, then
get an old OS and run my system on top of that. See the
Apertos OS for how continuations for drivers make most
existing code look ridiculous. And I intends to use
inheritance to good effect for all those strange hardware.
How would I do that if I import drivers as black boxes?
- When running on other OSes (some systems that already
do this: Inferno, Oberon, Pick, Magic Cap) try to blend
in. My idea is that a person might find a tictactoe.xyz
file on the net and download it to his machine. He then
finds he must also get a xyz.exe to run this (much like
all those pages that keep telling you to get Acrobat
Reader to see their PDF files). Now that everything is
ready, just clicking on the tictactoe.xyz file (or
whatever works on this system) will bring up a window
with the game in it. There is a whole other OS now
loaded on the machine, but there is no need for the user
to worry about this. Clicking on another .xyz file will
launch it much faster as the OS is already up (has
"booted"). And bringing another .xyz from the net is
now as simple as any other file type. xyz.exe looks
like a native executable to the host OS, but it could
also be a plugin for a web browser (see Dolphin Smalltalk
for a great example of this).
- I use the host OS as a "hardware platform". No native
widgets, no font managers, etc. I just need some space to
blast pixels to - let my code do the rest. My system doesn't
have files ( just a global persistent object store divided
into soups of objects called regions), but the regions
can be encapsulated inside the host OS's files (like the
.xyz examples above). This conflicts with the "blend in"
idea, but if care is taken in having visual preferences
(see Smalltalk/X for an example of this) so the look and
feel can be varied, then the applications can match others
running beside it closely enough so users are satisfied.
- The GUI should stand out in a crowd so that someone going
past a long row of PCs will double back and take a second
look at one running my system (see
seems to conflict with having applications run in their
own windows and feel part of the host OS. My idea is that
any object can be directly mapped to an output screen
(or window, in the case of an underlying OS) and the GUI
is just another such object. BTW, mapping a regular application
object to a whole hardware screen is great for kiosks and
other embedded uses.
I hope this helps a little, and doesn't just add more noise
to this hyperactive list...
-----=============( Jecel Mattos de Assumpcao Jr )===========-----
http://www.lsi.usp.br/~jecel/merlin.html | mailto:firstname.lastname@example.org