There was a project, quite some time ago, it was called "LiDos". I liked the idea very much:
It was a very simple Linux distro runing Dosemu at boot time. You could switch to a bare Linux console and use Linux Commands. Unfortunatly it was Slackware based and had too many modifications, so when the original author abandoned nobody was able to continue. We could make something similar, based on something more main-line like Debian... I am willing to help, but I don't know how to setup a minimum Linux BUT with the capability of detecting all possible Hardware... I am already working on a VM with a Debian+Lxde to run Dosemu with some predifined configurations like networking and charsets. Alain Em 14-09-2011 04:05, Andreas Berger escreveu: > I also think the task should look exactly like DOS. This either means > that resources (e.g. serial ports, printer ports, usb, ect) must be > given exclusively to one task which owns it until it closes or the > kernal must administer the conflicts WITHOUT one task being able to > crash another. > > Writing a multitasker is easy, but I have no understanding about how > DPMI, rings and resource allocation work. I think the idea of a > bare-bone linux behind the scene is a very good. Truth be told I would > like to see OS/2 resurrected with true DOS windows. > > Andreas > > On 12/9/2011 23:24, Michael B. Brutman 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
