Lesson 2 - Windows NT System Overview
|Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.|
On This Page
What You Will Learn
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:
Identify how the Windows NT architecture supports its goals to be compatible, portable, reliable, scalable, fast, extensible, and capable of distributed processing.
Identify the components of Windows NT in a block diagram.
Explain the relationship between applications, environment subsystems, and the Windows NT executive.
Explain how Windows NT protects itself from misbehaved applications, and how it protects applications from each other.
Explain what multiprocessing is and why it is useful.
Explain why a 32-bit operating system has performance advantages over a 16-bit operating system.
Explain how Windows NT's architecture ensures that it can grow to meet future needs.
What To Do
Parts of Windows NT
Windows NT is a modular operating system. That is, it is a collection of relatively small, self-contained software components (or modules) that work together to perform operating system tasks. Each component provides a set of functions that act as its interface to the rest of the system. Components can call each others' functions to get work done.
Figure 1 shows some of more important Windows NT components and the relationships between them. The responsibilities of these components are described briefly here, and in more detail later in the lesson:
Environment Subsystems--run programs written for several different operating systems as well as Windows NT. Examples are the Win32 subsystem, OS/2 subsystem, and POSIX subsystem.
NT Executive--kernel-mode portion of Windows NT. Does most of the I/O and object management, including security. Does not do screen and keyboard I/O, which is done by the Win32 subsystem.
Managers--modules of the NT Executive that manage I/O, Objects, Security, Inter-process communications (IPC), Virtual Memory, and Processes.
Device Drivers--modules which translate their calls into hardware accesses.
Kernel--manages processor only--more like a microkernel.
Hardware Abstraction Layer--virtualizes hardware interfaces, making Windows NT more portable.
Implementing A System That Meets Its Design Goals
The previous lesson highlighted the features that Microsoft's customers requested for inclusion in Windows NT. It also discussed the design goals established by the Windows NT developers to ensure that the system would support these features. These design goals were:
This lesson will provide an overview of the operating system architecture devised to meet these design goals.
One Operating System With Many Personas
Customers have a lot of money invested in applications written for existing operating systems such as MS-DOS, Windows for MS-DOS, OS/2, and POSIX. Windows NT was designed with the goal of maintaining compatibility with applications written for these operating systems. This was an ambitious goal, because it meant that Windows NT would have to provide the applications with the application programming interfaces (API) and the execution environments that their native operating systems would normally provide. The Windows NT developers accomplished their compatibility goal by implementing a suite of operating system environment emulators, called environment subsystems. The emulators form an intermediate layer between user applications and the underlying NT operating system core (Figure 2).
User applications and environment subsystems work together in a client/server relationship. Each environment subsystem acts as a server that supports the application programming interfaces of a different operating system . Each user application acts as the client of an environment subsystem because it uses the application programming interface provided by the subsystem. Client applications and environment subsystem servers communicate with each other using a message-based protocol (this will be discussed in detail later).
At the core of the Windows NT operating system is a collection of operating system components called the NT Executive. The executive's components work together to form a highly sophisticated, general purpose operating system. They provide mechanisms for:
Virtual memory management.
Each component of the executive provides a set of functions, commonly referred to as native services or executive services. Collectively, these services form the application programming interface (API) of the NT executive.
Environment subsystems are applications that call NT executive services. Each one emulates a different operating system environment. For example, the OS/2 environment subsystem supports all of the application programming interface functions used by OS/2 character mode applications. It provides these applications with an execution environment that looks and acts like a native OS/2 system. Internally, environment subsystems call NT executive services to do most of their work. The NT executive services provide general-purpose mechanisms for doing most operating system tasks. However the subsystems must implement any features that are unique to the their operating system environments.
User applications, like environment subsystems, are run on the NT Executive. Unlike environment subsystems, user applications do not directly call executive services. Instead, they call application programming interfaces provided by the environment subsystems. The subsystems then call executive services as needed to implement their application programming interface functions.
Presenting A Unified User Interface
Windows NT presents users with an interface that looks like that of Windows 3.1. This user interface is provided by Windows NT's 32-bit Windows subsystem (Win32). The Win32 subsystem has exclusive responsibility for displaying output on the system's monitor and managing user input. Architecturally, this means that the other environment subsystems must call Win32 subsystem functions to produce output on the display. It also means that the Win32 subsystem must pass user input actions to the other environment subsystems when the user interacts with their windows.
Support For Existing Hardware
Windows NT does not maintain compatibility with device drivers written for MS-DOS or Windows for MS-DOS. Instead, it adopts a new layered device-driver architecture that provides many advantages in terms of flexibility, maintainability, and portability. Windows NT's device driver architecture requires that new drivers be written before Windows NT can be compatible with existing hardware. While writing new drivers involves a lot of development effort on the part of Microsoft and independent hardware vendors (IHV), most of the hardware devices supported by Windows for MS-DOS will be supported by new drivers shipped with the final Windows NT product.
The device driver architecture is modular in design. It allows big (monolithic) device drivers to be broken up into layers of smaller independent device drivers. A driver that provides common functionality must only be written once. Drivers in adjacent layers can then simply call the common device driver to get their work done. Adding support for new devices is easier under Windows NT than most operating systems because only the hardware-specific drivers need to be rewritten.
Support For Existing File Systems and Networks
Windows NT's new device driver architecture provides a structure on top of which compatibility with existing installable file systems (for example, FAT and HPFS) and existing networks (for example, Novell and Banyan Vines) was relatively easy to achieve. File systems and network redirectors are implemented as layered drivers that plug easily into the new Windows NT device driver architecture.
Protecting The Executive
The Windows NT Executive is central to all major operating system functions. This makes it important to protect the executive from malfunctioning (or malicious) subsystems and applications. The Windows NT developers arranged for the executive to run in a privileged processor mode (called kernel mode), while subsystems and all other applications run in an unprivileged processor mode (called user mode). Because the executive runs in kernel mode, it has access to all memory in the workstation and can issue any machine instructions that it desires. All other code, including that of the environment subsystems, runs in user mode and can only access memory which the executive has given it permission to access.
When a subsystem calls an executive service, the call is routed to a system trap in the executive. The processor is switched from user to kernel mode so that the executive can issue the instructions and access the memory that it needs to execute the requested service. Once the service is complete, the executive switches the processor back to user mode and returns control to the subsystem.
All versions of Windows support multitasking. Windows for MS-DOS implements non-preemptive multitasking. This means that each executable program must voluntarily give up control of the processor on a regular basis to allow other programs a chance to run. If a program fails to voluntarily yield control to other programs, the system will stop responding to user actions and will appear to be hung. Windows NT resolves this problem by implementing preemptive multitasking. That means that the operating system fully controls which program runs at a given time and for how long. Each program is allowed to run for a small quantum of time. When the quantum expires, the operating system saves information about the executing program's state so it can later begin execution where it left off. It then loads the next program for execution. The process of saving one program's state and loading another one's is called a context switch.
On Windows on MS-DOS each program has only one thread of execution (thread for short). The program's code is executed in a single, continuous stream and can do only one thing at a time. On Windows NT, each program can have one or more threads of execution performing different tasks at the same time. For example, a spreadsheet application might dedicate one thread to managing the user interface, another thread to performing background recalculation of a spreadsheet's values. From the application's perspective, both threads execute simultaneously.
All of a program's threads run as part of the same process. Think of a process as a collection of one or more threads whose code and data share the same memory, files, and other system resources. For example, a process might contain two threads that cooperate to process data. One of the threads could transfer data from a file to a memory buffer, and the other thread could read the data from the buffer and process it. Because the threads are in the same process, they share the same memory and can work together easily.
AUTHOR'S NOTE For ease of explanation, this course sometimes implies that processes perform actions (for example, "process A passes a message to process B"). Technically, this is not accurate because processes are passive. This statement is intended to mean "a thread within process A passes a message to a thread in process B". This shorthand is used simply as a convenience.
Protecting Processes' Memory
Each Windows NT process has private address space through which its threads access memory. Within a process, memory looks like a 4 Gigabyte array completely available for its use. (In truth, virtual memory addresses in the upper half of the address space are reserved for access by the NT executive.) Because each process has a separate address space, a thread in one process can not view or modify the memory of another process without special permission.
A thread's view of its process's virtual memory is much simpler than the real arrangement of pages in physical memory (Figure 5). The virtual memory manager translates, or maps, virtual addresses in the process' address space to physical pages in the workstation's memory. In doing so, it hides the physical organization of memory from the process's threads. This ensures that the threads can access its process's memory as needed, but not the memory of other processes.
Communicating Between Processes
Windows NT gives each process a separate address space. This makes the applications and the operating system more reliable, robust, and secure. However, it also makes communication between threads in different processes more difficult because the threads can not view each other's memory or call each others' functions. This problem is most acute for application and subsystem processes which must communicate frequently due to their client-server relationship.
This problem is addressed by channeling communication between processes through a component of the Windows NT executive called the interprocess communication (IPC) manager. The IPC manager provides efficient mechanisms for threads in different processes to send each other messages (Figure 7).
Consider what happens when a Win32 (client) process calls a function that is provided by the Win32 subsystem (server) process:
A message is constructed in the client process. The message specifies which function to execute. The message also contains any data that the server will need to execute the function.
The message is sent from the client process to the server process via the Windows NT executive's IPC manager. The IPC manager retrieves the message from the client process, performs a context switch so that the server process can run, and delivers the message to the server process.
The server process executes the requested function.
The server constructs a reply message to send to the client. The reply message may contain the result of the function's execution.
The server sends the message back to the client via the IPC manager. The IPC manager retrieves the message from the server process, switches back to the client process' context, and delivers the message.
Although the client and server processes can not call each other's functions directly, the IPC manager provides a way for them to accomplish the same thing by exchanging messages. This is possible because the IPC manager runs in privileged (kernel) mode and can see the address spaces of both the client and server processes. The system's security and reliability are never compromised because the unprivileged (user) mode client and server processes are never able to see each other's address spaces.
One Operating System Running On Multiple Platforms
One of the key design goals of the Windows NT operating system was that it should be portable. Three strategies were applied to achieve portability:
Write code in a high-level language.
Isolate hardware-dependent code.
Hide hardware differences.
Most of the source code for Windows NT is written in C or C++. These high-level languages make it relatively easy to port Windows NT to different types of workstations. The same source code can be recompiled to build versions of Windows NT that are specific to each processor's instruction set.
A small amount of the code in Windows NT is written in assembly language. Typically, this is code that either interacts directly with a computer's hardware, or needs to run extremely fast. Because assembly language is specific to a particular instruction set, this code must be rewritten once for each type of processor on which Windows NT will run. To make it easy to locate and maintain, this code is isolated to just a few key places in the operating system:
The kernel is the heart of the Windows NT operating system. It controls which threads are run on the system's processor(s), and provides synchronization mechanisms that allow threads on multiple processors to coordinate their access to operating system data structures. It also dispatches interrupts and exceptions to the appropriate handler routines. To optimize the speed of these system-critical operations, portions of the kernel are written in assembly language.
Operating system code that directly accesses the hardware registers of the peripheral devices is isolated in device drivers. Conveniently, device drivers are written in C for Windows NT so they are portable across different processor types.
The hardware abstraction layer (HAL) is a thin layer of software that hides hardware differences from other layers of the operating system. It accomplishes this by making many different types of hardware look to the rest of the operating system like the same type of virtual machine.
Supporting Multiple Processors In One Computer
Windows NT is a symmetric multiprocessing (SMP) operating system. This means that it can use one or more processors in a computer as long as the processors are of the same type and are similarly configured. All processors are allowed to run a mixture of application and operating system code. In fact, different parts of the operating system can (and often do) run on different processors at the same time.
This arrangement is preferable to that offered by asymmetric multiprocessing (ASMP) operating systems. On ASMP systems, the operating system typically runs on a single processor and user applications run on the remaining processors. As a result, the single processor running the operating system can fall behind the processors running user applications. This forces the applications to wait while the operating system catches up, which reduces the overall throughput of the system.
The hardware abstraction layer hides the details of the symmetric multiprocessing hardware from the rest of the operating system. The Windows NT kernel works with the hardware abstraction layer to manage the multiple processors. The kernel controls which code runs on each processor at a given time. It ensures that the system's processors are always as busy as possible running the highest priority code.
32-bit Code Runs Faster
32-bit flat model code is smaller and faster than 16-bit code because it doesn't have to be concerned with loading segment registers. This also makes programming much simpler!
Windows NT is optimized in many ways to enhance its performance. Some of these ways include:
Caching messages in various ways--message passing is expensive, so Windows NT tries to minimize it.
Using multiple threads--gives advantages of multiple processes without the overhead of separate address space creation.
Lazy evaluation--Windows NT delays expensive operations until they're absolutely necessary in order to save time and memory.
Copy-on-write memory pages--means that two processes can share the same copy of read/write memory with only the pages that are different being distinct. Saves memory.
Subsystems not loaded until needed--saves time by not loading subsystems that aren't used.
Parts of Windows NT Can Be Replaced
Windows NT is designed as a set of modular components. A modular component is a relatively self-contained body of code with a well-defined interface that other components can call to get work done. A modular design allows components (such as device drivers, file systems, and subsystems) to be replaced without affecting the rest of the operating system.
In addition, any number of subsystems can be run at the same time. New subsystems can be written as need and installed on a system without impacting the NT executive or other subsystems. Existing subsystems can be replaced easily by more current ones. The message passing protocol could be extended over a network to allow client and server processes to reside on different machines.
Communicating Over Multiple Networks
A Windows NT workstation can communicate over a network using the services provided by multiple network providers. For example, a single workstation can act as a client on LAN Manager and Novell Netware networks at the same time. This is possible because Windows NT implements network redirectors as installable file system drivers. New network redirectors and protocol drivers can be added easily by simply loading new drivers.
Before Going On
Match each of the following software component names to an appropriate block in the diagram below: Process Manager, OS/2 Subsystem, Security Manager, OS/2 Application, Hardware Abstraction Layer, Memory Manager, Win32 Application, POSIX Subsystem, I/O Manager, Win32 Subsystem, Device Drivers, POSIX Application, Kernel, Object Manager, IPC Manager.
Name one feature of the Windows NT architecture that supports each of the following design goals: compatibility, reliability, portability, scalability, performance, extensibility, and distributed processing, .
What are executive services? Why are executive services generic rather than specific to a particular operating environment?
What is an environment subsystem? Why are environment subsystems used in Windows NT?
What is a client-server relationship? What components of Windows NT work together using a client-server relationship?
Which component of Windows NT supplies the graphical user interface and manages all user input?
What can be done in privileged (kernel) mode that can not be done in unprivileged (user) mode?
Which of the following run in user mode and which run in kernel mode?
Windows NT Executive
What is an address space? Why does Windows NT run each process in a separate address space?
Why do Windows NT applications communicate with subsystems using messages rather than function calls? What are the advantages and disadvantages of this method?
Why is code more portable if it is written in a high-level language?
Why is code more portable if the portions written in assembly language are collected into just a few components?
Which components of Windows NT contain most of the hardware-specific code?
How does Windows NT's hardware abstraction layer (HAL) increase the operating system's portability?
What is multiprocessing? How does it make Windows NT scalable?
How do symmetric multiprocessing and asymmetric multiprocessing differ?
Why is a 32-bit operating system such as Windows NT faster than a 16-bit operating system such as MS-DOS?
What does it mean for Windows NT to be modular?
What is one benefit of Windows NT's layered device driver architecture?
Where do network redirectors fit into the Windows NT architecture?
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:
Application programming interfaces (API)
Thread of execution
Virtual memory manager
Interprocess communication (IPC) manager
Hardware abstraction layer (HAL)
Symmetric multiprocessing (SMP)
Asymmetric multiprocessing (ASMP)
To Learn More
If you're interested in learning more about this topic, you may find the following resources useful:
- Inside Windows NT, Chapters 1 and 2.