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 we can't do it justice here. Our purpose in 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 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 go into the contents of the root keys in more detail.
HKEY_CLASSES_ROOT (HKCR)
Contains file types, filename extensions, URL protocol prefixes, and registered classes. The information in this branch can be thought of 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 HKEY_USERS (see below). 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, it is somewhat arbitrary what Windows applications seem to consider user-specific and what is for all users on the machine. Like many aspects of Windows, the Registry provides a mechanism for applications to store configuration data, but does little to enforce any policies about how and where it will actually be stored.
HKEY_LOCAL_MACHINE (HKLM)
Contains information about hardware and software on the machine 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, below, 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.
At first glance, Windows XP seems very object-oriented. Files, folders, and devices are represented by icons that respond differently to various actions such as single or double-clicks, right-clicks, 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 XP performs much like the Wizard of Oz, not with true object-oriented magic, but with a 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 one 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. (The exceptions are certain Microsoft Office documents, which are handled by Windows in a consistent manner regardless of the filename extension.) 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 like .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 XP.
Here's how it works: a file extension key (one which 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 how to handle double-clicks, right-clicks, and other operations.
You also may notice that 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 XP is first installed; thus, when one double-clicks on a .txt file or a .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 . key might have the value
name (Default) with the data
NetscapeMarkup. If you use Internet Explorer, the
value name (Default) will have the value data
The detailed subkeys and values that appear under the class
definition and document type keys start to get really confusing. (See
Windows Me
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 we
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, sorted alphabetically:
Class identifier for an ActiveX component, a unique, 16-bit 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 eight, four, four, four, and twelve 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\NetscapeMarkup might have a subkey CLSID with
the data value
{61D8DE20-CA9A-11CE-9EA5-0080C82BE3B6}, but
there's also a key called
HKCR\CLSID with the subkey
{61D8DE20-CA9A-11CE-9EA5-0080C82BE3B6}, which in
turn has the data value Netscape
Hypertext 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 XP.
If you search for "Recycle Bin"
here, for example, you'll find the key that
describes the Recycle Bin Desktop icon. Try changing the contents of
the Default value to "Trash,"
refresh your Desktop, and see what happens!
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 Netscape Navigator and
Internet Explorer, to help them identify downloaded files.
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.
If you see the value data "%1", it means that the
file will act as its own icon (a neat effect when used with BMP
files). 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 like 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. The easiest way to
edit these actions is with the File Types dialog in Explorer (Tools
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 DDE (Dynamic Data
Exchange) 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 Tools 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-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-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.,
netscapel, 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. 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, the Open With dialog appears, allowing you to
choose a new association for the filename extension, thereby
automatically creating new file type keys in the Registry box. Here
you find the rundll32 command line to bring up
that dialog box. runndll32 is merely a program
that allows a particular function in a .dll or
.exe file to be run via a command-line
interface. 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 or her 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 is a mirror (or symbolic link) of
HKEY_USERS\.DEFAULT
(see below), and its
contents always correspond to those of the currently logged-in user. By default, there are twelve top-level subkeys in HKCU: AppEvents,
Console, Control Panel, Environment, Identities, Keyboard Layout,
Printers, RemoteAccess, SessionInformation, Software, UNICODE Program
Groups, and Volatile Environment. HKCU\AppEvents The associations between events and system sounds are kept here. (See
"Sounds".) 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 Schemes\Names is where Windows stores the settings
for each of the sound schemes, such as Utopia. When you change the
sound scheme using the drop-down Scheme list on Control Panel
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 Registry
Editor and the target Control Panel applet. For example,
HKCU\ControlPanel\Accessibility maps directly to
Control Panel As is typical in the convoluted world of the Registry, some entries
point somewhere else entirely. For example,
HKCU\ControlPanel\International simply defines a
Locale value, such as 00000409, which is the
standard code for what the Control Panel calls
"English (United States)." If you
use 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
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 entered, making
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
older Windows and DOS applications, but still used by Windows XP. In
Windows 9x and Windows Me, information was added to the environment
via the AUTOEXEC.BAT file (now obsolete). Like
Windows 2000, Environment variables in Windows XP are set via Control
Panel username ) is where user-specific variables are
entered, and are thus stored in the
HKCU\Environment Registry key. The lower box
(system variables) is for system-wide, user-independent variables and
is stored in
HKLM\SYSTEM\CurrentControlSet\Control\SessionManager\Environment.
Note also the HKCU\Volatile Environment key, which
contains temporary environment variables, resets each time Windows is
started.
HKCU\keyboard layout This key is used only if you have installed more than one keyboard
layout via Control Panel
This key lists various types of information used by Dial-Up
Networking, including the default connection to be used by Internet
applications. The Implicit subkey lists the UNC path of any shared
folders or printers that are accessed over a particular Dial-Up
Networking connection. The Profile subkey stores information specific
to each connection, such as the saved login name that will be
supplied automatically when you make the connection.
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 Section 8.3.4.
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 Section 8.4, later in this chapter). HKLM\HARDWARE The data stored in this branch is used by Windows XP to load drivers
and initialize resources for the various hardware components of your
computer. All of the settings here are more easily accessible through
Device Manager (Control Panel
HKLM\SAM
This key stores data for the Security Accounts Manager (SAM), used only
if your Windows XP 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 the User
Manager for Domains (on NT Server) and User Manager (on NT Workstation). All of
the settings here can be accessed through the Local Security Policy
Editor (secpol.msc).
HKLM\SECURITY The Security branch is where Windows stores the local security
policy, which includes user accounts, permissions, passwords, and
group membership information. Like HKLM\SAM, there
is little reason to mess with this key. All of the settings here can
be accessed through Control Panel
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 Section 8.3.4.
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-&-Play management for all hardware on the system. All of the
settings stored in this branch are accessible via Control Panel
As noted earlier, both
HKEY_CURRENT_USER\Software and
HKEY_LOCAL_MACHINE\SOFTWARE are structured
similarly. Each of these areas has a branch for each manufacturer who
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 wrong branch, while 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 only have a single user account, but more
importantly, 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, since 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 XP 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 a dozen-or-so values describing some basic Windows
settings, such as the folder location for Program Files, and the
20-digit Product ID number. 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 like 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
path 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, I added a
PHOTOSHOP.EXE key, with the values: The end 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
Windows' mutability. Even the directory names that
Explorer relies on, such as \Windows\Desktop,
are not hard-wired. So Explorer doesn't know
anything about c:\Windows\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 the use of the REG_EXPAND_SZ data type
(explained earlier in this chapter) is used for some of the values.
..\Microsoft\Windows\CurrentVersion\Explorer\Desktop\NameSpace
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.
Since these are simply pointers to objects defined elsewhere in the
Registry (like Windows Shortcuts), they can be safely deleted (one
method of removing the respective icons from your Desktop).
..\Microsoft\Windows\CurrentVersion\Explorer\DontShowMeThisDialogAgain
Every time you click the "Don't
show me this again" option on some warning dialogs,
Windows records your choice in this key. If you'd
like to restore a warning you've previously
dismissed, you can remove the corresponding value here. Too bad you
can't add new values here to get rid of all the
annoying Windows messages!
..\Microsoft\Windows\CurrentVersion\Explorer\FindExtensions
Contains keys corresponding to the various entries in the Start
menu's Search menu and in the Explorer Search Bar.
While 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 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 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
..\Microsoft\Windows\CurrentVersion\Internet Settings
Contains a whole slew of settings for Internet Explorer and the
Internet Options dialog in 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 start up. 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. Also, items placed here (HKLM
only) are run before the login screen appears, while items in the
Startup folder are run only after a user logs in.
In addition to the previous specific keys, there are a few paradigms
that show up again and again, such as the following: ../MRU
Stands for Most Recently Used. Any time Windows shows you a
"history" of the last few things
you've typed into a field, such as the Start
menu's Run dialog, those items are stored in an MRU
key in the Registry. A quick search for MRU 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 the Find drop-down list with a set of long names you wanted
to search for repeatedly. In MRU keys, the value names are a series of letters; there is also a
value called MRUList that specifies the order in which the entries
should be displayed. That is, if you've just typed
in the filenames *.dll and
*.exe into the Find dialog box, they might
appear as items h and i in the
list. But then, if you picked *.dll again from
the list, the MRUList would show ijabcdefgh. The
list is updated only when you actually execute a find, not when you
type in a new filename to search for or pick an item from the
drop-down list. In addition, when you quit Find, value
j, which always contains an empty string, rotates
to the front of the list.
../Namespace
Keys named Namespace usually contain values or subkeys that point to
CLSIDs (16-bit 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. Despit
e 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. (For those of you familiar with this key in
Windows 9x and Windows Me, it does not quite work in the same way in
Windows XP.) This branch contains several keys, although only one of them is
mirrored as HKEY_CURRENT_USER (discussed above).
Usually, it's the one that looks like
S-x-x-xx-xxxxxxxxx-xxxxxxxxxx-xxxx, where the long
string of x's 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. The .DEFAULT key is used 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. A
s 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, but there's little reason to edit
this branch directly. Instead, go to Control
Panel
8.3.2. HKEY_CURRENT_USER (HKCU)
8.3.3. HKEY_LOCAL_MACHINE (HKLM)
8.3.4. HKCU\Software and HKLM\SOFTWARE
(Default) "C:\Program Files\Adobe Photoshop\Photoshop.exe"
Path "C:\Program Files\Adobe Photoshop"
8.3.5. HKEY_USERS (HKU)
8.3.6. HKEY_CURRENT_CONFIG (HKCC)