User-Mode Components

The user-mode components include everything else, including services (such as the Lan Man Server service, which is used to share resources on the network; the Lan Man Workstation service, which is used to access shared resources; and many other services) and the environmental subsystems, such as the OS/2, POSIX, and Win32. The reason OS/2, POSIX, and Win32 are called environmental subsystems is because each creates an emulation of a particular operating system (the environment) that the applications execute under (MS-DOS, Win16, Win32, and so on). What is important here is that each of these environmental subsystems executes in an entirely different process address space and is, therefore, protected from each other. This means that if a POSIX application crashes, it has no effect on the other applications you may be running.

All of these subsystems are completely isolated from each other and have no communication facilities among one another except through supported RPC functions, such as named pipes or sockets—with two exceptions. First, the Win32 subsystem is responsible for all I/O interaction. This includes the mouse, keyboard, and screen renderings. Every subsystem must request such support from the Win32 subsystem (by using local procedure calls), which is why if the Win32 subsystem hangs, the entire system becomes unusable unless the Win32 subsystem can be restarted (possible, but very unlikely). Secondly, the Win32 subsystem contains the support for your MS-DOS and 16-bit Windows applications. And both 16-bit and 32-bit Windows applications can pass messages back and forth to each other as well as make use of the standard OLE and DDE facilities.

The 16-bit Windows subcomponent is referred to as the Windows on Win32 (WOW) layer and can be restarted without complications (as far as I have seen to date). What’s interesting about these particular subcomponents is that they utilize the Virtual 8086 mode of the Intel processors hardware support to emulate an Intel 8086 (on RISC processors, this emulation is entirely in software). In addition, these subcomponents provide completely independent address spaces for MS-DOS and 16-bit applications to execute under (if desired). Figure 1.2 illustrates the MS-DOS virtual DOS machine (VDM) architecture, while Figure 1.3 illustrates the WOW architecture.

Figure 1.2  The Virtual DOS Machine (VDM) architectural model.

Figure 1.3  The Windows on Win32 (WOW) architectural model.

The OS/2 and POSIX subsystems are similar but less complicated than the VDM and WOW architectures because they are not built on the VDM concept. Instead, they just use the subsystem to directly support the application environment. What is important about the MS-DOS and WOW emulation is to note that in order to directly support hardware access by an application, a virtual device driver must be available to support the emulation of the device and control access to it. This is why many MS-DOS disk utilities fail under Windows NT and why many Windows fax applications (which use virtual device drivers in enhanced mode) fail to execute under NT. It also explains why protected applications (which use a dongle hanging off of the parallel port) fail, as the standard NT parallel port driver does not support access to the required I/O ports in the fashion expected by the protected application. In order to support these applications, the manufacturer must supply a Windows NT virtual device driver (VDD).

Another interesting concept for WOW applications is that, by default, they all run in a shared VDM. This provides the greatest level of compatibility, but if one WOW application fails, it can crash the entire WOW layer. In order to provide additional robustness, at the loss of compatibility, each 16-bit application can run in its own VDM. This provides the ability to preemptively multitask your 16-bit Windows applications, but it prevents these same applications from making use of any shared memory (because they run in their own address spaces). This is one reason why you cannot execute the 16-bit versions of Microsoft Mail and Schedule Plus in separate address spaces (they make use of shared memory).

Windows NT Server’s unique strengths flow from its design. It is not a hybridization of another operating system, nor is it a kludge like some other operating systems I could name. Windows NT Server was designed from the ground up to be a robust and compatible (where compatibility did not interfere with its robustness) operating system. Its compatibility occurs from its environmental subsystems, whereas its robustness occurs primarily from its split architecture and object-oriented design. Another feature, unique to Windows NT, that adds additional robustness to its role as a file server is its file system.