The Windows NT Architecture
In order to understand how and why Windows NT works, it is important to spend a little time looking at the different pieces of the operating system and how they interact. The NT architecture has three major parts:
The Hardware Abstraction Layer (HAL) is a software interface between the hardware and the rest of the operating system. The HAL is implemented as a dynamically-linked library (DLL) and is responsible for shielding the rest of NT from hardware specifics such as interrupt controllers and I/O interfaces. This abstraction makes NT more portable because the rest of the operating system does not care what physical platform it is running on. Each hardware platform that NT runs on requires a specialized HAL. The design intent is that when NT is ported to a new processor architecture, the HAL gets rewritten for the new processor, but the rest of NT can simply be recompiled, thus making NT extremely portable.
Although the intent of the HAL is to reduce the amount of hardware dependencies and make NT more portable, in reality, it's not always quite so simple, but by minimizing the dependencies on physical hardware characteristics the designers of NT have reduced the time and effort needed to move the operating system to a new platform.
The HAL can only be accessed by components of the NT Executive, and is never called directly by user-mode programs. Also, the HAL is intended to be the only piece of software on an NT system that is permitted to talk directly to the hardware. The advantage is that rogue programs cannot purposefully or accidentally write information to the hardware and cause a system crash. Also, preventing programs from reading information directly from the hardware helps to support NT's security model.
Although the goal in Windows NT is to have all hardware-related calls go through the HAL, the reality is that a small number of device driver and kernel calls bypass the HAL and directly interact with the hardware.
The downside of the HAL model is that it is the biggest single cause of incompatibility with older DOS and Windows programs, which were in the habit of reading and writing directly to hardware. However, this incompatibility is a small price to pay for the protection and portability afforded by the HAL.
The NT Executive takes care of the important tasks that are vital to the entire system. This includes services such as object management, virtual memory management, I/O management, and process management.
The Executive has the following components
On a multiprocessor system, a copy of the kernel actually runs on each processor. Because the kernel is involved in almost every action taken on an NT system, critical portions of the kernel are written in assembly language.
The Security Reference Monitor (SRM) is the bedrock of the all security on a Windows NT system and is responsible for enforcing all security policies on the local computer.
The protected environment subsystems act as mediators between the user-level applications and the NT Executive.
The Environment Subsystems allows Windows NT to effectively act as if it were a different operating system. In Windows NT, there are three protected environment subsystems: Win32, POSIX and OS/2.
Although you might see the Win16 and DOS personalities included in a list of protected environment subsystems, they are actually both part of the Win32 subsystem.
Each environment subsystem keeps track of its own processes and works independently of the other subsystems. Each application can run only in the subsystem for which it was designed. When you launch an application in Windows NT, it examines the file and determines which subsystem to run the application in.
Win32 is the native and primary subsystem for Windows NT. The basis for this subsystem is the Win32 set of APIs, which were written during the development of the NT product. Many of these APIs are direct extensions of their Win16 counterparts.
The POSIX (portable operating system interface) was developed by the IEEE as a standard for use on UNIX systems.
There are many levels of POSIX compliance ranging from POSIX.0 to POSIX.12. These levels represent an evolving set of proposals, not all of which have been ratified as standards.
The POSIX subsystem in Windows NT is POSIX.1 compliant. POSIX.1 compliance requires a bare minimum of services, which are provided by Windows NT. When a POSIX application runs on Windows NT, the POSIX subsystem is loaded and it translates the C language API calls for POSIX.1 support Win32 API calls, which are then serviced by the Win32 subsystem.
Because of the limited nature of POSIX.1, the POSIX subsystem on Windows NT does not provide any support for networking or system security. Many people feel that the inclusion of the POSIX subsytem was really a marketing ploy to increase NT's market penetration.
For the first year and a half of its design, the OS/2 subsystem was scheduled to be the default and primary subsystem for Windows NT. However, when the decision was made to give NT the Windows interface and to build it as the successor for the Windows platform, the emphasis on OS/2 support was diminished.
The result was a second crippled subsystem. The OS/2 subsystem is not able to run OS/2 2.x graphical applications and the OS/2 subsystem only works on Intel-based systems, not on RISC platforms.