Some of the main topics in this chapter are
The only people who truly have to understand operating system design and architecture are the programmers and systems designers who design and produce operating systems. Nevertheless, understanding the inner workings of your operating system, at least on a cursory level, can help you use the operating system to best advantage.
Windows NT uses two different processor modes--kernel mode and user mode. Kernel mode is a privileged processor mode in which running code has extensive access to the hardware and system data. User mode is a non-privileged processor mode in which code has only limited access to system data and must access hardware through various operating system services. Some Windows NT operating system components run in kernel mode, and others run in user mode.
Windows NT uses a client/server model to separate various operating system components. Object management, security, local procedure calls, process management, memory management, and I/O are low-level components that make up the Windows NT executive, which runs in kernel mode (see Figure 2.1). For more information about the executive, refer to the section "The Executive," later in this chapter.
Also running in kernel mode is the Hardware Abstraction Layer (HAL). The HAL provides a low-level interface between the executive and the system's hardware. For more information regarding the HAL, see the section "The Hardware Abstraction Layer (HAL)," later in this chapter.
Windows NT's client/server model relies on kernel mode and user mode to segregate operating system functions.
NOTE: Because the HAL is self-contained, it can be revised to support a different hardware platform. This means that the executive can remain relatively unchanged while the HAL is rewritten to support a different hardware platform, simplifying Windows NT's portability. Protected subsystems that interact with the executive conceivably could require little modification to work with the new platform.
Although the executive and HAL run in kernel mode, Windows NT's various protected subsystems run in user mode. Placing these subsystems in user mode isolates them from low-level access to the system's hardware and data. This isolation makes the operating system more reliable and secure because these subsystems can access the system only through the executive. The importance of this separation will become clearer as you read more about the operating system components and how they interact.
The HAL forms the lowest level of the Windows NT operating system. The HAL does just what its name implies--it inserts a layer of abstraction between the computer's physical hardware and the executive components. The HAL is platform-specific, containing code to enable it to communicate with and control the hardware on which Windows NT is running. For example, most of the code that differentiates the MIPS version of Windows NT from the Intel version resides primarily in the HAL. Hardware-dependent functions such as I/O interfaces, interrupt controllers, and multiprocessor communication are buried deep in the HAL, isolated from the other parts of the operating system.
Protected subsystems and applications work through the executive to access hardware, and the executive works in turn through the HAL, so the HAL ultimately controls all hardware access.
The executive, as explained previously, comprises a set of components that form the core of the Windows NT operating system (see Figure 2.2). These components are of two types: system services, which subsystems and other executive components can call, and internal routines, which can be called only by other executive components.
The executive forms an abstraction layer between subsystems/applications and the HAL.
Each of the executive components provides an API-like interface through which it communicates with other components and through which the operating system's subsystems and applications communicate with the executive components. In effect, the executive components function like servers, with the subsystems functioning as clients. The executive components can also function as clients when they are communicating with other executive objects.
Each executive component is independent from the other components. For this reason, an executive object can be removed and replaced by a new version to add new features to the operating system without affecting other executive components. As long as the new version of the component provides the same services and interfaces to enable the other components and subsystems to communicate with it, the operating system continues to function. For example, Windows NT developers could write a new security reference monitor to add new security features without affecting other components. For more detailed discussion of the executive components, see the section, "Exploring the Executive," later in this chapter.
The parts of Windows NT that run in user mode are its protected subsystems (see Figure 2.3). Protected subsystems get their name from the fact that each is a separate process that runs in its own address space, which means that each is protected from the others (and from errant applications) by the Windows NT virtual memory manager. If a Win32 client somehow succeeds in destabilizing the Win32 subsystem, for example, the security subsystem is unaffected.
Protected subsystems communicate with one another through the executive.
Windows NT's protected subsystems provide APIs to enable communication between subsystems and with applications, enabling subsystems to act as servers (reinforcing the client/server model). An application or another subsystem makes an API call to the executive, and the local procedure call (LPC) facility in the executive translates the call to the server. The server replies to the call, and the LPC routes the message back to the caller.
The protected subsystems are separated into two types: integral subsystems and environment subsystems. Integral subsystems subsystems are those protected subsystems that provide system-wide services. An example of an integral subsystem is the security system. The security system handles all security authentication, such as logon and file access.
In addition to the integral subsystems, Windows NT's protected subsystems include environment subsystems. Environment subsystems, as mentioned in the previous section, are those that provide an application execution environment. The Win32 subsystem is the primary environment subsystem in Windows NT and is the one through which all other environment subsystems process user I/O (keyboard, mouse, and video, for example).
NOTE: The Win32 subsystem handles all user/program I/O. All keyboard entry, for example, is handled by the Win32 subsystem, even if that keyboard activity occurs within a DOS console window or Win16 program.
Besides the Win32 subsystem, Windows NT includes a POSIX subsystem, Win16 subsystem, and MS-DOS subsystem (see Figure 2.4).
The environment subsystems run as separate processes, each within its own private address space. Just as Windows 3.x is an application that runs on top of the DOS operating system and provides Windows applications with an operating environment in which to work, so do these environment subsystems run as applications on top of the Windows NT core operating system (the kernel) and provide their own application execution environments. When a core operating system function is required, either by an end-user application or one of the environment subsystems, the subsystem in question turns control of the executing thread over to the executive. When the function is complete, the executive returns control of the thread to the subsystem. The executive schedules the subsystems' threads in the same way as for other applications, which means that the environment subsystems all multitask.
By providing self-contained execution environments, Windows NT ensures that a program failure in one environment subsystem won't affect another subsystem. If you're running a Win16 application, for example, and it fails, it won't take down any Win32 applications that are running.
NOTE: Even though the environment subsystems are isolated from one another, they don't operate in a vacuum. Because all user I/O is processed through the Win32 subsystem, the other environment subsystems can communicate with one another and share data through the Clipboard.
The environment subsystems serve as an abstraction layer between user applications and the kernel.
Structuring the environment subsystems as distinct user processes instead of incorporating their functions into the kernel is an important facet of Windows NT's reliability and extensibility:
An important feature of Windows NT for an increasing number of users is its scalability, which is the capability of the operating system to run on systems with multiple processors. As hardware prices drop, the cost of systems containing multiple processors naturally drops, making them increasingly more attractive for users with demanding applications.
A single-processor computer does not actually multitask. Instead, processes (such as user programs) share the single CPU's time on a rotating, prioritized basis. Because the CPU can switch between processes so quickly, the programs seem to run at the same time.
Multiprocessor systems, which contain two or more CPUs, use one of two methods: asymmetric multiprocessing (ASMP) or symmetric multiprocessing (SMP), shown in Figure 2.5. In an asymmetric multiprocessing system, one processor is dedicated to running the operating system code, and user threads are handled by one or more other processors. In a symmetric multiprocessing system, processor load is distributed more evenly, with user threads and operating system threads running on any available processor.
Windows NT uses the symmetric multiprocessing (SMP) model.
Although ASMP is easier to implement in an operating system, ASMP introduces a potential performance bottleneck by placing the burden of running the operating system on a single processor. Although the CPU handling the operating system might be operating at maximum capacity, the other processors might be relatively idle, wasting their processing capability.
An SMP system, however, increases throughput by equalizing the burden of running both the operating system and user threads across all processors. Moreover, with SMP, multiple threads of a single process can run on separate processors. A program might have a graphics-related thread running on one processor, a computationally intensive thread running on another, and a printing thread running on a third. This capability to schedule threads on multiple processors improves the program's performance.
As previously explained, Windows NT's kernel comprises the HAL and the executive. The HAL handles hardware-specific functions, and the executive provides the set of core operating system functions that enable user-mode processes to communicate with the hardware and one another.The executive has six components, which are explored in the following sections.
An object is a single runtime instance of a statically defined object type. An object type comprises a system-defined data type, a set of services that operate on that data type, and a set of attributes that define the object and the data it contains. In effect, objects are like black boxes: accepting input, providing output, but you have no idea what goes on inside. A program can interact with an object and use the data contained in it without knowing anything about the internal structure of the object type. Instead, the program (including the operating system) uses the object's attributes and services to use the object and its data. For this reason, the object can be modified and enhanced internally without affecting processes' capability to work with the object.
NOTE: In Windows NT, not all data structures are encapsulated in objects. Data structures used internally by an executive component and not shared with other executive components or required by user-mode processes are not structured as objects. Only those data structures that must be named, secured, shared, or visible to other components and processes are created as objects.
The component of the executive that manages objects is called, appropriately, the object manager. The object manager creates, tracks, protects, and deletes objects. Placing the responsibility for object management in a single component of the executive achieves a variety of objectives. For example, the object manager provides a common mechanism for managing system resources (such as memory). The object manager also plays a critical role (as sole manager) in protecting objects, ensuring data security and integrity. Because access to all objects occurs through the object manager, an errant program can't corrupt an object by handling it directly, nor can a process gain access to an object without necessary security authorization.
The object manager also enables the operating system to audit the use of objects, which means that usage limits can be set on specific objects, preventing a process from taking control of a resource or using it excessively at the expense of other processes.
Windows NT supports two types of objects: executive objects and kernel objects. Executive objects are maintained by the executive's components and are accessible to user-mode processes. Executive components and user-mode protected subsystems can create and manipulate executive objects.
Kernel objects are created and manipulated only within the executive by the various executive components. Kernel objects are not visible or accessible to user-mode subsystems. Kernel objects provide low-level features and define low-level entities within the operating system.
Objects consist of two parts: an object header and an object body (see Figure 2.6). The object header stores variable data about the object, and the object body stores static data about the object. For standardization and simplicity, every object has a consistent set of object attributes that enable the object manager to manage the object. These attributes include the object's name, security descriptor, type (kernel or user), and other common information about the object. These attributes are contained in the object header. Static information that is specific to the object type, such as size, is stored in the object body.
An object comprises an object header and object body.
The object manager is responsible for general object manipulation such as creating, naming, protecting, and deleting objects. Other executive components work through the object manager to define and access objects, but the object manager does not have complete control over objects. Other executive components provide services to manage objects that they define. The I/O manager, for example, provides services that enable other executive components and user-mode subsystems to handle files. The I/O manager calls the object manager to create a file object, passing it the necessary parameters to define the file object. The object manager then creates and protects the object, but the I/O manager provides the services by which other processes use the object.
The security reference monitor is the kernel-mode portion of Windows NT's security system. The security reference monitor is responsible for providing security authentication and auditing for operating system resources.
Consider an example in which you attempt to open a file with a program. The first part of the whole authentication process for opening the file actually begins much earlier, when you log on. The security subsystem validates your user ID and password in the security database. If your ID and password are valid, the security subsystem creates an access token object and attaches it to your process. The access token contains security-related information derived from your user account. The security ID attribute in the access token object is your user ID. Other attributes in the access token object include your group IDs (memberships) and privileges.
When you attempt to open the file, your program makes an API call to the Win32 environment subsystem. Win32 calls the object manager to open the file, passing it your access token. Object manager calls the security reference monitor, which also uses the access token, comparing it with the security settings for the file to determine whether you have the authority to perform the requested operation on the file. If so, the file is opened. If not, an error message is generated to inform you that you do not have the necessary access privileges.
Authenticating a user's access privileges to various objects is not the security reference monitor's only function. The security reference monitor provides similar security functions for executive components that attempt to create, access, or modify objects. In addition, the security reference monitor is responsible for security auditing--adding security audit events to the appropriate system logs, and when configured to do so, also generating audible or visual cues to the system administrator when security events occur.
Entries in the ACL are called access control entries (ACE). Each ACE includes a security ID (such as a user or group name) and a list of access privileges that apply for that security ID (see Figure 2.7). An ACL can contain multiple ACEs because you (and operating system components) can assign multiple levels of access for various objects.
A process comprises an executable program with initial execution code and data, a private address space for the process's use, needed system resources such as I/O ports and files, and at least one thread. A thread is essentially a unit of execution--a logical, executable portion of a program. Printing a spreadsheet is a good example of a thread within a process. The spreadsheet program constitutes the overall process (along with address space, resources, and so on), and the task of printing the document is one thread of execution.
The process manager is the executive component responsible for creating and managing processes and their threads. In reality, the process manager's primary function is working through the object manager to create process and thread objects on behalf of the environment subsystems. The process manager also is responsible for destroying (through the object manager) those process and thread objects.
An access control list comprises the access control entries that define how an object can be used and by whom.
The local procedure call facility (LPC) component of the executive is responsible for handling communication between client and server processes, such as between executive components, subsystems, and user processes (programs). When an environment subsystem calls the process manager to create a thread, for example, the call comes through the LPC to the process manager. The process manager sends a call through the LPC to the object manager to create the thread. The reply from the object manager comes back through the LPC to the process manager, which then communicates back to the environment subsystem through the LPC.
The LPC is modeled after the industry-standard remote procedure call (RPC) facility that enables processes on different computers to communicate with one another. LPC is optimized specifically for processes running on the same computer.
Two primary types of memory come into play in today's personal computers: physical memory and virtual memory. Physical memory refers to the actual memory locations in the computer's RAM and consists of 1-byte storage units. Each byte has an address to identify it uniquely, much like the numbers on a house identify its address. Each byte is numbered starting at zero and continuing incrementally to the last physical byte.
Virtual memory refers to the way in which the physical memory is structured and managed by the system and is not tied to the physical memory structure or capacity. Each process is allocated its own virtual address space, which is a range of memory addresses the process can use. The range of addresses in the virtual address space can exceed the amount of physical RAM in the computer. The computer might contain 16M of RAM, for example, but the process might be allocated as much as, say, 4G of virtual memory.
It's therefore the function of the virtual memory manager (VMM) to map sections of the process's virtual memory address space to physical address space. It's unlikely that you'll have 4G of RAM in your computer in the near future, so the VMM can obviously only accommodate a portion of the virtual address space in physical memory. The second function of the VMM is to swap the contents of physical memory to disk when the amount of available physical RAM is insufficient to accommodate the amount of virtual memory needed. By swapping the contents of the virtual memory to disk, the VMM makes it seem to the process that the computer and the process itself actually have 4G of physical RAM available to them.
This swapping is like presenting an entire book to a reader by using only two pages of erasable paper, one visible to the reader and one invisible. When the reader finishes with the current page (the data in memory), you copy it to the spare, invisible page (to disk). Then you write the next requested page of data to the visible page. If the reader wants to thumb back to the previous page, you swap the contents of the visible page for the invisible page. The VMM simply accomplishes a similar task with memory pages, swapping pages in memory for pages on the disk.
In addition to mapping memory address space, the VMM also enables processes to share memory. If two processes need to access the same data, the VMM copies the data into a range of physical addresses. Then the VMM simply maps the virtual address spaces of both processes to the same range of physical memory.
Finally, the VMM is responsible for protecting memory. It's a certainty that multiple processes will always be running on your computer, each requiring its own address space. It's also a certainty that these processes will be using different ranges of physical memory at one time. It's the VMM's job to ensure that one process's virtual address space is invisible and inaccessible from another. This ensures security (an unauthorized process can't read data from another process's memory) and reliability (one process can't corrupt another process's memory).
A computer processes an amazing amount of input and output (I/O). I/O comes from and goes to a variety of devices: the mouse, keyboard, the display, disk drives, CD-ROM drives, tape drives, redirected network resources, serial ports, parallel ports, infrared ports, and more. Something within Windows NT must manage and coordinate all this I/O, and that something is the I/O manager, another component of the executive.
All I/O within Windows NT is packet-based, with each I/O request represented by a structured I/O Request Packet (IRP). The IRP is simply a data structure for controlling how its associated I/O operation is processed. The I/O manager's job is to define a structured mechanism by which IRPs are created and exchanged. When an I/O request is generated (by an application, for example), the I/O manager receives the request and creates an IRP. The I/O manager then passes the IRP to the appropriate device driver. The device driver processes the IRP, performing whatever function the IRP specifies and then passes the result back to the I/O manager.
The I/O manager also provides code to support common functions that device drivers can use to process I/O requests. By implementing these common functions, the I/O manager reduces the number and types of functions that the individual device drivers must perform, simplifying the device drivers' design (and making them easier to develop).
The I/O manager also provides a set of common services that enable the environment subsystems to implement their own I/O functions.
The Windows NT kernel, comprising the executive and HAL, forms a complete operating system, though one without a user interface. The user-mode subsystems briefly described earlier in this chapter provide that user interface. But paning windows on the display is just one small facet of what the subsystems do. They also provide security, application execution environments, and other features. The following sections explore the three most common Windows NT user-mode subsystems. Figure 2.8 shows the subsystems covered in this chapter.
The user-mode subsystems form the upper layers of the Windows NT operating system.
The security subsystem serves as a gatekeeper between user processes (such as other subsystems and network access requests) and the resources controlled by the operating system. Local logon, for example, is processed through the security subsystem. To log on locally to a Windows NT computer, you press Ctrl+Alt+Del to display the logon dialog box. Because all I/O is handled through the Win32 subsystem, the process that monitors the system for logon requests is a Win32 program. When this process detects a logon attempt, it prompts for user name, password, and logon location (domain/workgroup). The logon process then forwards this information to the security subsystem.
The security subsystem passes the logon information to the appropriate authentication module, which varies according to the source of the security request. In the case of local logon, the security subsystem passes the logon information to the Windows authentication module, which compares that logon information with the security account manager (SAM) database. If the logon information supplied matches an account in the SAM, the authentication module returns to the security subsystem the user's ID and a list of groups to which the user belongs.
The security subsystem then checks the local policy database for other access restrictions and privileges for that user, such as quota limits. The security subsystem uses that information to build an access token, which identifies the user's access privileges and rights to other processes. The security subsystem then passes that access token to the logon process, which calls the Win32 subsystem to create a user process for the user, complete with interactive shell--the Windows NT Explorer GUI.
In essence, the security subsystem serves as a high-level security monitor. In addition to processing logon requests, the security subsystem also tracks which resources are audited and works with the security reference monitor in the kernel to implement that auditing.
Without question, the most important of Windows NT's subsystems to the operating system is the Win32 subsystem. First and foremost in the Win32 subsystem's list of responsibilities is to provide an application execution environment for 32-bit Windows applications. The Win32 subsystem is therefore the environment subsystem that enables Windows NT and Windows 95 applications to run on a Windows NT system.
In addition, the Win32 subsystem is responsible for providing the Windows NT user interface. In actuality, the part of the interface that you might typically consider to be Windows NT--the Explorer interface--is really just another Win32 application running on the Win32 subsystem. The core interface components that support the Explorer interface are an integral part of the Win32 subsystem, including:
The Win32 subsystem is obviously important to your ability to run Win32 applications and access the computer through the Explorer interface. But the Win32 subsystem also is indispensable to the other environment subsystems for running non-Windows applications. For example, the Win32 subsystem processes all user I/O, so when you are running a DOS program under Windows NT, it's actually the Win32 subsystem that processes your keyboard and mouse input and translates that input to the DOS process in which the program is running.
The Win32 subsystem also processes all the output for the other environment subsystems, which means our sample DOS program's output is processed by the Win32 subsystem for display, even when the program is running full-screen. The Win32 subsystem does more than just provide a means of I/O handling for the other environment subsystems, however. Win32 also is responsible for process creation and management for the other environment subsystems, which means Win32 is an integral link between the other subsystems and the executive.
One of the primary goals for Windows NT's design and success was application compatibility. The success of Windows 3.x and 16-bit Windows applications was a real incentive to Microsoft to support those applications under Windows NT. Although most Windows NT users would switch to Win32 versions of their programs over time, Microsoft had to ensure compatibility for those users' Win16 applications for the short term. And, many Win16 applications would never be rewritten for Windows NT--another incentive to support Win16 applications under Windows NT.
Under Windows 3.x, all Windows applications run in a single virtual machine (VM) called the system virtual machine. This means that all running Windows applications on a Windows 3.x system cooperatively multitask in the same operating environment, sharing system resources. DOS programs running on a Windows 3.x system each has its own VM, a necessity because DOS programs by their very nature expect to have full and exclusive use of all system resources (because DOS was not designed as a multitasking operating system). Figure 2.9 illustrates VMs on a Windows 3.x system.
As they do under Windows 3.x, DOS applications running under Windows NT do so in a virtual DOS machine (VDM). A VDM is a process created by the Win32 subsystem and is, in essence, a 32-bit Windows program that only looks like a DOS environment. The VDM process provides a DOS-like environment complete with segregated address space and all other features and characteristics of a true single-tasking DOS operating system. Because the VDM duplicates a DOS operating environment, DOS programs running in a VDM perform just as they do on a computer running only the DOS operating system. The primary difference is that the VDM does not interact directly with the hardware as does DOS, but instead works through the Win32 subsystem and executive, providing isolation of VDMs from one another and other application environments to ensure system reliability.
Under Windows NT, all Win16 applications also run in a single virtual machine. Like DOS programs, the Win16 applications run in a single VDM process, sharing address space. Like the DOS VDM, the Win16 VDM simulates the DOS-based Windows 3.1 environment under which Win16 applications run. In effect, the Win16 VDM provides a Windows 3.1 operating environment, complete with its own GDI, window manager, and other Windows 3.1 components. But the Win16 VDM works through the Win32 subsystem and executive, as do DOS VDMs.
Under Windows 3.x, DOS and Windows 3.x programs are accommodated in separate virtual machines.
TIP: By default, Win16 applications share address space. You can, however, run Win16 in separate address spaces if you prefer. In such a case, Windows NT runs the application as a separate process. This offers a means of running a potentially aberrant application without affecting other Win16 applications. To run a Win16 program as a separate process, use the Run command in the Start menu. In the Run dialog box, enable the Run In Separate Memory Space check box.
By structuring the DOS and Win16 VDMs as Win32 user processes, Windows NT enables DOS and Win16 programs to be isolated from other programs such as Win32 programs. This isolation provides a high degree of reliability, ensuring that an errant DOS or Win16 program will not adversely affect Win32 applications by performing unsupported system calls or stepping on the address space of another program. This isolation also protects the operating system itself from such errant programs. Figure 2.10 illustrates the interaction between the Win16 VDM, DOS VDMs, Win32 subsystem, and kernel.
The Win16 and DOS VDMs interact with the system through the Win32 subsystem and the executive.
Programs written for single-tasking, single-processor operating systems such as DOS are very different in design from a Windows NT application. Even so, all programs, regardless of their target operating system, are similar in that all are a fixed sequence of instructions. The difference involves how the instructions are executed.
A simple BASIC language program, for example, might start execution with its first statement and execute each consecutive statement in turn until the last statement is executed. Such a program is obviously linear in its execution. But most of today's programs are much more modular in design, owing to the structure of today's more capable programming languages, such as C, which lend themselves to a more modular approach to programming. Opening a file, for example, is written as a self-contained function that can be called from any point in the program, as necessary.
The distinction between a program and a process is an important one. A program is the static set of instructions, whether linear or modular. A process is a running instance of the program, complete with address space, variables, and other resources (files, ports, and so on) needed by the program to function.
Windows 3.1 is a multiprocessing operating environment. As with Windows NT, you can run multiple programs concurrently under Windows 3.x. You might have three or four DOS programs and a handful of Win16 programs running at the same time, for example. Each of the DOS programs is a process, and the Win16 programs function collectively as a process. One of the differences between the DOS/Windows 3.x operating environment and the Windows NT operating system is that Windows NT supports multithreaded execution.
A thread often is loosely defined as a unit of execution. The easiest way to envision a thread is to think of basic tasks that a typical program performs: open a file, repaginate a document, perform a database query, print a document, and so on. Each of these tasks represents a thread of execution (although the program must be designed to structure these tasks as threads under a multithreaded operating system).
In Windows NT, threads are created as objects. A thread's object body attributes include a client ID that identifies the thread uniquely, a thread context (set of register values and other data that define the execution state of the thread), and other information about the thread and its status. The object manager in the executive has the responsibility of creating, managing, and destroying threads.
The kernel schedules threads for execution on the system's CPU(s) based on the thread's priority and changes the priority of waiting threads periodically to ensure that all waiting threads are processed. On a multiprocessor system, different threads are scheduled and execute concurrently on the system's CPUs, providing true multitasking.
Threads are typically used in a program for asynchronous operations or those tasks that do not have to be performed linearly with other tasks in the program. Printing is a good example of such a task. If the program is designed such that printing is handled through a separate thread, you can begin printing the document (scheduling the print thread on the CPU) and then continue editing the document (which uses other threads) while the printing operation takes place. On a multiprocessor system, this means that the system could be running different parts (threads) of the program at one time.
Multithreading is one of the most important reasons for upgrading your applications if you're currently running Windows 3.x versions of those applications. By upgrading to the Windows 95 or Windows NT versions, it's likely that you'll gain the advantage of multithreaded operation in those programs. Multithreading will improve the application's performance, usability, and the smoothness with which it multitasks with other applications.
NOTE: Just because an application is written specifically for Windows 95 or Windows NT is not a guarantee that the program supports multithreaded execution. The program must be specifically designed to support multithreading. If you're not sure about a program, check with the publisher's tech support staff.
By definition, an operating system does not include network functionality. When Microsoft designed Windows NT, however, it did so from the point of view that Windows NT should be a complete out-of-the-box solution, including all the features necessary to enable the computer to function in a networked environment. This meant that the operating system should include its own peer-to-peer network capability and be able to interface with other network operating systems through support for a range of network clients and protocols.
In addition to wanting to provide a complete operating environment with Windows NT, Microsoft had its sights set on Novell NetWare when it designed Windows NT, hoping to take market share away from NetWare. Although it has taken quite a bit of time, Microsoft has succeeded--Windows NT is rapidly gaining market share against NetWare.
Network functionality can be broken into two primary functions: requesting resources stored on a remote computer and providing access to local shared resources. These two functions are handled by the two primary networking components in Windows NT: the redirector and server.
Ideally, the network should be as transparent to the user as possible. When you open a remote file, for example, you should be able to do so in the same way you open a local file. A network redirector provides that transparency. A redirector processes local requests for network resources, redirecting those requests onto the network and to the remote server where the resource is stored. When you open a file stored on a remote computer, for example, the redirector intercepts the request, packages it, and sends it out on the network. The redirector then waits for a reply and directs the information to the application when it arrives from the remote server. The redirector also redirects printing to remote printers so that the application can print to a network printer as easily (and using the same mechanisms) as printing to a local printer.
In Windows NT, the redirector is a file system driver. The redirector's primary function is to provide a layer of abstraction between you and remote network resources, making it look to you like remote network resources such as files and printers are installed right on your computer (just like local resources). When you perform an operation--requesting a file, for example--the I/O manager in the executive creates an I/O Request Packet (IRP), just as it does for local I/O, and passes the IRP to the redirector. The redirector processes the IRP, communicating with the remote server. The redirector then passes the results to the I/O manager, which in turn passes the results to the calling process.
Besides handling network I/O, the redirector performs supporting tasks for maintaining network resource availability and reliability. For example, the redirector automatically reconnects to a remote server when the connection to the server is lost.
The second major component of the network is the server. Not to be confused with the generic term applied to any computer that shares its resources on the network, the Windows NT server is a file system driver that processes requests by other computers on the network to access local shared resources. When a request comes in from another computer on the network, Windows NT's security components process the request and pass it to the server. The server then processes the request, returning the results to the remote computer.
The server could have been designed as a protected subsystem, but implementing it as a file system driver (even though it processes requests for non-file resources such as printers) offers performance advantages. As a file system driver, the server becomes a part of the kernel, and therefore can access other kernel components directly rather than through NT services, as do the subsystems. A prime example is in moving large amounts of data; the server can communicate directly with the cache manager to move the requested data to the cache, and the server then moves the data directly from the cache to the network. The server therefore can bypass functions that would cause additional system overhead and reduce system throughput.
The server and redirector are just two components in a many-layered network mechanism in Windows NT. To ensure that network traffic can move between computers reliably, a network transport or protocol is used. The protocol defines the way in which the network data packets are structured and transmitted across the network. For one computer to communicate with another, both computers must be running the same protocol.
Windows NT implements protocols as drivers that interact with the redirector and server components to provide network access. While the redirector and server handle higher-level tasks such as receiving and processing requests for resources, the protocols convert those requests and the associated data into a standard format that the two computers can exchange reliably. Windows NT provides protocols to support a wide range of network environments. Most common are NetBEUI, TCP/IP, and IPX/SPX.
© Copyright, Macmillan Computer Publishing. All rights reserved.