Vista reduces the total number of HAL types to include only halacpi.dll and halmacpi.

dll, and both are copied to the hard drive on all installations. Vista does not support the other HAL types. Because of the many HAL versions used by Windows XP, creating an image of Windows XP that will be used for installation on multiple systems should take place on a system that uses the same HAL as the target systems. The systems need not be identical, but both source and target systems should both have the same features (both supporting ACPI, both supporting multiple physical processors or multicore processors, and so on). If you create an image on a system that uses a different HAL than the target system, the target system may display a STOP 0x0000007b error after you apply the image and restart it.

Note To learn the relationships between sysprep images of Windows XP and supported HAL types, see Microsoft Knowledge Base article 309283 at http://support.microsoft.com. Windows Vista no longer uses different HAL drivers for systems. Instead, it uses a hardwareindependent HAL that enables you to create a Windows Vista image and deploy it to any Windows Vistacompatible system, as described in Chapter 3, "Installing Windows." You no longer need to be concerned about mismatches between source and target hardware as with Windows XP or earlier Windows versions.

Note If you support both 32-bit and 64-bit versions of Windows Vista, the only limitation you have is that you must create a 32-bit image for 32-bit processors (or 64-bit processors running the 32-bit version of Windows Vista) and a separate 64-bit image for 64-bit processors running the 64-bit version of Windows Vista. With Windows Vista SPI, a single image can be used for both 32-bit and 64-bit installations. Thus, it is no longer necessary to maintain separate 32-bit and 64-bit images.

Device Drivers Device drivers are BIOS-level components written to manage specific hardware devices, and act as an interface between the device and the operating system. Although the driver is concerned with the intimate details of the particular make and model of hardware it's designed to control, it also shields the operating system from having to know these specific details. As far as Windows is concerned, the various categories of device drivers are just interchangeable parts, each doing the same job in exactly the same way. For example, device drivers for graphic display adapters come in versions for each model of display adapter made, and there are dozens if not hundreds of these. Each one uses memory differently, has different mechanisms for setting resolution and update frequency, and so on. But as far as Windows is concerned, these hardware details are irrelevant; Windows can instruct the driver to shade a particular pixel on the screen a certain color, and the display adapter driver does whatever it has to do to make the hardware display that pixel. Likewise, the drivers for ATA and SATA hard disk interfaces shield Windows itself from the details of managing those devices; Windows can, for example, simply request logical block address number 63 from hard disk 0, and the disk driver will fetch it.

Part of the job of the operating system is to protect each of the system layers and user applications from interference by each other; this increases both security and reliability. On Windows NTbased operating systems like Windows XP and Vista, user-level programs are not allowed to directly access any system hardware; the processor instructions that initiate input/output activity are blocked (or in some cases are intercepted, and the action they would have performed is simulated by the operating system using calls to the appropriate device driver). The memory ranges that correspond to device hardware interfaces are not accessible. The reason for these restrictions is primarily to give the operating system absolute control over the hardware in an environment where several applications could attempt to perform the same action at the same time. For example, with several applications running, it might happen that two of them would attempt to write data to the disk at the same time. If allowed to access the disk hardware directly, one application might instruct the disk to move its read/write head to a certain position and then to write data at that position. Another application could decide to do the same thing, and could move the disk head to a different location, while the first was still writing. The result would be a scrambled disk. Device drivers themselves, however, must have unfettered access to the device hardware that they manage. The majority of them run in the context of the Windows kernel, where they are permitted to execute input/output instructions and hardware devices. And while each application program is allowed to access only a limited amount of memory dedicated for its use, device drivers have direct access to all of the PC's memory. This total access carries some risk. A bug in a device driver can cause it to execute inappropriate instructions or memory accesses, leading Windows to conclude that its code could have become corrupted, and as discretion is the better part of valor, this causes an immediate halt: Windows displays the infamous Blue Screen of Death (BSOD), so named because the screen is blue with white error message text, and the system halts dead in its tracks and the only remedy is to cycle its power. Usually the BSOD indicates that a device driver caused the shutdown, but occasionally the bug corrupts some other driver or component, and...well, it's a nasty situation in any case. But the advantage of a kernel driver is its faster performance. When the device driver is copying data between a hardware device and an application program, kernel mode makes it possible to copy the data in a single step. A user-mode driver would require a copy from the device to the driver's address space, and then another copy from the driver to the application.

File Systems and Filters For storage devices such as hard disks, floppy disks, CDs, and DVDs, device drivers are used to manage the disk's physical controller hardware and to read and write data. However, the data on these devices is structured into files and folders, using any of several different file systems. For example, floppy disk data is organized using a file system called FAT-12, where FAT stands for File Allocation Table, and the 12 refers to the fact that the system is based on 12-bit numbers. The NT File System (NTFS) is used on larger volumes under NT-based operating systems such as XP or Vista, with PCs running Windows Me or older using FAT-32 and FAT-16 file systems. Many external drives also use FAT-32 to ensure read/write compatibility with Apple Mac systems, which cannot write to NTFS volumes. CDs, CD-Rs, CD-RWs, and DVDs use still other formats, and then there are flash cards, smart cards, and other devices. In order to maintain independence between the software that operates the hardware and the software that interprets the data stored on it, there is an additional layer of software called file system drivers.

Here's how these layers work: An application program that wants to read a file from the disk passes its request to the Win32 subsystem. If the desired file is on a disk formatted with the NTFS file system, the NTFS file system driver works out exactly where on the disk the data is located. It asks the disk drive's driver to get it, the driver instructs the disk's hardware to move to a particular location and read it, and the data is passed back up through the same chain. Now, added to this picture are other drivers called filters that position themselves in between any of the layers we've described so far. Filters can let requests move down through the layers and their results come back up, or they can intercept the flow of data and take some other action. One use of the filter mechanism is to allow a developer to add support for some new feature, file system, or device that hasn't been conceived yet. Another use of the filter mechanism is to add a security feature. For example, antivirus programs add filter drivers just above the file system drivers, where they intercept requests for reading data from your drives. When the data has been read, they can examine it all before any other program has a chance to see it, and can take appropriate action if they decide the data contains a virus program.

Services Device drivers have unhindered, unprotected access to hardware. A great many of the internal functions of Windows don't need to have the kernel's unrestricted access, but they do need to run all the time, whether you're logged in or not, and they may need high privileges. Examples of these functions are the Automatic Update service, which downloads and installs critical Windows security patches, the Windows Firewall, which monitors all network activity and blocks attempts by outsiders to hack into your system, and the Print Spooler, which manages the flow of data to your printers. Most operating systems provide a means of having programs run independently of any logged-on user. On UNIX and Linux, they're called daemons, and on Windows, they're called services. A Windows service is a program that can be started automatically when Windows starts up, and which provides some essential function. In most cases, services do their jobs without interacting with the keyboard, mouse, or display at all. It's possible, although uncommon, for a service for display a message on the screen. The Print Spooler is one service that does thiswhen a printer jams, the Print Spooler service pops up a message. But most do their job silently, and in the event of a problem usually just record an error message in the Windows Event Log.