Inside the Difference Between Windows NT Workstation and Windows NT Server

Since its inception, Windows NT has been available in two forms: asa workstation operating system (Windows NT Workstation) and as a serveroperating system (Windows NT Server). Microsoft sells the two platforms withdifferent licenses and different bundled software and portrays them as beingsuited for different workloads. The question then is what is different when youremove the software and licenses from consideration? Microsoft has statedpublicly that Workstation and Server "share the same kernel architecture,"and a recent article on Microsoft's Web site goes further, describing howWorkstation and Server are tuned in a variety of ways to suit their distinctroles: Workstation is for desktop interactive use, and Server is for file,print, and Web serving. Given this information, the reasonable assumption isthat Microsoft constructed Workstation and Server from different, althoughpossibly in many respects shared, code bases. However, a binary comparison ofthe installation CDs reveals that the code base is the same.

This article will describe what files on the setup disks are different, andI'll then show that only a Registry key or two determines which type of runtimetuning the kernel and user-level applications will perform. A detailed study ofthe operating system and device driver tuning differences follows, and thearticle concludes with a tour of applications that check, for one reason oranother, 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 underdirectories that identify processor- specific versions. The NT 4.0 final releasehas about 2500 unique files when you combine Workstation and Server's files forany particular processor set.

A binary comparison of corresponding processor subdirectories from a ServerCD and a Workstation CD flags about 200 files as inconsistent. Roughly 100 ofthese flagged files ship with Server but not with Workstation. This numberincludes files related to Dynamic Host Configuration Protocol (DHCP), DomainName System (DNS) administration, JET database integration, license management,log viewing, Macintosh volume management, network client administration, NetWaremigration, remote-system policy management, remote boot management, domain usermanagement, and domain configuration management. Finally, the Server logonbitmaps are only on the Server CD.

Another 10 flagged files ship with Workstation but not Server. Localmachine user management and a different version of Disk Manager Help files makeup the bulk of this group. In addition, the workstation logon bitmaps ship onlyon the Workstation CD, of course.

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

The remaining differences are the result of file entries related tocomponents that ship on one platform but not the other. Beneath theprocessor-specific subdirectories on the Workstation and Server CDs are inetsrvdirectories. They are where Internet Information Server (IIS) installs from on aServer 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 areidentical at the binary-level. Server ships with a network monitor andMicrosoft's FrontPage Web site-creation software, neither of which comes withWorkstation.

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, andother low-level system components. Because the ntoskrnl.exe image is identicalon the Workstation and Server CDs and because Microsoft and empirical evidenceshow that these subsystems behave differently on installed workstations andservers, the NT OS must dynamically obtain the factor that determinesWorkstation or Server behavior. In fact, very early in the operating system'sinitialization, it queries the Registry to determine whether the platform is aworkstation or a server.

On NT 3.51, only one Registry value separates Workstation from Server:hkey_local_machinesystemcurrentcontrolsetcontrolproductoptionsproducttype. The Microsoft Developer'sNetwork Knowledge Base article Q124305 documents this entry and defines itas 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 theNT Memory Manager in the MmInitSystem() routine, where it sets a globalvariable, Mm ProductType, to reflect ProductType's value. Internally, theoperating system does not distinguish between a server and an advanced server.So for either type, MmProductType is set to 1; for Workstation, MmProductType isset to 0.

On NT 4.0, two Registry values play a role in separating Workstation fromServer, and the ProductType value's role is carried forward from NT 3.51. An8-byte additional value (two DWORDs) is involved, and its primary purpose it isto encrypt operating system expiration date information. However, the value hasa component that must be set according to the ProductType value. A violation ofthis 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 notificationwork items for the two values in question. If somebody attempts to change thesevalues, a system worker thread is notified to write the original value over thechange. Attempting to alter ProductType also results in the system popping up amessage box stating that the user has tried to violate the licensing agreement.

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

User-level applications have two options for determining the operatingsystem configuration. The first is just to read the ProductType Registry valuedirectly. 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 theresult in an internal variable that it returns to the caller. The internalvariable is 1 if the Winnt string was read, 2 if Lanmannt was read, and 3 ifServernt was obtained. Subsequent calls avoid reading the Registry by returningthe cached variable.

Operating System Tuning
NT initialization accesses the Mm ProductType variable and the MmIsThisAnNtAsSystem() function several times to directly affect the values of about 25internal variables and indirectly affect many more. The basic philosophy thetuning evidences is that when NT is acting as a server, the system'sresponsiveness to file- and network-related work needs to be of primary concern,and memory footprint is secondary in importance. Workstation aims responsivenessat systems that run multiple applications simultaneously, and memory footprintsare kept smaller to accommodate more applications, so responsiveness ofsystem-related functions can suffer. The NT Executive, the Memory Manager, theFile System Runtime, the Process Manager, the I/O Manager, the Cache Manager,and the Object Manager perform optimizations according to the product type.

Product Type and System Size
The product type directly affects the system size identifier variable, MmSystemSize, which has repercussions for many other dynamic tuning variables. Itcan have one of three values: Mm SmallSystem, MmMediumSystem, and MmLargeSystem.

The system size is the basis for tuning throughout the operating system andaffects such things as the number of worker threads to create and the amount ofmemory to set aside for specific subsystem tasks. Table 2 shows theamount of memory necessary to rate a system as small, medium, or large. Notethat the threshold for a large Server is double the large threshold forWorkstation.

The NT Executive is in charge of creating system worker threads, and itinitializes them in the routine, Exp WorkerInitialization(), which uses both thesystem size and the product type to determine how many threads to create. An NTsystem has three types of worker threads, each aimed at different priorities ofwork: delayed worker threads perform low-priority tasks; critical worker threadsperform jobs that must be completed as soon as possible and run at a realtimepriority; and one hypercritical worker thread exists only for specific,system-related operations such as exited-process cleanup.

Ideally, the number of worker threads needs to be high enough that theypick up work tasks as soon as the tasks are assigned. The tradeoff is that idleworker threads needlessly use system resources.

Table 3 shows how many critical and delayed worker threads thesystem creates by default for different parameters. On medium and large systems,a server has twice as many critical worker threads as a workstation.

However, by changing Registry settings under the key hkey_local_machinesystemcurrentcontrolset controlsession managerexecutive, anadministrator can direct a workstation to have just as many, or even more,worker threads than a default server configuration. The AdditionalCriticalWorkerThreads value under this key controls the number of extra critical workerthreads that are created, and you can set it to a value up to 16. Similarly,AdditionalDelayedWorkerThreads controls the number of extra delayed workerthreads created, and it can also be a value up to 16.

Once worker threads are started, they sleep until an item that they need toprocess is placed on a work queue. The form of sleep that Server worker threadsperform differs from that of Workstation worker threads: Server threads sleepwith their stacks locked into memory, whereas Workstation worker threads canhave their stacks paged to disk. This optimization means that Server workerthreads are generally more responsive when work arises, because they never havea delay reading their stacks in from the disk. However, Server threads alwayscontribute to the in-memory footprint of the operating system.

Product Type and Memory Manager
The Memory Manager uses the product type value to make tuning decisions inseveral places. The first decision occurs in MmInitSystem(), where the MemoryManager sets the variables MmThrottle Top and MmThrottleBottom. The system'slazy modified-page writer thread uses these variables in its determination ofwhether to write pages to the paging file if they have been changed out, inanticipation of a future need to do so.

On a server, these values are about twice as high as on a workstationbecause a workstation is likely to have more paging activity as processes andthreads of different interactive applications are started and stopped. Serversare assumed to run a few unchanging applications that have fairly stable memoryrequirements, so the anticipation for paging activity is lower than forworkstations.

The next place where the Memory Manager tunes each product type is ininitializing the system's working-set manager. The working-set manager is abackground thread that trims the in-memory footprint of applications to fitwithin certain ranges.

On workstations with less than 32MB of memory, a flag, MiDoPeriodicAgressiveTrimming, is set to TRUE. This setting causes the working-set managerto trim the footprints of active processes every second or so. This trimminggives more applications a chance to simultaneously squeeze at least part oftheir required data and code into memory.

On servers and large workstations, trimming is much more conservative andoccurs only in situations where memory usage and page faulting are extremelyhigh. In addition, during process creation on servers, processes are flagged sothat the working-set manager gives them more physical memory than they would geton a workstation.

The final place where the Memory Manager accounts for running on a serverrather than a workstation is where the Memory Manager determines the size of theoperating system's pool of pageable memory. The pageable pool is the area fromwhich the operating system and device drivers allocate data. Once this pool isexhausted, the system will fail to function properly. On Server, the paged poolsize is a minimum of 50MB.

Tunneling
The file system runtime performs an interesting optimization that Microsofthas introduced with NT 4.0: To preserve long file names in the face of legacy16-bit applications that would otherwise destroy them, the NT 4.0 file systemsupports the notion of long file name tunneling. Tunneling is necessarywhen a 16-bit application, such as a word processor, maintains the currentversion of a document in a temporary file. When the user saves the document, theprogram may delete the original and rename the temporary to the original file'sname.

In the absence of tunneling, the renaming of the temporary file replacesthe original long filename with the short-name form. When tunneling is ineffect, the file system typically remembers delete operations for 15 seconds,and if a new short filename file is created with the name of a file that hasrecently been deleted, the file is automatically assigned the long name of therecently deleted file. On a server, the default number of remembered deleteoperations is 1024, but on a workstation, the number is only 256.

You can explain this difference if you assume that servers are likely toserve file systems to large numbers of clients that will probably have much moreactivity over short periods than a workstation file system will have. You canoverride the default number in the Registry value hkey_local_machinesystemcurrentcontrolsetcontrol file systemmaximumtunnelentries. Also, underthe same key, by setting the value MaximumTunnelEntryAgeIn Seconds, you can tunethe time-based window of recall for delete operations.

Foreground Execution Quantum
One dramatic optimization that the Process Manager performs is that it setsthe foreground execution quantum on a server to twice that of the foregroundquantum on a workstation. And the background quantum on a server, which isidentical to its foreground quantum, is six times larger than the correspondingquantum on a workstation. This difference means that on a server, threadsexecute for longer periods without interruption, and fewer threads generally geta share of a processor over a given duration. Because the implicit assumption isthat servers will be running fewer and less interactive applications thanworkstations, this optimization usually aids server throughput by doing awaywith needless thread-switching overhead.

Lookaside Lists
The remaining optimizations that the operating system performs involve thecreation of lookaside lists, which are new in NT 4.0. Lookaside listsare private stashes of fixed-sized chunks of memory created for specific tasks.This approach avoids an expensive call to the system-wide memory allocator whenmemory is available in a private store. In some cases, this approach can evenavoid a lengthy wait for a disk operation to complete as the system makes roomfor an allocation out of physical memory. The Object Manager creates a stash forallocating internal object names, the Cache Manager creates a stash for the diskwrite-behind and read-ahead threads, and the I/O manager creates lookaside listsfor I/O commands. In all these cases, the lookaside lists are larger if youconfigure the system as a server, because performance of these variousoperations in a server environment is considered more important than the impactof removing this memory from the general pool.

Device Driver Tuning
Only four device drivers that ship with NT behave differently depending onthe platform they are running on. These four drivers are afd.sys, srv.sys,nwlnknb.sys, and ntfs.sys.

afd.sys is the device driver responsible for managing Microsoft's WinsockTCP/IP communications protocol. afd. sys performs two modifications.

1. afd.sys sets the size of the network transfer frame to 4KB if afd.sys isrunning on Workstation and 64KB if this device driver is running on Server. Alarger size means that communications will usually be faster but also thatallocated buffers will have a negative impact on the system's available memory.

2. afd.sys modifies a variable according to the product type. This changeoccurs where this driver sets the limit on simultaneous network file transfersto 2 if it is running on Workstation. But afd.sys checks the Registry entry:hkey_local_machinesystemcurrentcontrolsetcontrolservicesafdparametersmaxactivetransmitfilecount for thelimit, if afd.sys is running on Server. This variation exists purely to limitthe functionality of Workstation, rather than to optimize performance.

srv.sys is the network server device driver that controls networkconnections to a machine. Its check of the product type is also forfunctionality limitation. About 10 of its variables are restricted to certainvalues if this driver is running on a Workstation.

The most notable of these variables is SrvMaxUsers. On a Server,SrvMaxUsers is set to an effectively infinite value. But on a workstation,SrvMaxUsers has an upper limit of 10, allowing a maximum of 10 simultaneousnetwork connections to the machine. This limit applies whether the connectionsare file transfers or network logons.

Unlike srv.sys, nwlnknb.sys, the NetWare network NetBIOS communicationsprotocol driver, queries the system type for performance-optimization purposes.nwlnknb.sys maintains an internal cache of network routes. On Server systems,this cache is three times larger than on workstations, apparently because aserver will need more network connections.

ntfs.sys is the file system driver for disks that are formatted with thenative NT File System (NTFS), and this driver checks the product type fortuning. During its initialization, a call is made to MmIsThisAnNtAsSystem(), andbased on the result, ntfs.sys sets the size of 11 lookaside lists that itcreates for memory caching. Each lookaside list is dedicated to a differenttemporary data structure that must be allocated during file system operations.Again, in anticipation of more file system activity, the lists are twice as bigon large servers (according to the MmSystemSize variable), as on largeworkstations.

User-Level Application Tuning

Figure 1 shows a list of the user-level components that query the systemtype. These components are too numerous to allow in-depth explanation of theirbehavior. However, I can highlight a few.

Winlogon checks the product type to determine which splash screen todisplay, lanman.bmp (for 16-color video modes) or lanma256.bmp for Server logon,and winnt.bmp or winnt256.bmp for Workstation logon. Explorer checks the producttype and shows a bitmap along the left side of the Start menu. The bitmap readsWindows NT Server or Windows NT Workstation, as appropriate.

The last application in Figure 1 is windisk.exe, the NT disk administratorprogram. It reads the Registry directly to determine which platform it isexecuting on.

If Windisk is on a Server, it provides a Fault Tolerance menu that hasentries you can use to create striped sets with parity, and mirrored drives. Ona Workstation, Windisk does not make this menu available. This differenceexplains why only Servers can create and manage fault-tolerant disks.

Several Microsoft products have setup programs that check the product type.Notable examples are BackOffice and IIS. BackOffice refuses to install anyBackOffice suite programs, SQL Server, Exchange Server, IIS, and SystemManagement Server (SMS), if the product is on a Workstation.

No technical reason lies behind this limitation: Tests show that theseapplications function properly if the setup program is foiled into installingthem on a Workstation.

As I mentioned earlier, the version of IIS that ships with the NT 4.0 CDschecks the product type and installs as Peer Web Services if its setup programdetects that it is on a Workstation, and as IIS if it detects that it is on aServer.

No Blanket Statements
Although NT Workstation and NT Server share the same bits, the few tweaksthat the system makes according to the product type can significantly affect theperformance of the systems, so that given the same workloads, one or the otherwill perform better. The tuning that takes place seems to aim Workstation andServer at different, clearly-defined workloads. However, making blanketstatements about the suitability of this tuning for all situations that canarise in actual installations is impossible. For example, some people arguethat, with the advent of Common Gateway Interface (CGI), a Web serving NT Serverwould do better to tune itself as an interactive Workstation than as a singleapplication Server.

NT's predefined optimizations may be suitable for many cases. However,Microsoft was shortsighted in not giving systems administrators control over theoptimizations, rather than foisting on them one-size-fits-all solutions.