Inside the Difference Between Windows NT Workstation and Windows NT Server

Since its inception, Windows NT has been available in two forms: as a workstation operating system (Windows NT Workstation) and as a server operating system (Windows NT Server). Microsoft sells the two platforms with different licenses and different bundled software and portrays them as being suited for different workloads. The question then is what is different when you remove the software and licenses from consideration? Microsoft has stated publicly that Workstation and Server "share the same kernel architecture," and a recent article on Microsoft's Web site goes further, describing how Workstation and Server are tuned in a variety of ways to suit their distinct roles: Workstation is for desktop interactive use, and Server is for file, print, and Web serving. Given this information, the reasonable assumption is that Microsoft constructed Workstation and Server from different, although possibly in many respects shared, code bases. However, a binary comparison of the installation CDs reveals that the code base is the same.

This article will describe what files on the setup disks are different, and I'll then show that only a Registry key or two determines which type of runtime tuning the kernel and user-level applications will perform. A detailed study of the operating system and device driver tuning differences follows, and the article concludes with a tour of applications that check, for one reason or another, to see whether they are running on Server or on Workstation.

File Differences
NT's core operating system and support components are on the setup CDs under directories that identify processor- specific versions. The NT 4.0 final release has about 2500 unique files when you combine Workstation and Server's files for any particular processor set.

A binary comparison of corresponding processor subdirectories from a Server CD and a Workstation CD flags about 200 files as inconsistent. Roughly 100 of these flagged files ship with Server but not with Workstation. This number includes files related to Dynamic Host Configuration Protocol (DHCP), Domain Name System (DNS) administration, JET database integration, license management, log viewing, Macintosh volume management, network client administration, NetWare migration, remote-system policy management, remote boot management, domain user management, and domain configuration management. Finally, the Server logon bitmaps are only on the Server CD.

Another 10 flagged files ship with Workstation but not Server. Local machine user management and a different version of Disk Manager Help files make up the bulk of this group. In addition, the workstation logon bitmaps ship only on the Workstation CD, of course.

The other 90 or so flagged files have different content for each platform and are related to text-based inf setup files. Most differences in these files result from NT Setup's internal management of virtual setup disks that have different names for Workstation and Server.

The remaining differences are the result of file entries related to components that ship on one platform but not the other. Beneath the processor-specific subdirectories on the Workstation and Server CDs are inetsrv directories. They are where Internet Information Server (IIS) installs from on a Server setup and where Peer Web Services installs from on a Workstation setup. Except for a few setup files, the files that make up these products are identical at the binary-level. Server ships with a network monitor and Microsoft's FrontPage Web site-creation software, neither of which comes with Workstation.

How Does the Operating System Know What It Is?
NT's core is in the file ntoskrnl.exe. It consists of the NT microkernel, the Executive, the Object Manager, the Memory Manager, the Process Manager, and other low-level system components. Because the ntoskrnl.exe image is identical on the Workstation and Server CDs and because Microsoft and empirical evidence show that these subsystems behave differently on installed workstations and servers, the NT OS must dynamically obtain the factor that determines Workstation or Server behavior. In fact, very early in the operating system's initialization, it queries the Registry to determine whether the platform is a workstation or a server.

On NT 3.51, only one Registry value separates Workstation from Server: \hkey_local_machine\system\current controlset\control\productoptions\producttype. The Microsoft Developer's Network Knowledge Base article Q124305 documents this entry and defines it as a string that can have one of the three values shown in Table 1. Setup reads the value early in system initialization and later initializes the NT Memory Manager in the MmInitSystem() routine, where it sets a global variable, Mm ProductType, to reflect ProductType's value. Internally, the operating system does not distinguish between a server and an advanced server. So for either type, MmProductType is set to 1; for Workstation, MmProductType is set to 0.

On NT 4.0, two Registry values play a role in separating Workstation from Server, and the ProductType value's role is carried forward from NT 3.51. An 8-byte additional value (two DWORDs) is involved, and its primary purpose it is to encrypt operating system expiration date information. However, the value has a component that must be set according to the ProductType value. A violation of this rule results in a blue-screen error during boot. This "system_ license_violation" error makes the system inoperative.

Another change from NT 3.51 is that NT 4.0 creates Registry notification work items for the two values in question. If somebody attempts to change these values, a system worker thread is notified to write the original value over the change. Attempting to alter ProductType also results in the system popping up a message box stating that the user has tried to violate the licensing agreement.

Other operating system subsystems and even device drivers can query the system's type by invoking the exported Memory Manager function MMIThis AnNtAsSystem(). It simply returns the MmProductType value.

User-level applications have two options for determining the operating system configuration. The first is just to read the ProductType Registry value directly. The second is to call a native NT function, RtlGetNtProductType(), that is in the ntdll.dll. When called for the first time after a system boot, RtlGetNtProductType() reads the Product Type Registry value and caches the result in an internal variable that it returns to the caller. The internal variable is 1 if the Winnt string was read, 2 if Lanmannt was read, and 3 if Servernt was obtained. Subsequent calls avoid reading the Registry by returning the cached variable.

   Previous  [1]  2  3  4  Next