🚀 go-pugleaf

-----BEGIN PGP SIGNED MESSAGE-----

In article <41gi05$4l0@blackice.winternet.com>,
Jeff Dege <jdege@winternet.com> wrote:

>   Multi-tasking MsDOS apps has absolutely no bearing on the argument, as the
>performance gains of multitasking of any sort only appear with processes
>that block on I/O.  MsDOS apps never block for any reason.  Hence, the
>impact on the system of a single MsDOS app sitting there polling for a
>user keystroke can be as or more significant than the heaviest bunch of
>number crunching.

you can get around this by co-opting the DOS interrupts and/or device
drivers (or even the BIOS) and replacing them with code that _does_
properly block the process.  this won't protect you from apps that
bypass the DOS and BIOS and go directly to the hardware (you can catch
these on a 386 or later with the I/O protection map, but doing so is
grossly inefficient), but the majority of DOS apps aren't this evil:
the worst case would be, i suspect, graphics apps, which can be
intercepted by modifying the memory map (you either map what the DOS
process thinks is the graphics memory into a buffer which the real OS
then displays using its own routines, or else you invalidate those
pages and simulate all accesses).

you can protect the DOS process from twiddling with the interrupt
vectors by protecting the zero page and simulating all accesses to it.

none of this is really remarkable; IBM has been doing virtual machines
for a long time.  the obvious model for a DOS process is a virtual
machine, where the OS simply simulates excluded hardware accesses
and/or substitutes system services where necessary.

if Windows does _not_ do it this way, i would have to wonder how they
_are_ doing it, and why.


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMDvt/RbgfSHT/piVAQHQxgP/QIiD7p6Gj3KFr9wcwJRhB01R9paIdq1z
oeOA/iCgI2PZ3z9arHzG6gLT7rfBLg6BLCEqeqU5vg3m5AM9RMpvIHO7ew0GC/au
9DQFsUf1N71VSSr8L8VVkVIq0McUE2X/dX4KmSl2jOl8+qzF0/12a9q19Mo3t325
IKKFWwmMzsM=
=wa37
-----END PGP SIGNATURE-----