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.