.gif)
.gif)
.gif)
Note: Again, if it’s easier
for you to think in terms of a folder structure,
think of keys as the folder names. Since you can
have subfolders within folders, keys can have
subkeys. Think of the subkey as a subfolder
name. Just as a subfolder is also called a
folder, subkeys are also called
keys. | To make it easier to refer to
specific items within the registry database,
Microsoft has adopted a naming convention that is
similar to a folder (or directory) structure. As
you traverse down the registry tree, keys are
separated by backslashes (\). Figure
11-3 illustrates the concepts of subtrees,
keys, and subkeys and how they relate to the
registry naming convention.
Understanding Value
Entries So far, all I’ve talked about
is the organization of the database into subtrees
made up of keys and their subkeys. So is there any
data in this database, or is it just a big empty
tree structure? Yes, Virginia, there’s data in the
database. When you drill down as far as you can go
into the registry hierarchy, you’ll run into the
actual data. In fact, along the way, you may
encounter some of the actual data, before you get
to the lowest levels.
The depth of the
hierarchy varies, depending on which part of the
registry you’re examining. At some point, a key
contains actual data, perhaps in addition to other
subkeys. For the moment, let’s ignore the subkeys
and concentrate on the actual data, called
value entries.
Each value entry
within the registry has a name, a data type
(sometimes called a class), and the value itself.
The name is simply an identifier like “Current.”
It can be up to 16,000 characters long, but I
recommend staying under 20 characters for
readability. Table
11-1 describes the data types that value
entries can have. The length and format of the
value itself depend on its data type. REG_DWORD is
always four bytes long. All other types can be any
length up to 1MB. (For efficiency, it’s best to
limit values to no more than 2KB. Larger values
should be stored in files, and the filenames
should be inserted in the registry. NT abides by
this rule of thumb in most cases.)
The Case of the Disappearing
Keys |
Most of the
registry database is stored in files on disk and
survives from one operating system boot to the
next. Some portions of the registry, however,
are regenerated each time you restart the
computer. They’re never stored in a disk file
and live only while the operating system is
running. These disappearing keys are known as
volatile keys. Information on detected system
hardware, for example, is stored in volatile
keys, as you’ll see later in this
chapter. | As an example, let’s look at the
key HKEY_LOCAL_MACHINE\SYSTEM\Select. It contains
four value entries, including this one: Current:REG_DWORD:0x1 where
Current is the value entry name, REG_DWORD
indicates that the value is a four-byte number,
and 0x1 is the actual value expressed in
hexadecimal.
Note: You may encounter other
data types in your exploration of the registry.
For example, there’s a type somewhere in there
called REG_FULL_RESOURCE_DESCRIPTOR. New data
types can be defined by programs and are often
used internally by the application or operating
system. Registry Editor exclusively supports
managing the types listed in Table
11-1, so you need only concern yourself with
these types. | Understanding Registry
Subtrees The Windows NT registry is
typically depicted as five major subtrees in a
hierarchical tree structure. As you’ll see in the
following sections, these subtrees aren’t all
rooted at the same place in the database. Only two
of the five are actually in the database
root—HKEY_LOCAL_MACHINE and HKEY_USERS. All other
subtrees live below one of these two and are
depicted separately only for convenience in
editing the registry.
The HKEY_LOCAL_MACHINE
Subtree The HKEY_LOCAL_MACHINE subtree,
which exists at the root of the database, contains
all of the information about the hardware
configuration of your computer, as well as
applications and services running on it. Some of
the hardware information is updated automatically
each time you restart the operating system, as new
hardware configurations are detected. The data
stored in this part of the registry is common to
all users of this computer.
Of all the
hours that you spend working directly with the
registry, you’ll likely spend most of them inside
this subtree. I cover portions of it in more
detail later in this chapter.
HKEY_LOCAL_MACHINE contains its own set of
subtrees. Table
11-2 presents these five subtrees. All
subtrees except the HARDWARE subtree are stored in
separate files in the SystemRoot\SYSTEM32\CONFIG
folder of your NT Server installation tree.
The HARDWARE subtree isn’t stored in a
file, since NT automatically regenerates it at
boot time by running NTDETECT.COM (the hardware
recognizer utility) and the NT kernel itself. Both
of these programs feed the registry with hardware
information during the boot process. (NTDETECT
runs on Intel platforms only. On RISC platforms,
NT extracts this information from the firmware.)
Tip: If you want to find out
quickly which database files go with which
registry subtrees, look in the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\
hivelist key. You’ll find the list of subtrees
and files, similar to what’s presented in Table
11-2. (You’ll find out why this key is named
“hivelist,” later in this
chapter.) | The remaining subtrees are
stored in two files each. The files without a file
extension (SAM, SECURITY, SOFTWARE, and SYSTEM)
are the actual registry database files. The files
with extensions are used for fault tolerance and
backup purposes. Each .LOG file is actually a
journal of registry modifications, used to
reconstruct the registry file if a power failure
or other crash leaves it in an inconsistent state
while it’s being changed. Because the SYSTEM
registry file is vital to the boot process,
SYSTEM.ALT is a complete backup copy of the SYSTEM
file and is used to boot the computer if the
SYSTEM file becomes corrupt. I talk more about how
the registry participates in the boot process
later in this chapter.
The HKEY_CLASSES_ROOT
Subtree No, this isn’t some sort of
registry pep rally. The HKEY_CLASSES_ROOT subtree
contains file association information and the OLE
registration database (REG.DAT, if you’re a
Windows 3.x guru) to keep track of which
applications to launch when you double-click on
files, objects, and icons. For example, it maps
video files ending in .AVI to the action of
starting MPLAY32.EXE (NT’s Media Player utility)
whenever you double-click the .AVI file.
This subtree is actually a pointer into
the HKEY_LOCAL_MACHINE subtree—specifically,
HKEY_LOCAL_MACHINE\SOFTWARE\Classes. Figure
11-4 shows the relationship between
HKEY_CLASSES_ROOT and HKEY_LOCAL_MACHINE. Changes
made in HKEY_CLASSES_ROOT are immediately
reflected in HKEY_LOCAL_MACHINE, since they occupy
the same space.
The HKEY_CURRENT_CONFIG
Subtree The HKEY_CURRENT_CONFIG subtree
has been introduced for the first time in Windows
NT 4.0. It contains information about the specific
hardware profile used to start the computer. This
subtree is actually a pointer into the
HKEY_LOCAL_MACHINE subtree—specifically,
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Hardware
Profiles\Current. Figure
11-5 shows the relationship between
HKEY_CURRENT_ CONFIG and HKEY_LOCAL_MACHINE.
Changes made in HKEY_CURRENT_CONFIG are
immediately reflected in HKEY_LOCAL_MACHINE, since
they occupy the same space.
Cross-Reference: I discuss
management of hardware profiles in some detail
in Chapter 8. | This subtree stores the profile
information that you generated using Control Panel
applications. In general, it’s best not to edit
this portion of the registry directly, since
Control Panel applications (specifically System,
Services, and Devices) provide you with full
control over hardware profile management.
The HKEY_USERS
Subtree
The HKEY_USERS subtree,
which exists at the database root, contains user
profiles for all user accounts on the computer.
|
Page: 1,
2, 3,
4 |
next page  | |
| |
|