See the reason why I'm thinking of DOS is because I need the host OS
that runs on the slave PC to use a minimum amount of ports etc. so that
we can control _everything_ from the plex86 "guest" (the heiarchy:
kernel<--monitor/host<--guest<--"MultiPlex86" slaves).
To use Linux as the slave OS we'd have to strip it down to using next to
nothing. We'd have to remove PCI support, in fact jut about _all_
support. There wouldn't even be a Keyboard driver! I don't know how to
do that because I'm more comfortable with DOS (I like the control of
being able to directly access hardware etc. which, interestingly, Plex86
will eventually allow! Thus with plex86 people can "safely" move over
from DOS, while still being able to write "advanced" things and play
around with microkernel algorithms).
Anyone know how to build a *minimum* linux kernel? I think Linux is a
better choice then DOS since it already has memory management (that we
can use, e.g. that works well in pmode so we can use more than 1MB RAM
easilly in pmode on the slave PC) and even a TCP/IP stack. The problem
is, it needs to be a *legacy* OS. That's because the slave's PCIset is
going to be programmed by the guest (on the physical "host" PC).
Now it didn't occurr to me that this could be used for distributed
computing. One could, for example, call an entrypoint with various
values to see what the outputs are, and see which inputs cause the
system to hardware reset (on the network you'd see the PC stop
responding until it rebooted). Using multiple PCs at once could even let
people "donate" their idle PCs to research & development of, say, an
SVGA chipset.
But that's all just an example application of MultiPlex86. Here, we're
developing the low-level things and I'm only planning on connecting
_one_ slave PC at a time (at least at first).
I think Award Software did something similiar to this (the 'MultiPlex86'
thing) and I think that they were sued and that they won in court
because they didn't disassemble but only mapped out functions and then
called various entrypoints with different values, presumably; then they
could find out what part of the stack was trashed and is thus safe to
use in a cloned BIOS; and they _could_ query all the legacy devices to
find out what has changed about them, but that wouldn't be necessary if
the BIOS they were cloning were to run under Plex86. In that case,
legacy hardware would be emulated. They wouldn't watch the BIOS
functions _as_ they modified the hardware, but only keep track of what
has changed since entry to a function, and then see what the _ending_
condition is of the hardware.
Thus one needs not query all I/O devices to see what's changed; one
needs only to keep track by adding code to the device emulation.
For the record, my goal is NOT to clone a BIOS. I want to develop Plex86
so that it can be used (by other people) to clone BIOSes and software,
to promote interoperability and to try to covertly shift Windows users
to Linux. For all we need to do is provide the right tools for people
with funds to set up cleanrooms and reverse engineer Windows. If we can
provide good tools, eventually someone might offer an open-source
program similiar to Wine only that is 100% compatible with Windows
(probably it would be a Plex86 application that emulated a whole PC,
complete with all the SVGA chipset functionality and all the hardware).
Remember, Award made a 100% compatible BIOS. It can be done.
-Willow
Eric Laberge wrote:
>
> With some work, you could have the basis of a damn good distributed
> computing system. A name for such a project? How about Multiplex86 ?
>
> EL
