>> That depends on whether you'd consider MSW 3.x or 4.x respectively to >> constitute a "complete new and different OS" on top of MS-DOS =P > > What is MSW?
Does this help?: http://www.google.com/search?q=MSW+4.x+%22MS-DOS%22+DOS+kernel Basically an abbreviation that doesn't suggest some sort of "Win". >> Well, at least as far as I understood it, FreeDOS-32 did aim for >> something >> similar - specifically, running the new (FreeDOS-32) kernel in protected >> mode, and ultimately allowing to run virtual(ised) machines for (V)86M >> DOS >> compatibility similar to regular tasks in that system (as well as DPMI >> or >> native applications, or potentially others). > > Sounds easy, but people seem to forget the problems with all DOS > internal structures and calls/interrupts being 16bit real mode, this > would be a far from trivial task. Even DOS extenders have already > quite a hell of a time to stay compatible with that... DOS extenders are something entirely different (API translation from one mode to another). Virtualisation and even full emulation are relatively 'easy' to implement on current machines (because of their performance), though some work is still necessary. To allow multiple tasks to access the same physical resources, some abstraction is needed of course, such as using a redirector-like interface for file system access within the task and handling the calls from this interface by passing them to the actual file system drivers (which necessarily must implement workable file locking semantics, unlike the typical expectation for DOS systems that do not explicitly multi-task). Or accessing a file system image instead of an actual file system, where each image is typically associated with no more than one running task. Both of these methods are provided by DOSBox and dosemu, the former is employed by NTVDM, the latter is generally provided by emulators. (If memory serves, DOSBox unfortunately provides high-level file system redirection only within its integrated DOS, which itself is a bad choice for other reasons.) >> DOS, however, allows external file system drivers to (relatively >> speaking) >> easily integrate into the kernel as redirectors. (As mentioned, a >> consistent LFN extension has not yet been defined for the redirector >> interface.) The roots of this go back to MS-DOS 3.x and the redirector >> interface has been used (provided) ever since by various networking >> clients as well as *CDEX programs, as well as more 'exotic' file system >> drivers. > > But you can't use the redirector interface really for any file system > running on DOS itself, Depends on your definitions. If you mean "local" (on that same machine, and running on that DOS): The file systems of a *CDEX driver are "local", and eg iHPFS also accesses "local" file systems from hard disk partitions. > not to mention that on the receiving end > (DOS), you still have all the inherited limitation of DOS. Different > character representations are just a start here (256/512 bytes code > pages compared to UTF8/16/etc)... Yes, no one doubted that these restrictions are still carried along (specifically those concerning naming). Regards, Chris ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
