Windows 2000 Product Packaging | Inside Microsoft Windows 2000, Third Edition (Microsoft Programming Series)

[Previous] [Next]

There are four editions of Windows 2000: Windows 2000 Professional, Windows 2000 Server, Windows 2000 Advanced Server, and Windows 2000 Datacenter Server. These editions differ by:

The number of processors supported

The amount of physical memory supported

The number of concurrent network connections supported

Layered services that come with Server editions that don't come with the Professional edition

These differences are summarized in Table 2-2.

Table 2-2 Differences Between Windows 2000 Professional and Server Editions

Edition	Number of Processors Supported	Physical Memory Supported	Number of Concurrent Client Network Connections*	Additional Layered Services
Windows 2000 Professional	2	4 GB	10
Windows 2000 Server	4	4 GB	Unlimited	Ability to be a Server domain controller, Active Directory service, software-based RAID, Dynamic Host Configuration Protocol (DHCP) server, Domain Name System (DNS) server, Distributed File System (DFS) server, Certificate Services, Remote install, and Terminal Services
Windows 2000 Advanced Server	8	8 GB	Unlimited	Two-node clusters
Windows 2000 Datacenter Server	32	64 GB**	Unlimited	Four-node clusters, Process Control Manager tool†

* The End-User License Agreement for Windows 2000 Professional (contained in \Winnt\System32\Eula.txt) states, "You may permit a maximum of ten (10) computers or other electronic devices (each a "Device") to connect to the Workstation Computer to utilize the services of the Product solely for file and print services, internet information services, and remote access (including connection sharing and telephony services)." This limit is enforced for file and print sharing and remote access but not for Internet Information Services.

** Theoretical limit—the supported limit might be less than this due to availability of commercial hardware.

† See Chapter 6 for more on the Process Control Manager tool.

What is not different between the various flavors of Windows 2000 are the core system files: the kernel image, Ntoskrnl.exe (and the PAE version, Ntkrnlpa.exe); the HAL libraries; the device drivers; and the base system utilities and DLLs. All these files are the same for all editions of Windows 2000. For example, there are no special server versions of the HAL.

However, a number of these components operate differently depending on which edition is running. Windows 2000 Server systems are optimized for system throughput as high-performance application servers, whereas Windows 2000 Professional, although it has server capabilities, is optimized for response time for interactive desktop use. For example, based on the product type, several resource allocation decisions are made differently at system boot time, such as the size and number of operating system heaps (or pools), the number of internal system worker threads, and the size of the system data cache. Also, run-time policy decisions, such as the way the memory manager trades off system and process memory demands, differ between the Windows 2000 Server editions and Windows 2000 Professional. Even some thread-scheduling details have different default behavior in the two edition families. Where there are significant operational differences in the two products, these are highlighted in the pertinent chapters throughout the rest of this book. Unless otherwise noted, everything in this book applies to both the Windows 2000 Server editions as well as Windows 2000 Professional.

If the kernel image is the same across the various product editions of Windows 2000, how does the system know which edition is booted? By querying the registry values ProductType and ProductSuite under the HKLM\SYSTEM\CurrentControlSet\Control\ProductOptions key. ProductType is used to distinguish whether the system is a Windows 2000 Professional system or a Windows 2000 Server system (any edition). The valid values are listed in Table 2-3. The result is stored in the system global variable MmProductType, which can be queried from a device driver using the kernel-mode support function MmIsThisAnNtAsSystem, documented in the Windows 2000 DDK.

Table 2-3 ProductType Registry Values

Edition of Windows 2000	Value of ProductType
Windows 2000 Professional	WinNT
Windows 2000 Server (domain controller)	LanmanNT
Windows 2000 Server (server only)	ServerNT

A different registry value, ProductSuite, distinguishes Windows 2000 Server, Advanced Server, and Datacenter Server as well as whether Terminal Services have been installed (Server systems only). On Windows 2000 Professional systems, this value is blank.

If user programs need to determine which edition of Windows 2000 is running, they can call the Win32 VerifyVersionInfo function, documented in the Platform SDK. Device drivers can call the kernel-mode function RtlGetVersion, documented in the Windows 2000 DDK.

Checked Build

There is a special debug version of Windows 2000 Professional called the checked build. This version is available only with the MSDN Professional (or Universal) CD subscription. It is provided to aid device driver developers—the checked build performs more stringent error checking on kernel-mode functions called by device drivers or other system code. For example, if a driver (or some other piece of kernel-mode code) makes an invalid call to a system function that is checking parameters (such as acquiring a spinlock at the wrong interrupt level), the system will stop execution when the problem is detected rather than allow some data structure to be corrupted and the system to possibly crash at a later time.

The checked build is a recompilation of the Windows 2000 source code with the compile-time flag DEBUG set to TRUE. Much of the additional code in the checked-build binaries is a result of using the ASSERT macro, which is defined in the DDK header file Ntddk.h and documented in the DDK documentation. This macro tests a condition (such as the validity of a data structure or parameter), and if the expression evaluates to FALSE, the macro calls the kernel-mode function RtlAssert, which calls DbgPrint to pass the text of the debug message to a kernel debugger (if one is attached) to be displayed and then prompts the user for what to do (breakpoint, ignore, terminate process, or terminate thread). If the system wasn't booted with the kernel debugger (using the /DEBUG switch in Boot.ini) and no kernel debugger is currently attached, failure of an ASSERT test will crash the system.

Although Microsoft doesn't supply a checked-build version of Windows 2000 Server, Advanced Server, or Datacenter Server, you can manually copy the checked (debug) version of the kernel image onto a Windows 2000 Server system, reboot, and run with a checked kernel. (You could also do this for other system files, but most developers who use the checked build really only need the checked version of the kernel image—not the checked versions of every device driver, utility, and DLL.)

Multiprocessor-Specific System Files

Six system files* are different on a multiprocessor system than on a uniprocessor system. (See Table 2-4.) At installation time, the appropriate file is selected and copied to the local \Winnt\System32 directory. To determine which files were copied, see the file \Winnt\Repair\Setup.log, which itemizes all the files that were copied to the local system disk and where they came from off the distribution media.

Table 2-4 Multiprocessor-Specific vs. Uniprocessor-Specific System Files

Name of File on System Disk	Name of Uniprocessor Version on CD	Name of Multiprocessor Version on CD
Ntoskrnl.exe	\I386\Ntoskrnl.exe	\I386\Ntkrnlmp.exe
Ntkrnlpa.exe	Ntkrnlpa.exe in \I386\Driver.cab	Ntkrpamp.exe in \I386\Driver.cab
Hal.dll	Depends on system type (See the list of HALs in Table 2-5.)	Depends on system type (See the list of HALs in Table 2-5.)
Win32k.sys	\I386\UNIPROC\Win32k.sys	Win32k.sys in \I386\Driver.cab
Ntdll.dll	\I386\UNIPROC\Ntdll.dll	\I386\Ntdll.dll
Kernel32.dll	\I386\UNIPROC\Kernel32.dll	\I386\Kernel32.dll

EXPERIMENT
Looking at Multiprocessor-Specific Support Files
You can see the files that are different for a multiprocessor system by looking at the driver details for the Computer in Device Manager:

Open the System properties (either by selecting System from Control Panel or by right-clicking on the My Computer icon on your desktop and selecting Properties).

Click on the Hardware tab.

Click Device Manager.

Expand the Computer object.

Double-click on the child node underneath Computer.

Click on the Driver tab.

Click Driver Details.

You should see this dialog box for a multiprocessor system:

The reason for having uniprocessor versions of these key system files is performance—multiprocessor synchronization is inherently more complex and time consuming than the use of a single processor, so by having special uniprocessor versions of the key system files, this overhead is avoided on uniprocessor systems (which constitute the vast majority of systems running Windows 2000).

Interestingly, although the uniprocessor and multiprocessor versions of Ntoskrnl are generated using conditionally compiled source code, the uniprocessor versions of Ntdll.dll and Kernel32.dll are created by patching the x86 LOCK and UNLOCK instructions, which are used to synchronize multiple threads with no-operation (NOP) instructions (which do nothing).

The rest of the system files that comprise Windows 2000 (including all utilities, libraries, and device drivers) have the same version on both uniprocessor and multiprocessor systems (that is, they handle multiprocessor synchronization issues correctly). You should use this approach on any software you build, whether it is a Win32 application or a device driver—keep multiprocessor synchronization issues in mind when you design your software, and test the software on both uniprocessor and multiprocessor systems.

On the checked build CD, if you compare Ntoskrnl.exe and Ntkrnlmp.exe or Ntkrnlpa.exe and Ntkrpamp.exe, you'll find that they are identical—they are all multiprocessor versions of the same files. In other words, there is no debug uniprocessor version of the kernel images provided with the checked build.

EXPERIMENT
Checking Which Ntoskrnl Version You're Running
With Windows NT 4, you can tell which version of Ntoskrnl you're running by clicking on the Version tab in Windows NT Diagnostics (Winmsd.exe). In Windows 2000, there is no utility to show this information. However, an Event Log entry is written each time the system boots that does record the type of kernel image (uniprocessor vs. multiprocessor and free vs. checked), as shown in the screen shot below. (From the Start menu select Programs/Administrative Tools/Event Viewer, select System Log, and double-click on an Event Log entry with an Event ID of 6009, indicating the entry was written at the system start.)

This Event Log entry doesn't indicate whether you booted the PAE version of the kernel image that supports more than 4 GB of physical memory (Ntkrnlpa.exe). However, you can tell if you booted the PAE kernel by looking at the registry value HKLM\SYSTEM\CurrentControlSet\Control\SystemStartOptions. Also, if you boot the PAE kernel, the registry value HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PhysicalAddressExtension is set to 1.

You can also determine whether you installed the multiprocessor version of Ntoskrnl (or Ntkrnlpa) by examining the file properties: run Windows Explorer, right-click on Ntoskrnl.exe in your \Winnt\System32 folder, and select Properties. Then click on the Version tab, and select the Original Filename property—if you're running the multiprocessor version, you'll see the dialog box below.

Finally, as mentioned earlier, you can see exactly which kernel image and HAL were selected at installation time by looking at the file \Winnt\Repair\Setup.log.