|
|
|
1.2 What Does the Registry Do?The concept of a central repository that holds all the system's configuration data may strike you as a boon (since it keeps applications and services from scattering their settings in hundreds of small files buried in odd locations) or a danger (since it provides a single point of failure). The truth is somewhere in between these extremes. The Registry provides a neat, tidy way for applications, device drivers, and kernel services to record configuration data. That data can be used by, and easily shared between, the original owner or by other system components. At the same time, if the Registry is damaged, the effects can range from not being able to use a single application to not being able to boot Windows 2000 at all. (Chapter 3, details the backup and recovery tools you can use to keep this single point of failure from causing trouble.) 1.2.1 It Holds Lots of Important StuffThe chief role of the Registry in Windows 2000 is as a repository for configuration data. In this role, it acts as a sort of super-librarian; system components can look for their own configuration information in the Registry, then use what they find to control how they interact with other system components. The "important stuff" stored in the Registry falls into six separate categories; each category's data is gathered during a particular stage of the boot process, as shown in Figure 1.4. Figure 1.4. Registry data exchange 1.2.1.1 Hardware configuration dataAs part of the Windows 2000 boot loader's normal execution, it runs a program called ntdetect; as its name implies, ntdetect figures out what hardware exists on the computer. This configuration data is basically an inventory of five things:
Once all this information has been gathered, ntdetect stores it in memory and maps it to the Registry's HKEY_LOCAL_MACHINE\HARDWARE subtree so that the Windows 2000 kernel and device drivers have access to it. No hardware configuration information is written to disk, because at the time the kernel loads, it the needed drivers won't have been loaded yet! (However, hardware profiles' configuration information can be stored on disk; the profile tells the device loader what devices to configure after it's finished detecting hardware.) Because knowing the low-level details of the hardware is critical to the kernel, this detection phase has to happen first. Unlike the Windows NT 4.0 version, the Windows 2000 HKEY_LOCAL_MACHINE\HARDWARE subtree can be dynamically modified after the machine is booting; this facility supports the dynamic loading and unloading of device drivers, which is required for proper support of Universal Serial Bus (USB) and FireWire/IEEE-1394 devices. 1.2.1.2 Driver parameters and settingsAfter the hardware detection phase, the boot loader loads the Windows 2000 kernel, which handles the difficult work of finding the right driver for each device installed in the computer. The kernel can load device drivers in three different places. Drivers that are set to load during the boot phase load immediately after the kernel. These drivers are typically low-level drivers that provide basic services to other drivers, such as the drivers required to support PCMCIA cards and SCSI disk drives. Once those drivers have loaded, the spiffy new Windows 2000 loading screen (complete with a progress bar at the bottom) appears; in addition to the other things happening during this boot phase, the kernel also loads any drivers whose load state is set to "system." These drivers, which are usually mid-level components such as the CD-ROM driver, normally require the presence of one or more boot drivers such as the IDE, SCSI, or ATAPI drivers. Once Windows 2000 has started its GUI, the logon dialog appears, and the kernel begins loading all drivers marked as "automatic." Automatic drivers can be loaded as a result of some system action or automatically as part of the GUI startup. If the system has previously detected a new USB or IEEE-1394 device, it can attempt to load the matching driver at this point. If no matching driver is found, the Add New Hardware wizard can be run after a user logs on. No matter where it loads in the boot process, each driver makes heavy use of the Registry during its initialization. As each driver loads, the kernel uses the Registry for three things. First, the kernel's driver loader walks through the hardware configuration inventory to figure out which driver to load for each device. Second, once Windows 2000 identifies the right driver for a device, the driver starts; as part of its startup, the driver claims the device it "owns" by marking it as owned in the Registry. Finally, the driver reserves whatever machine resources it needs; for example, the generic SoundBlaster16 driver provided as part of Windows 2000 attempts to reserve an IRQ, port address, and DMA block to talk to the sound card. Which values it requests depends on the hardware configuration information gathered by ntdetect. Once the driver has staked out the device and resources it needs, the Registry reflects the driver's reservations so other drivers that load later in the boot sequence won't try to seize them. Each of these steps uses a separate subtree under HKEY_LOCAL_MACHINE\HARDWARE; see the specific subkey mappings in Chapter 2 for complete details on which subkeys correspond to each phase. 1.2.1.3 Dynamic dataActually, no dynamic data is stored in the Registry at all! Instead, the kernel intercepts requests for subkeys of the HKEY_PERFORMANCE_DATA key and returns the requested data directly. Because the data for this key is assembled on demand and not written to disk, HKEY_PERFORMANCE_DATA doesn't show up in the Registry editor. This is less of a problem than it might seem, since that data isn't directly of use to you anyway. The Windows 2000 performance monitoring tools (and, of course, kernel components) can get to it when needed. 1.2.1.4 User profiles and user-specific settingsFrom its inception, Windows NT supported the idea that more than one person could use a single computer. Each user on a Windows 2000 or NT machine (whether it's a workstation or a server) has her own profile that controls when, how, and whether she can log on; what scripts or programs are executed at logon time; and what she can do once logged on. In addition, the user's profile stores the contents of her Start menu, the appearance of the desktop, and other look-and-feel settings. The profile's actually a composite of the data from several different subkeys in the Registry, including security account manager (SAM) data for the user, plus a number of settings scattered around in different places in the Registry. To users, however, it looks like it's all one seamless collection of data; your workspace magically reappears when you log onto any computer in your domain. In earlier versions of NT, these profiles were only usable on one machine--you and your officemate could share a PC in your office, but if you had to go down the hall to use another machine, your profile wasn't available, and you'd be stuck with an unfamiliar workspace. To solve this problem, NT 4.0 included support for two new types of profiles: roaming and mandatory. In many environments (such as college computing labs or workstation clusters in an engineering office), it makes sense for a user's settings to be kept on a central server and downloaded to whatever machine the user actually logs onto. This makes it possible for a user to sit down at any machine, not just the one at her desk, and go right to work. Roaming profiles make this possible; when you log onto a machine in a domain that uses roaming profiles, your profile is fetched from the server and cached in the local machine's Registry. Mandatory profiles work the same way, but with a twist: by renaming an ordinary profile with a .man extension, the system applies the policy automatically and restricts the end user's ability to change its settings. In practice, this means that administrators can build profiles that configure users' workspaces a certain way and don't allow users to change them--a great help for environments where lots of people need to share machines. 1.2.1.5 System and group policiesBesides the user's profile, other Windows 2000 settings can find their way into the Registry. For computers that are part of an Active Directory domain, GPOs largely supersede the system policy mechanism that defines and distributes policies for Windows NT 4.0 clients. You still use the native Windows NT 4.0 System Policy Editor (SPE) to set policies for Windows NT 4.0 and 9x machines in your Windows 2000 domains; you also use it to create policies for Windows 2000 machines that aren't part of an Active Directory domain. GPOs are set using the group policy object editors (discussed more in Chapter 7) instead of SPE. That's not the only difference: while system policy settings are "sticky" (persistent and hard to remove, not unlike an old piece of bubble gum), GPO settings are applied in special areas of the Registry dedicated for that use. This makes them easy to reverse or remove, since reversing a setting in the policy automatically applies that setting to whatever machines or user accounts it's targeted to. It's possible to attach an SPE template file to a GPO, offering the best of both worlds by allowing you to use the same template files (such as the ones included with Office 2000) for Windows 9x/NT and Windows 2000 clients. 1.2.1.6 OLE, ActiveX, and COMWindows 3.0 introduced the concept that a file's extension can be used to automatically figure out which program created it. Adding these file associations to the Windows File Manager meant that Windows users could double-click on a data file to launch the application that created it and open the file.[1] In Windows 3.0, these associations were kept in the win.ini file, but in Windows 3.1 and later, they're stored in the Registry instead. Windows 95 and NT 4.0 extend the concept of associations to include information about the kind of data stored in the file, too; this is especially useful for figuring out what to do with data downloaded by a web browser.
Windows 3.1 also marked the debut of Object Linking and Embedding, or OLE. OLE was designed to allow users to build compound documents that contained several different types of data. For example, you could create a Word document and embed an Excel chart and an Imagineer Technical[2] mechanical drawing in it, then edit either of the embedded objects without leaving Word using what Microsoft called in-place activation ( IPA). IPA required a large amount of new information to work; to start with, there had to be a list of all the types of data that could be embedded in a document, plus some way to figure out which program to run when the user wanted to create a particular kind of data object. The original Windows 3.1 Registry had only one root key, HKEY_CLASSES_ROOT; its purpose in life was to store the data OLE needed to function.
In 1993, Microsoft started touting the Component Object Model, or COM, as the wave of the future. (The combination of COM and OLE has since been retitled ActiveX; you've probably heard of that by now.) The basic idea behind COM is that developers can break their software down into lots of little, independent objects that communicate with each other via COM interfaces.[3] As with OLE, though, COM requires still more new data to make it work. Each type of object has to have its own unique ID so the system can tell them apart; in addition, the system has to somehow keep track of which interface methods a particular object supports (especially since COM objects can pass commands back and forth). ActiveX controls, which can be embedded in web pages, Office documents, and other kinds of documents, have the same requirements; the system has to be able to turn the unique class ID into the name of the program it should run to create, draw, or edit the object. All this data (and more besides) lives under the HKEY_CLASSES_ROOT subtree.
The primary change in Windows 2000 is that the settings in HKEY_CLASSES_ROOT are now split into two categories. In the old-style scheme, both file associations and MIME type mappings are stored in a single Registry file. The default permission settings for HKEY_CLASSES_ROOT allow any user on a machine to change these settings. This is a bad idea for two reasons. First, users may want their own MIME type mappings. For example, two users who share a workstation might disagree on whether Internet Explorer or Netscape is the best browser; under NT 4.0 the MIME type settings for HTML would continually be pingponging back and forth as the two browsers reset the default MIME types. The second reason is more serious: permitting any user on the machine to change file associations allowed any user to change those associations so that untrusted, or even malicious, applications could potentially be run without the user's knowledge. Windows 2000 solves this problem by putting MIME type mappings into the user-specific section of HKEY_CURRENT_USER and moving the file associations and OLE/COM mappings into a system subkey that has tighter permissions than the Windows NT equivalent. 1.2.1.7 Application settingsSo far, I've only talked about how the operating system uses the Registry. Applications can use it too, and most well-written Win32 applications do. The proliferation of INI files in Windows 3.x was bad for users, but it was every bit as bad for most software vendors--imagine trying to troubleshoot a customer's problem when your product's settings are intertwined with settings for every other program on that user's computer! The Registry offered a neat solution to this problem, with the twin benefits of better performance and some tamper-resistance thrown in as lagniappe.[4]
Microsoft's guidelines (which may be, and frequently are, freely ignored by Microsoft and third parties) say that third-party programs should install program-specific settings in the HKEY_LOCAL_MACHINE\SOFTWARE\<VendorName> subtree. For example, Netscape's products keep their settings under HKEY_LOCAL_MACHINE\SOFTWARE\Netscape. This key is for settings that pertain to the program itself, not the user's configuration settings for that program. User-specific settings go under the user's key in HKEY_USERS. This is a subtle but important distinction. As you can see in Figure 1.5, the settings under the Netscape Navigator key in each of the Registry root keys are quite different. HKEY_LOCAL_MACHINE\SOFTWARE\Netscape\Netscape Navigator\4.04 (en) stores information about where different components of Navigator are installed, while the corresponding entry under HKEY_CURRENT_USER\SOFTWARE\Netscape has settings that apply only to your configuration, such as where your personal bookmark file is stored. Applications and system components can store any kind of data in the Registry: configuration settings for hardware or software, user preferences, paths to shared components, licensing information, and so on. Most "modern" Win32 applications tend to keep all their settings in Registry values. For example, the Office 97 and 2000 suites use the Registry to store information about each user's preferences for which toolbars are displayed, whether the Office Assistant appears, and so on. Netscape and Microsoft's web browsers both keep their user profile data in the Registry. Figure 1.5. User versus application settings Of course, applications can freely use any of the other types of data stored in the Registry. For example, an image-retouching program can use the Registry to get the I/O address of the port to which the user has connected his digital camera, or a web page editor might use it to fetch a list of all the ActiveX objects a user can embed in a page he's designing. For the most part, though, well-behaved applications will read, but not modify, keys that aren't theirs. |
|
|
|