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).
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.
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.
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.
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 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.
FIGURE 21.3. An abstracted model of a Hardware Abstraction Layer (HAL).
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.
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.
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.
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.
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.
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.
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 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.
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:
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."
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.
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.
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:
FIGURE 21.9. The Win16 subsystem and Win16 applications within it.
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.
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 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.
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.
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.
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:
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.
All in all, Windows NT provides many different options for network connectivity and services.
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.
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.
Despite what Microsoft would have you believe, however, UNIX and NetWare still have their uses. Consider some of NT's disadvantages:
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.
© Copyright, Macmillan Computer Publishing. All rights reserved.