13.4. Organization of the Registry The Registry is enormous and complex; a full Registry might easily contain 15,000 keys and 35,000 values. Entire books have been written about it, and I can't do it justice here. The purpose of this section is to arm you with a basic understanding of how the Registry is organized, not to document individual values in detail or suggest changes you might want to make with the Registry Editor. The top level of the Registry is organized into five main root branches. By convention, the built-in top-level keys are always shown in all caps, even though the keys in the Registry are not case-sensitive. (For example, HKEY_CURRENT_USER\SOFTWARE\MICROSOFT\Windows is identical to HKEY_CURRENT_USER\Software\Microsoft\Windows.) Their purposes and contents are listed in the following summaries. Note that the root keys are sometimes abbreviated for convenience in documentation (although never in practice); these abbreviations are shown in parentheses. Subsequent sections discuss the contents of the root keys in more detail.
HKEY_CLASSES_ROOT (HKCR) Contains file types, filename extensions, URL protocol prefixes, and registered classes. You can think of the information in this branch as the "glue" that binds Windows with the applications and documents that run on it. It is critical to drag-and-drop operations, context menus, double-clicking, and many other familiar user interface semantics. The actions defined here tell Windows how to react to every file type available on the system. This entire branch is a mirror (or symbolic link) of HKEY_LOCAL_MACHINE\SOFTWARE\Classes, provided as a root key purely for convenience.
HKEY_CURRENT_USER (HKCU) Contains user-specific settings for the currently logged-in user. This entire branch is a mirror (or symbolic link) of one of the subkeys of HKEY_USERS (discussed shortly). This allows Windows and all applications to access and store information for the current user without having to determine which user is currently logged in. An application that keeps information on a per-user basis should store its data in HKEY_CURRENT_USER\Software and put information that applies to all users of the application in HKEY_LOCAL_MACHINE\SOFTWARE. However, what Windows applications consider user-specific and what applies for all users on the machine is somewhat arbitrary. Like many aspects of Windows, the Registry provides a mechanism for applications to store configuration data, but it does little to enforce any policies about how and where that data will actually be stored.
HKEY_LOCAL_MACHINE (HKLM) Contains information about hardware and software on the machine that is not specific to the current user.
HKEY_USERS (HKU) Stores underlying user data from which HKEY_CURRENT_USER is drawn. Although several keys will often appear here, only one of them will ever be the active branch. See the discussion of HKEY_USERS, later in this chapter, for details.
HKEY_CURRENT_CONFIG (HKCC) Contains hardware configuration settings for the currently loaded hardware profile. This branch works similarly to HKEY_CURRENT_USER in that it is merely a mirror (or symbolic link) of another key. In this case, the source is HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Hardware Profiles\XXXX, in which XXXX is a key representing the numeric value of the hardware profile currently in use. On a system with only a single hardware profile, its value will most likely be 0001. 13.4.1. HKEY_CLASSES_ROOT (HKCR) At first glance, Windows Vista seems very object-oriented. Files, folders, and devices are represented by icons that respond differently to various actions such as single-, double-, right-, and left-clicks. But in a true object-oriented system, the object itself contains the knowledge of how to respond to events such as mouse clicks. By contrast, Windows Vista performs much like the Wizard of Oz, not with true object-oriented magic, but with complex machinery hidden behind a screen. The knowledge of how the Explorer should treat each object is stored in the Registry in a complex chain of interrelated keys. Much of the system's behavior depends on filename extensions. A filename extension, the string of letters that appear after the last dot in a filename, is the primary mechanism Windows uses to determine a file's type. Therefore it's essential that each filename extension accurately reflect the file type. For example, a file named stuff.txt will be treated by Windows as a text file. If you were to rename the file to stuff.old, it would still be a text file, but Windows would treat it differently: it would have a different icon in Explorer, a different description in Explorer's Details view, and a different action when double-clicked. This illustrates how fragile and fallible Windows' file types system is, how some applications can so easily register themselves as the default for any given file type, and how stupid it is that filename extensions are hidden in Explorer by default. When you open HKEY_CLASSES_ROOT, the first thing you'll see is a very long list of file extensions known to the system, from something such as .ai (Adobe Illustrator Document) to .zip (ZIP archive). What follows is a list of document type keys, which typically contain the actual file type information. These two sets of keys make up the file types in Windows Vista. Here's how it works: a file extension key (one that has a dot at the beginning of its name) has its default value set to the name of a document type key (and thus "points" to that key). For example, HKEY_CLASSES_ROOT\.txt, which corresponds to all files with the .txt extension, has its default value set to txtfile. Lower down, the HKEY_CLASSES_ROOT\txtfile key contains several keys that describe files of this type and instruct Windows what to do when you right-click on a .txt file and select options such as open and print. You may notice that the HKEY_CLASSES_ROOT\.log key also has its default value set to txtfile; in this way, many extension keys can point to a single file type key, and hence, a single file type can encompass several different filename extensions. Applications frequently add new file types to the Registry, registering themselves with certain filename extensions. In the case of the txtfile file type, Notepad is registered as the default application when Windows Vista is first installed; thus, when you double-click on a .txt or .log file, the file is opened in Notepad. A common conflict occurs when two or more applications find themselves fighting to be the default application. For example, should a file with the .htm extension be opened by Firefox or Microsoft Internet Explorer? If you use Internet Explorer, the value name (Default) will have the value data htmlfile. If you then install Firefox, the .htm key will have the value name (Default) with the data FirefoxHTML. If you then look at either of those two class definition keys (FirefoxHTML or htmlfile), you'll see a different chain of subkeys. Although both Firefox and Internet Explorer know how to handle HTML files, they use a different set of internal instructions for figuring out how to display or edit the files, which icon to display for the file, and so on. The detailed subkeys and values that appear under the class definition and document type keys start to get really confusing. (See Windows Vista Annoyances for an in-depth examination of file types.) Because each program may record and retrieve different keys, it's very hard to generalize about them. The best I can do is mention some of the kinds of keys you might see associated with a particular file extension subkey or class definition subkey. Here are some of the most common keys and values you may find in HKEY_CLASSES_ROOT:
CLSID Class identifier for an ActiveX component, a unique, 16-byte number in the following format {aaaaaaaa-bbbb-cccc-dddd-ffffffffffff}, in which each letter represents a hexadecimal digit. (That's a sequence of 8, 4, 4, 4, and 12 hex digits, with a hyphen between each group of digits and the whole thing enclosed in curly braces.) CLSID appears both as a subkey of many file type definition keys and as a class definition key in its own right. That is, the key HKCR\htmlfile might have a subkey CLSID with the data value {25336920-03F9-11cf-8FD0-00AA00686F13}, but there's also a key called HKCR\CLSID with the subkey {25336920-03F9-11cf-8FD0-00AA00686F13}, which in turn has the data value HTML Document. The first entry is simply a pointer to the second, which contains the actual class data. You must always be on the lookout for this kind of indirection. CLSID keys don't necessarily correspond to filename extensions or file types. The HKEY_CLASSES_ROOT\CLSID branch, for example, contains a huge list of class ID keys, which each represent a different component. Most of the components are of little interest to mere mortals, but some correspond to visual elements in Windows Vista.
Content Type The data in this value is the Multipurpose Internet Mail Extension (MIME) descriptor for the corresponding file type. This key will typically appear in the file type key for Internet-related file types such as GIF and JPEG. It's used by email programs that support attachments and web browsers, such as Firefox and Internet Explorer, to help them identify downloaded files.
DefaultIcon The location (usually a pathname and an optional "icon index" within the file) of the file containing the default icon to use for a file type or CLSID. Note that there may be more than one default icon for a given file type. A good example is the Recycle Bin, which shows a different icon when it is empty and when it is full. In cases such as this, the program knows to copy its icon for the appropriate state to the DefaultIcon (Default) value. In other cases, though, a DefaultIcon may be specified in more than one place (e.g., under a document type key and under an associated CLSID key).
Shell Contains subkeys that define actions (open, edit, print, play, and so forth) appropriate to the object. These actions appear on the context menu for the associated file type, among other things. A common structure that uses the Shell key is Shell\Open\Command, where the default value in the Command key is the executable filename for a registered application. The command line often ends with "%1" (including the quotes), which represents a command-line parameter passed to the application (familiar to those who use batch files). For example, when you double-click on a .txt file (say, c:\stuff\junk.txt), Windows replaces "%1" in the command line with the name of the file, resulting in the following command being run: notepad c:\stuff\junk.txt. If you were to select Run from the Start menu, and type that command, Notepad would appear and open the file. Note that the quotes around the %1 accommodate any spaces in the filename; otherwise, Windows would interpret a single filename with a space as two distinct filenames, and you'd get an error. You might also find the key, Shell\Open\ddeexec, which contains information necessary for a Dynamic Data Exchange (DDE) conversation. DDE is the mechanism with which Windows communicates with applications that are already open. For example, Windows might send a DDE message to an application to tell it to print a file after opening it. Microsoft insists that DDE is obsolete, but you'd never know it from the important role DDE plays in Windows file types. You'll see the same split between command-line options and DDE using the Explorer interface to file associations, via Start  Default Programs  Associate a file type or protocol with a program. Some actions will list a command line; others will use DDE. If youre not a programmer with access to the DDE documentation for a particular application, you may find this difficult to follow at times. You may find that a particular Shell branch doesn't contain all the actions for a particular file type. This is because these items may be specified in three other places. First, the ShellEx key contains more advanced actions. Second, the HKEY_CLASSES_ROOT\* key contains additional actions that apply to all file types. Third, some actions available to all files, such as the Delete and Properties actions, can't be removed and therefore don't appear in this key.
ShellEx This is short for Shell Extensions. These keys contain entries that supplement a file's context menu (via the ContextMenuHandlers subkey), a file's Properties sheet (via the PropertySheetHandlers subkey), and a file's drag-and-drop behavior (via the CopyHookHandlers subkey). These extra features are too complex to be simple Shell\Command structures; instead, these keys simply point to registered CLSIDs (described earlier) and special programs that perform advanced features. For example, if you install the WinZip utility (http://www.winzip.com), all ZIP files will have extra items in their context menus (click with the right mouse button) and their drag-and-drop menus (drag with the right mouse button) that handle certain ZIP operations. Also, movie files (.avi, .asf, and .mpg) and Word documents (.doc) all have an extra Summary tab in their Properties sheets that displays additional information about the contents of the file.
ShellNew Defines whether the file type will appear on Explorer's New menu. If the ShellNew key is present inside a file type or file extension key, the file type will appear in the list when you select New from Explorer's File menu. In most cases, this key will be empty, if it exists at all. (Contrast the enormous number of file types defined in the Registry with the much smaller number that appear on the New menu.)
Command Contains a command line to create the new file, used only for Briefcases and Windows Shortcuts (the .bfc and .lnk extensions, respectively), as well as any other file type that can't be created merely by copying a template (see next).
Filename Contains the name of a file "template" to copy to the new location. Its value data may contain a complete pathname, but if it's just a filename (e.g., netscape.html, winword.doc, or winword8.doc), it will be found in the directory \Windows\ShellNew. If the Filename value is not present, Windows will create an empty, zero-byte file.
Nullfile If present, instructs Windows not to create the file at all but instead to launch a program that will create the file when first saved. Some file types (such as .bmp files, which may contain data in any one of a number of related formats, as specified by binary header data within the file itself) are described by the NullFile value. NullFile has the empty string ("") as its value data.
Data Contains binary data that needs to be written to the new file. This might, for example, be some kind of binary header data. Before leaving HKEY_CLASSES_ROOT, two other keys are worthy of note:
HKCR\* Contains information that will be applied to all files, regardless of their extension. Be sure to check out the ShellEx entries here.
HKCR\Unknown Describes, via its Shell\OpenAs\Command subkey, what will happen to a file whose type is unknown, either because the file has no extension or because the particular extension has not yet been registered with Windows. By default, if you double-click on a file Windows categorizes as unknown, a dialog appears allowing you to choose the correct program to use, thereby automatically creating new file type keys in the Registry. 13.4.2. HKEY_CURRENT_USER (HKCU) The Registry separates settings specific to individual users from global Windows settings applicable to all users. In the FreeCell example earlier in this chapter, each user of the machine can have his own separate won/lost statistics because the program keeps these statistics in the HKEY_CURRENT_USER branch of the Registry. If it instead used HKEY_LOCAL_MACHINE, all users would share the same statistics. This entire branch has the same structure as HKEY_USERS\.DEFAULT (discussed shortly) and is a mirror of the HKEY_USERS entry corresponding to the current user, and its contents always correspond to those of the currently logged-in user. By default, there are 13 top-level subkeys in HKCU: AppEvents, Console, Control Panel, Environment, EUDC, Identities, Keyboard Layout, Network, Printers, SessionInformation, Software, System, and Volatile Environment. Here are descriptions of some of the most important subkeys:
HKCU\AppEvents The associations between events and system sounds are kept here. There are two branches: EventLabels and Schemes. EventLabels contains the labels that will be used for the sounds; Schemes contains the pointers to the actual sounds. Schemes has two main subkeys: Apps and Names. Applications that use sounds can create their own subkey under Schemes\Apps, or they can add sounds into the default list, which is kept in the subkey Apps\.Default. If they add their own subkey, the sounds will show up in a separate section of the sounds list in Control Panel Sounds. So you might see a subkey such as Mplayer or Office, because these applications add some of their own sound events in addition to the default sounds. Note that unless Windows or an application is specifically designed to look for an event listed here, any new events you might add will have no effect. Schemes\Names is where Windows stores the settings for each sound scheme. When you change the sound scheme using the drop-down Scheme list on Control Panel Sounds, the appropriate scheme is copied into .Default.
HKCU\Console This stores data for the console, which is what hosts all command-line applications, including the Command Prompt. So, for example, it contains data about the font size, screen colors, buffer size, and so on, used by the cmd.exe command prompt. To see the kinds of information stored here, open the Command Prompt, right-click on the window's title, and select Properties. You'll see tabs for all of the different options for the Command Prompt; each option has a corresponding value in HKCU\Console. For example, FontSize corresponds to the choice you make for font size on the Font tab.
HKCU\ControlPanel Data from several of the Control Panel applets is stored here, particularly Accessibility and some of the Display settings. The names don't match up cleanly to the names used in the Control Panel, but you can usually figure out what's what by going back and forth between the Registry Editor and the target Control Panel applet. For example, HKCU\ControlPanel\Accessibility maps to Control Panel [Appearance and Personalization] Ease of Access Center, but HKCU\ControlPanel\Cursors maps to Control Panel Mouse Pointers. As is typical in the convoluted world of the Registry, some entries point somewhere else entirely. For example, HKCU\ControlPanel\International controls a wide variety of settings related the specific international version of Windows you're usingfor instance, a Locale value, such as 00000409, which is the standard code for what the Control Panel calls "English (United States)." There are many other similar settings here, such as for your local currency (sCurrency), and so on. It also controls your date and time format, and similar settings. If you use the Registry Editor's Find function to trace this value, you'll eventually find the scattered locations of many of the individual values that Control Panel [Clock, Language, and Region] Regional and Language Options brings together in one place.  | This example illustrates a key point: there's usually little reason to poke around in the Registry for values that have a convenient user interface in the application. The exception is where the interface has limited which values can be enteredmaking the Registry a tool you can use for greater control (at the expense of the convenience of a user interface)--as well as where there is simply no interface for some of the more obscure settings. |
|
HKCU\Environment The environment is a small chunk of memory devoted to storing a few system-wide settings, primarily for use with command-line applications, but still used by Windows Vista. In Windows 9x and Windows Me, information was added to the environment via the AUTOEXEC.BAT file (now obsolete). Environment variables in Windows Vista are set via Control Panel [User Accounts and Family Safety] User Accounts Change my environment variables. The upper section of this dialog box (user variables for HKCU\keyboard layout This key is used only if you have installed more than one keyboard layout via Control Panel [Clock, Language and Region] Keyboards and Languages. A Preload subkey lists a separate subkey for each installed language, with subkey 1 specifying the default language.
HKCU\Software Probably the most useful key in HKEY_CURRENT_USER, this key contains subkeys for each vendor whose software is loaded onto the machine and, within each vendor's area, subkeys for each product. The keys stored here are supposed to contain only user-specific settings for each software application. Other settings, which are common to all users of software on the machine, are stored in HKLM\SOFTWARE. The structure of this branch (and particularly of the Microsoft\Windows\CurrentVersion branch under both) is described later in this chapter, in "HKCU\Software and HKLM\SOFTWARE." 13.4.3. HKEY_LOCAL_MACHINE (HKLM) HKLM contains hardware settings and global software settings that apply to all users. It has five top-level subkeys: HARDWARE, SAM, SECURITY, SOFTWARE, and SYSTEM. Each of these keys is stored in a separate hive file (see "Hives," later in this chapter):
HKLM\HARDWARE The data stored in this branch is used by Windows Vista to load drivers and initialize resources for the various hardware components of your computer. All of the settings here are more easily accessible through the Device Manager (Control Panel [System and Maintenance] System Device Manager); theres little need to edit them directly. However, you may find it interesting to snoop around in this branch and see the various pieces of information that are stored for your CD Writer, your scanner, your hard disk, and your processor. The HKLM\HARDWARE\DESCRIPTION\System\CentralProcessor\0 key tells me that my CPU's vendor identifier is "GenuineIntel," for example.
HKLM\SAM This key stores data for the Security Accounts Manager (SAM), used only if your Windows Vista system is providing domain services. You'll find little reason to ever mess with the settings in this branch, and as most of the data is in binary format, you'll have a hard time deciphering it anyway. The information stored in this key is managed primarily through User Manager for Domains (on Windows Server). You can access all of the settings here through the Local Security Policy Editor (secpol.msc).
HKLM\SOFTWARE Probably the most useful key in HKEY_LOCAL_MACHINE, this key contains subkeys for each vendor whose software is loaded onto the machine and, within each vendor's area, subkeys for each product. The keys stored here are supposed to contain global system settings for each application, common to all users on the machine. Other settings, specific to each user, are stored in HKCU\SOFTWARE. The structure of this branch (and particularly of the Microsoft\Windows\CurrentVersion branch under both) is described later in this chapter, in "HKCU\Software and HKLM\SOFTWARE."
HKLM\SYSTEM The settings in this branch primarily handle multiple hardware profiles. Windows uses this data together with HKLM\HARDWARE to handle drivers and Plug and Play management for all hardware on the system. 13.4.4. HKCU\Software and HKLM\SOFTWARE As noted earlier, both HKEY_CURRENT_USER\Software and HKEY_LOCAL_MACHINE\SOFTWARE are structured similarly. Each area has a branch for each manufacturer that has software installed on the system, and most vendors will have keys that appear in both areas. In each manufacturer key, there will be one or more subkeys, corresponding to each of that manufacturer's applications that are installed. For example, under the Adobe key, you might see an entry for Photoshop and one for Illustrator, assuming both of those applications are installed on your system. In theory, the HKCU branch should include information that is configurable on a per-user basis (which is the case, for instance, with a software package with a per-user license or per-user customization). The HKLM branch should include software that is standard for all users. In practice, though, it doesn't seem to be as consistent as that. Some data might seem to be placed in the wrong branch, and other data might be placed in both branches. Fortunately, this doesn't pose much of a problem in practice, partly because the vast majority of systems will have only a single user account, but more important, because the only practical rule as to the location and organization of data in the Registry is that it is consistent with the application that uses it. For example, because WordPerfect knows where to look for its own settings, it doesn't really matter that they aren't in a place the casual user would expect. Basically, if you're looking for something, look in both branches (HKLM and HKCU). Because this is a book about Windows Vista and not about the third-party applications that might be installed in it, the primary focus of this discussion is on the Microsoft\Windows\CurrentVersion branch, located in both HKCU and HKLM. There is a ton of information in these two areas, and the following keys represent the more useful and intelligible data:
..\Microsoft\Windows\CurrentVersion This key contains seven values describing some basic Windows settings, such as the folder location for Program Files, and the default folder location for your media. There are also many keys underneath here. Note the use of REG_EXPAND_SZ values, described earlier in this chapter.
..\Microsoft\Windows\CurrentVersion\App Paths (HKLM only) This branch lists a path for many application executables (Microsoft and otherwise) that are installed in nonstandard locations (i.e., not in \, \Windows, or \Windows\Command). It is the reason why you can successfully type a command name such as excel or winword at the Run prompt, but not at the command prompt, unless you add \Program Files\Microsoft Office\Office to your search path. They have listed their paths individually under this key. | If you have an application that installs a shortcut on the Start menu but doesn't let you type its name at the Run prompt, add a key for it in the App Paths key (using an existing entry as a template). For example, you can add a PHOTOSHOP.EXE key, with the values: (Default) "C:\Program Files\Adobe Photoshop\Photoshop.exe" Path "C:\Program Files\Adobe Photoshop"
The result is something like the Path environment variable, except that the target is a specific executable rather than an entire folder. |
|
..\Microsoft\Windows\CurrentVersion\Explorer\ShellFolders
..\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders Specifies the locations of many of the standard Windows system folders, including Desktop, Programs, Send To, Start Menu, Startup, and Templates. This branch really brings home the extent of the mutability of Windows. Even the directory names that Explorer relies on, such as \Users\username\Desktop, are not hard-wired. So Explorer doesn't know anything about c:\Users\username\Desktop. All it knows is that it can get the name of the folder it's supposed to use as the Desktop from the Registry. Most of these values probably shouldn't be changed. The ShellFolders and User Shell Folders keys each exist in the HKCU and HKLM branches. If you're looking for a particular setting, make sure you look in all four keys; whenever a key seems to be duplicated in more than one place, it's good practice to make changes in both places. Note also that the REG_EXPAND_SZ data type (explained earlier in this chapter) is used for some of the values.
..\Microsoft\Windows\CurrentVersion\Explorer\Desktop\NameSpace (HKLM only) Contains keys named with the CLSID of system icons that appear on the Desktop, such as the Recycle Bin, My Documents, and My Network Places. Because these are simply pointers to objects defined elsewhere in the Registry (such as Windows Shortcuts), they can be safely deleted (one method of removing the respective icons from your Desktop).
..\Microsoft\Windows\CurrentVersion\Explorer\FindExtensions (HKLM only) Contains keys corresponding to the various entries in the Start menu's Search menu and in the Explorer Search Bar. Although you can't indiscriminately add items here (unless you're a programmer), you can remove unwanted entries.
..\Microsoft\Windows\CurrentVersion\Explorer\MyComputer Contains several keys that relate to the Computer window. The NameSpace subkey, for example, contains keys pointing to CLSIDs of various optional components that might appear in your Computer window. To identify any unlabeled CLSID that shows up here or anywhere else, copy the entire CLSID string to the Clipboard and paste it into the Registry Editor's Search box.
..\Microsoft\Windows\CurrentVersion\Explorer\StartMenu (HKLM only) Contains several keys that relate to the seemingly hardcoded entries that appear in the Start Menu My Computer window. The NameSpace subkey, for example, contains keys pointing to CLSIDs of various optional components that might appear in your My Computer window. To identify any unlabeled CLSID that shows up here or anywhere else, copy the entire CLSID string to the Clipboard and paste it into the Registry Editors Search box.
..\Microsoft\Windows\CurrentVersion\Internet Settings Contains a whole slew of settings for Internet Explorer and the Internet Options dialog in the Control Panel. You'll find settings in this key for just about everything, from Passport settings to the filename of the bitmap used for the background of Internet Explorer's toolbar.
..\Microsoft\Windows\CurrentVersion\Run (HKLM only)
..\Microsoft\Windows\CurrentVersion\RunOnce In these keys, you'll find a list of programs that Windows loads at startup. Note that these aren't the same as those found in the Startup folder in your Start menu, but they work similarly. The format is simple enough: the data in each value contains the full path- and filename of a program to be launched, and the name of the value is merely a reminder as to the purpose of the entry. You can safely add any program you like, or remove entries you'd like to stop loading automatically. Note that values placed in either of the RunOnce keys (HKCU or HKLM) will only be run the next time Windows starts, and will be deleted immediately thereafter. There are several advantages of these keys over the Startup folder. For example, they're more concealed and therefore more tamper-resistant. | Another way to look for programs that run on startupand to disable them if you wantis to use the System Configuration Utility (msconfig.exe). For details, see Chapter 11. |
|
In addition to the preceding specific keys, a few paradigms show up again and again, such as the following:
../MRUList MRU stands for Most Recently Used. Anytime Windows shows you a "history" of the last few things you've typed into a field or otherwise launched, those items are stored in a key in the Registry. A quick search for MRUList in the Registry Editor will yield dozens of instances. Knowing the location and use of a particular MRU list has several advantages. For example, you can write a script to clear a given list to erase your "footprints," so to speak. Or, perhaps you could create a Registry patch that would preload a drop-down list with a set of long names you wanted to search for or open repeatedly. MRUList values contain a series of letters; for each letter, you'll find a value in the same key that is a lookup table into the MRUList. For example, you might find an MRUList whose value is bdca. Right next to it, you'd find four values (a, b, c, and d) with the corresponding filenames or search terms (the MRUList specifies the order in which they appear). For example, in HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.jpg\OpenWithList, a might correspond to mspaint.exe, b to PhotoViewer.dll, and so on.
../Namespace Keys named Namespace usually contain values or subkeys that point to CLSIDs (16-byte identifiers to registered program components), which, in effect, instructs Windows to load those components. For example, if a CLSID for the Recycle Bin is listed under the Desktop\Namespace key, it corresponds to the Recycle Bin object appearing on the Desktop. Sometimes, removing these entries will have the effect of removing the corresponding objects, but not always. I recommend experimentation with some degree of caution. 13.4.5. HKEY_USERS (HKU) Despite its name, this branch does not contain the Registry entries for all users configured on the system. This is because user information is loaded when a user logs in, and only one user can be logged in at any given time. Rather, it contains only information for the currently logged-in user as well as a template for new user profiles. This branch contains several keys, although only one of them is mirrored as HKEY_CURRENT_USER (discussed earlier). Usually, it's the one that looks like S-x-x-xx-xxxxxxxxx-xxxxxxxxxx-xxxx, where the long string of xs is the Windows serial number. If it's not clear which key is the active one, just create a new key or value in one of the branches called test. Then, move up to HKEY_CURRENT_USER and press F5 to refresh the view. If the test entry you just added shows up here as well, you've found the active key; if not, delete test and try again in a different key. You use the .DEFAULT key as a template for creating new users, and unless you want to affect new user settings, you should leave this key alone. In fact, there's little reason to ever play with the HKEY_USERS branch, as all applicable settings for the active user are more easily accessible through HKEY_CURRENT_USER. This design prevents one user from easily viewing or changing another user's settings. 13.4.6. HKEY_CURRENT_CONFIG (HKCC) As noted earlier, HKCC is mirrored from the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Hardware Profiles\XXXX, in which XXXX is a key representing the numeric value of the hardware profile currently in use. On a system with only a single hardware profile, its value will most likely be 0001. This branch contains hardware configuration settings for the currently loaded hardware profile. |
