Implementation of the Subsystem

The following sections describe the 16-bit Windows subsystem.

VDM Structure

The 16-bit Windows subsystem is implemented as a virtual MS-DOS machine (VDM) with a layer that emulates Windows 3.1 functionality. By default, 16-bit Windows-based applications run in a single VDM, a multithreaded Win32 process in which each application runs in its own thread. Windows NT preemptively multitasks the VDM with respect to other processes but cooperatively multitasks the Win16 apps with respect to each other.

Each Win16 and MS-DOS application can, however, run in its own private address space, thus protecting it from other Win16 programs. This allows Windows NT to preemptively multitask all operating system services and all applications.

To run each Win16 application in its own VDM

1. Right-click the Start button.

2. Click Open.

3. Locate the Win16 application, and click to select it.

4. Click Properties on the File menu.

5. Click the Shortcut tab.

6. Select the Run In Separate Memory Space check box.

7. Click OK.

The following diagram shows the 16-bit Windows subsystem VDM. A description of each layer follows.

Figure 27.1 16-bit Windows Subsystem VDM

The 16-bit MS-DOS emulation layer contains all the information to emulate BIOS calls and tables. Some 16-bit Windows applications depend upon BIOS calls, because 16-bit Windows is built on top of MS-DOS.

The Windows 3.1 emulation layer provides the functionality of the Windows 3.1 kernel and 16-bit API stubs. A 16-bit application cannot call a 32-bit API routine. When an application calls a 16-bit API routine, that call is made to a stub routine, which in turn calls a 32-bit API routine. The 32-bit API routine performs the required action, and the result is transformed back into the format expected by the 16-bit API stub, which returns the result to the application. The transformation between 16-bit and 32-bit formats is known as thunking and is carried out by the 32-bit WOW translation layer. (WOW stands for Win16-on-Win32.)

16-bit Windows-based applications use the memory from 640K to 16 MB for their own purposes.

Windows NT does not support 16-bit device drivers that have unrestricted access to hardware (character-mode device drivers that do not depend on special hardware are supported). A secure and robust multitasking operating system cannot let user-level applications talk directly with the hardware because they could completely bypass security and crash the system. (There are exceptions to this, however; refer to "Restrictions on Win16 Applications," earlier in this chapter). The VDM contains a layer of virtual device drivers (VXDs) that allow the sharing of hardware and provide the necessary functionality in a way that is consistent with the design of Windows NT.

The 32-bit MS-DOS emulation layer is for the DOS Protect Mode Interface (DPMI) and 32-bit memory access. This layer replaces calls made to the MS-DOS-level functions for extended and expanded memory with Windows NT memory calls. Windows NT then makes the appropriate conversions so that the 16-bit application sees segmented memory as it normally would.

For Windows NT running on a non-x86 computer, the Instruction Execution Unit emulates the Intel 80486 instruction set, which lets the computer run the binary application.

On an x86 computer, the Instruction Execution Unit acts as a trap handler, capturing instructions that cause hardware traps and transferring control to the code that handles them. A VDM (such as the 16-bit Windows subsystem) on an x86 computer supports Enhanced mode applications; it does not, however, support 16-bit VXDs (virtual device drivers).

Input Queue

Under Windows NT, each application has its own input queue. This eliminates lockups due to programs halting the queue. Under Windows 3.x, all applications receive input from the same queue. As in Windows 3.x, the 16-bit Windows-based subsystem provides just one input queue. A 16-bit Windows application can lock up the subsystem by halting the queue. This does not affect any 32-bit applications running under Windows NT, as they each have their own input queue.

If, however, you run each Win16 application in its own VDM, each application is then treated by Windows NT as a Win32 application, and each has its own input queue.

Scheduling

Within a VDM, threads are scheduled cooperatively. Because Win16 applications running in a single VDM share memory, a single input queue, and are scheduled cooperatively, an ill-behaved application can cause the subsystem to lock up. This will not affect the rest of Windows NT, because Windows NT treats the VDM as a whole just like any other 32-bit application. Each VDM is scheduled preemptively along with all of the other 32-bit applications. Running each Win16 application in its own private address space causes it to be preemptively multitasked.

Files Used

The following are the principal files used by the 16-bit Windows subsystem: