>> 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
