Plug and Play
Another desirable feature in Win9x is the OS's ability to automatically detect a new hardware device and install the appropriate device driver. Microsoft has kept this functionality in Win2K. The Win2K PnP Manager can identify hardware conforming to the ACPI standard that is located on a system's I/O buses; if a device driver isn't installed for the detected device, the PnP Manager initiates the driver's installation procedure. To make this capability possible in Win2K, Microsoft made significant changes to the way NT 4.0 implements device drivers.
In NT 4.0, a device driver must enumerate buses to search for hardware that the driver works for. In Win2K, the PnP Manager enumerates the buses to locate devices and inform drivers of the devices' presence. Two numbers identify a device on a bus: a vendor ID (VID) and a device ID (DID). The combination of these ID numbers uniquely identifies a device. Upon locating a combined VID and DID, the PnP Manager checks the HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Enum subkey that corresponds to the bus on which the device is located (e.g., the PCI bus). The PnP Manager searches the subkey for a key that connects to the detected VID and DID. If a driver is already installed for the device, a Registry value for the device's key will reference another Registry key in HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\Class that contains information about the device driver file. If a driver isn't yet installed for the device, the PnP Manager notifies the user-mode PnP subsystem that the subsystem needs to locate the appropriate driver's installation script (.inf file) and initiate the driver's installation.
Another advantage of PnP is that it lets Win2K tell drivers to reconfigure their hardware. Some buses, such as Personal Computer Memory Card International Association (PCMCIA), generate OS notifications when you add or install devices. For example, suppose a user inserts a new PC card that requires the use of hardware resources, such as interrupts, that another device is using. The Arbiter, a Win2K PnP component, reorganizes device-resource assignments to accommodate the new device. The PnP Manager informs the other drivers of the changes, and the drivers reset their devices accordingly.
The Windows Driver Model
The final significant change that Microsoft has made to the NT 4.0 kernel in Win2K is adding support for the Windows Driver Model. WDM is a convention that Microsoft has adopted for separating a device class' general functionality from a particular device's specific functionality. For example, Human Interface Devices (HIDs) such as keyboards and mouse devices share common characteristics but differ from one another in control and configuration details. Thus, one WDM class is the HID class, for which Microsoft provides a HID-class driver that serves as the high-level interface to all types of HID devices. Hardware vendors implement proprietary HID minidrivers that interface the HID-class driver to their devices and support the device's particular functionality. Table 1 lists the device classes that WDM supports.
WDM makes life easier on hardware vendors in another way, albeit in a way that will eventually become unimportant: Properly written WDM drivers easily port from Win2K to Win98, and vice versa. Microsoft has already made this capability possible with network adapter drivers and mass storage device drivers, but WDM extends the convenience to many more types of devices.
Reliability Enhancements
Win2K debuts several features that prevent, avoid, and resolve system crashes. In NT 4.0, device drivers can modify, or write to, any part of kernel-mode memory. Device drivers and the NT kernel reside in kernel-mode memory, which creates the possibility that an errant driver can corrupt another driver or the OS. With the aid of a processor's memory management unit (MMU), Win2K marks as write-protected the drivers' and OS image's code portions. If an errant driver attempts to modify these portions of kernel memory, the Win2K Memory Manager immediately detects the violation, and an administrator or developer can then easily identify the faulty driver.
A new Win2K development tool called the Driver Verifier isolates many more types of device-driver errors. When the system applies the Verifier to a device driver under suspicion of misbehaving, the Verifier closely monitors the device driver's use of kernel memory buffers and the driver's interactions with the Win2K kernel. The Verifier relies on Win2K kernel support to immediately detect common violations of device-driver programming rules. Thus, an administrator can precisely and immediately identify drivers that cause system instability, rather than having to work with possibly misleading clues when a crash occurs at a later point.
To help resolve system crashes, Win2K offers the Safe Boot and Repair Console options. Safe Boot is a boot option that Win2K presents to a user as the OS prepares to load. Safe Boot lets users specify that Win2K load a minimal subset of device drivers and services, rather than loading all installed device drivers and services. When a third-party device driver habitually prevents successful startups because it crashes Win2K, you can choose Safe Boot to tell Win2K to avoid loading the driver. Two basic safe-boot types exist: minimal and network-enabled. The Registry key HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\SafeBoot has the Minimal and Network subkeys, which list the device drivers and services that are part of each configuration.
The Repair Console is a recovery option that you can fall back on if Safe Boot fails to get a system running. The Win2K setup CD-ROM installation procedure gives you the option to boot from the CD-ROM to a minimal command prompt from which you can access a fault installation. You use commands at the prompt to enable and disable device drivers, and to copy, delete, and refresh system and device-driver files.
NTFS Version 5
The NTFS file system's version 5 implementation, which ships with Win2K, has undergone major enhancements. A long-standing user complaint about NTFS has been that NTFS won't let users create symbolic links—files that redirect path processing to another file. For example, if \temp\link is a symbolic link to \myfiles, then the path \temp\link\ mark.txt would resolve to the file \my files\mark.txt. NTFS in Win2K implements reparse points to address symbolic-link creation. Reparse points are files that contain a tag and as much as 16KB of application-defined data. The reparse tag identifies the device driver that interprets the application-defined reparse data associated with the reparse point. Thus, when NTFS processes a path and encounters a reparse point, NTFS hands the reparse data to the device driver that the reparse tag references. The referenced driver can return a different path to NTFS to process, or it can perform other processing specific to the reparse-point type.
Symbolic links are specific types of reparse points called junction points. Figure 3 shows an example of a junction point. The NTFS drive manages junction points. Other reparse points you might use as you deploy Win2K are associated with Hierarchical Storage Management (HSM). An HSM driver can designate reparse points to identify files and directories that the system migrates to offline storage. When NTFS processes a path with such an HSM-associated reparse point, NTFS notifies the HSM driver and can bring the data back to main storage.
In the NT 4.0 market, numerous third-party disk quota-management tools fill the need systems administrators have to control the amount of disk space users consume. Win2K brings quota support directly to NTFS; in NTFS, administrative tools can define quota thresholds for specific user accounts or as global defaults for all users. Every NTFS file has an Ownership security attribute that, with a SID, identifies the user account with which the system associates the file. So that it can invoke appropriate actions when users reach data limits, NTFS keeps track on a per-disk basis of the total amount of data that the system associates with each user. Administrators can define two user limits: a warning threshold and a limit. When users reach the warning threshold, Win2K informs them that they need to delete files to stay within their quota. When users reach their limit, the system prevents them from allocating more disk space.
Many applications that manage on-disk databases or caches often allocate sparse files. Sparse files are files that might contain a large number of undefined spaces—spaces that the application might never initialize. For example, an application might create a 2GB database file upon installation, then fill the database file as users add records to the database. The database application might not store the records at the beginning of the file but rather where the application determines is most efficient with respect to its storage algorithms. In NT 4.0, whenever an application allocates a file, whether the file is sparse or not, NTFS allocates on-disk storage to represent the file and fills the space with zeros. A Win2K optimization permits applications to designate a file as a sparse file; NTFS then allocates on-disk space only for the portions of the file that the application defines. This enhancement results in disk-space savings and improves application performance.
Desktop and Start menu shortcut links are convenient NT user interface (UI) features. However, if you move the file that a shortcut refers to, you break the shortcut. Then, you must manually reconnect the shortcut to the link target. NTFS in Win2K has built-in link tracking, a facility that lets NTFS track the movements of link targets. When a link target moves to another NTFS volume within the same domain, NTFS can transparently update the link to point at the file's new location. Link tracking applies to desktop shortcuts and OLE links.
The final Win2K NTFS enhancement is Encrypting File System. EFS is an add-on device driver that is tightly connected to NTFS. EFS and NTFS together provide transparent file encryption and decryption facilities for user files. A user marks a file or directory as encrypted, and EFS and NTFS generate a file encryption key (FEK) for the encrypted file. EFS uses the FEK and a stronger variant of the Data Encryption Standard (DES) algorithm—DESX—to encrypt the file's data. Then EFS uses RSA public-key-based encryption to encrypt the FEK with the user's automatically assigned EFS encryption key and stores the encrypted FEK with the file. When a user accesses an encrypted file, EFS uses the user's key to decrypt the file's FEK, then uses the FEK to decrypt the file's data. Although third-party utilities provide encryption facilities for NT 4.0, EFS has the advantages of being totally transparent and supported by Win2K's administrative, backup and restore, and data-recovery interfaces.
Other File-System Enhancements
Win2K includes file-system enhancements that aren't related to NTFS. First, Win2K fully supports the FAT32 file-system format. NT 4.0 can't interpret FAT32 drives without a third-party add-on's help, and under no circumstances can NT 4.0 boot from a FAT32-formatted drive. Because FAT32 handles space more efficiently than FAT16 does and can also handle larger disk sizes than FAT16 can, FAT32 is a better file system format for installations that don't require NTFS's reliability or security features. Many Win 9x installations use FAT32 for the advantages it confers over FAT16, so Win2K's support for FAT32 makes it possible to share data on FAT32 drives between the OSs in dual-boot environments. Instead of adding a new device driver to implement FAT32 in Win2K, Microsoft simply extended the FAT12/ FAT16 driver, \%systemroot%\ system32\drivers\fastfat.sys, to understand FAT32.
NT 4.0 assumes the CD-ROM File System (CDFS: International Organization for Standardization—ISO—9660) as the format for read-only media, including CD-ROMs. The Universal Data Format (UDF) file system is a cross-platform standard (ISO 13346) that will slowly replace CDFS for CD-ROMs and will become the DVD-ROM format. Win2K includes UDF support with the \%system root%\system32\drivers\udfs.sys file system driver, which lets Win2K access DVD-ROM file-system data, which will become useful as DVD-ROMs proliferate and replace CD-ROMs.
Terminal Services
To support multiple interactive user sessions through thin-client connections, the Win2K kernel incorporates the kernel changes that Microsoft implemented in NT Server 4.0, Terminal Server Edition (WTS). These changes require the kernel to support the concept of a session (in which a session includes a private copy of the Win32 kernel subsystem, graphics drivers, and input devices) for each user connected to the server. In addition, in user mode, each session has a copy of the logon process (i.e., Winlogon) and the Win32 user-mode subsystem (i.e., csrss.exe).
By specifying that each user associate with a complete desktop state, Win2K can implement a multiuser environment with minimal changes to the kernel architecture, device drivers, and user-mode applications. Microsoft incorporated many other changes in Win2K to make terminal services work, including adding RDP device drivers and enhancing the Object Manager kernel subsystem's naming scheme to specify kernel objects that are local to a session or global to the system.
More than 90 percent of Microsoft's work in making Win2K support multiple interactive user sessions involved changes to the core memory manager. By tightly integrating this support in the core, most drivers and user components in Win2K work without needing to be aware that multiple sessions might exist.
The End of the Tour
As you've seen, Microsoft leaves much of the Win2K kernel unchanged from NT 4.0. The Process Manager, Security Manager, Cache Manager, and I/O Manager, for example, enter Win2K from NT 4.0 without alteration. However, all the kernel subsystems in Win2K are performance-tuned, and some have significant new functionality. In addition, Win2K includes the new PnP Manager and Power Manager subsystems. All of the changes in Win2K fully round out the foundation that Microsoft built with NT 4.0.
End of Article
)
Register
RAJAGOPAL May 09, 2004