You’ll recognize the architecture of Windows 2000, which builds on the solid foundation poured for NT 4.0.

Looks Like Home

You’ll recognize the architecture of Windows 2000, which builds on the solid foundation poured for NT 4.0.

• By Michael Chacon
• January 01, 2000

With Y2K almost behind us, we won’t have to read any more articles about the end of civilization. Of course, it could be argued that civilization ended quite awhile ago, but at least we don’t have to worry about our information systems collapsing. Sure, there will be anomalies popping up now and then for amusement’s sake, but now we can focus on the blocking and tackling of fundamental network design and support. Happy New Year!

With distractions behind us, we can more clearly focus on digestion of Windows 2000, which is necessary, as this is one hearty meal. I highly recommend you take small bites or risk choking. As Win2K hits the streets, early adopters will slide in their CDs straightaway and run toward the upgrade and migration adventure. The cautious majority will watch with a careful eye and then follow behind, plucking the arrows out the backs of predecessors and marking their locations.

No matter what group you fit into, you’ll be considering how Win2K fits into your information system future. This will include at minimum evaluating the product against your Windows NT 4.x environment. As with all operating system evaluations, the most important aspects to begin with are architecture, architecture, and architecture.

A Sound Foundation

The good news for those of us drowning in this sea of new information is that the architecture of Win2K isn’t fundamentally different from NT 4.0. This is also good news because the new services that make up the bulk of what is considered Win2K are running upon the low-level services that have matured into a sound foundation.

Of course, there are changes to these low-level individual components of NT, but they’re essentially extensions to the existing components, which is in line with the extensibility of the original NT design. This reliance on the existing architecture as the foundation for new services is a good thing. It allowed Microsoft to make major renovations and to add high-level services, while maintaining reliability and stability by using production-tested core components.

Win2K continues with the familiar dichotomy of user mode and kernel mode areas, with an abstracted wall of protection between them. The user mode area is the container for the subsystems and processes that directly support the user’s applications. Processes running in this area can’t directly access the low-level processes and hardware in the kernel mode area. This prevents any one process running in user mode from bringing down the entire operating system.

The Kernel Mode

The kernel mode, otherwise known as processor mode, remains the same in Win2K. To review, it contains three major subdivisions that support the low-level operating system services. These are the Executive, Kernel, and Hardware Abstraction Layer (HAL).

The HAL is an image of CPU-specific code that allows Win2K to run across various hardware platforms. HAL allows a single version of Win2K to be optimized for different hardware. The kernel is responsible for the preemptive scheduling and management of the threads that ultimately perform the actual work of the system. The bulk of the kernel mode work is performed in the Executive, which is further subdivided into such fundamental services as the I/O Manager, Security Reference Monitor, Process Manager, and Virtual Memory Manager.

Briefly, when a process is initiated, it’s allocated its own virtual memory space and assigned an identifying handle so it can be referenced in the system. Any requests the process makes for resources are passed through the Security Reference Monitor to verify that the process has permission to access that resource with the specific permission requested. As the process reads or writes data, it uses the I/O Manager to access the particular device where the information is needed or where you want to place it.

Yes, There Are Changes

Now let’s talk about what changes. As I mentioned, the differences in Win2K are more about extensions and enhancements than major architectural reworks. The vast majority of the extra 10 million lines of code are in the new services. However, some of those lines deal with issues that companies have had with NT on its road to becoming accepted as an enterprise-level contender.

One of the most visible additions to the Executive is the Plug and Play Manager. This new Executive-level service manages communication between the Plug and Play bus drivers and the Plug and Play device drivers. The bus drivers allow Win2K to communicate to devices on PCI, ISA, SCSI, and USB bus types. The Plug and Play Manager has to exist in the Executive layer of Win2K because it deals directly with hardware through the drivers. This is a great example of adding functionality in Win2K through the existing architecture by adding to the Executive-level services instead of rewriting them.

This also points out that to fully exploit the new services in Win2K, you should seriously consider getting new hardware that supports the Advanced Configuration and Power Interface (ACPI). This will help to ensure that Plug and Play support in Win2K doesn’t devolve back to the “Plug and Pray” support found in the early testing ground that was Windows 95. Isn’t that just what you wanted to hear? Open up your wallets.

The New Security Model

Other examples of the extensibility through modularity of Win2K are the new security models supported. As I’ve discussed in the past, NT 4.0 authentication is based on NT LAN Manager (NTLM), which works rather well, but with some limitations. First, you must have an account on the system you want to access; and second, only users are authenticated, not servers. While servers have accounts in the SAM, when a user attempts to establish a session with a server, only the user’s token is compared to the ACL on the server to grant access. There’s no similar check with the server’s “token” for the client. Therefore, only users are verified, not servers. With Kerberos, both sides of the session conversation are equally verified.

To solve these limitations, public/private key security and shared key security—Kerberos—have both been added to the security services of W2K. All of the various new security services communicate with the Executive’s Security Reference Monitor (SRM) through standard security APIs exposed by the Security Support Provider Interface (SSPI). So instead of having to write a completely new security model, the authentication token compared to a DACL model is still intact. The only difference is that now you can use different (and more sophisticated) mechanisms to authorize the LSA to create a token to represent client processes.

Thread Handling

Another subtle low-level change affects how Win2K handles multiple threads. On the NT exams, a common question refers to the smallest unit of work as a thread. While this is essentially true in terms of CPU requests, threads have governors associated with them so that the system can allocate access to the CPUs fairly in relation to the thread’s priority. This mechanism is called a quantum, a measurement tied to the number of internal clock ticks of the processor. This controls the length of time a given thread can run on the CPU before the scheduler pauses that thread in deference to another thread of equal priority. You’ve seen this in the Control Panel | System | Performance tab, where you can select a performance boost in the foreground application.

Even though this tab is available in both NT Workstation and Server, it affects only Workstation. The control directly relates to a table that is preloaded with quantum (time slice) numbers of 6, 12, and 18 that will run the selected number of clock ticks before another thread with the same priority is given a chance at the CPU. On the server, the same table exists but the quantum numbers are the same throughout—each has a value of 36. That’s because Microsoft has determined for us that a server-based process is always best served by letting each thread have a longer crack at the CPU. It’s also been decided that foreground processes shouldn’t have longer access than background processes, which, of course, are assumed to be serving network clients.

In Win2K, the same control exposes this quantum configuration in more detail and with more flexibility. Win2K gives you, as administrator, control over how many quantum time slices should occur before a thread is paused to give another thread of equal priority access to the CPU. In the first change, this control is extended to both Win2K Professional (the workstation version) and Win2K Server.

The second change is that you can choose a variable or fixed quantum number. This choice determines whether Boost slide control in the Application Performance area on the Performance tab has any effect. The other control gives you an option to choose a short or long quantum time via a radio button. This control can be used to give a range of 3 to 9 quantums with short and 6 to 18 with the long selection. With this granularity, you can have more control of the preemptive multitasking aspect of Win2K. You can thus match it with the structure of your applications.

Job Objects

Another change is that processes can be collected and controlled as one job object. With this type of control, higher-level tasks that are accomplished through the combination of numerous processes can be assigned common parameters. Those common parameters include base priority, shared working set parameters and CPU time limits, and the ability to run all of the associated processes with the same access token.

These and other nuances demonstrate that the overriding design of Win2K supports significant changes to the functionality of the OS without having to alter the underlying architecture. Even the new encryption file service plugs in between the Security Reference Monitor (SRM) and the Local Security Authority (LSA). As encryption algorithms change, the Encrypted File System (EFS) driver and service can be replaced with a new one without radically changing the I/O manager or the SRM and LSA.

Although there’s much to learn about Win2K, much remains the same—allowing us to leverage our existing painfully acquired knowledge. This is an often unspoken strength of Win2K.