Kernel enhancements are often seen as only of interest to developers. Administrators may wonder, what’s in it for me? In this Daily Drill Down, I’ll explain some of the more significant improvements Microsoft has made to the XP/.NET kernel and, more importantly, what these changes mean to you—even if you’re not a programmer. The new kernel features I’ll discuss can be broken down into four categories:
- · Registry improvements
- · Beefed-up I/O subsystem
- · New memory management features
- · Faster boot-up
The Registry serves an important function in all Microsoft operating systems from Windows 95 forward. In each new operating system version, Microsoft has refined the functionality of the Registry, adding new subkeys and entries to give administrators even more control over the behavior of the operating system.
The XP/.NET Registry code provides a couple of practical benefits to users and administrators: The Registry can be larger than in previous versions of Windows, and Registry queries are faster.
Support for larger Registry size
In previous versions of Windows, the size of the Registry was limited to about 80 percent of the paged pool size. This generally meant a Registry size limit of about 376 MB.
The paged pool consists of the memory for objects that can be paged to disk (virtual memory). The size of the paged pool is set by the operating system, based on how much physical RAM is installed in the machine, and taking into consideration the size of the nonpaged pool (memory for objects that cannot be paged to disk).
Windows XP/.NET has removed this limitation. The Registry has been moved out of the paged pool; XP uses the Memory Cache Manager to map the Registry, in chunks of 256 Kb, into the system cache. Now the total Registry size is limited only by the amount of disk space available. The System hive, however, still has a maximum size, but it has been increased from 12 MB to 200 MB.
Support for faster queries
Queries to the Registry are processed faster in XP, due to the caching performed by the Memory Cache Manager and the way Registry information is stored. With earlier Windows versions, when a new Registry subkey was created, it was stored in the first available space located. XP uses a more organized approach, placing all related subkeys into the same physical group, located contiguous to one another. This reduces the number of page faults that occur when accessing Registry information.
A page fault occurs when the data that the software is attempting to access is not found in memory and has to be retrieved from the disk.
Windows XP further speeds up query time by caching Registry keys so that they can be accessed faster. XP is able to monitor the usage of Registry keys by applications, so that the keys that are needed are already in memory.
Beefed-up I/O subsystem
The operating system kernel is divided into several parts, called subsystems. The I/O subsystem gives applications access to the computer hardware, gives driver software access to system resources, and manages communications with I/O devices. It acts as the intermediary between the operating system and hardware devices (through their device drivers).
Improvements to the Windows XP I/O subsystem make the operating system more stable than in previous versions of Windows and provide for faster performance.
Performance is only one factor in selecting an operating system, and in most cases, it’s not the most important one. For a production machine, whether it’s a desktop client or server, stability and reliability are the top priorities. A fast machine is of little use if it crashes frequently.
Microsoft has made some changes to the kernel to increase stability and reduce the chance of system crashes:
- · I/O throttling: When the system runs out of memory that can be allocated, it processes I/O information in sequence, one page at a time. This reduces performance but keeps the system from crashing when there is no memory left.
- · Drivers no longer allowed to make “must succeed” requests of the operating system: In earlier Windows versions, the operating system was required to allocate memory to the driver even if memory was low, which could cause a system crash. Even if the driver software does make a “must succeed” request in XP, that request will not be granted.
Defragger on steroids
The APIs for system defragmentation have been rewritten to change the way data is defragmented and improve the defrag process. In Windows 2000, the defragmenter was limited in functionality; for example, encrypted files couldn’t be defragged, nor could the Master File Table (MFT). Because the system cache is no longer used by the defragmentation APIs (which required read access), files that are encrypted can now be defragmented. The MFT can be defragged, as well.
Another drawback of the W2K defragger was its inability to defrag drives that had large cluster sizes (over 4 Kb). This limitation has been removed in Windows XP. It is also possible to mark NTFS files so that they won’t be defragged.
A number of improvements have been made to NTFS that further enhance security, performance, and reliability. The default access control list (ACL) on NTFS volumes is stronger now, for improved security. It’s now possible to use EFS to encrypt the client-side caching database. Also, the Windows XP Explorer uses the Read-only directory flag to increase performance when the directory contains metadata.
Improved fault tolerance
Several of Windows XP’s new kernel features support increased fault tolerance. Along with reliability, fault tolerance is an essential component for any mission-critical computer. New or improved fault tolerance features include:
- · System Restore
- · Improved driver rollback
- · Shadow copy
The System Restore feature (available in Windows XP but not in .NET Server) lets you create checkpoints and then restore the system to the state it was in when the checkpoint was created. This doesn’t affect your data files—common data file extensions like .doc aren’t restored, and nothing in the My Documents folder is restored, to prevent overwriting your data.
System Restore uses a file system filter driver named Sr.sys. Restore points are created automatically at set intervals for all drives (you can modify this by changing restore settings) and when specific events take place, such as the installation of a program. You can also create a checkpoint manually at any time.
Improved Driver Rollback
Driver Rollback support in XP makes it easy to revert to a previous version of a device driver if you install a new driver and find that it ends up causing problems. XP saves a copy of the old driver in a special folder, from which the old driver can be restored to replace the new one.
You can use the Device Manager (accessed via Start | Control Panel | System | Hardware) to roll back a driver. Just locate the device in Device Manager, right-click on it, select Properties, click the Driver tab, and click the Roll Back Driver button.
If the system won’t boot into the operating system after you install the new driver, you obviously can’t access the Device Manager. In that case, press [F8] during startup to bring up a menu from which you can select the Last Known Good option. This will start the computer with the drivers as they were the last time the system booted successfully (i.e., with the old driver).
You can only use Driver Rollback if you’ve upgraded the driver at least once. Be aware that multiple levels of rollback are not supported; that is, you can only roll back to the previous driver. Also note that driver rollback is not available for printer drivers.
Another new feature in XP is the ability to create a shadow copy as part of the backup process. This is like a snapshot or replica of all files on a volume, even those that are open. This means that a backup can be made while users or programs are accessing the files, and the open files will not be left out of the backup as they were with previous versions of Windows.
One of the most noticeable improvements in Windows XP is the much faster boot process. If you’re used to waiting … and waiting … and waiting for Windows 2000 to apply personal settings, apply security settings, load services, and so on, you’ll be pleasantly surprised to find that Windows XP boots into the operating system in a fraction of the time.
Microsoft has made a number of improvements that combine to make XP the “fastest boot in the west.” These include:
- · Quick logon
- · Quick hibernate and resume
- · Prefetcher
You can log on more quickly with XP because the Winlogon service no longer sits around and waits for the workstation service to start (which in turn must wait for networking services to start) before it starts up and provides the user logon screen.
Another change that speeds up the boot-up and logon process is that the drivers for network cards and serial devices can load simultaneously, instead of one at a time, as is the case with Windows 2000.
Note that some circumstances may slow down the normally fast logon process in XP. For example, if you’re logging on to a domain, and modifications have been made to domain policies that pertain to logon, this can slow the process. Using a roaming profile also slows the logon process, because the profile must be located and downloaded from the server.
Another component of faster startups is the ability to resume operation quickly from hibernate or standby modes. When you place the computer in hibernate mode, everything that is in physical RAM is saved to the hard disk in the hyperfil.sys file. (By default, this file is placed in the root of the system partition.) If pages that aren’t used are in memory, they’re freed to decrease the size of the file, and the rest of the pages are compressed to further save space on the disk. Then, the monitor and computer are turned off. When you restart, the saved pages are decompressed and read back into memory, one at a time. The desktop is restored to the same state it was in when you shut down.
Standby mode doesn’t turn off the system completely but puts it into a lower power-usage state. Energy hogs such as the monitor and hard disk are turned off, and the computer uses only enough power to maintain its idle state. You can resume from standby mode more quickly than from hibernate mode because the system is never completely turned off. However, the data in RAM is not saved to the disk in standby mode; if the power goes off (for example, if the laptop battery dies) or someone shuts down the system, the state of your desktop will not be restored when you restart and unsaved data will be lost.
One of the more exciting new components of XP’s fast startup process is the prefetcher, which allows the operating system to actually “fetch” data from the disk and put it in memory before it’s needed. This works in several ways to speed up performance:
- · Loading of drivers is prioritized and performed in parallel (several at a time), rather than serially (one after the other).
- · Boot codes are defragmented so that all of the code is placed together in memory, resulting in faster seek and execution time.
- · Drivers, startup applications, Registry entries, and shell code are monitored by the operating system during boot-up. This information is then saved. On subsequent boot-ups, these files are preloaded into memory in parallel, saving time on subsequent boot-ups. (Information from the previous eight boot-ups is stored.)
- · Application code can be loaded more quickly because the system monitors frequently used files and then loads the code in bulk. The code that is used most frequently is moved into contiguous space. Each time the application is loaded, the process is fine-tuned.
The prefetch information is stored in the Windows directory, in the Prefetch subdirectory, in binary format.
How does the system know which data should be prefetched? The Cache Manager component takes care of monitoring page faults, which tell it which data has to be retrieved from disk in the paging (or swapping) process. Cache Manager monitors the boot process and the first 10 seconds of the startup process for each application. This produces information called a trace, which is passed to a Task Scheduler component that processes the trace data and writes it to a file in the Prefetch directory. You can identify the application to which the trace pertains because the filename will start with the application name. The filename also contains a hash, in hexadecimal notation, of the path to the file, and has a .pf extension. (The trace file for the boot process is called NTOSBOOT-B00FAAD.PF.)
The next time the system boots or the application is started, the Cache Manager looks in the Prefetch directory. If there’s a file there for the boot process or application, the data and code referenced in the trace file will be put into memory, if they’re not already there. This prefetching decreases the amount of time that was lost under previous operating systems in seeking the data and reading it into memory from different, disparate locations on the disk.
Task Scheduler also defragments the prefetch information on a regular basis to make subsequent prefetches even quicker because the data will be located on the disk in the order in which it is to be used.
The Windows XP kernel has numerous improvements not addressed here, many of which are of interest only to developers, and others that pertain only to installation on specific hardware (such as support for 64-bit Itanium processors). I’ve provided an overview of some of the XP kernel changes that make a difference to users and administrators in terms of stability and reliability, recoverability, and performance. The XP kernel provides the foundation for Microsoft’s fastest and most stable desktop operating system yet.