What role did MS-DOS play in Windows 95?

MS-DOS in Windows 95 was used for two purposes:

• She served as a loader.
• She acted as a compatibility layer with 16-bit drivers.

When Windows 95 started, it first loaded a special version of MS-DOS, it was she who processed your CONFIG.SYS file, ran COMMAND.COM , which your AUTOEXEC.BAT ran and eventually executed WIN.COM , which in turn started the boot process 32 -bit VMM virtual machine manager.

This special version of MS-DOS was fully functional to the extent that the words “fully functional” are generally applicable to MS-DOS. It couldn’t have been any other way; when it went into MS-DOS emulation mode, only this version remained to work.

The WIN.COM program started downloading what most people call “Windows” itself. Through a copy of MS-DOS, she loaded the virtual machine manager, read the SYSTEM.INI file, loaded the virtual device drivers, then turned off the EMM386 (if there was one), and switched to protected mode. “Real Windows” from the point of view of most people is exactly protected mode.
')
In protected mode, virtual device drivers worked their magic. Among their actions was pulling out the entire MS-DOS state , translating it into the 32-bit file subsystem state, and disabling MS-DOS. All further file operations were directed to the 32-bit file subsystem. When the program accessed int 21h , the 32-bit file subsystem was responsible for processing.

This is where the second role of MS-DOS comes into play. You see, MS-DOS programs and drivers liked to be embedded in the depths of the operating system. They could replace the interrupt handler 21h , they could patch the system code, they could replace the low-level disk handlers int 25h and int 26h . They could also create mind-blowing things with interruptions of BIOS type int 13h , responsible for working with disks.

When the program accessed int 21h , first the request was sent to the 32-bit file subsystem, where it underwent some preprocessing. Then, if the file subsystem detected that someone had intercepted the int 21h vector, it went back to the 16-bit code to allow the interceptor to execute. Replacing the int 21h vector is ideologically similar to subclassing a window. You get the old vector and install the new vector. When the handler you set is called, you do something, and then call the old handler. After returning from the old handler, you can still do something before returning control.

One of the 16-bit drivers loaded from CONFIG.SYS was IFSMGR.SYS . His task was to intercept MS-DOS first , before all the other drivers and programs got their chance! This driver was in collusion with the 32-bit file subsystem, returning from 16-bit code back to 32-bit so that the file subsystem could continue its work.

In other words, MS-DOS was just an exceptionally adept decoy . The 16-bit drivers and programs patched and intercepted the handlers, which for them looked just like real MS-DOS, but in reality were bait. If the 32-bit file subsystem saw that someone had bought the bait, she made the decoy duck quack.

Let's start with the system without the "evil" drivers and programs that are embedded in MS-DOS.


It is a paradise. The 32-bit file subsystem was able to do all the work, without interacting with annoying drivers who did fancy things. Note the additional step of updating the MS-DOS state variable. Although we retrieved them during the download, we keep them up to date, as drivers and programs often "knew" about them, bypassed the operating system, and worked directly with state variables. Consequently, the file subsystem should have maintained the illusion of MS-DOS responsibility (despite the fact that MS-DOS actually does not work anymore) for such drivers and programs to see what they expected.

Please also note that the state variables are different for different virtual machines. (That is, each open MS-DOS session got its own copy of state variables.) In the end, each MS-DOS session had a separate current folder , a separate file table, and so on. However, all this was a performance, because the real list of open files was stored in a 32-bit file subsystem. It could not be otherwise, since disk caches should have been reconciled, and file sharing restrictions should be checked globally. If one MS-DOS session opened a file for exclusive access, then an attempt by a program running in another MS-DOS session to open the same file should have completed with an error.

Well, it was a simple case. Difficult case: you had a driver that intercepted an int 21h . I do not know what this driver does, say, a network driver that intercepts input-output for network drives and processes it somehow. Suppose also that some TSR program running in an MS-DOS session intercepted int 21h to print on screen 1 when int 21h is called, and 2 when int 21h ends . Let's trace the access to the local disk (not network, so the network driver does not do anything):


Note that all the work is still done by the 32-bit file subsystem. The call goes through the entire 16-bit chain only to maintain the illusion of the responsibility of 16-bit MS-DOS. In the 16-bit world, only the code set by the TSR and the driver were IFSMGR , plus a small piece of IFSMGR connecting the components. No 16-bit MS-DOS code was executed. The 32-bit file system intercepted all work from MS-DOS.

A similar dance “to intercept normal work, but to allow unusual actions if someone asked for unusual actions” occurred when the I / O subsystem took control of your hard disk from 16-bit device drivers. If the subsystem recognized the drivers, it collected their status and processed all operations in the same way as the 32-bit file subsystem processed the operations instead of 16-bit MS-DOS. On the other hand, if a subsystem did not recognize some kind of driver, it left it responsible for the disk. The component that transmits commands from a 32-bit environment to a 16-bit driver is called RMM .

If you are not lucky enough to use RMM for a disk, you probably noticed that the performance of operations with this disk is terrible. The reason for this is the use of the old clumsy 16-bit driver instead of the fast multi-threaded 32-bit driver. (While the 16-bit driver was processing a single I / O operation, it was impossible to process other I / O, because the 16-bit drivers were not multi-threaded.)

RMM, oddly enough, turned out to be useful for its terrible, because its use was an early sign of infection of your computer with MS-DOS-virus. In the end, MS-DOS viruses did the same thing as TSR and drivers: they intercepted interrupt vectors and take control of your hard disk. From the point of view of the I / O subsystem, they looked exactly like 16-bit hard disk drivers! When people complained about “Windows suddenly started to terribly slow down,” we sent them to the system performance page in the control panel and asked if there was a line “Some disks work in MS-DOS mode” or “All disks use MS-DOS compatibility mode” . If it does, then RMM was responsible for the disks, and if you didn’t change the hardware, it probably meant a virus.

Finally, some parts of MS-DOS were not related to I / O. For example, there were functions for allocating memory, parsing a string with possible wildcards in FCB format, and the like. Such functions were still handled by MS-DOS, since these are just functions of the "auxiliary library" and did not benefit from rewriting in 32-bit code, except the possibility to say "yes, we did it." The old 16-bit code worked fine, and using ready-made code made it possible to maintain compatibility with programs patching MS-DOS to change the behavior of such functions.

The first comment to the original article: “Most impressive is that most of this time (most of the time) actually worked (mostly).”