I have been thinking about what a more modern DOS would look like.  Some
ideas ...


- A "task" would look a lot like a single instance of DOS running
today.  The address space of a task would look the same, so it would
have the interrupt table, BIOS area, video display buffer, expansion
ROMs, system ROM, and extended memory that you find on a DOS system
today.  (Kind of like a running instance of DOSBox, but with better
device and hardware emulation.)

- MS DOS has its own concept of "process", which is an instance of a
running executable.  That concept remains unchanged.  Multiple processes
live within a "task" (as defined above) just as they do today.

- The DOS kernel supports most (if not all) of the standard DOS
functions.  As there is an interrupt table and system ROM, BIOS
functions are available as well.

- Multiple tasks could be started and running.  But they are logically
part of one machine and one OS, not just separate instances of an emulator.


The underlying kernel is a bit more sophisticated:

- There is a shared filesystem for the machine.  If that filesystem is
not FAT then it is made to look like FAT by the time the DOS function
calls run.

- Memory mapping is used so that the tasks exist in different address
spaces, and thus are protected against each other.  Memory mapping is
also used to give the illusion that each copy has its own video buffer
so that direct screen writes and other normal practices are not problems.

- The DOS portion of the operating system that is visible to the user
applications is a thin wrapper that calls into the real OS.  That keeps
the memory footprint of the DOS kernel in each task minimal.

- There is a real networking stack that can be used, and is shared
across the entire machine.  Additional DOS function calls are defined to
use it, or a packet driver used a "shim" is used to support existing
applications.

- The kernel provides some other services that we are missing, like cut
n paste support between the different tasks and inter-process communication.




Another way to look at this is that you have a real operating system
like Linux with a new (or better) DOS emulator.  The DOS emulator takes
some pain to try to emulate a real machine; keyboard interrupts, timer
tick interrupts, 8250 and 16550 device emulation, etc.  The difference
is that unlike running multiple instances of DOSBox in separate Linux
processes, the emulator allows some sharing of common state and data
between the different emulated DOS tasks.

I can't see adding all of this (or even 1/10th of it) to FreeDOS.  But I
can see starting with a fairly stripped down Linux base and doing some
hardcore development work with KVM to build this.  Riding on top of
Linux takes care of our hardware compatibility problems and the emulator
should preserve most of our existing software base.


Mike



------------------------------------------------------------------------------
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
Learn about the latest advances in developing for the
BlackBerry® mobile platform with sessions, labs & more.
See new tools and technologies. Register for BlackBerry® DevCon today!
http://p.sf.net/sfu/rim-devcon-copy1
_______________________________________________
Freedos-devel mailing list
Freedos-devel@list...
https://lists.sourceforge.net/lists/listinfo/freedos-devel