Lesson 5 - Windows NT Subsystems

On This Page

What You Will Learn
Thinking Ahead
What To Do
Before Going On
Speaking The Language
To Learn More

What You Will Learn

By the end of this lesson, you should be able to do the following:

• Tell what environment subsystems are included with Windows NT and describe their capabilities and limitations.

• Explain how various the various subsystems and applications interact with each other and the Windows NT executive.

• Describe how the subsystem architecture of Windows NT allows subsystems to be implemented relatively easily and efficiently.

• Explain how what interoperability features Windows NT supports and describe at a high level how they're implemented.

• Tell whether code written for other operating systems is binary compatible, source compatible, or not compatible with Windows NT running on different processor platforms.

• Describe the drivers necessary for MS-DOS and Windows 3.1 programs to be able to access devices under Windows NT.

Using knowledge learned in this module, you'll be able to explain the following:

• Why a hung Win16 application freezes all Win16 apps but not any other apps.

• Why you can exchange data in any format (including using DDE and OLE) between Win16 and Win32 apps but only in text format between other types of apps.

• Why MS-DOS and Windows programs that directly access non-standard devices might not work under Windows NT and what will need to happen before the program can work.

Thinking Ahead

What To Do

Running Many Different Types Of Applications

Several of the major goals for Windows NT centered around the need for it to many different types of applications seamlessly on the same graphical desktop. Windows NT runs applications written for existing operating systems such as MS-DOS, OS/2, and Windows 3.1. It is also runs applications written to newer application programming interfaces such as POSIX and Win32.

Windows NT supports this variety of applications through the use of environment subsystems . Environment subsystems are Windows NT processes that emulate different operating system environments. The Windows NT executive provides generic services that all environment subsystems can call to perform basic operating system functions. The subsystems build on the executive's services to produce environments that meet the specific needs of their client applications. Implementing common operating system functions once (in the Windows NT executive) and separating them from environment-specific features (in the environment subsystems) reduces the effort required to develop new environment subsystems and makes it easier to maintain them. An idealized view of the Windows NT subsystem architecture is shown in Figure 1.

Applications and environment subsystem have a client/server relationship. The subsystems (servers) provide services that applications (clients) utilize. Client and servers communicate using messages that they send via the Windows NT executive.

Strengths Of The Subsystem Architecture

Using user-mode environment subsystems to implement operating environments provides a number of benefits:

• Compatibility--users can continue to use applications written for other OS's.

• Extensibility--subsystems can be added later.

• Maintainability--subsystem changes and Windows NT changes don't affect other parts of Windows NT.

• Reliability and robustness--since subsystems run in separate address spaces, they're safe from each other.

Each subsystem can emulate a different operating system, and new subsystems can be added as needed and dynamically loaded.

With the exception of the Win32 subsystem, environment subsystems are optional and are only loaded when their services are required by a client application.

Implementation details of each subsystem are isolated. Changes to the subsystems don't effect code in the executive. Changes to executive services don't affect code in the subsystems (unless interfaces change).

Each subsystem runs as a separate user mode process, so it can't crash other subsystems or the executive. Applications are also user mode processes, so they can't crash the subsystems or the executive. If one subsystem does crash, the others are unaffected (unless it's Win32, which handles keyboard and mouse input and screen output for all subsystems).

Challenges Introduced By The Subsystem Architecture

The implementation of operating system environments as user-mode processes that run in their own address spaces raised various issues, including how to:

• Hide Client/Server Message Passing.

• Optimize Performance.

Hiding Client/Server Message Passing

Applications and environment subsystem have a client/server relationship. The subsystems (servers) provide services that applications (clients) utilize.

Applications communicate with servers by passing messages via the Windows NT executive's local procedure call (LPC) mechanism. The message passing process is hidden from the client applications by function stubs provided in special dynamic link libraries (DLL) (Figure 2).

Consider an example of how this process works in the Win32 subsystem. When a Win32 application is loaded for execution, it is linked to a dynamic link library that contains stubs for all of the functions in Win32 application programming interface. When the application calls a Win32 function, for example CreateWindow(), the call is processed as follows:

• The CreateWindow() stub function in the DLL is called.

• The stub function constructs a message that contains all of the data needed to create a window and sends the message to the Win32 server process.

• The Win32 server receives the message and calls the real CreateWindow() function. The window is created.

• The Win32 server sends a message containing the results of the CreateWindow() function back the stub function in the DLL.

• The stub function unpacks the server's message and returns the results to the Win32 application.

From the application's perspective, the CreateWindow() function in the DLL created the window. The application does not know that the work was actually performed by the Win32 server process, that a message was sent to make it happen, or even that the Win32 server process exists!

Client/server messaging is hidden from client applications of all environment subsystems in a similar manner.

Optimizing Message Passing Performance

The cost of separating applications and servers into separate address spaces is that a context switch must be performed every time a message is passed from a client application to a server. Context switches are expensive, so the object is to avoid them.

Client-Side DLLs avoid sending messages except when necessary:

• If a function in the DLL can handle an operation itself, it does. (e.g., caching of attributes)

• If it can call executive services directly to handle the operation without the server's help, it does (executive calls require system trap but no context switch).

• If it must call the server, it may batch several messages and combine them all in a single message.

When a message MUST be passed, it is handled as efficiently as possible:

• Context switching code is optimized for speed.

• Special message passing mechanisms are used to optimize performance for different situations (e.g., small and large messages).

Support for MS-DOS and 16-bit Windows Applications

You have probably noticed that the Win32, OS/2, and POSIX servers have consistently been used as examples in our discussion of environment subsystems. In contrast, MS-DOS and 16-bit Windows have not been mentioned. This is because MS-DOS and 16-bit Windows applications (sometimes called Win16 applications) are not supported by their own environment subsystems running in separate user-mode processes. Instead, they are supported by special Win32 applications called virtual (MS-)DOS machines (VDM) . VDMs provide MS-DOS and Win16 applications with an execution environment that looks to them like native MS-DOS.

The relationship between VDMs, the MS-DOS and 16-bit Windows applications that they support, and the Win32 subsystem is shown in Figure 3.

The Structure Of A Virtual DOS Machine (VDM)

A virtual DOS machine is a Win32 application designed to emulate an Intel 80286 PC running MS-DOS operating system. Emulating MS-DOS on Windows NT is a real challenge for several reasons:

• MS-DOS is completely unsecure. Applications written for MS-DOS often try to manipulate the computer's hardware directly. They expect free access to the computer's memory, including the areas where operating system code and data structures reside. These needs conflict with the requirement for Windows NT to be a secure operating system.

  Windows NT solves this problem by protecting itself from VDM's and by running each MS-DOS application in its own VDM (so that they're protected from each other).

• MS-DOS is a 16-bit operating system. It accesses memory using segmented addresses. Windows NT accesses memory using a flat, or unsegmented, memory addresses.

• The application programming interface for MS-DOS relies on Intel 80x86-specific machine instructions that invoke software interrupts. Windows NT is a portable operating system designed to run on processors that do not support the Intel 80x86 instruction set.

The software components that reside in a virtual DOS machine are shown in Figure 4.

The lowest 16Mb of the VDM uses 16-bit segmented addressing to access memory. It contains MS-DOS emulation code and MS-DOS applications.

The upper areas of the VDM use 32-bit addressing. The 32-bit MS-DOS emulation code calls Win32 and Windows NT executive services to perform functions normally provided by MS-DOS itself. The VDDs interact with the native Window NT device drivers to perform device I/O.

Each MS-DOS application runs in its own VDM to mimic the single-tasking nature of native MS-DOS. It can access memory just as it would on a native MS-DOS system. Its attempts to directly access hardware devices are intercepted and processed by appropriate virtual device drivers , which translate those attempts into Windows NT API calls. Running MS-DOS applications in separate VDMs also increases the overall robustness of Windows NT. The worst that an MS-DOS application can do is to crash its own VDM, which has no negative impact on other applications or Windows NT as a whole. Since each MS-DOS application has a single thread, they can be preemptively scheduled for execution just like any other processes in the system. The failure of one process does not affect the others.

The Structure Of A WOW Virtual DOS Machine

The basic environment used to run Win16 applications is a virtual DOS machine. A VDM used to run Win16 applications contains an extra layer of software, called the Win16 on Win32 (WOW) layer (Figure 5).

Some components, like the 16- and 32-bit MS-DOS emulation code and the VDDs are the same as those found in the VDM used to run MS-DOS applications.

The 16-bit Windows kernel code used in the WOW layer is derived from Windows 3.1's standard mode (Intel 80286) kernel. Note the WOW emulates Windows in STANDARD, not enhanced mode. That means that Windows programs that rely on enhanced mode are not supported. (This may change as soon as product one for Intel processors only.)

The 16-bit User and GDI code is just a series of stubs that call 32-bit thunking functions. Win32's User and GDI API are a logical superset of their Windows 3.1 counterparts, so there is an easy 1-1 mapping from the 16-bit stubs to 32-bit User and GDI functions.

A single VDM is shared by all Win16 applications. This is done to emulate the native Windows 3.1 environment in which multiple Win16 applications coexist in a single address space. It also allows the WOW layer to mimic the non-preemptive multitasking environment expected by Win16 applications. Each Win16 application does get its own thread; however, the WOW layer insures that only one Win16 application's thread is active at any given time, so the effect is the same as if only one thread had been used.

Running all Win16 applications in the same VDM provides maximum compatibility with the native Windows 3.1 environment. However, this compatibility has a cost. It forces the WOW VDM to have the same weaknesses as Windows 3.1. It allows Win16 applications to inadvertantly (or intentionally) access memory that is belongs to other Win16 applications or to WOW, with potentially disasterous effects. It also allows a single Win16 application that does not yield control of the processor to effectively crash all other Win16 applications. Even so, a crashed Win16 application does not affect the other VDMs, nor does it affect applications running under other subsystems.

The WOW VDM can be started when a user logs on for an interactive session, or loaded automatically when the first Win16 application is run in the session. When additional Win16 applications are invoked, a message is sent to the WOW VDM and the application is loaded and run.

Intel Emulation On Non-Intel Platforms

Computer users own millions of copies of applications written for MS-DOS and Windows for MS-DOS. All of these applications contain non-portable 80x86 machine instructions. One of the goals of Windows NT was to make these existing applications run on all Windows NT platforms, including those that do not natively support 80x86 machine instructions.

To support this goal, versions of Windows NT developed for non-Intel computers contain code that emulates Intel 80286 machine instructions using the computer's native machine instructions. When a MS-DOS- or Win16-based application is run on a non-Intel platforms, each instruction the application executes is emulated by one or more instructions in the processor's native machine language. The process of emulating these instructions consumes processor time, and slows the application's execution. However, since RISC processors are several times faster than an 80286, the decrease in performance is small (if there is one at all). For many users, the ability to run their existing applications on non-Intel platforms is worth a small decrease in performance.

MS-DOS and Win16 applications are said to be binary compatible across all Windows NT platforms because all versions of Windows NT can execute the same binary image. OS/2 character mode applications are binary compatible across all Intel 80x86-based Windows NT platforms. However, they are not supported on non-Intel platforms because of limitations in the Intel 80286 emulation software. Win32 and POSIX are portable application programming interfaces. Applications written to these application programming interfaces are said to be source compatible across all Windows NT platforms. This means that the same source code can be recompiled to create different binary images for each Windows NT platform.

Application Compatibility Across Windows NT Platforms

Presenting A Seamless User Interface

One goal for Windows NT was that all types of applications should run seamlessly on the same graphical desktop. The only practical way to make this work is to have all of them use the same method(s) of producing graphical output and obtaining user input. As a result all subsystems rely on Win32 subsystem for these services (Figure 7).

The Win32 subsystem is an integral part of the Windows NT operating system. It has exclusive responsibility for producing graphical output and collecting user input. Win32 manages all of the windows on the screen. Should the Win32 subsystem crashes, the entire user interface would be disabled.

The Win32 subsystem provides two different application programming interfaces for producing output on the display - the console API and Windows Graphical Device Interface (GDI).

Console Applications

The console API allows character oriented applications to create windows that look very much like the MS-DOS command window in Windows 3.1. The console API allows applications to display characters and line drawings in a window and retrieve keyboard and mouse input.

Typically, console applications display simple textual information such as the time of day, the names of files in a directory, or the occurances of a text string with a file. Because the Win32 console API is used to manage I/O for all four types of character-oriented applications (MS-DOS, OS/2, POSIX, and Win32 console applications), these applications look and behave very similarly (Figure 8). In addition, users can also cut and paste text between any applications, even applications running under different environment subsystems.

All Character Mode Applications Use Win32 Console I/O

Graphical Applications

Graphically oriented applications, such as the File Manager and Program Manager, are displayed using the rich set of tools provided by the Windows graphical device interface (GDI) and window manager . Both 16-bit and 32-bit Windows applications are drawn on the display using Win32's GDI functions. As a result, you can not distringuish Win16 applications from Win32 applications simply by looking at them. In addition, you can freely cut and paste and even use OLE and DDE between both Win16 and Win32 applications

Win32 GDI Is Used By 16- and 32-bit Windows Applications.

Application Interoperability

One of the strengths of Windows is its support for sharing data between applications. All Windows NT applications can share data using the Windows clipboard. In addition Win16 and Win32 applications can share data using the dynamic data exchange (DDE) and object linking and embedding (OLE) protocols. This level of interoperability is possible because all of the subsystems rely on the Win32 subsystem for their interactions with the user.

Clipboard Interface For Win32's Console Windows

MS-DOS, OS/2, and POSIX applications use Win32's console windows to manage their graphical output and user input. Win32 console windows provide an Edit menu that allows users to transfer characters from a console window to the clipboard, and transfer characters from the clipboard to a console application's input buffer (Figure 10). The console windows manage the transfer of information to and from the clipboard in a way that is transparent to the application running in the window. As a result, applications that use Win32's console windows get the clipboard interface "for free."

As discussed earlier, Win16 applications are supported by the WOW layer, which runs in a special type of Win32 application called a virtual DOS machine. When an application calls a Win16 function, the WOW layer intercepts the call and passes control to the equivalent Win32 function. As a result, Win16 applications implicitly use Win32 functions for everything that they do. From the perspective of the Win32 subsystem, the WOW VDM is just another Win32 process that uses 32-bit DDE, OLE, and clipboard functions to communicate with other processes.

Collecting User Input

The Win32 subsystem is responsible for collecting all user input and delivering it to the appropriate applications. The Win32 input model has been optimized to take advantage of Windows NT's preemptive multitasking capabilities (Figure 11).

When Win32 receives user input it stores it in a single raw input queue. As soon as it can, it transfers the input to the input queue for the appropriate thread. If a thread stops retrieving its messages, no other threads are affected..

All input for WOW (Win16) apps sits in a common input queue. All apps but one are blocked at a given time, and if the executing app stops retrieving input, all WOW apps are stay blocked--just like Win3.1.

Before Going On

Before you go on, make sure you can answer the following questions:

1. What environment subsystems are supported by Windows NT?

2. How does the Windows NT executive's design allow each environment subsystem to provide a different process structure to its clients?

3. List a benefit gained because Windows NT's subsystems have separate address spaces from each other, from applications, and from the Windows NT Executive.

4. Draw a diagram depicting the following parts of Windows NT and their relationships to each other: the NT Executive, the Win32 subsystem, the OS/2 subsystem, the POSIX subsystem, virtual DOS machines, and the WOW layer. Use arrows to indicate how messages are passed between components. In addition, show how applications relate to their environment subsystems.

5. List two ways that the Windows NT subsystem architecture has been optimized for good performance.

6. What is a Virtual DOS machine? What processor does it emulate most closely?

7. What is a VDM virtual device driver? What do VDM virtual device drivers do?

8. What undesirable behaviors occur because all Win16 applications share the same address space and input queue and are non-preemptively multitasked? Why was that design decision made?

9. Fill in the compatibility chart below to indicate whether applications originally written for the following operating systems are binary compatible (B), source compatible (S), or not compatible (N), with Windows NT on Intel and non-Intel platforms: Win16, MS-DOS, OS/2 1.x, POSIX, Win32.

   Win16	MS-DOS	OS/2 1.x	POSIX	Win32
   Intel
   non-Intel

10. How can Win16 and MS-DOS applications run on a non-80x86 processor (such as MIPS or Alpha)?

11. Why might a given MS-DOS or Win16 application not run under Windows NT even though it runs under Windows 3.1 or MS-DOS.

12. What type or types of data exchange are supported between all applicaitons running under Windows NT? What types of data exchange are supported only among Win16 and Win32 applications? What part of Windows NT environment subsystem design allows these data exchanges?

13. How can you tell if a given application is a Win16 or Win32 application when running it under Windows NT?

14. How does desynchronizing the Windows input model improve Windows NT's responsiveness and robustness?

Speaking The Language

This lesson introduced terms that it is important for you to understand. Please look through the list and verify that you understand the meaning of each term:

• Environment subsystems

• Local procedure call (LPC)

• Procedure stub

• Dynamic link libraries (DLL)

• Virtual (MS-)DOS machines (VDM)

• Virtual device drivers

• Win16 on Win32 (WOW) layer

• Binary compatible

• Source compatible

• Console

• Graphical device interface (GDI)

• Window manager

To Learn More

If you're interested in learning more about this topic, you may find the following resources useful:

• Inside Windows NT chapter 5.