[Contents] [Back] [<< Prev] [Next >>]

Windows NT Architecture

The Windows NT operating system was designed to handle applications from other operating systems. This capability was implemented by using environment subsystems.

The applications believe that they are running in their native environment because the environment subsystems provide application programming interfaces (APIs) that the foreign programs can recognize. The environment subsystems translate calls made by the application into commands that the Windows NT Executive can perform for the application.

Windows NT provides two subsystems that provide support for applications meant for other operating systems. The following operating systems are supported:
These subsystems receive all programmatic calls from the applications that they support (see Figure 5.1). They either handle the request themselves or pass the request on to the Windows NT Executive Services or to the Win32 subsystem. The Win32 subsystem handles all error handling, application shutdown, and console applications display.

All basic operating systems’ functions are handled by the Windows NT Executive Services, which resides in the Kernel mode. By being located in Kernel mode, the Executive Services provides stability in that no application can directly access the Executive Services. This prevents a malfunctioning user application from causing a Kernel-mode component from functioning.

All graphics-related requests are passed to the Win32K Windows Manager and GDI component of Executive Services. Using a common executive service ensures that users of applications are provided a consistent user interface.


[note.gif]

The moving of the Win32K Windows Manager and GDI to the Kernel mode is a major change in the Windows NT architecture. In version 3.x of Windows NT, this component was located in User mode. By moving this component to Kernel mode, great enhancements in GUI speed were achieved.

Building each subsystem into the Windows NT architectural model eliminates duplication of services in the environment subsystems. The I/O Manager executive service, for example, handles any disk input/output activity. Having each subsystem rely on the Executive Services makes possible the easier creation of future environment subsystems. It also makes maintenance easier because only Executive Services needs to be updated rather than every environment subsystem.