Technical Notes on MS-DOS Components in Windows 95

Many users have wondered whether Windows 95 contains MS-DOS code, and if so, whether that means that Windows 95 is somehow built on top of MS-DOS. Many of these questions relate to how Windows 95 achieves the highest possible degree of compatibility with existing devices and the myriad applications created for MS-DOS and Windows 3.x. Three key questions are answered here:

How does Windows 95 support internal processes and certain application services?
How does Windows 95 reclaim memory from real-mode drivers?
Why does IO.SYS load WIN.COM rather than directly loading VMM32.VXD?

The following services are based on entirely new code created for Windows 95, not revisions to MS-DOS code:

Process and thread memory management
Interprocess communications and synchronization
Preemptive Win32 subsystem
CD-ROM, hard disk, and network I/O services
High-level graphics operations and window management
Printing services

Some functions, however, are handled by MS-DOS code, although the code itself is running in virtual 8086 mode, not real mode. Functions implemented in this manner ensure backwards compatibility with existing real-mode software, such as the Novell® NetWare® client. The following list shows such functions:

Create Program Segment Prefix (function 55h)

Create Temp File (function 5Ah)

Dup File Handle (function 45h)

Exit (function 4Ch)

Get Date/Time (functions 2Ah and 2Ch)

Get DOS Version (function 30h)

International (function 65h)

Set/Get Drive (functions 0Eh and 19h)

Set/Get Program Segment Prefix (functions 50h and 51h)

NetWare Get Station Num (function DCh)

An important example of how Windows 95 reclaims memory from real-mode device drivers is MSCDEX, the CD-ROM driver. After Windows 95 Setup is completed and Windows 95 starts from the hard disk for the first time, special code runs to determine whether the protected-mode CDFS drivers have taken over the CD-ROM drive completely. If so, the real-mode MSCDEX driver in memory is matched to the related lines in AUTOEXEC.BAT, and the MSCDEX entries are then commented out. This provides a trail in AUTOEXEC.BAT to show what has happened. Similar methods are used for other device drivers that Windows 95 knows to be safe to remove, such as other vendors' real-mode disk cache utilities and redundant protected-mode VxDs.

As a final example, some users have wondered whether the fact that IO.SYS loads WIN.COM (rather than loading VMM32.VXD directly) is an indication that Windows 95 is built on Windows 3.x code, with the addition of new virtual device drivers. However, IO.SYS is used to load WIN.COM only for purposes of backward compatibility. Certain real-mode drivers and TSRs insert themselves at various places in the Windows 3.1 startup process. If Windows 95 were to bypass the loading of WIN.COM and instead load virtual device drivers directly, any driver that needs to insert itself when WIN.COM is loaded would never be called. Instead, Windows 95 starts in precisely the same way as Windows 3.1 and loads the same components in the same order, ensuring compatibility with earlier versions of applications and device drivers.