Christopher J. McKenzie - 2002-12-27

From: Christopher J. McKenzie
Date: Fri Dec 27 15:11:16 PST 2002
Re: FreeDOS update; a few emails.

Abstract:       Update on plausibility of FreeDOS as a starting point.

After installing a system with the FreeDOS OS I found it to be a most worthy
contendor with respect to speed.  Upon looking at the source I made note
that it was developed and compiled in another DOS; probably another FreeDOS.
Such a modality is in principle violation of the "any" part of the allonany
idea.

In contacting people with similar projects I have found some fascinating
ideas that fall in line with the allonany concept; none of which were my
own.

Similar to my device model, Zhen Yao writes to me:
"The "hardware" for
the virtual machine is extended, not only the actual hardwares like disks
and keyboards or screens, but also some OS specific features like X
protocol, (quite in the same analogue as the concept "file" in UNIX, but
programmed with IO ports at "hardware" level, in order to provide compact
and shorter instruction code).  For example, assume the Evima is running
under windows, and you write a plug-in for window management as a piece
of hardware, then a window will be launched when the virtual machine
output the parameters into the port of the window-hardware.  The same
philosophy can be employed to modelling network sockets etc.  However,
it's impact on OS design will be amazing.  It will allow the programmer
concentrate on the actual OS design, hence fits into the educational
purpose."
Essentially it appears that Zhen, in his "EVIMA" project is trying to
facilitate a unity between hardware and software communication protocol
in a sense that they may appear to be of the same class.
I however don't believe that allonany should ever deal with something
as specific as a windowing protocol being that it is not application
software.

Another fascinating person, Alan Conroy replied to my message asking for
his feedback on my project, he wrote:
"One of the
original ideas was to implement the hardware in a script that would allow
the emulation to occur on any hardware."

This single idea, a minor point in his entire message, was to me one of the
most profound ideas I had ever seen applicable to such a project as Allonany.
Realistically, being a fundamental operating system, there will exist no
subsystem upon the execution of the allonany system upon which any
interpretation can be done.

There have been many roadblocks for me in defining an Allonany system.  It
has been easy to dream and make magnificant speculations upon what I would
like to happen, but I have relatively been at a loss to find out how to go
about doing it.

In the previous memo, "How to start" I professed that a desire to run
on multiple platforms and have a modular base which is common amongst all
platforms suggests that a possibility of a multi-fold base system may be
quite a viable option to accomplish the goals.

The folds of the base system are as such that a sophisticated batch control
language (examples, Rexx APL Python MetaCard tcsh bash perl) can be understood
but also there will exist another fold, the fundamental operating system part
that will manage such a language.  In effect, it is an integration of a control
language to the native system void any interactive shell.  This is how many
early systems like IBM DOS worked (the 1960's DOS).

However, the difference in the modular kernels of the present is that there
need not be any ports.  The modular Allonany system will be designed for
the Allonany virtual system.  This is a rather difficult concept for me to
comprehend so I hope I can explain it sufficiently.

In the act of bootstrapping, Allonany will load a master translation device
wherein the rest of the system will be able to boot from.
This master translation device is hardware specific and is the only necessary
bridge between the hardware and allonany.
By being able to spawn logical devices and their correlations with physical
devices, all other parts of allonany, whereinto other systems, such as the
BSD's went to hardware specific modules, will go to Allonany specific modules
which will interact with the logical devices which will then tell the physical
devices to function.  Therein, the division remains absolutely consistent
with the various models.

Any update to the allonany system will automatically be portable to all
hardware platforms even though it is a fundamental operating system.

Any new correlation between logical or physical devices or new definitions
of the devices themselves will not make allonany inoperable as long as the
standard allonany type device is still able to correlated with the hardware
specific physical device.