The following requirements drove the specification of Windows NT back in 1989:
To guide the thousands of decisions that had to be made to create a system that met these requirements, the Windows NT design team adopted the following design goals at the beginning of the project:
As we explore the details of the internal structure and operation of Windows 2000, you'll see how these original design goals and market requirements were woven successfully into the construction of the system. But before we start that exploration, let's examine the overall design model for Windows 2000 and compare it with other modern operating systems.
Windows 2000 vs. Consumer Windows
Windows 2000 and Consumer Windows (Windows 95, Windows 98, and Windows Millennium Edition) are part of the "Windows family of operating systems," sharing a common subset API (Win32 and COM) and in some cases operating system code. Windows 2000, Windows 98, and Windows Millennium Edition also share a common subset device driver model called the Windows Driver Model (WDM), which is explained in more detail in Chapter 9.
From the initial announcement of Windows NT, Microsoft has always made it clear that this operating system was to be the strategic platform for the future—not just for servers and business desktops but eventually for consumer systems as well. The following list highlights some of the architectural differences and advantages that Windows 2000 has over Consumer Windows:
- Windows 2000 supports multiprocessor systems—Consumer Windows doesn't.
- The Windows 2000 file system supports security (such as discretionary access control). The Consumer Windows file system doesn't.
- Windows 2000 is a fully 32-bit operating system—it contains no 16-bit code, other than support code for running 16-bit Windows applications. Consumer Windows contains a large amount of old 16-bit code from its predecessors, Windows 3.1 and MS-DOS.
- Windows 2000 is fully reentrant—significant parts of Consumer Windows are nonreentrant (mainly the 16-bit code taken from Windows 3.1). This nonreentrant code includes the majority of the graphics and window management functions (GDI and USER). When a 32-bit application on Consumer Windows attempts to call a system service implemented in nonreentrant 16-bit code, the application must first obtain a systemwide lock (or mutex) to block other threads from entering the nonreentrant code base. And even worse, a 16-bit application holds this lock while running. As a result, although the core of Consumer Windows contains a preemptive 32-bit multithreaded scheduler, applications often run single threaded because so much of the system is still implemented in nonreentrant code.
- Windows 2000 provides an option to run 16-bit Windows applications in their own address space—Consumer Windows always runs 16-bit Windows applications in a shared address space, in which they can corrupt (and hang) each other.
- Shared memory on Windows 2000 is visible only to the processes that are mapping the same shared memory section. (In the Win32 API, a shared memory section is called a file mapping object.) On Consumer Windows, all shared memory is visible and writable from all processes. Thus, any process can write to any file mapping object.
- Consumer Windows has some critical operating system pages that are writable from user mode, thus allowing a user application to corrupt or crash the system.
The one thing Consumer Windows can do that Windows 2000 will never do is run all older MS-DOS and Windows 3.1 applications (notably applications that require direct hardware access) as well as 16bit MS-DOS device drivers. Whereas 100 percent compatibility with MS-DOS and Windows 3.1 was a mandatory goal for Windows 95, the original goal for Windows NT was to run most existing 16-bit applications while preserving the integrity and reliability of the system.