Windows XP Kernel Enhancements

Before we dive into the depths of Windows XP's new kernel features, let's first set the stage. You've most likely heard by now that Windows XP builds on Windows 2000 core technology, and attempts to provide better software and hardware device compatibility. We'll start a brief review of the major technical enhancements provided by each new version of Windows starting with Windows 1.0 to present day. In addition, we'll talk about some of the key shortcomings of each of those operating system versions. Of course, if you don't care for such a history lesson, fearing that it will bring back too many painful memories, we understand. You can simply jump to "The XP Kernel Enhancements" directly.

Windows 1.0
Windows has come a long way since the flat, slow graphical interface of Windows 1.0, circa 1985. With a dearth of supported applications, most users got their first taste of Windows as a runtime environment for PageMaker 1.0. Initially a DOS Add-on, every new version of Windows pushed the limits of CPU speed, memory capacity, and disk space. Early versions of Windows suffered from hardware and software compatibility problems and it wasn't until Windows 3.0 that the computer industry and users stood up and really paid attention.

Windows 3.0
Windows 3.0 took off in 1990 as the PC application platform de jour, providing a colorful interface, cooperative multitasking, and a comprehensive API for developers. The API abstracted many tasks that let the developer spend less time on the interface and more time on program logic. Though the Windows API existed from version 1, more third party development tools supported the Windows API. Unfortunately, Windows 3.0 and applications suffered from frequent crashes, popping up the dreaded UAE (Unrecoverable Application Error) at the slightest provocation.

Windows 3.1
With stability a problem, when Microsoft released Windows 3.1 in 1992 they focused on tightened parameter checking of the API. Under Windows 3.0, an application could pass bad parameters to API's unchecked, that is until it crashed, usually with a GPF (General Protection Fault). Under 3.1, while Microsoft tried to reign in developers by tightening up parameter checking, they also ended up breaking apps that walked on the wild side. Windows 3.1 was still a 16-bit OS that had little inter-application protection. It was far too easy for one application to inadvertently access another application's memory space. This was a problem on two fronts--an application crash could bring down another app (or the system), and one application could access the data of another, causing a security problem. For standalone or home users, this was not typically a serious problem, but for corporations it could cause big problems.

Windows NT About a year after Windows 3.1 was released, David N. Cutler (and his crew of Microsoft engineers hired away from Digital Equipment Corp (DEC) in 1988) were getting ready to ship Windows NT, which meant "New Technology". Originally intended as a replacement for OS/2, Microsoft designed it in the image of Windows 3.1. Five years in the making, Windows NT, or as critics dubbed it, "Nice Try", was written as a 32 bit OS from the start. Though it looked like Windows 3.1, the Windows NT architecture provided more security and protection from inter-application corruption, by running applications in protected memory space. Applications were prevented from accessing hardware and memory resources, except when given explicit permission by NT. The NT Kernel, or core system, ran in its own protected memory space as well. Theoretically, an application could crash and not bring down the system. In addition to memory protection, a new NTFS file system, Microsoft's newer version of HPFS (the OS/2 High Performance File System) offered higher levels of security.

Unfortunately, even with all its great new memory protection and security features, NT was limited in its support for new devices. As a server operating system, NT didn't need extensive sound, video, and input device support. Board manufacturers provided drivers for NT, but they often lagged Windows 3.x releases, so if you wanted to use the latest graphics card you had to be running DOS or Windows. Additionally, game and software developers were still writing directly to the hardware for best performance, which NT wouldn't allow. Many "well behaved" DOS and Windows 3.x apps would run on NT, but when it came to writing directly to the hardware, NT drew the line. If you wanted to play some of the more popular games, you had to use DOS or Windows 3.x

Windows 95 and NT 4.0
With the announcement of Windows 95 in 1995, consumers and business users were treated to better networking support, better device support, and a more user-friendly environment. The jump was also made to a mostly 32-bit architecture, though backward compatibility with the DOS and 16-bit world was preserved, and a large part of Windows 95 was still 16-bit. Windows NT 4.0 followed, which inherited the Windows 95 user interface, but was built on the more robust NT code base. The main difference between NT and the consumer line of Windows was that it controlled every aspect of I/O for better security and stability, Windows 3.1 and 95 still allowed real mode applications to access the hardware. For gamers, this was good, as most action games ran in real or extended DOS to control video and input hardware directly for better performance. While most game graphics could be drawn using the Windows API's, the performance was not good enough for action. Windows NT would not allow direct hardware control, which sidelined NT as a game platform.

While game programmers were still writing DOS-based applications, accessing the hardware directly, Windows 95 was trying to gain support for DirectX. Windows DirectX promised DOS-like device support, but through Windows-based APIs. The idea was to allow developers to program to the DirectX API and not worry about the underlying hardware. DirectX was streamlined as APIs go, but still didn't receive much support initially. Microsoft revamped DirectX several times, independently of Windows releases. As it improved (and as hardware got orders of magnitude faster), game programmers started adopting DirectX.

Windows 98
Windows 98 brought a better user experience with more device support and the first real USB support (though Windows 98 SE did a better job) and 1394 support, an integrated FAT-32 file system (though Windows 95 OSR2 introduced FAT-32) for more efficient and larger hard disk support, application load improvements and more utilities for system maintenance. While Windows 95 OSR2 (Operating System Release 2) was fairly stable for a Microsoft Windows operating system, it wasn't without problems. Windows 98 included tools to increase stability and provide proactive maintenance. Such features included Scandisk running at boot if you shut down improperly, the Registry checker, and the disk cleanup utility that pops up if you run short of disk space. Windows 98 also improved Internet support, making it very easy for users to setup dialup accounts and get on the web. Internet Explorer was improved with support for DHTML and Java, and it came with email, newsgroup, and web authoring clients. Windows 98 also included DirectX support and kernel enhancements for better audio and video playback.

Windows 98 also brought the Win32 Driver Model, to theoretically provide driver device support common with Windows NT. Windows 98 delivered selected NT kernel services through a special device driver, NTKern.VXD. Windows 98, however, preserved backward compatibility with Windows 95, and was plagued with stability difficulties, such as the infamous Windows 98 SE hang-on-shutdown condition.

Windows 2000

Windows 2000 served as the bridge from NT to Windows XP

Windows 2000 launched amid great fanfare, Microsoft claiming that this new revision of the NT platform would now be easier to use, more robust and more flexible. Earlier versions of NT had supported CPU architectures other than x86-based processors, originally with MIPS, PowerPC, and Alpha. NT for MIPS and PowerPC versions languished, though Alpha NT was fairly successful. Windows 2000 would not provide support for any of these platforms and was squarely an x86platform.

Windows 2000 borrowed much of Windows 98's UI, and supported the FAT-32 file system (in addition to NTFS), so compatibility and upgrades from Windows 98 machines was possible. Windows 2000 was easier to maintain with the Microsoft Management Console (MMC) that put a common interface across all aspects of system maintenance. Third parties could also add snap-ins to provide a common interface for their applications as well. The Active Directory file system added a DNS based file system, with LDAP directory and Kerberos authentication support. Thanks to the Win32 Driver Model, more devices were supported. This made installation easier, though there were still holes in that support. Above everything, Windows 2000 was the most stable in the line of NT versions.

Windows Me
When released in 2000, Windows Me (Millennium Edition) was the last version of the old Windows 95 line. As the first version of Windows focused directly at the home user, it broke from the earlier versions by neither allowing you to boot into DOS mode nor create system disks with Format /S or the Sys command. Windows Me provided the widest level of device support of any previous version of Windows. Previously the domain of IS departments, home users could now add networking with the simple-to-use Home Network Wizard. Windows Me inherited the Windows 2000 TCP/IP stack for more robust Internet connectivity. Windows Me added PC Health features with the ability to restore to previous configurations. This solved a problem that plagued earlier versions of Windows, where poorly-behaved applications could not only not be uninstalled, but would also sometimes render the system unable to boot. Microsoft's focus for Me was compatibility so unfortunately, Windows Me still had occasional stability problems inherited from previous versions.

Windows XP and 2002
With the announcement of Windows XP and Windows 2002, the landscape has changed. The split between the consumer desktop and corporate/enterprise code bases is gone. Microsoft's long-time dream of a unified platform became a reality. Windows XP Professional and Home versions, and Windows 2002 Server, Advanced Server and DataCenter [Note: Microsoft has not committed to either the final name or final SKUs of the Server versions of the new version of Windows. We are following current naming conventions.] are built from the same code base of Windows 2000. This brings a number of advantages for corporate users, consumers and for Microsoft. Corporate users will gain the increased device and software compatibility of the consumer versions, without sacrificing stability and security. With built in DVD support, DirectX 8, and the Windows Media Player, consumers also benefit from the basic stability and security of the corporate versions. Finally, Microsoft can support one code base, concentrating on making it better, and providing features for each group on a solid foundation, which is good for everyone. Time to get down to the nitty-gritty. We'll focus here on the kernel changes in boot up, memory, Registry and file loading that help Windows XP provide better stability and performance. We'll also explore WebDAV support and the controversial Windows Product Activation mechanism. We will address Windows Media, Security, Backup, 64-bit Windows, and User Interface issues in future ExtremeTech articles.

Boot Load Time
Probably high on most users gripe list is boot time or more accurately stated, "boot delays". Whether you're waiting for your desktop machine to get up and running, or you have to restart a server after an upgrade, boot time is important. There are many factors that affect boot time, memory checks, hardware discovery, driver loading, BIOS POST tests, network domain authentication, DHCP access, etc., all of which add to "the experience". Over the last several versions of Windows, Microsoft has worked with BIOS vendors to minimize boot delays by eliminating unnecessary processes, such as memory checks, and memory initialization. With Windows XP, Microsoft has set a performance goal for PC manufacturers to achieve boot timings as specified in Table 1 below.

Changes in the kernel have facilitated these goals, and made it easier for PC vendors to achieve. In the following sections, we'll look at those areas in more detail.

Simple Boot Flag
The first time-saver in Windows XP's boot process is support for the Simple Boot Flag (SBF) specification. The SBF is a simple CMOS BIOS register that is set after Windows boots for the first time, and can minimize subsequent boot times. Windows XP is not the first OS to use SBF, a 1998 spec, as Windows Me and Windows 2000 both set the flag, but it is the first NT-based OS to support it. The Boot register flag is located in CMOS memory and accessed though ports 70h & 71h. The flag holds three bits that identify the OS as Plug and Play (PnP), if the last boot was successful, and if diagnostics need to be run.

Table 2 -- Simple Boot Flag

Bit

Name

Description

PNPOS

Shows that the installed operating system is Plug-and-play capable. If this bit is set, then the BIOS only loads what it needs to boot and transfers execution to the OS boot records.

BOOTING

Shows that the last boot was successful (or not) as set by the OS or the Bios. The BIOS checks this during initialization. If it’s set, the BIOS sets the DIAG bit so it and other components run diagnostics.

DIAG

Shows whether to run the system diagnostics. It is set by the state of the BOOTING bit, or by the OS during a previous boot.

3 - 6

Reserved

Not used, must be set to 0

PARITY

Shows integrity of this register. The other bits are set, and then this bit is set with odd parity. If on boot, the parity doesn't agree, the register is assumed corrupted.

The PnP bit is important in optimizing boot time. When set, it tells the BIOS to only configure the devices it needs to boot. It won't take time to configure resources such as I/O ports, memory windows, and interrupts. In fact, if the BIOS does boot as a non-PnP legacy system (bit not set) it can limit the ability of Windows to reassign resources. The exact spec of what BIOS features are or are not run is in the PC2001 specification, a guide for PC device manufacturers drafted by Intel and Microsoft to create Windows Logo compatible hardware. The guide is updated annually, and the PC2001 guide (http://www.pcdesguide.org/pc2001/) is the most current.

The BOOTING bit is set by the BIOS when it passes control to the OS. If the OS successfully boots, it clears this bit. If the OS boot fails, the bit is left set, and the BIOS assumes a failed boot, and also sets the Diagnostics Bit. This forces the BIOS to run POST (power on self test) diagnostics on the next boot. When clear, i.e. the last boot was good, then the BIOS clears the diagnostic bit so they don't run again. The BIOS will then transfer program execution to the boot sector as quickly as possible. Not only does this avoid POST, but it can avoid memory tests, start disk spin-up early, optional ROM initialization (performing tasks such as SCSI enumeration and video memory clearing), Logo screens, and the floppy disk check. On the second booting of Windows XP, you will really see the effect, even before windows starts to boot. Depending on the speed of your PC, this can save considerable time.

The Parity bit checks the byte against corruption. If the parity doesn't agree, then the register is assumed corrupted. At that point the BIOS will boot as if a legacy OS is installed, (non-Plug&Play), and will set the BOOTING and DIAG bits accordingly and a full diagnostic test is run. Windows XP Boot Loading Optimizations
Beyond support for the Simple Boot Flag, new techniques in Windows XP to optimize the boot process push beyond previous versions of Windows. The Windows XP boot loader has been rewritten to incorporate parallel pre-fetching of drivers, boot code, and Registry items. It also loads larger chunks of memory and rearranging files on disk for more efficient file access. In addition to the physical loading of drivers and data, Windows XP prioritizes driver loading to get the user up to a usable desktop. It loads NDIS and other network drivers, but the system doesn't wait for them to complete before proceeding. Protocol binding for network devices is done in parallel and can significantly improve boot time, especially when negotiating with hubs and routers, or if the cable is unplugged from the network card. If your PC is part of a domain, however, the system waits for network drivers to load to provide authentication, login, and attaching to resources.

On first boot up, Windows XP monitors the drivers, startup applications, Registry entries, and shell code being loaded--basically anything after the kernel starts--and saves information about prior logical disk read operations. Starting on the second boot, Windows pre-loads drivers and code asynchronously in parallel into memory in anticipation of their use. When the boot execution path is ready for a particular driver file, it's already in memory. Windows keeps track of your last eight boots and applies heuristics on what to pre-fetch. If you stop loading a particular driver, such as from a hardware change or different startup application, Windows will see that it isn't being used after a couple of boots and stop pre-fetching that code. In previous versions of Windows, boot files and drivers would load serially, that is one driver would load, then another, then another, and so on. Since much of the delay in boot time in earlier systems was the physical loading of bits into memory, pre-fetching saves time.

Working hand in hand with pre-fetching drivers and applications, Windows XP also dynamically rearranges the layout of files on the hard drive to facilitate better loading. Windows 98 did this to a degree, but as you'll see below, it had shortcomings compared to XP's method. Most people know that defragmenting a hard drive puts programs and data in consecutive sectors for faster loading. When Windows prefetches a driver or application, it will try to load the whole file in one shot. Saving disk seek time is critical because it's an expensive operation in terms of processor cycles.

When a file is fragmented, portions of program code and data that will ultimately be loaded into memory in chunks, typically 4K each, called memory pages, are stored in different locations on the drive. Each request for code or data not already present in memory requires a physical disk access. The disk I/O system looks in the file allocation tables to find the required code or data in a file on the hard drive, and then "seeks" it on the right disk location. This can be a very costly time sink, especially if done repeatedly for the same application as with earlier versions of Windows.

If you assume that the data is consecutively laid out on the hard drive, when the file is small enough it can be loaded in one operation. If it's bigger than the file buffer, then it is read in successive disk reads. By having the data in one contiguous file, only a single multi-track seek might occur, and successive reads only need to read other tracks at the same cylinder, or move a track at a time to get to the next set of data. The operating system keeps a pointer into the file, which is reset to the next point in the file after each read, so explicit seeks are not needed. While the efficiency and time savings in this approach are obvious, it isn't the whole story.

Traditional de-fragmentation rearranges whole files. As we know, you rarely use all the features of an application. Likewise, you also rarely use all the sectors in an application file during each use. Windows 98 pioneered an approach for the OS (third parties offered utilities with similar capability) to increase application load performance by watching and arranging the most frequently used disk sectors of an application within a contiguous area on disk when you ran the defrag utility.

Intel created the technology used by Microsoft, called the "Intel Application Launch Accelerator", and it's used in both Win 98 and Windows Me. The setting in the OS defrag utility was called "Rearrange program files so my programs start faster". Under the covers, it actually arranged the application load sequence in sector load order, which wasn't the same as arranging the entire application files contiguously. Windows 98/Me would look at Word and Excel while running and move program code, DLLs, and even Registry settings to contiguous areas based on their load ordering. In many cases, it would actually increase fragmentation on a file-by-file basis. The problem is that this technique wouldn't scale past a few applications. If the OS always asked for the code in the same order, it worked fine. However, since DLLs aren't replicated, if you loaded up another app that happened to share one of the pre-arranged DLLs, it still has to seek to the location. This can result in better application load performance for some applications, and worse for others. Windows 2000 did not do any application optimization like Windows 98/Me, except it was the first version of NT technology to provide a defrag utility.

Unlike Windows 98/Me, Windows XP uses the more traditional defrag approach of making complete application files contiguous. One big difference between Windows XP and earlier versions is that the optimization is automatically done at idle times. When the machine is idle for 10 minutes or you run defrag c: -b, Windows XP will use that time to optimize the most used files. Through monitoring application load and boot up, Windows XP's determines which application and code files are used, and moves them to a contiguous file space. Windows 98/Me's optimization required a number of runs to get the information it needed to optimize file layout on the disk. Windows XP will start optimizing after your first boot, so your second boot will be faster. While Windows XP is constantly tuning, Microsoft estimates that 90% of the optimization is already done immediately after the first boot or run, and is fine-tuned from there. Go Fetch
So if Windows XP has gone back to contiguous files, rather than grouping sectors in load order like Windows 98/Me, how does it get performance boosts? The saying two heads (or more) are better than one comes into play. When Windows XP boots, it requests, or pre-fetches, everything it'll need for the session at once. Basically, it gives a shopping list to the File I/O system, which in turn brings in large chunks of data from multiple files in overlapping requests. Windows XP not only brings in boot and shell code, but device drivers and Registry settings. There are two exceptions to this, if you need to authenticate against a domain, and if you manually turn off pre-fetch in the Registry.

As with boot, when Windows XP runs an application that has been run in prior user sessions, it pre-fetch's as many of the memory pages it can from the files. For example, consider an application that starts up and uses some pages from the EXE file, then when you load a document, needs more from a DLL file, then more pages of code from a different DLL file. With earlier versions of Windows NT/2000, the I/O system would be asked to load pages separately when needed at runtime, called demand paging, causing delays while pages were loaded. Windows NT/ 2000 did try to optimize by trying to load pages nearby the target pages. Sometimes these extra pages were the ones it needed, sometimes not. However, demand paging did not help when the application needed pages from separate files.

Windows XP, on the other hand, asks for all pages from all known files (from its knowledge of prior loads) in one asynchronous request, letting the I/O subsystem worry about bringing in the data. It will tune the amount of code and data it preloads based on available memory. Windows XP monitors the last eight loads of the application and modifies what it prefetches when conditions change. It also loads applications with as much overlapping of disk requests as possible. Windows prefetches data and Registry settings asynchronously as well as program code. This approach of prefetching all code and data in parallel in one request, coupled with on-going monitoring and disk optimization, creates a self-tuning environment.

I/O Subsystem
The I/O subsystem of the kernel is the workhorse of the operating system. It provides device drivers with access to system resources, such as memory, plus manages the process. It also provides applications with access to the hardware. The performance and robustness of this section is what makes or breaks the OS. Every driver, application, and operating system process relies on memory access. Communications with I/O devices is frequently accomplished using programmed I/O or DMA transfers via various memory buffers and queues. Design decisions in the past, such as allowing device drivers to request memory whether it's available or not, have caused stability problems. The memory architecture can also cause performance problems by using more disk-based virtual memory than needed. Improvements have been made in Windows XP that should lessen or eliminate some of the past stability problems, and the architecture improvements will give better performance. Memory Page Pool
No matter how much your PC has, physical memory is always a precious resource and Windows XP has made some improvements to help the situation. In Windows, physical memory has "page pooled" and "non-page pooled" allocations. Non-page pooled memory is for code that is time critical, such as the Virtual Memory Manager (VMM) itself. Page pooled memory is mapped to disk files and allows the OS to swap the memory pages out to disk if additional physical memory is needed elsewhere.

A memory page represents 4K of physical memory, as mentioned earlier. Memory pages can hold system or user data, application or driver code, or Registry data. When an application runs, executable code is loaded through file mapping objects. The pre-fetcher loads these memory pages. Data and settings are similarly mapped. The pages in pooled memory are mapped to the file and are referred to as views into the file.

Pool memory is managed by a system of descriptors called Page Table Entries (PTE) that incorporate memory page frame numbers, which point to physical memory pages. In addition to memory page frame numbers, the PTE contains bits on the usage status of the page--in use, dirty, clean, and unused. The memory manager keeps track of page status with Page Table Lists for fetching and reuse. To cause the least interruption of running apps, the memory manager uses various algorithms to determine least recently used blocks of memory to spool to disk, though in a low memory condition, or when a large memory allocation is requested, it is not always possible to avoid touching actively used memory and swapping portions to disk. While all virtual memory schemes allows programs to use more memory then is physically available, it can be slow and can cause bottlenecks in processing if not handled well. In previous versions of Windows, memory waste was a prime cause of delays through extra paging to disk.

Windows XP increases the maximum memory size that can be mapped by PTEs to approximately 1.3GB, about twice Windows 2000's pool size (your mileage may vary depending on machine or Registry settings). This allows Windows XP to track more memory without reusing PTEs. Windows XP can allocate up to 960MB of contiguous pooled memory if needed on a system with 256MB of RAM. To increase performance, Microsoft has tweaked its algorithms to use less page pool and minimize going to disk.

When an application or driver creates a file object, it must request the full size of the object, whether it needs it then or not. In earlier versions of Windows, when an application created a file mapping object, the kernel allocated, or "charged" 1/1000th of the file size in PTEs, regardless of the final file view used. While this isn't as bad as charging the whole file, it still can waste space. For example, if a driver created a 1GB file mapping object, the kernel would charge 1MB of PTEs or memory pages. But if the driver only ends up committing to a small 64K view to the file, the potential for waste is obvious. Windows XP does not charge or allocate any PTEs before the view is created, so when the PTEs are needed, they are then created dynamically.

Managing PTEs is an ongoing process, as there is no discrete garbage collection phase. By tracking PTE use continuously, the memory manager can be more proactive in reducing the amount of paging required. For example, an application may allocate large blocks of memory during startup, but then not need them anymore. The PTEs can be reclaimed early, rather than wait until the application terminates.

Within the Page Pool, Windows XP now uses the concept of a small and a large pool. When a driver requests PTEs, the memory manager aggressively tries to fulfill the request from the small pool, saving the large pool for large allocations. This allows the large pool to stay less fragmented, giving Windows a better chance of allocating large memory blocks when needed.

Low Memory Condition Improvements
In the fight between drivers or processes for memory under low memory conditions, the user often loses. Often these conditions are temporary, and are relieved when a driver or process frees up their blocks. When a driver or application process needs memory, it asks the system for a memory allocation. The allocation is either provided or denied. In past versions of Windows, allocation routines that must succeed were allowed to force the system to give the driver some memory. Unfortunately, during lean memory times, it could crash the system. To help get past these low times, Windows XP no longer permits drivers to allocate must-succeed requests. If an application or driver uses a must succeed request, it is denied. All internal Windows XP drivers have been rewritten to avoid the use of must succeed requests. Third party drivers will also have to comply to earn "signed driver" (Microsoft-approved) status.

Another step taken by Windows XP for more robust memory handling is I/O Throttling. For performance reasons, Windows tries to do as much processing in parallel as possible. However, if memory usage gets to the point where there's none left to allocate, Windows will "throttle down" it's processing of memory to a page a time, using the resources it can. While this slows the system, it doesn't crash.

While not directly related to Windows XP I/O or memory subsystem internals, it's worth mentioning a PC's physical memory requirement. For a PC manufacturer to obtain the "Built for Windows XP" logo, they must provide 128MB of RAM. Windows XP Pro and Home Editions can run in 64MB of ram, but the new Fast User Switching would be turned off by default. Microsoft does not feel you can get an acceptable user experience with Fast User Switching in a 64MB configuration. You can still run with the feature, but performance may be impaired. Power Saving
A hot button for laptop users is the performance of an OS when entering or resuming sleep or hibernation. Improvements in recent years in power saving techniques on laptops have dramatically increased battery life, and provided better cooperation with the operating system, which in turn helps with performance. Windows XP has made improvements to increase performance when entering or exiting both standby and hibernation modes.

ACPI power management defines various standard states that the System, CPU, and Devices can interpret and implement depending on their architecture. States are defined as Global level states (G0-G3), sleep states (S0-S5), of which S0 is "system working state", and S1-S5 are actually levels of sleep states that are a subset of the G1 sleeping state. Device level states (D0-D3) exist, and the CPU has its own dedicated operating states (C0-C3). The C0 state is "normal operations" state for the CPU, and it can be subdivided into numerous "performance states" as seen in Intel's SpeedStep, AMD's PowerNow!, and Transmeta's LongRun, though the ACPI performance states don't appear to directly align with the CPU vendor performance states. Power States abstract device specific hardware requirements so the operating system doesn't need to deal with them. For example, when Windows goes to standby mode it can tell the CPU to go to its C3 state. Depending on manufacturer, the CPU may reduce the voltage from 5 to 2 volts on one chip, or 3.3 to sub 1.0 volt on another. (New mobile processors operate well below2 volts, with very low current draw when in sleep modes). The OS doesn't know or care how the CPU went to sleep.

For better CPU power control, Microsoft has moved from power management at the Hardware Abstraction Layer (HAL) to a processor driver architecture. The new power control standard, ACPI 2.0 came too late in the Windows XP development cycle to be fully implemented, but Microsoft has incorporated partial support. With the processor driver architecture, Windows XP has native support for Intel SpeedStep technology, AMD PowerNow!, and Transmeta Long run for improved battery life on mobile PCs. Windows XP supports the 8.3 section of the ACPI 2.0 spec, giving higher granularity of processor control, C-States (CPU power states), processor clock throttling, and P-states (Performance states). C-States define different levels of power savings that shut down various sections of the process that aren't being used. Windows XP can now be smarter about power control. It's essentially the same as shutting down a spare bedroom in your home to save heat and electricity.

Sleep Mode
When Windows XP goes to sleep or standby, it attempts to set the system to the deepest level (i.e. most power saving). Before going to sleep, Windows queries the system to find out if it can go to the deepest level (S3). In reply, the drivers and BIOS either give the go ahead, or not. If it can't go to S3, it requests a lighter sleep level until it gets a unanimous go ahead. One condition, for example, that would prevent it from going to the deepest level would be a modem card set for Wake on Ring, requiring power to monitor the incoming phone line.

When your PC resumes from standby, through a wake up call from a modem, a key press or mouse movement, a number of things happen. To change the power state of the PC from standby to active, Windows sends a series of I/O Request Packets (IRP) to devices that indicates a power change to S0, full on. Windows XP's IRP dispatching engine has been rewritten to send messages more asynchronously than previous versions. Windows XP's ndis.sys, the network driver, has been changed to initialize without waiting for device initialization to complete. In addition, The PCMCIA, keyboard, and mouse drivers now initialize in the background, cutting out even more wait time for the user. For the drivers and code that is needed to get you to a useable state, Windows uses asynchronous pre-fetching as it does with boot up to get up faster as well. Microsoft's license agreement won't let us publish exact benchmark times on a Beta version. However, we found with a clean installation of Windows XP Professional Beta 2 resumed from standby mode in less than 8 seconds on a Dell 4100 PC with a PIII 1GHz processor.

Hibernation Mode
Hibernation is the process where the operating system saves an image of the system's physical memory to a hidden file (\hiberfil.sys) so it can power down completely. The difference between Hibernation (power state S4) and off (power state S5) is that system memory is saved to disk. Depending on your hardware, you can put a machine into Hibernation manually, for instance by closing the lid on a laptop, or from a set amount of time in the Power Options Property dialog box. The hiberfil.sys file is by default in the root directory of the boot drive (usually C:\), and is the same size as physical memory.

Windows XP improves performance on saving and returning from hibernation in several areas. Before the hibernation file is written to disk, unused memory pages are freed, reducing the overall amount of memory that needs to be saved. The remaining physical memory pages are compressed as well. When the compressed memory pages are written to disk, Windows XP uses IDE DMA (Direct Memory Access), a more efficient method, rather than PIO (Programmed Input/Output). With PIO access, data goes through the CPU, while DMA goes direct from memory to the drive. In addition, the compression algorithm has been optimized to work on large, 64K blocks of memory for more efficient data transfer. Lastly, Windows XP overlaps compression and disk writes so while one block is being written, another is being compressed.

On resume, Windows XP is at the mercy of the BIOS for disk access, since not enough of the operating system is loaded to be able to do overlapping reads and decompressions. The memory pages are read and decompressed serially. However, the memory preparation and compression that Windows XP did on the writing side results in smaller amount of data to retrieve from disk. Since this is slowest horse in the race, keeping disk reads at a minimum gives a performance boost on the resume. With our informal testing with a clean install of XP Professional on a Dell 4100 with 256MB of RAM, resuming from hibernation took less than 30 seconds. Registry
The Windows Registry can be both a blessing and a curse. As a big database, the Registry has become responsible for everything in Windows from application locations and settings, logons and file associations, to the color of your desktop background. Almost every application touches the Registry in some way. Users of Windows 9x & NT have noticed performance degradation as the Registry grows.

When the Registry is churned, through installing and uninstalling programs, or applications deleting keys, the Registry becomes fragmented, just as a hard drive does. Third parties such as McAfee, Norton, and Trend have offered utilities to cull unused keys and compress the Registry. Windows itself has command line Registry cleaning tools as well, but none of these work until you start them manually. Under previous versions of Windows, when an application saves keys and settings to the Registry, the kernel puts them into the first space in the Registry that it finds. If there isn't enough space for all the keys, they are split up. This results in more fragmenting, and related keys end up on different memory pages. When the application goes to read those keys and settings, the kernel has to read more memory pages from the disk, which causes delays.

Find the Right Space
For Windows XP, the Registry code has been redesigned and the algorithm for storing keys and settings has been changed. Now, when an application or the OS goes to store keys and settings, the kernel will search for a space large enough to contain all the data. By grouping application keys physically, when the kernel later looks up a key, all the data is on the same or adjacent memory page, resulting in fewer page faults (which occur when requested data's not in memory, resulting in a disk read).

Microsoft has also moved the Registry data out of the kernel paged pool memory to mapped files. The Registry management code itself is still in the kernel, but with the data stored outside the kernel memory, it won't run out as fast. In previous versions of Windows, the Registry was stored in the paged memory pool of the kernel, which was limited to approximately 160MB.

What good is having more Registry memory, you may ask, as that will only create longer delays in key searches. Under earlier version of Windows, this was true. An architectural change in Windows 2000 helps the situation by caching keys and settings, so a first request for a key actually hits the Registry memory, but subsequent requests are pulled from the cache, increasing performance.

However, a common programming practice is to use the presence of a Registry key as a flag in applications. If the key data is present, the application does one thing, if not, it does something else. While a simple concept, it unfortunately has a heavy performance hit when the key doesn't exist. Some applications create empty trees of keys in the Registry at runtime, and just leave them empty. Other applications don't create keys, but search the Registry for keys just the same. When this happens, the kernel is asked to search the entire Registry, or at least through trees of empty keys, every time. Windows 2000 caches existing Registry keys, but if the key or keys are not found in the cache, a Registry search is performed, and as the registry grows, so do the delays.

To boost Registry performance, Windows XP now caches both existing and non-existent keys. This results in a relatively large performance boost when an application requests a Registry key, because it is retrieved from the cache regardless of the key's existence.

click on image for full view

click on image for full view

Compare key searches with Windows 2000 and Windows XP

Also, when an application requests a Registry key for the first time, a Registry search is made, and regardless of whether the key is found or not, the result is cached. At the same time, Windows monitors and records the keys that the application has requested, and when the application loads in the future, Windows pre-fetches the Registry keys required. This improves performance on future application loads even if the OS has been rebooted, which resets the cache, by asynchronously requesting the keys and getting them cached so when the application requests the key or keys, they are already loaded. WebDAV Redirector Support
Web Distributed Authoring and Versioning (WebDAV) is a simple extension to the HTTP/1.1 protocol that allows data to be written directly to HTTP servers. Defined by RFC (request for comment) 2616, WebDAV was designed as a protocol for collaborative authoring using existing tools and protocols. It uses XML encoding to move, copy, delete, and create collections of items (groups of like objects, such as documents). WebDAV also supports getting and setting properties, such as document titles or author name. It is used today in a number of ways, including uploading web sites from development tools, version control, and general web document storage. Microsoft's MSN Web Communities allows WebDAV access, giving you a centrally located file store. Microsoft IIS 5 (with Windows 2000) has WebDAV built in, as will IIS 6 when it ships. Office 2000 and FrontPage have been able to access WebDAV enabled sites, but with their own support for the protocol. WebDAV is also supported in Microsoft's Web Storage System.

Windows XP integrates a WebDAV redirector into the file system. Now you can use any existing Windows application to access a WebDAV file share. Windows XP lets you use standard network UNC file format (e.g. \\www.servername.com\target\dir\file.doc) or by mapping a drive letter just as you would to any network share. In addition to the UNC format, when an application uses a standard Windows file dialog, it can also use the http: name format (e.g. http://www.servername.com/target/dir/file.doc). What this means is you can open a file on the web with notepad, make changes, and if you have write permission, save it back. Windows XP uses the built in authentication manager to authenticate you if needed.

Being able to save documents on a web site directly from an application may not seem like a big deal, but having the capabilities built into the OS can save developers considerable work. In addition, when combined with Windows XP's file encryption, the possibilities really start to come into view. Personal files can now be stored securely on a public place. It suddenly makes using MSN Communities, or any of the dozen other web storage sites useable for more than sharing pictures. To use Windows XP's encryption system, you must have an NTFS volume. To automatically encrypt WebDAV files, the cache should also be on an NTFS formatted drive. While similar, WebDAV differs from the FTP protocol in that FTP uses two channels, one for data and one for control, while WebDAV uses a single channel. Another advantage of using WebDAV is that it works through a firewall, as long as it allows Internet HTTP traffic and doesn't filter explicit WebDAV packets (a lot of overhead for a system). If you can browse the web, you can use WebDAV. The CIFS (Common Internet File system) file format, the standard Microsoft Windows file sharing protocol, is powerful, but is more apt to be blocked by a firewall. Unlike CIFS, which allows partial file modification, WebDAV requires that a whole file be written. When you open a file from the Web, the file is copied locally to Internet Explorer's cache. Once you make your changes and close the file, Windows XP automatically puts the updated file back to the Web location.