An easy way to get there, of course, is by simply using instances of a lightweight VM emulator like DOSemu, on a stripped down version of Linux. An even better way would be to support true multitasking. But I would be thrilled if we provided even task switching, such as through a shell.
I emailed the contact person of VMiX yesterday, to see if he might be interested in opening VMiX as open source software. That project hasn't been updated since 2007, so it's possible no one is working on VMiX anymore. If they would be willing to open VMiX under the GNU GPL, I'd love to see us add VMiX to a future release of FreeDOS.
But this is all "2.0" talk, and we have yet to get 1.1 out. So I'll table the rest of my thoughts for now.
> 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
> - 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.
> 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