High-Performance Networking Unleashed

Previous chapterNext chapterContents


- 21 -

Windows NT 4

by James Causey

The recent explosive growth of the Windows NT market is arguably the most heavily discussed and debated trend in today's enterprise marketplace. Windows NT has been described in myriad terms, ranging from "NetWare killer" and "the heir apparent to UNIX" to "another Wintel disaster" and "more marketing than meat."

Once the dust has settled, however, the question remains: "What is Windows NT and why should I use it, or not use it?" This is the question that this chapter attempts to answer.

Windows NT is a critically important product, incorporating features from desktop, server, and mainframe operating systems, while introducing some new wrinkles all its own. After reading this chapter, you should be able to evaluate NT's pros and cons and decide whether Windows NT can fill some of your computing needs (and if so, how).

Windows NT: A Brief History

In order to best understand Windows NT, its role in the market, and some of the terminology critical to designing and setting up an NT network, it's important to understand the legacy of network operating systems which led up to Windows NT, and which NT has inherited (see Figure 21.1).

FIGURE 21.1. The Microsoft network operating system family tree.


Early Microsoft Network Operating Systems

Microsoft has been in the networking operating system market longer than most people suspect. In the early to mid-1980s, the increasing popularity of using local area networks to connect desktop computers brought about the creation of a whole new subclass of the PC market: the PC-based network operating system. Networks with central, shared hardware using operating systems such as UNIX, VMS, and other such powerful network operating systems had been used successfully for quite some time, and the capability for a PC to both perform desktop business tasks and replace dumb terminals dedicated to connecting to centralized systems proved to be a boon to companies investing in the new desktop computers. In addition, the shared network connections (typically using technology such as early Ethernet and Token Ring) allowed PCs to share resources, such as hard drives and printers.

In this burgeoning market, PCs dedicated to serving files, print queues, and applications to PCs quickly exploded in popularity. Operating systems such as Banyan's VINES (based on UNIX System V) and Novell's NetWare (a server operating system written from the ground up for Intel hardware) quickly gained success and early dominance. Microsoft, in an attempt to gain a share of this market, developed a primitive extension to MS-DOS called MS-NET, designed to give DOS networking file and print-sharing capabilities without running NetWare, VINES, or another competing product.

MS-NET had some serious flaws, however, the most important of which was the lack of multitasking in DOS. Without this capability, not only could an MS-NET server not process instructions or code executed locally on the server while processing network requests at the same time, but also it could not even service more than one network server request at once. This flaw severely limited MS-NET's usefulness and popularity. Though some third parties (such as 3COM, Microsoft's partner in competing against Novell in the early days of the LAN market) attempted, with varying degrees of success, to extend MS-NET with re-entrant server code to get around DOS limitations, the product was a market failure.

The Step up to OS/2

Microsoft did not give up so easily, however. Microsoft and IBM later partnered to develop OS/2, a revolutionary desktop operating system for Intel hardware. OS/2 was designed to expand the vast popularity of MS-DOS by providing a new, pre-emptively graphical environment. OS/2's new inherent abilities also made it a good candidate for extension into the role of a network operating system. Microsoft did just that, by developing Microsoft LAN Manager (or LANMAN, for short).

LAN Manager was designed around a model similar to NetWare: a centralized, high-powered server, providing file, print, and application services; and specialized client software running on each OS/2 and DOS client, to give those workstations the capability to take advantage of those network services. LAN Manager used NetBIOS, an IBM-designed protocol that provides high-speed, efficient network services (though limited to subnet-only communications). IBM also licensed the LANMAN technology for their server product, IBM LAN Server, which was also based on OS/2.

Though OS/2 proved to be something of a disappointment to IBM due to its lackluster sales, LANMAN's popularity as a server operating system and an alternative to NetWare continued to grow; however, it never seriously threatened NetWare's dominance of the market.

The NT Project

Later on in the 1980s, however, Microsoft realized that OS/2 had some serious long-term flaws. OS/2 was wedded tightly to the Intel processor architecture (having been written largely in 286 assembly language), suffered from an unpopular user interface and poor market image, and lacked the necessary developer and hardware manufacturer support enjoyed by other operating systems. Microsoft decided to leave the OS/2 development effort entirely to IBM and follow its own path in developing the next generation of desktop network operating systems.

Microsoft hired famously talented operating system designer David Cutler, architect of such important operating systems as VMS, to lead this new effort. The project was dubbed "NT," standing for "New Technology" (though one of the most intriguing, and probably apocryphal, myths of this time describes Cutler's fabled choice of the letters "WNT," or "Windows NT," because each letter is the result of adding one to the ASCII codes for the letters "VMS," thus snubbing his past efforts on that operating system).

Windows NT was designed to build on the humble but important success of the LANMAN product line and provide an advanced, high-performance network operating system (see the "Windows NT System Design" section later in this chapter). In 1993, Windows NT came to market (see Figure 21.2 for a list of the NT product line).

FIGURE 21.2. Windows NT product timeline.

Microsoft chose to use the Program Manager interface used by their wildly popular desktop product, Microsoft Windows. To synchronize their product lines, the first version of Windows NT was released under version number 3.1, as the most recent version of Microsoft Windows was also 3.1. NT was available in two forms: Windows NT Advanced Server, or NTAS, to act as the server backbone for an NT network; and Windows NT Workstation, to provide a powerful desktop operating system using the same design features and core as the Advanced Server.

Windows NT 3.1 was seen by many in the industry as something of a disappointment. Although its architecture and design were impressive, it was a massive memory hog and ran quite slowly. In addition, hardware support was rather weak, due to its newness. With its next version, however, NT became a force to be reckoned with in the market.

Windows NT 3.5 was released in 1994, with the server product being renamed to Windows NT Server. The vast performance and application support improvements, as well as the new NT domain structure, made NT a much more popular operating system, and sales began to take off. A more incremental upgrade, version 3.51, was released in 1995.

Windows NT 4.0, released in late 1996, has once again energized NT's sales and popularity, by combining increased Internet/intranet integration and improved performance with greater compatibility with other Microsoft operating systems (DOS and Windows 95, particularly) and the new Windows Explorer interface, introduced previously with Windows 95.

Now that you've looked at NT's legacy, let's examine NT's design goals.

Windows NT System Design

Windows NT was designed to be a modern operating system, incorporating lessons learned from the classic network operating systems (including the king, UNIX), as well as more modern and robust design elements. It achieves these goals through a highly flexible, stable, and secure design.

When the NT project was initiated, Microsoft wanted to ensure that NT would be an advanced network operating system, with the inherent modernity and flexibility to survive well into the future as their flagship networking product. To that end, they designated several important design goals: robustness, portability, compatibility, security, performance, and upgradability.

Desktop operating systems have long earned a reputation for instability. Due to their design, applications or failed system services could easily lock up or crash the entire system or severely reduce system performance and stability. This vulnerability is simply not appropriate for a high-performance network operating system, which needs to be able to provide mission-critical network services or perform intense long-term computational tasks with a minimal risk of failure. Major network operating systems of the past, such as UNIX, incorporated this important fact in their design. Other network operating systems attempted to achieve these goals in a somewhat dubious fashion, reducing their stability and their usefulness outside of basic file and print sharing. The NT project, however, was driven from the very beginning by a desire to provide an extremely stable platform for enterprise network services, and such protective features as true pre-emptive multitasking and full memory protection were incorporated in the system. In addition, Windows NT includes a new, modern file system, known as NTFS, which is designed to allow efficient, rapid, fault-tolerant access to disk drives ranging from small IDE hard disks to large SCSI-based RAID arrays. NTFS utilizes transaction logging to prevent corruption of the file system in the event of a system failure.
One of the powerful advantages of an operating system like UNIX is its ease of portability to multiple platforms, making the operating system totally non-dependent on the design and performance of one vendor's hardware solutions. Windows NT was designed with portability in mind, with the vast majority of the operating system being written in easily portable C, with hardware-specific functions and calls being abstracted by a system-specific Hardware Abstraction Layer, or HAL (see Figure 21.3).

FIGURE 21.3. An abstracted model of a Hardware Abstraction Layer (HAL).

The use of a Hardware Abstraction Layer allows important hardware-specific calls that most greatly impact system performance to be written in fast, optimized assembly language, while still retaining the vast majority of the operating system in easily portable high-level languages.

This portability allowed Windows NT to be released originally with support for Intel x86, Digital Equipment Corporation Alpha, and MIPS RISC processors. With NT 3.51, support was extended to the IBM/Motorola PowerPC processor. Recent developments, however, have led Microsoft to limit its cross-platform hardware support to Intel x86 and DEC Alpha processors. NT still has the essential portability necessary to take advantage of future processor innovations, however.
In the vastly heterogeneous enterprise market of the 1990s and beyond, the ability to maintain a high level of compatibility with other products is critical to a network operating system's survival. Windows NT approaches compatibility from multiple perspectives.

First, NT maintains a high level of software compatibility. Windows NT's primary programming interface, the Win32 API (Application Programming Interface), is virtually identical across all Microsoft 32-bit platforms, making it simple for vendors to design 32-bit products that run on both the newer Windows consumer desktop operating systems (Windows 95 and the forthcoming Windows 97) and on Windows NT. Windows NT can also run most 16-bit Windows applications designed for Windows 3.1x in a protected environment, allowing a high level of backward compatibility while still preventing those applications from crashing the system or other 32-bit applications and services. NT also has the inherent ability to run POSIX.1-compliant applications, requiring only that those programs be recompiled for the target hardware platform. Finally, NT can run applications written for OS/2 ver- sion 1.x.
Second, NT's ability to provide services over several network protocols gives it the flexibility to integrate with and provide services to networks running such disparate operating systems as NetWare, UNIX, OS/2, DOS, Windows 3.1x, and Windows 95, as well as providing Internet and intranet connectivity and support. Add-on products let NT provide gateways to entities such as IBM SNA mainframes.

Third, Windows NT's file system, NTFS, maintains multiple data streams within each file, which can be used to emulate many types of file systems (including the data fork/resource fork structure used by Macintoshes). In addition, Windows NT can access disk partitions using the FAT file system (used by MS-DOS, Windows, and Windows 95) and the HPFS file system (used by OS/2). As a result, an NT system can easily serve files to multiple platforms without impacting those platforms' functionality.
NT was designed from the beginning with the potential to provide extremely secure network services. NT's object-oriented structure and integrated security manager authenticate actions and processes within the operating system on a per-access basis, giving system administrators a high level of flexibility in determining user and service rights and privileges. Windows NT 3.51 received the highly coveted Red Book C3 certification, designating it as an extremely secure operating system. NT 4.0 is currently in the evaluation process for C3 certification.
Operating systems such as UNIX have found wide acceptance not only as powerful servers and network service providers, but also as high-performance computational, design, and graphic workstations. In order to compete with these products in these areas, NT needs to provide a high level of system performance.

To this end, NT supports Symmetric Multiprocessing (SMP), the ability to split application threads over multiple processors. This allows customers to add CPUs to increase system performance.

NT's network stack is also optimized for high-speed networking, and when using high-quality hardware, it can achieve network performance similar to a UNIX workstation.

NT's native file system, NTFS, also includes features designed to enhance I/O performance, including powerful data-level caching and physical data location.

One of NT's weaknesses, however, from a performance standpoint, is its extreme level of hardware abstraction. Although hardware abstraction greatly enhances stability, it introduces layers of complexity to most system services, imposing a performance burden in the process. In order to reduce this performance burden, NT's designers have been carefully reducing the abstraction of certain key areas, such as the video subsystem (an important change in Windows NT 4.0), in order to significantly boost performance while not significantly impacting reliability.

An important feature of a modern operating system is the ability to extend or modify the system to respond to changes and advances in technology. NT provides this upgradability by being extremely modular. Individual components can be rewritten and redesigned without impacting the rest of the operating system as long as essential basic functionalities are still provided. This flexibility has been evidenced by the rapid growth in features and performance NT has shown through the life of the product.

You've seen NT's design mission, and in the process, two important questions arise: How did Microsoft achieve these goals, and how well did it do so? To begin to answer these questions, the next section looks at NT's system architecture.

NT System Architecture

As discussed earlier, NT relies on a series of interconnected modules, separated from direct hardware access by a Hardware Abstraction Layer. This section covers some of the specific architectural features relied upon by NT, and then describes the layout of NT's system architecture itself.

User Mode Versus Kernel Mode

One of the most important distinctions to understand when viewing NT's system architecture is the distinction between User Mode services and Kernel Mode services. In Kernel Mode, a piece of code has the ability to execute any instruction that a processor is capable of and can generally access all system resources. In User Mode, however, a piece of code has a much more restricted set of functionality and resources, in order to significantly reduce the danger to the operating system's stability posed by providing complete resource access. These modes are abstract modes, designated by Windows NT, but they're based on the ability of most modern processors to switch state between a full-access mode and a more restricted secure mode (see Figure 21.4).

NT takes advantage of these modes by placing application code and related components in User Mode. By doing so, NT both eliminates the potential of an application or related service to execute a bad instruction or perform a task that locks a resource designed to be allocated by the operating system itself, and makes certain that changes in basic interface and application components do not require changes in more sensitive Kernel Mode components.

FIGURE 21.4. User Mode versus Kernel Mode.

NT places those components in Kernel Mode only if those components require that level of privilege in order to execute, or if placing those components in User Mode would severely impact system performance. For example, in previous versions of Windows NT, video and printing services ran in User Mode, which eliminated the ability of a bad video driver or video-related instruction to crash the entire system, but the system overhead incurred by switching between User Mode and Kernel Mode constantly for video hardware access hurt NT's video performance. Moving those components to Kernel Mode has increased the risk that NT's stability could be affected by video-related functions and drivers, but has also significantly improved system performance.


NOTE: Are you concerned about the stability of Windows NT 4.0 in comparison to other versions of NT? Keep in mind that in earlier versions, a severe problem in the video subsystem could crash the entire Win32 subsystem, which all other application subsystems rely on for access to system services (this point is covered in more detail in the section "Environmental Subsystems"). Though a similar problem in NT 4.0 can crash the entire system rather than just the Win32 subsystem, there is little practical difference between the two types of crashes because a dead Win32 subsystem will prevent anyone from administering the system or running any applications. In both cases, it's critically important for video and printer driver designers to thoroughly test and refine their drivers before releasing them.

Object-Oriented Architecture

Another important feature of NT's design is the use of modular components, or objects. Objects are self-contained, self-controlling pieces of code that maintain all their procedures and data internally, while providing an abstracted set of interfaces to other objects and/or applications. Using objects makes maintaining and updating a program, particularly one as complex as an operating system, a much easier and more reliable process.

As an example, take a look at two different ways to implement file access in an operating system.

In a non-object-oriented OS (such as the one shown in Figure 21.5), the procedures of file access must be understood down to the lowest level by everyone designing portions of the operating system that rely on them. If the designers decide at some point to change how file access is performed, the file access code throughout the OS must be changed to reflect the new methods. This is a time-consuming, painstaking process, and one in which it is nearly impossible to avoid making errors or forgetting to change portions of the OS.

FIGURE 21.5. Without objects, all components must understand every detail of file access.

In an object-oriented OS, however, the details of file access are known only to the object handling those details (see Figure 21.6). That object presents a common interface of abstracted file manipulation functions to the rest of the operating system. In this model, should the particulars of file access need to be changed, the file access object can be modified, or even completely replaced, as long as it presents the same interface to the rest of the OS. If this basic interface requirement is met, the designers of the operating system can even provide new, enhanced functionality, as long as the old interface is maintained for backward compatibility.

Windows NT uses the object-oriented model throughout its architecture, from actual operating system components to individual manipulation objects (such as files, users, groups, processes, and the like). This not only makes it easier to code and maintain the OS, but also provides a superb framework for implementing many of NT's design goals. For instance, because each object maintains its own data, the operating system as a whole is, in theory, far more reliable because individual processes can't run roughshod over each other's resources. In addition, the use of objects makes it easy to enhance and revise the operating system because components can be rewritten, replaced, and added on, as long as the interfaces relied upon by other portions of the operating system are not altered. Portability is enhanced as well because any component that relies on the specifics of a particular platform (such as the HAL) can be replaced with a component designed for another.

FIGURE 21.6. With objects, only the file access object needs to understand details of file access.


Operating System Components and Architecture

Now that you've examined some of the crucial concepts behind NT's architecture, take a look at NT layout itself. Figure 21.7 contains a complete diagram of the layout of NT's various components and subsystems.

The discussion of these various components begins by starting at the lowest level and working upwards.

HAL

As already discussed, the HAL performs the task of abstracting the CPU and other platform-specific resources, providing a generalized interface to higher-level system components for maximum portability. Windows NT includes a generic HAL for each major platform (Intel, x86, Alpha, and PowerPC), as well as other HALs provided by manufacturers for variations in hardware design. Manufacturers can also provide different HALs for application after NT has been installed, to maximize performance and reliability on specific hardware.

FIGURE 21.7. Windows NT 4.0 component layout.

The Kernel

The Windows NT kernel is a microkernel, meaning that it performs only the scheduling and execution of instructions on the system's processor or processors. By using such a small system kernel, NT's designers hoped to improve both the system's performance and reliability; the kernel cannot be pre-empted by any other portion of the OS, so it is critical that it be both lightweight and extremely reliable. Limiting the kernel to these essential tasks provides NT with a great deal of inherent stability. The kernel does not determine how many threads a process has, nor does it determine precisely when to create or destroy them; those tasks are handled higher up, in the NT Executive.

Windows NT is a threaded operating system. A thread is a small, organic task or set of instructions. Processes running under Windows NT can each spawn multiple threads, in order to execute multiple tasks concurrently. The use of multiple threads can greatly enhance a process's speed and efficiency. Every process uses at least one thread, and threads are implemented by the kernel, which creates, schedules, executes, and destroys threads on the system CPU.

NT includes support for Symmetric Multiprocessing (SMP), meaning that if a system contains more than one CPU, the kernel can schedule threads freely on whichever processor is least burdened. SMP allows systems to be scaled for better performance under heavy processor load situations by adding more processors. NT comes with support for up to four processors, and system manufacturers can provide modifications to NT in order to support even more CPUs.

Executive Services

Above the kernel, but still in kernel mode, lie Windows NT's Executive services. The members of the NT Executive provide important operating system services needed by applications and other services to perform their allotted tasks. These services include:

The I/O Manager, rather like the theoretical file access object from the earlier example, handles most hardware data input/output services for NT, ranging from such functions as disk access to network communications.


NOTE: Because this is a book on networking, you'll take a look at the network model for the NT operating system later in this chapter, in the section titled "Windows NT Networking."
It uses a series of administrator-configurable drivers to handle communications with those specific pieces of hardware. Because they deal so closely with hardware, these drivers have to be able to bypass the Hardware Abstraction Layer and communicate directly with hardware devices, lest the HAL become unwieldy and large and system performance suffer severely as a result.

Graphical Device Interface (GDI) Services

The GDI services include all services that control how data is rendered and displayed visually, both to the video card and to the printer. For maximum stability, previous versions of NT placed most of the GDI in User Mode. Unfortunately, system performance was severely impacted as a result of this decision.

For Windows NT 4.0, the system's designers decided to move all GDI services into Kernel Mode, to reduce the performance impact of those tasks. As discussed earlier, although this move does provide a threat to system stability, in practice it provides little or no significant stability impact.

The LPC module provides NT objects, applications, and services the ability to communicate with one another using named pipes. Maintaining this functionality within one object assures that any module written for Windows NT can use the same basic set of calls to communicate with other modules.
The Virtual Memory Manager controls the allocation and manipulation of pages of application and system-wide virtual memory pools, which can consist of both high-speed RAM and the slower, but larger, system swap file. All processes under Windows NT have access to a virtual memory space of 4GB. When an individual process requires access to memory, the Virtual Memory Manager (with help from the I/O Manager) handles the actual movement of pages from RAM to disk (and back again) and provides a virtual interface to those hardware addresses that the individual process can manipulate, without having to know where its individual pages are located.
The Process Manager controls process objects, determining when they are created and destroyed. It also handles the creation and destruction of threads. It does not, however, directly schedule and execute those threads on the system's processor or processors; that task is handled by the kernel.
The Security Reference Monitor maintains the system-wide database of security rights, privileges, and identities, and is called upon by other modules of the operating system to verify an object's rights and privileges to other objects and tasks. This low-level, constant comparison and verification of object security are an important part of NT's C2-level security rating.
The Object Manager, appropriately enough, manages the identity of all objects within the system. It works closely with the rest of the operating system to maintain a database of all active objects, whether they be processes, files, users, groups, network resources, drives, or any other possible system object. It also maintains the database of available interfaces and methods for those objects and verifies attempts to access objects at that level.

NT's Kernel Mode modules provide the services you expect from an operating system, such as security, I/O, hardware control, and other basic services. The next section moves higher up NT's architectural model to look at the User Mode application services.

Environmental Subsystems

The most important, and most common, module that NT runs in User Mode is the Environmental subsystem. Environmental subsystems provide applications with a generic interface to the Executive services below. Individual subsystems can be designed to provide specific APIs, memory models, and other features an application expects. In this way, applications for other operating systems can be run under Windows NT.

The primary subsystem running under User Mode is the Win32 Subsystem. The Win32 API is Microsoft's 32-bit programming interface for applications written to run under Windows NT. It provides all features available under NT, including pre-emptive multitasking, protected memory, a flat 32-bit memory model, and so on. Every other subsystem running in User Mode is a Win32 application, each with its own memory space and input queue. All access to NT resources and Executive services takes place through the Win32 subsystem because each application and subsystem running as a Win32 application makes API calls, which are interpreted and passed on to the appropriate Executive module (see Figure 21.8).

No Win32 application can access another Win32 application's memory pool, nor can it interfere with its input. Because each Win32 application is pre-emptively multitasked, no one Win32 application can hog system resources and prevent others from accessing them.

FIGURE 21.8. Every subsystem in User Mode is a Win32 application.

The Win32 API is standardized across all of NT's hardware platforms; an application written for NT in Win32 needs only to be recompiled for each target platform.


NOTE: Developer support for NT platforms other than Intel has been lackluster, outside of core products (such as the BackOffice suite). In order to get around this limitation, Digital Equipment Corporation has developed FX!32, a recompilation engine for Intel Win32 applications. When a Win32 application written for the Intel platform is first run on an Alpha, the Intel instructions are translated into equivalent Alpha code by an emulator. In the meantime, the Win32 instructions used by the application are recompiled into Alpha-native binaries and saved to disk. The next time that application is launched, those functions run natively on the Alpha, greatly improving their performance. Over time, more and more of the application is converted to Alpha-native code. This amazing innovation greatly enhances the viability of the Alpha platform for Windows NT.

Windows NT includes a number of other environmental subsystems, each a Win32 application in its own right, to run other types of applications. These subsystems include:

The Win16 subsystem, or Windows On Windows (WOW) as it's commonly known, is a Win32 application that provides a virtual DOS/Windows 3.1 machine. MS-DOS and Windows 3.1x 16-bit applications can run in this subsystem, with access to the complete Win16 API, and standard 16-bit Windows memory models. Most 16-bit DOS and Windows applications run perfectly within the WOW subsystem; the only exceptions are those applications that attempt to directly access system hardware and resources. Windows NT does not allow such applications to have direct access to those resources, in order to maintain system stability and performance (see Figure 21.9).

FIGURE 21.9. The Win16 subsystem and Win16 applications within it.

Each Win16 subsystem provides a complete emulated version of a DOS/Windows 3.1 machine, including all the limitations included therein. Within a Win16 subsystem, poorly behaved Win16 applications are multitasked cooperatively, and share one 16-bit virtual memory pool. A Win16 application can crash other Win16 applications within that subsystem, as well as the entire subsystem itself. However, because the Win16 subsystem is, in fact, just another Win32 application, the Win16 applications within it cannot crash the entire operating system, nor can they affect other Win32 applications. In fact, in order to provide more crash protection between multiple Win16 applications, users can start each Win16 application on their NT systems in a separate WOW subsystem.


NOTE: Because Win16 applications are written only for the Intel platform, versions of NT 4.0 for other operating systems run Intel emulators to allow those applications to be run. As with any software emulator, however, performance of those Win16 applications suffers on other platforms.
The OS/2 subsystem allows applications written for OS/2 versions 1.x to be run under Windows NT without being recompiled. This support is only provided on NT for Intel, however, and only command-line applications can be run, as the OS/2 subsystem does not include support for the OS/2 Presentation Manager interface.
NT'S POSIX subsystem allows applications written to the POSIX.1 standard, a standard that defines application compatibility standards among various UNIX variants, to be run under Windows NT. POSIX.1-compliant applications need only be recompiled for the applicable NT platform in order to function under NT. NT provides additional compatibility features to meet POSIX.1 compliance, including providing the necessary file system functions needed by POSIX applications within the NTFS file system.

The Windows NT Registry

One crucial portion of NT's architecture not shown in Figure 21.7 is the Registry. The Windows NT Registry is a dynamically maintained system database. NT uses the Registry for a number of functions, including:

The Registry provides a valuable, efficient storehouse for many, many different types of data, used by both NT itself and the applications that run under it. Because the Registry can be accessed and manipulated by a standard set of APIs, its presence simplifies the tasks of programmers who need to retrieve or modify system data or store individual user or application preferences.

Now that you understand how NT is put together, it's a good opportunity to talk about the use of Windows NT as a network operating system (because this is a book on networking, after all).

Windows NT Networking

Windows NT was designed from the ground up as a network operating system. To understand its potential as a network OS, it's important to understand how NT can communicate on a network, and what features and protocols it supports. You'll also look at the model Microsoft has chosen for NT-centric networks, and how those networks can be integrated with other products.

The NT Network Stack

Windows NT's network stack was designed to allow multiple methods of communication, use different protocols, and allow myriad services to be used over those protocols. In addition, the basic NT network stack can be extended to use additional add-on network products.

Figure 21.10 illustrates the model used in the design of NT's network stack.

FIGURE 21.10. The Windows NT network stack.

Rather than starting from the bottom, as with NT's system architecture, start at the top of this diagram.

The topmost level consists of networking APIs. These programming interfaces contain the actual function calls made by applications in order to communicate over the network and use those calls to perform network functions. Perhaps the most important of those network APIs is NetBIOS, the Network Basic Input/Output Interface. NetBIOS is the core API used by NT and LANMAN networking. When an NT system (or any other system, for that matter) communicates with other systems using Microsoft networking, the calls made are made to the NetBIOS API. NetBIOS can, through the NT network stack, perform those functions using other protocols, as you'll see in a moment. Other APIs live at this level as well, such as the Windows Sockets (or Winsock, for short), which provides standard TCP/IP Internet/intranet connectivity such as you've become accustomed to with UNIX and other operating systems.

Right below the network APIs themselves lives a component known as the Transport Driver Interface, or TDI for short. The TDI allows networking APIs such as NetBIOS, Winsock, or others to be written in a protocol-independent fashion, so that they can be bound to any lower-level transport protocol.

Underneath the TDI, you have the transport protocols themselves. Windows NT can, out of the box, use any of three primary protocols for Microsoft/LANMAN networking:

NetBEUI is a proprietary protocol used for Microsoft/LANMAN networking only. NetBEUI stands for the NetBIOS Extended User Interface. NetBEUI is a fast, efficient, subnet-only protocol, designed for use in small workgroups using peer-to-peer or small server-based networks. NetBEUI cannot be routed, so it is suitable only for local subnet communication.


NOTE: Confused yet about the difference between NetBIOS and NetBEUI? Don't worry; many NT system administrators don't understand the difference.

NetBIOS, when originally designed in the 1980s, was a network protocol into itself. It was later extended to provide more functionality, and renamed NetBEUI (NetBIOS Extended User Interface). Finally, in the late 1980s, NetBIOS and NetBEUI were split apart. NetBIOS became a generic networking API, and NetBEUI the network protocol. This is the state in which these two terms remain.


TCP/IP and IPX/SPX are the other protocols available for Microsoft/LANMAN networking under NT. They are available due to their many advantages; they can be routed across subnets, and they are very commonly used for other networks, so an administrator can design his NT network to fit best into his current LAN/WAN setup.


NOTE: In fact, if TCP/IP is used for a Microsoft network, an administrator can use the Internet itself as an extended Wide Area Network!

TCP/IP and IPX/SPX are encapsulated within an NT version of the Streams interface, originally designed for UNIX System V. Streams allows network component designers to easily wrap various network protocols in a standard interface, so that higher-level and lower-level protocols can plug into them seamlessly.

Beneath the transport protocols is the NDIS interface. NDIS stands for Network Driver Interface Specification. The NDIS interface provides even more modularity within NT's network stack, allowing the higher-level transport protocols to interface seamlessly with any type of lower data-link protocols (such as Ethernet, Token Ring, CDDI, or others) without being rewritten. Finally, underneath the NDIS interface itself lie NDIS drivers, written for specific network devices. These drivers also only have to be written once for NT because the abstraction provided by the NDIS interface allows that same driver to connect with higher-level protocols.

Microsoft Windows Networking Models

Like any network operating system, NT was designed to provide its network services in a number of specific ways. Many operating systems have been designed with one specific purpose, but NT networks can be modeled in two different fashions: a Microsoft workgroup or a Microsoft domain.


NOTE: Before moving on into the discussion of Microsoft network models, you need to understand the difference between the products in the NT product line: Windows NT Workstation and Windows NT Server.

Windows NT Workstation was designed as an individual desktop workstation operating system, or as a peer-to-peer server for a very small workgroup. A Windows NT Workstation can connect to any other Microsoft operating system (whether NT Server, NT Workstation, a Windows 95 workstation, a Windows for Workgroups workstation, or any other Microsoft network-capable system). An NT Workstation can also connect to other operating systems for which it has clients; for example, NT Workstation has the ability (through the Winsock interface) to use TCP/IP Internet/intranet applications such as Telnet, FTP, and a Web browser, and can also connect to NetWare servers. In addition, Windows NT Workstation can serve connections to other Microsoft systems, or to Internet/intranet clients (or even Macintosh workstations). However, the license for Windows NT Workstation restricts its use to a maximum of 10 concurrent server connections.

Windows NT Server, on the other hand, was designed as a central file, print, application, and Internet/intranet server. It has all the capabilities of Windows NT Workstation, with additional licensing and performance tuning options specifically aimed at use as a server operating system. NT Server can also provide authentication services for a Windows NT Domain.


A Microsoft workgroup is just that, a small workgroup of computers designed to perform simple network file, print, and application sharing. All Microsoft network-capable clients can be members of a workgroup, whether NT, Windows 95, Windows for Workgroups, or other. Within a workgroup, there is no centralized authentication for user or group resources; users must maintain an account, with appropriate privileges, on every system where they want to have access, either directly at the system console or over the network (see Figure 21.11).

For small groups of systems, a workgroup model can be highly useful. In very large organizations, however, the task of maintaining individual accounts and all the needed passwords across an entire group of mixed resources can quickly grow out of hand.

FIGURE 21.11. The NT workgroup model.

In order to simplify the management of large groups of network resources, Microsoft devised the Windows NT domain. An NT domain provides a centralized authentication service, with one security database containing all users and groups within an organization. Users authenticate once to that domain, and then can access any resource shared to their user account (or a group to which their user account belongs). Figure 21.12 illustrates an NT domain.

The security database for an NT domain is maintained on a Windows NT server that has been designated the Primary Domain Controller (or PDC) for that domain. To provide fault tolerance and better scalability, an NT domain can also use multiple Backup Domain Controllers (or BDCs), which are NT servers that maintain read-only mirrors of the domain's master database. When an authentication request is made, it can be tested against the database on any Backup Domain Controller as well as on the PDC, thus reducing the load on that PDC (see Figure 21.13). Should the PDC fail for whatever reason, any BDC can be promoted to replace it.


NOTE: A Windows NT server does not have to be dedicated solely to acting as a Domain Controller, whether used as a PDC or BDC. In small- to medium-sized domains, a PDC or BDC can also serve as a file, print, or application server. In larger domains, however, it can significantly increase domain performance to dedicate a server to those purposes.

FIGURE 21.12. The NT domain model.

FIGURE 21.13. Primary and Backup Domain Controllers in an NT domain.

To further extend the domain model, domains can perform pass-through authentication of users to other domains, through a trust relationship. Trust relationships allow domains to establish secure communications through which authentication requests can be passed off to the domain controller responsible for that user's account. Using trust relationships, resources can be easily shared between organizations, while still maintaining centralized user authentication.

Integrating NT with Other Network Operating Systems

Windows NT has the capability, using both included services and add-on software packages, to integrate well with other types of networks. Its flexibility of protocol choice allows an administrator to select the protocol that best meets his needs for network simplicity, LAN/WAN management, and capabilities. In addition, NT computers have the ability to use resources from, and serve to, many different types of network operating systems, including:

Windows NT 4.0 comes with a Client for NetWare Networks, which allows it to connect to NetWare servers using both Bindery authentication and NDS. In addition, an add-on product available from Microsoft allows an NT server to masquerade as a NetWare 3.x Bindery server, so that NetWare clients can take advantage of its resources.
Windows NT workstations and servers can run an included set of Services for Macintosh, which allows them to share files and printers to Macintosh clients using the AppleShare protocol. They cannot, however, connect to Macintosh clients without a third-party product (either an AppleShare client for NT, available from Apple, or a product that allows a Macintosh to share resources over LANMAN-standard protocols).
Windows NT includes the Windows Sockets service, which allows it to connect over TCP/IP to standard Internet/intranet services such as Telnet, FTP, WWW, and other such services. In addition, Windows NT Server includes the Internet Information Service (IIS), which allows an NT server to act as an enterprise WWW, FTP, and Gopher server. Third-party products are also available from vendors such as Netscape to provide such Internet/intranet services, and Windows NT Workstation includes a less powerful version of IIS for peer intranet services.

Additional third-party products allow NT systems to more directly interact with UNIX workstations and servers, using services such as X-Windows and NFS. There are also clients for UNIX systems (such as the shareware product SAMBA), which allow UNIX machines to take part in NT workgroups and domains, and share files and printers with Microsoft systems.

Windows NT also includes the DLC protocol, used by both many IBM mainframes and by Hewlett-Packard JetDirect print servers. NT can connect to both. In addition, products are available that allow NT servers to act as gateways to IBM SNA networks, such as Microsoft SNA Server.

All in all, Windows NT provides many different options for network connectivity and services.

High-Performance Networking with Windows NT

Windows NT's advanced network connectivity model has allowed the implementation of a number of high-performance networking systems on Windows NT. The range of available tools for some bleeding-edge technologies pales in comparison to those available on UNIX, which is the de facto development platform for advanced networks. However, most high-performance network technologies are available on Windows NT.

Perhaps the simplest and most common of all high-speed technologies is the use of 100 Megabit Ethernet. All common 100Mbps implementations, including 100base-T, have both interface cards and drivers compatible with Windows NT.

As the standards and implementations for ATM are sorted out, support for Windows NT is keeping up quite well. A number of major vendors, such as Digital and 3COM, provide interface cards for running ATM connections directly to a Windows NT server or workstation for use as a high-end computer or data server.

Multicast technologies for videoconferencing are also being made available for the NT platform; the most popular research multicast system, the MBONE, has clients and servers for Windows NT currently in beta-test. For more information on MBONE on Windows NT, check the ICAST Web page at http://www.icast.com. Other videoconferencing systems are available for NT as well, such as the non-multicast CUSeeMe package and proprietary systems from vendors such as Intel Corporation.

Wrapping It All Up: Should You Use Windows NT?

Now that you've seen where NT came from, how NT is designed, and some of what it can do, the decision remains: Can NT be useful to you?

First, it's important to evaluate NT Workstation and NT Server separately. NT Workstation is a very powerful, secure, stable workstation operating system. With its combination of an easy-to-use graphical user interface and a wide variety of available software programs (the library of software for Microsoft Windows is the largest on earth), an NT Workstation can serve as a reliable desktop solution, for tasks ranging from basic office automation (word-processing, spreadsheets, and the like) to software development to high-end computational tasks such as 3D modeling and statistical processing. Its combination of stability, performance, and flexible platform choice (particularly on the high bang-for-buck Intel platform) makes it an appealing alternative to more expensive UNIX desktop workstations (and can even exceed their performance when running on powerful hardware such as the Alpha), as well as a more advanced and more reliable alternative to other Windows and Macintosh computers. As more high-speed network implementations become available on NT, the ability to augment or replace UNIX systems with NT becomes a more viable option. For many, the decision to use Windows NT Workstation on the desktop is a no-brainer, particularly for organizations moving from other Microsoft operating systems.

Whether or not to use Windows NT Server is a much more complicated choice. Due to its advanced architectural design, simple interface, and rapidly growing industry support, a Windows NT server can work wonderfully in any number of roles, including:

Windows NT servers can be used for a wide range of application services. Products from Microsoft, Sybase, Oracle, and other vendors exist to use an NT server as a SQL database server, for example. NT servers can also be used to maintain a centrally controlled source for most applications used by an organization, though this is simply another facet of file serving.

Due to their favorable cost/performance ratio, NT servers are seeing increasing use as World Wide Web, FTP, and other Internet service providers. Many of the Web's most used sites, including Microsoft's, run on NT Server, using either IIS or a third-party Web server product. NT servers can also act as DNS (Domain Name Service) servers multiprotocol routers and provide other services essential to a TCP/IP network.
Many messaging and groupware products, ranging from simple SMTP servers to integrated products such as Microsoft Exchange and Lotus Notes, can be (and are) run on Windows NT servers.

In these roles, an NT server can completely replace similar servers running other network operating systems, such as UNIX or NetWare.

Despite what Microsoft would have you believe, however, UNIX and NetWare still have their uses. Consider some of NT's disadvantages:

At first glance, this statement may seem confusing. Windows NT can multitask, can't it? And it can serve multiple network connections, as well as an interactive console user, can't it? Well, yes, it can. However, NT is not designed to provide more than one interactive session at a time. UNIX machines are often used to allow multiple users to connect using terminal emulators (such as Telnet) and run interactive sessions on the system, to perform their computing tasks. NT is simply not designed to do this; NT machines are designed to allow one user to sit at the console and manage and use the machine for personal computing tasks, and/or to serve files, print queues, and applications to multiple remote users over client/server connections.
When compared to more monolithic operating systems such as NetWare, the model used by Windows NT is extremely complex. These layers of complexity can reduce performance; when doing raw file transfers, for example, a Windows NT server can be somewhat slower than an equally equipped NetWare server (though NT 4.0 mostly eliminates this performance edge). The tradeoffs for this reduced performance, however, include better security and reliability.
Windows NT is a very young product, particularly when compared to UNIX and NetWare. Because of this, some of its management tools are rather poorly designed. Managing a complicated structure of Windows NT domains can currently be a very complex, time-consuming task, as NT lacks some of the advanced management tools available to UNIX system administrators. NT is quickly closing these gaps, particularly when compared to NetWare, but it has a long way to go.
Windows NT currently cannot scale to the degree that many operating systems, such as UNIX, can. For example, Windows NT supports only up to four processors out of the box. Although a server using four Pentium Pro or Alpha processors is an extremely powerful machine, there are times when huge megaservers with many, many processors and huge amounts of RAM and disk can be necessary, and NT is not suitable for such tasks. In addition, Windows NT is a 32-bit operating system, and some very rare, very large datasets can require the performance and memory access capabilities afforded by a 64-bit system architecture. Future versions of NT will address these issues, but for now, NT cannot serve as a megaserver or as a massively parallel server.
Though Windows NT is available for many hardware platforms, the vast majority of developer support focuses on Intel-based platforms (with slowly increasing support for the DEC Alpha). Recently, Microsoft has dropped support for future versions of NT running on MIPS and PowerPC processors, so the next version of NT will be available only for Intel and Alpha. On the plus side, Intel's expanded range of processors (including the Pentium, Pentium Pro, and MMX processors) does allow for many different price/performance ratios, and the DEC Alpha is still the world's fastest computer, making it suitable for very high-end tasks. However, if you do not want to be tied to a one- or two-platform solution, NT may not be right for you.

Summary

This chapter looked at Windows NT from a number of different perspectives, in order to let you see its advantages and disadvantages. NT is a powerful product, with many advantages and a great deal of increased future potential, and has the power of Microsoft's goliath development, marketing, and relations capabilities to help push it to new heights. There are still some areas, however, when your particular needs may require features NT cannot (and will not) provide. With the information in this chapter, you should have much of what you need to make that decision.


Previous chapterNext chapterContents


Macmillan Computer Publishing USA

© Copyright, Macmillan Computer Publishing. All rights reserved.