Go To TechNet Home Page
| Updated: March 13,1996 | Go To TechNet Home Page |
Reprinted with permission from the September/October 1993 issue of DIGITAL SYSTEMS JOURNAL. Copyright 1993 Cardinal Business Media, Inc., 101 Witmer Road, Horsham, PA 19044; (215) 957-1500.
Introduction
System Architecture Overview
Environment Subsystem Details
Binding of Applications to Subsystems
Interaction Between User Applications and Subsystems
Minimizing the Cost of the Client-server Approach
Which Subsystem to Choose?
16-bit Applications for MSDOS and Windows
A Test of the Windows NT Subsystem Design
Please Note
The Microsoft® Windows NT™ operating system, unlike OpenVMS and OSF/1, is a "multiple personality operating system." It was designed to support more than one application programming interface (API). The advantages of this approach are:
1. It is easier to provide emulation for older OS environments; and
2. New or different operating system interfaces can be more easily added without requiring major OS rework.
This approach is not new-it was influenced by the Mach microkernel developed at Carnegie Mellon University (IBM itself is taking this approach with their new 32-bit microkernel OS being developed in Boca Raton, Florida). And, it presents disadvantages versus the more traditional design of OpenVMS and OSF/1.
How does it work? And, has the design met its goals? Let's answer these questions by first taking a look at the overall Windows NT system architecture.
The following figure shows the overall Windows NT system architecture block diagram. There are three main components:
1. The Windows NT Executive & Kernel
2. Environment Subsystems
3. User Applications
The role of the Windows NT Executive is to provide a set of fundamental operating system primitives on which one could build any modern operating system programming interface. Services in this category include process and thread management, I/O, security, memory management, and interprocess communication. The following diagram shows these components and shows the relationship of the Executive to the Kernel and HAL (Hardware Abstraction Layer), two other critical components of Windows NT, which are not covered in this article:
Application programs on Windows NT do not call the Executive directly-in fact, the Windows NT Executive services are not even documented1. Instead, system service calls go through a layer of code that maps the user visible interface to the appropriate Windows NT Executive service. This translation code appears in one of two places:
Since environment subsystems are a key interface between application programs and the Windows NT Executive, let's examine in more detail what they do and how they interact with the rest of the system.
The job of an environment subsystem is to expose to the programmer a set of APIs that make up one particular operating system interface (for example, POSIX or Win32®). Environment subsystems are also responsible for defining the semantics of the process environment and the syntax for device and file names visible to the calling process.
Environment subsystems are implemented as detached, multithreaded user-mode processes that execute concurrently with the user applications boxes shown on the left. This is different from OpenVMS and OSF/1, where the majority of the user visible system services run in a privileged mode as part of the OS executive.
However, this approach has a performance disadvantage because system service calls can require a process context switch, which is not the case on OpenVMS or OSF/1. The techniques Microsoft has applied to minimize this added cost are described below under the subheading "Minimizing the Cost of the Client-Server Approach."
The Windows NT Executive does not impose any process hierarchy-that is left up to the individual subsystems to define. Therefore, each subsystem is responsible for maintaining the process semantics for that "operating system world." For example, when a POSIX process does a fork() call, the POSIX subsystem needs to know about it so it can keep track of parent/child relationships.
This also means that each subsystem only knows about the processes that are in its "world." If you wanted to write a program that displayed a list of all processes running in the system, you could not get that information from a single subsystem. Instead, you would have to look in a system-wide database that was not specific to a subsystem. This kind of information is accessible to user programs through something called the Windows NT Registry. Although the inner structure of the Registry is not fully documented, the source code for a utility that displays system-wide process information (called PVIEW) is included with the Win32 Software Development Kit.
It is also the responsibility of the subsystems to expose how device and filenames appear. For example, the Win32 subsystem uses the "MSDOS®-style" syntax (C:\dir\file.typ). MSDOS-style device names (like A:, B:, C:) are simply symbolic links in the Windows NT I/O system name space to the names that it knows about (such as "Floppy0" or "Disk1"). The POSIX subsystem on the other hand accepts the POSIX-style filename syntax (/dir/file.typ). If someone ever implemented an OpenVMS subsystem on Windows NT, it would accept OpenVMS-style names (for example, DUA0:[dir]file.typ).
Each time you run an application on Windows NT, the subsystem that "owns" that application is notified so it can perform the necessary per-client initialization required to support the new process. This likely will mean creating a thread within the environment subsystem process to handle future requests from this new client.
How does Windows NT know which subsystem to notify when you run an image? This is specified in the Windows NT image header. You specify this at link-time with the Microsoft Linker /SUBSYSTEM qualifier. The currently defined values are (taken from WINNT.H):
IMAGE_SUBSYSTEM_UNKNOWN 0 // Unknown subsystem IMAGE_SUBSYSTEM_NATIVE 1 // Image doesn't require a subsystem IMAGE_SUBSYSTEM_WINDOWS_GUI 2 // Image runs in the Windows GUI subsystem IMAGE_SUBSYSTEM_WINDOWS_CUI 3 // Image runs in the Windows character subsys IMAGE_SUBSYSTEM_OS2_CUI 5 // image runs in the OS/2 subsystem IMAGE_SUBSYSTEM_POSIX_CUI 7 // image run in the Posix subsystem
Because each executable image is tied to one and only one environment subsystem, you cannot mix calls between subsystems. A POSIX program can only call services exported by the POSIX subsystem; a Win32-based application can only call services defined by the Win32 subsystem, and so forth2. This is a restriction that Microsoft has said they will never lift due to the complexities that would be imposed on those that implement subsystems.
This design is a real limitation for POSIX applications on Windows NT, since the first release of the POSIX subsystem does not provide access to services like networking, multithreading, and security. It is not a problem for applications written to the Win32 interface, since that subsystem does provide access to the majority of the Windows NT OS programming features (more on this under the subheading "Which Subsystem to Choose?").
User applications have a client-server relationship With the environment subsystems the application being the client and the subsystem the server.
As a Windows NT-based application makes system service calls, one of two things occur:
1. The call is mapped directly to a Windows NT Executive service; the request is not passed on to the environment subsystem.
2. The type of call requires that it be serviced by the environment subsystem, so a process context switch occurs from the client thread to the matching server thread in the environment subsystem.
What determines the outcome? If the call in any way modifies (or requires access to) the global state of that environment subsystem's "world," then the call must be passed on to the subsystem. One example is process creation-because the environment subsystem must maintain information about all its processes, it needs to know when a user application wants to create a new process.
The other reason why an application system service will turn into a client-server request to a subsystem is screen I/O. This is because the Win32 subsystem owns the display-it is the only subsystem that can perform screen I/O. Therefore, when any type of application (even POSIX or OS/2®) needs to do screen I/O, this will be passed on to the Win32 subsystem.
One potential drawback of the client-server subsystem model is the impact on system performance. Whereas in OpenVMS and OSF/1 a system service call doesn't normally require a process context switch, this is of course much more common with Windows NT. To counter this, Microsoft has taken several steps to reduce both the frequency and the cost for client applications to switch to the environment subsystem. First, when a client application must make a call to the server subsystem, the data passed is not copied from one address space to another-instead, it is stored in a region of shared memory that both the user application and environment subsystem have access to, as follows:
Second, the Windows NT scheduler has been optimized such that in the common case of a thread in a client application needing to make a context switch to its corresponding thread in the environment subsystem, a reschedule operation is not required-just a context switch from client thread to server thread and back again.
Third, graphics calls are buffered on the client side to avoid unnecessary round trips from the user application to the Win32 subsystem. For example, if an application needs to draw a green line on the screen, that requires two Win32 calls: one to set the color and another to draw the line. However, there really is no need to send the "set color" call over to the Win32 subsystem until the actual line needs to be drawn. So, the Win32 client side shareable images automatically "batch" graphics calls to defer sending them to the Win32 subsystem until absolutely required.
You can control the level of batching on a per-thread basis with the Win32 GdiSetBatchLimit() system service. With this call, you specify the number of graphics calls that the system is allowed to buffer. For example, an application that requires real-time display update could set the batching limit to 1 (which disables any buffering). Conversely, applications that perform large numbers of graphics calls but don't need the display updated as each call is executed could set a higher batching limit and then, when a screen update is required, call the GdiFlush() service, which forces any buffered graphics calls to be sent through to the Win32 subsystem.
Windows NT ships with three environment subsystems: Win32, POSIX, and OS/2. The OS/2 subsystem supports OS/2 1.x character mode applications (not OS/2 2.x graphical applications). The POSIX subsystem currently provides only the POSIX 1003.1 system services and no more. This means that POSIX applications on Windows NT cannot currently access services like networking (sockets), security, or multithreading (which is one reason why Microsoft's recommended method for porting UNIX applications is to port to Win32).
If you want to get at the majority of the "new" 32-bit operating system features of the Windows NT Executive, you'll have to use the Win32 subsystem. This makes sense, however, since the other subsystems (POSIX and OS/2) are really just emulation environments that provide interfaces that already exist on other systems.
There are even some services and capabilities in the Windows NT Executive that are not yet exposed by any subsystem-these are there for possible future extensions to the Win32 API. Examples of this include: the ability to allocate a device (like OpenVMS $ALLOC), cancel a pending asynchronous I/O, and mark a file for "erase on delete." These features exist in Windows NT, but are not currently accessible to the programmer.
Contrary to what some articles have shown, there is no separate MSDOS or Win16 subsystem. When you run an MSDOS- or 16-bit Microsoft Windows®-based application, it actually runs as a Win32 process because the program that provides the virtual MSDOS environment, NTVDM.EXE, is implemented as a Win32-based application. Calls made to the 16-bit Windows API are translated to their 32-bit counterpart and execute in the native Win32 subsystem.
Each time your run an MS-DOS-based application, a new VDM process is created to execute the program. Multiple MSDOS-based applications on Windows NT are therefore preemptively scheduled (like regular OpenVMS or OSF/1 processes). Windows-based 16-bit applications, by default, share a single VDM (like on Windows 3.1 on MSDOS today). They are nonpreemptively scheduled (referred to as cooperative multitasking). You can, with Windows NT 3.5, run Windows-based 16-bit applications in their own separate VDMs, however.
The "multiple operating system personality" design of Windows NT was put to the test back in 1989 when Microsoft had a major change in direction for the Windows NT project. Originally, the design goal for Windows NT was to have an OS/2 Presentation Manager® interface (in addition to POSIX.1).
However, after Windows 3.0 took off in late 1989, Microsoft decided to align Windows NT with Windows (see Inside Windows NT, page 4, Microsoft Press®). This necessitated the creation of a new 32-bit Windows-based application programming interface (Win32) and thus the implementation of a new environment subsystem.
Although this was a major change for the group that wrote the OS/2 subsystem, it ended up requiring little change to the Windows NT Executive-positive proof that the environment subsystem approach paid off and that the Executive design was in fact complete.
For more information on the Windows NT Executive and subsystem design, see Chapter 5 of the book Inside Windows NT by Microsoft Press.
Microsoft has said that it expects some day to document these interfaces, but not in the short term. That makes sense for two reasons: 1) the interfaces are likely to undergo change as the system evolves from its first release; and 2) the number of people who would need this documentation is very small.
There is a way for a POSIX and a Win32-based application to exchange IPC messages through the use of named pipes. You can download the sources to this "workaround" on CompuServe® from the MSWIN32 Forum, Library 11. The filename is PSXRPC.ZIP.
© 1995 Microsoft Corporation.
THESE MATERIALS ARE PROVIDED "AS-IS," FOR INFORMATIONAL
PURPOSES ONLY.
NEITHER MICROSOFT NOR ITS SUPPLIERS MAKES ANY WARRANTY, EXPRESS
OR IMPLIED WITH RESPECT TO THE CONTENT OF THESE MATERIALS OR THE
ACCURACY OF ANY INFORMATION CONTAINED HEREIN, INCLUDING, WITHOUT
LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. BECAUSE SOME STATES/JURISDICTIONS DO
NOT ALLOW EXCLUSIONS OF IMPLIED WARRANTIES, THE ABOVE LIMITATION
MAY NOT APPLY TO YOU.
NEITHER MICROSOFT NOR ITS SUPPLIERS SHALL HAVE ANY LIABILITY FOR
ANY DAMAGES WHATSOEVER INCLUDING CONSEQUENTIAL INCIDENTAL, DIRECT,
INDIRECT, SPECIAL, AND LOSS PROFITS. BECAUSE SOME STATES/JURISDICTIONS
DO NOT ALLOW THE EXCLUSION OF CONSEQUENTIAL OR INCIDENTAL DAMAGES
THE ABOVE LIMITATION MAY NOT APPLY TO YOU. IN ANY EVENT, MICROSOFT'S
AND ITS SUPPLIERS' ENTIRE LIABILITY IN ANY MANNER ARISING OUT
OF THESE MATERIALS, WHETHER BY TORT, CONTRACT, OR OTHERWISE SHALL
NOT EXCEED THE SUGGESTED RETAIL PRICE OF THESE MATERIALS.
 |
Click Here to Search TechNet Web Contents | TechNet CD Overview | |
Microsoft TechNet Credit Card Order Form At this time we can only support electronic orders in the US and Canada. International ordering information. |
| Go To TechNet Home Page |
©1996 Microsoft Corporation |  Go To Microsoft Home Page |