> 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. clicking on the [download] button leads to ftp://ftp.sysdev.org/pub/VMiX-3/ > That project > hasn't been updated since 2007, similar to freedos 1.0, so it's possible that this is dead as well > 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. it's GNU LESSER GENERAL PUBLIC LICENSE. how much more o you expect ? > 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. > jh > On Sep 12, 2011, at 9:24 PM, "Michael B. Brutman" <mbbrut...@brutman.com> > wrote: >> >> 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@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/freedos-devel > ------------------------------------------------------------------------------ > 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@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel Mit freundlichen Grüßen/Kind regards Tom Ehlert +49-241-79886 ------------------------------------------------------------------------------ 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
