Requirements and Design Goals

[Previous] [Next]

The following requirements drove the specification of Windows NT back in 1989:

  • Provide a true 32-bit, preemptive, reentrant, virtual memory operating system
  • Run on multiple hardware architectures and platforms
  • Run and scale well on symmetric multiprocessing systems
  • Be a great distributed computing platform, both as a network client and as a server
  • Run most existing 16-bit MS-DOS and Microsoft Windows 3.1 applications
  • Meet government requirements for POSIX 1003.1 compliance
  • Meet government and industry requirements for operating system security
  • Be easily adaptable to the global market by supporting Unicode

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:

  • Extensibility The code must be written to comfortably grow and change as market requirements change.
  • Portability The system must be able to run on multiple hardware architectures and must be able to move with relative ease to new ones as market demands dictate.
  • Reliability and robustness The system should protect itself from both internal malfunction and external tampering. Applications should not be able to harm the operating system or other applications.
  • Compatibility Although Windows NT should extend existing technology, its user interface and APIs should be compatible with older versions of Windows and with MS-DOS. It should also interoperate well with other systems such as UNIX, OS/2, and NetWare.
  • Performance Within the constraints of the other design goals, the system should be as fast and responsive as possible on each hardware platform.

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.



Inside Microsoft Windows 2000
Inside Microsoft Windows 2000, Third Edition (Microsoft Programming Series)
ISBN: 0735610215
EAN: 2147483647
Year: 2000
Pages: 121

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net