Root keys are like disk volumes: they sit at the root of a hierarchy and aren’t contained or “owned” by any other item in the hierarchy. Windows Explorer groups all local disks together under “My Computer,” and the Win95 RegEdit app does the same for Registry keys, but these groupings are fake, since the disks and root keys are actually logically separate entities. The groupings just provide a convenience for users. The six root keys that make up the Registry (see The Big Six later in this chapter) are logically independent of one another; to reinforce this idea, the Windows 2000-specific Registry editor, RegEdt32, shows each root key in an individual window.

In Windows 2000 and Windows NT 4.0, there are six root keys:

Earlier versions of NT don’t have HKEY_CURRENT_CONFIG or HKEY_PERFORMANCE_DATA.

Think of a subkey as a subdirectory somewhere on disk. Any key in the Registry may have subkeys. Just as folders are contained inside other folders, these subkeys can in turn hold other subkeys, and so on down the line. (Throughout the rest of the book, I’ll call a subkey’s parent a parent key.) Naturally, the root keys all have subkeys, but no parent keys; any other key, though, can have both parents and subkeys.

A subkey can have values of its own, or it can be a placeholder for subkeys that contain values themselves. For example, HKEY_CURRENT_USERSoftware has subkeys, but it doesn’t have any values attached to it. By contrast, HKEY_CURRENT_USERSoftwareNetscapeNetscape Navigator is a subkey too, but it has several values of its own in addition to those of its subkeys. For example, the Netscape Navigator key has subkeys named Bookmark List, Mail, and Security, among others. The Bookmark List key in turn has a value named File Location. If you talk about the value named HKEY_CURRENT_USERSoftwareNetscapeNetscape NavigatorBookmark ListFile Location, then you’ve completely described the path to a particular value. Leave off File Location, and you’re talking about a subkey.

Speaking of values, now would be a good time to mention that any Registry key may have zero or more values attached to it. These values normally have three components:

As with most other statements that include the word “normally,” there’s an exception to this three-part rule: Registry keys can have a single value with no name. The Microsoft editing tools show this value with a name of (Default) or <No Name>; applications can still reach it by querying the key it’s attached to. This behavior is an artifact from Windows 3.x, but many modern applications still use this unnamed value.

The combination of these components makes it possible for Registry clients (including editors, applications, and the OS itself) to locate specific values, figure out what kind of data they contain, and get that data.

Hives aren’t just for beekeepers any more.^[7] In the Registry world, a hive is a portion of the Registry tree structure from any subkey under a root key on down. For example, the SOFTWARE hive contains HKEY_LOCAL_MACHINESoftware and all its subkeys, and their subkeys, and their subkeys, on down to the values attached to the “deepest” subkey.

Hives are significant because each hive corresponds to a disk file that contains the hive’s data. Instead of INI files, these hive files are the actual on-disk location for the system’s crucial configuration data. Consequently, they’re what you need to back up and restore (you’ll learn how to do this in Chapter 3). Windows 2000 normally uses eight hives: HARDWARE, SAM, SECURITY, SOFTWARE, SYSTEM, .DEFAULT, and two for the currently logged-in console user (one contains the user’s profile, while the other contains the user-specific portion of HKEY_CLASSES_ROOT).

Windows NT has only one hive for the logged-on user instead of two; it contains all the user’s profile data.

You’ll learn what each hive is for and where its corresponding file is stored in Hives and Files later in this chapter. In the mean time, if you look at HKEY_LOCAL_MACHINESYSTEMControlCurrentControlSetControlhivelist, you can get a sneak preview of the list of supported hives.

The Windows 2000 shell and filesystem support shortcuts. (You might be familiar with aliases or symbolic links, the Mac and Unix equivalents.) All a shortcut does is point to something else. For example, the Internet Explorer icon on your desktop is actually a shortcut to the real installation of whatever version of IE you have installed, if any. When you double-click it, the shell can resolve the shortcut to find the thing it points to and run that instead.

The Registry equivalent of a shortcut is called a link. These links provide alternate paths and names for Registry subkeys. For example, the entire HKEY_CURRENT_USER root key is a link to the current user’s subkey under the HKEY_USERS root. Since links can be built dynamically, it’s easy to construct a link whose destination varies depending on some condition or other. Windows 2000 uses these links internally in a number of places; HKEY_LOCAL_MACHINESystemControlsCurrentControlSet is a link whose origin depends on which set of device drivers, hardware components, and system software is currently active.

Figure 2-1 shows a road map of the root keys and their major hives. As you can see, several keys and subkeys are actually links to areas in different root keys. You may find it helpful to refer back to this figure as we plunge forward into discussing the six root keys themselves.

Figure 2-1. The Registry’s overall organization

HKEY_LOCAL_MACHINE (abbreviated HKLM) is the king of the Registry. Its job is to consolidate and store all the systemwide configuration data for a particular computer. HKLM includes the hardware configuration data without which Windows 2000 couldn’t even boot. Besides that, it also holds settings for the computer’s network connections, security configuration, device driver settings, and more.

There are five major subkeys under HKLM, each of which plays a critical role in keeping Windows 2000 running. They’re enumerated in Major Subkeys of HKLM later in the chapter. As you may have noticed in Figure 2-1, some of the other root keys and their subkeys are actually links to subkeys of HKLM ; that’s another reason why this root key is so important. For example, HKEY_CLASSES_ROOT is actually a link to HKLMSOFTWAREClasses.

Under Windows 2000 and NT 4.0, HKEY_USERS (also known as just plain old HKU) contains all the profile and environment settings for users on the local machine. These settings comprise all the per-user controls controllable by the System Policy Editor (see Chapter 6, for more on SPE), plus user-specific environment variables, as well as user-specific software settings. In Windows 2000, many of these profile settings are actually applied by group policy objects, using the rules discussed later in this section. The GPO provides the settings, and those settings are applied to HKU when the policy is downloaded. Changes to the user’s settings are stored in her profile, but the GPO-specified settings can always override it. However, HKU still contains much of the user-specific data, since in Windows 2000 it is mapped to the hive file that contains the user’s profile.

Each subkey of HKU is named by its security ID, or SID, a long string of digits that uniquely distinguishes every system object, process, user, and computer on an Windows NT/2000 network. Once an object is created, its SID never changes, but, its name can, so Windows 2000 uses the SID to keep track of user account profiles to keep them working when you change your account name from FredSmith to “The Administrator Formerly Known As FredSmith.” ^[8] For a more concrete example, the SID for my account on my desktop machine is S-1-5-21-220523388-1214440339-682003330-1001,^[9] so when I log on locally to that desktop machine, I see subkeys with that name under HKU.

In Windows NT 4.0, there are at least two subkeys of HKU. The first, .Default, contains a default group of settings (surprise!) named .DEFAULT that are applied when someone whose profile isn’t already in HKU logs in. This facility provides a default profile that any profile-less user gets if there’s no default profile in the NETLOGON share. The second group of settings are for the built-in Administrator account.

Windows 2000 is a little different; at any time when a user is logged on to the machine’s console, there will be three subkeys under HKU. The first is .DEFAULT, which serves the same function it does in NT 4.0. The other two contain the settings of the logged-on user: one (named with the SID) contains the profile data, and the other (named with the SID with the string “_Classes” appended) contains the user-specific setting stored in HKCR. Windows 2000 users also get settings automatically from a special profile that’s available to all users; it’s stored in the Documents and SettingsAll UsersNTUSER.DAT. Settings in the user’s profile override the contents of the All Users profile, so the all-users default for a particular setting applies only if the user hasn’t created a conflicting setting.

When you create local accounts on a machine running Windows 2000 (whether Professional or Server), their profiles are stored under HKU when they first log on from that machine’s console. When that logon takes place, Windows 2000 copies the standard profile from HKU.Default and creates a new subkey under HKU, named with the account’s SID. Until an account logs on interactively, no profile exists for that account. At this point, you might be wondering what’s under the individual subkeys of HKU, since each user on an Windows 2000 machine has her own subkey, which stores her settings independently of everyone else’s. Instead of answering that directly, let’s see what lives in HKEY_CURRENT_USER.

Surprise! HKEY_CURRENT_USER (better known as HKCU) is actually a link to the currently logged-in user’s subkey in HKU. (On machines running Terminal Server, each user has his own HKCU, and Windows 2000 uses the correct one for each user--one of the benefits of HKCU being a link to a subkey of HKU!) Using a link was a smart decision on Microsoft’s part; the link allows applications to look up things they need without needing to obtain the current user’s SID first. When faced with the choice of finding data in HKCUSoftwareKoolStuffAnApplication or the mysterious-looking HKUS-1-5-21-1944135612-1199777195-24521265-500SoftwareKoolStuffAnApplication, the choice is pretty clear. More importantly, since the Windows 9x family lacks the API routines needed to get SIDs, code written to use HKCU can run without modification on Windows 95/98, NT, 2000, and even CE.

Microsoft’s guidelines require that applications should put their settings into HKLM and users’ settings into HKCU. The idea is that settings that apply to all users on a machine go in that machine’s key, while settings that users may--and probably will--change should be stored somewhere else. HKCU provides this mechanism; as an added bonus, a collection of subkeys under HKCU can be used as an individual user profile, and it’s easy to store, load, or remove settings on a per-user basis. In fact, when Windows 2000 loads a profile, it actually copies data from the stored profile into HKCU.

HKEY_CLASSES_ROOT (better known as HKCR) made its debut in Windows 3.1 and has been around ever since. It serves as a giant lookup table that maps file extensions to the applications that own them. The Windows 2000 shell components (the desktop interface, Windows Explorer, the File Manager, and Internet Explorer 5.x) all make heavy use of HKCR, as do OLE container and server applications and ActiveX-capable software.

HKCR works because each registered file type or OLE class has two subkeys associated with it. File extensions are registered under their own name; for example, Microsoft registers HKCR.doc, HKCR.xls, and HKCR.ppt (among others) as keys for Office 2000 document types. The file extension key’s value specifies the default file type to associate with the extension. For example, the default value of HKCR.doc is WordPad.Document.1, since WordPad comes with the standard Windows 2000 installation.

Besides the associated name, the file extension’s key can contain a subkey called ShellNew. The Windows 2000 shell uses this subkey’s value to figure out how to create a new instance of that file type when the user requests it. In addition to ShellNew, the file extension key can contain one or more document type keys that tie the extension to particular document types. This allows a single extension such as .doc or .bmp to be shared by several applications on the same machine. Each of these document type keys contain a ShellNew key.

The file extension key tells the shell what type corresponds to a document, but so what? The Windows 3.1 File Manager could do that too. In order to support OLE embedding and linking, HKCR has some additional tricks that center on the file type key. This key’s name matches the default value of an extension key: when you install WordPad, you’ll get a new key named HKCRWordPad.Document.1, which matches the file type specified in HKCR.doc. Its structure looks like this:

HKEY_PERFORMANCE_DATA, or HKPD for short, was originally introduced as HKEY_DYN_DATA in Windows 95. It provides a central clearinghouse for dynamic data that is rebuilt anew each time the OS starts. In Win95, it stores performance data plus some other useful information; under Windows 2000 and NT 4.0 (it’s not present in NT 3.x), HKPD stores performance data only. “Stores” is perhaps a misnomer; none of the data in HKPD is ever written to disk. Instead, when an application requests a subkey value for any of HKPD’s subkeys, the kernel gathers the appropriate dynamic data, makes a fake subkey under HKPD, and passes it back to the requester. Since the data doesn’t exist until it’s requested, you could even argue that it’s not stored in memory.

There’s another catch, too: alone among the Big Six, HKPD doesn’t appear in the Windows 2000 Registry editors. (It does appear in the Windows NT version of RegEdit, though it’s labeled as HKEY_DYN_DATA.) You can’t directly enumerate or expand HKPD, either, as you can in Win95; only kernel clients can get or set values for keys under HKPD, making it pretty worthless to most of us.

HKEY_CURRENT_CONFIG, abbreviated HKCC, is the one-stop shopping center for data about the computer’s current hardware configuration. If you’ve defined hardware profiles using the Hardware tab of the System control panel, when Windows 2000 boots you can choose whatever hardware profile reflects your current hardware setup. The profile is actually a subset of HKLM; when you choose a profile, it’s stored in the key HKCC actually links to, HKLMSYSTEMCurrentControlSetHardware ProfilesCurrent. Like HKDD, HKCC is new in NT 4.0 and later; it’s not present on NT 3.51 machines.

The simplest and least effective control method is via a key that Microsoft provided, first in Win95 and then in NT 4.0 and Windows 2000, which administrators can use to disallow Registry editing on a machine. The good news is that this key, HKCUSoftwareMicrosoftWindowsCurrentVersionPoliciesSystemDisableRegistryTools, exists. The bad news is that this key doesn’t actually do anything! Microsoft’s Registry editors check the key and refuse to run if it exists; however, there’s no enforcement of this method, so third-party Registry editors can, and do, ignore this value with no penalty.

Worse still, users can clear this flag themselves if they have access (and permission) to use the System Policy Editor or group policy objects on their local machines. Don’t depend on this flag to keep any but the least sophisticated users out of your Registry; even though it’s not much help, it’s still worth setting.

The next step up the security ladder is to restrict who can attach to, and modify, your Registry remotely. By default, Windows NT machines grant remote read access to their Registries. This stands in sharp contrast to Win95, where you have to manually install the Remote Registry Access service on clients whose Registries you want to edit remotely. Windows 2000 is somewhere in the middle. It also has a remote Registry access service, but it’s started by default, and it allows read-only access to ordinary users. Depending on the account permissions you have, you may even be able to make changes to other systems’ Registries; however, you may disallow it manually as described in Fixing Registry Security ACLs in Windows NT in Chapter 9.

In Windows NT and Windows 2000, Registry keys all have access controls and permissions attached to them. Unfortunately, by default, in NT 4.0 prior to Service Pack 3, most keys in the Registry had Everyone:Full Control as their permissions. This led to a security exploit popularly known as the " RedButton” or “MWC” exploit, where an untrusted program could attach to and modify Registries on machines where the exploiter had no Administrator access. SP3 fixes this problem; in addition, Fixing Registry Security ACLs in Windows NT in Chapter 9 explains how to set adequate access controls on your Registry keys.

Windows 2000 doesn’t suffer from this problem nearly as much, because it has a much less permissive set of default permissions. With appropriate application of security templates (discussed in more detail in Chapter 9) you can tighten things down even further.

As an additional safety measure, you can--and should--set up auditing events to log changes to the Registry on critical machines. There’s a fine line between doing this too much and not enough; there are guidelines in Chapter 9 as well.

Microsoft has frequently (and not always fairly) been criticized for leaving security holes in its products. In particular, an exploit was reported in mid-1997 that took advantage of the fact that NT 4.0 and earlier stored some account passwords--those for services--in the Registry. Even though the passwords were obfuscated, having them there represented a security risk, since an attacker could, in theory, grab the hive files and figure out the passwords.

To fix this, Microsoft introduced a new feature called System Key Security, or SYSKEY, in Service Pack 3 for NT 4.0. SKS encrypts a portion of the Registry (mainly the SAM and SECURITY subkeys of HKLM) using the CryptoAPI cryptographic services. As a practical matter, this makes it statistically very unlikely that someone can get useful information out of your Registry unless the attacker knows or steal the key used to encrypt it. You can choose your own password (which then must be entered when you boot the machine), or you can have the system generate and store a password. Either way, without that password, the SAM data stored in the Registry is useless. It’s important to note that SYSKEY doesn’t keep people from browsing the Registry or opening keys with the programming interfaces, and it doesn’t prevent them from actually making a copy of the SAM hive itself; it just encrypts the SAM data so it’s no longer directly useful for password crackers such as l0phtcrack.^[11] (However, a tool such as Todd Sabin’s pwdump2, or future versions of l0phtcrack, make it harder to extract these hashes.)

Windows 2000 turns on SYSKEY by default, and there’s no way to turn it off. This might seem like an odd thing to do; after all, Windows 2000 uses the Active Directory to store user account information, so why would there be a SAM hive present in the first place? Not every Windows 2000 machine is an AD domain controller; for example, member servers or Windows 2000 Professional machines may still have local accounts on them. So can domain controllers, for that matter. In addition, machines that don’t run the AD services have a local SAM hive; domain controllers have one too, with AD information mirrored into it.

Once you turn on SKSKEY, it can’t be turned off. If you want to turn on SKSKEY on your Windows NT machines, complete instructions are given in Encrypting HKLMSAM with SYSKEY in Chapter 9.

REG_DWORD is a double word (the DWORD is Hungarian notation for a double word). Since a word is a 16-bit number representing the range 0-65535, a double word is just two 16-bit words, so it’s a 32-bit value, probably the most common datatype in the Registry. A REG_DWORD value can hold any integer up to 232. Even though this provides a range of more than four billion possible values, many Registry keys use REG_DWORD to stand in for Boolean^[12] values: you’ll see a lot of keys whose values can either be 1 or 0. In other cases, the value represents a quantity of something, like the percentage of time a replication request can echo on the network or the number of seconds allowed between replication attempts. The hard part is knowing what the value represents, since without that there’s no way to intelligently decide whether it needs to be changed. Chapter 10, points out some of the most significant or interesting Registry keys, and others are documented in Microsoft’s knowledge base (http://support.microsoft.com) and in the Windows 2000 and NT Server resource kits.

There is one other stumbling block: the Registry editors default to showing REG_DWORD values in hexadecimal, not decimal, and you have to use hex values when you’re setting them unless you tell the editor you’re entering decimal or binary values. This isn’t too surprising, since the Registry stores values internally as raw bytes, not in decimal. It can be annoying to have to set Registry values for things such as replication timers: “Start with the time, which is 2 days, 4 hours, 30 minutes--that’s 189,000 seconds, which is, ah, 0x2d620 hex.”^[13]

In Hungarian notation, S means “string,” and Z means “terminated with a zero byte at the end.” Put them together, and you get the REG_SZ datatype, which stores fixed-length strings by tacking on a zero at the end of the string. This extra zero is usually called the string’s terminator . The simple string “W2K” actually takes up four bytes when stored as a REG_SZ: three bytes for its contents, and one for the terminator. The terminator is mostly invisible to you (unless you write programs to manipulate Registry values in C or C++); the Registry editing tools add, remove, and store the terminator as appropriate, and they don’t display it.

After REG_DWORD, REG_SZ is probably the second most-common Registry datatype. Strings are pretty versatile; they can store human-readable names, file paths, version numbers, and lots of other useful tidbits. These strings can contain Unicode characters, which means they’re not limited to the ASCII character set. If you have occasion to edit the Registry on a machine running the Japanese, Korean, or Chinese versions of Windows NT/2000, be prepared to see non-ASCII characters aplenty.

Sometimes it’s useful to store a group of related strings as a single block. For example, since a single PC can have more than one video BIOS, NT stores the identification strings for each video BIOS it finds in HKLMHARDWAREDESCRIPTIONSYSTEMVideoBiosVersion. To support this aggregation, Windows 2000 supports a special datatype called REG_MULTI_SZ--a fancy name for what is essentially a collection of several Unicode strings. Programs that use REG_MULTI_SZ values get the strings as a block and can add to or remove from the block at will. Of course, you can edit the strings too, using the editor provided as part of RegEdt32; see Figure 2-2.

Figure 2-2. The multiple-string editor in RegEdt32

As part of what passes for its system scripting language, Windows 2000 provides a number of system-defined variables. You may already know that these variables can be used in .BAT files, the Environment Variables button on the System control panel’s Advanced tab, and directly from Windows 2000’s command line, but they can also be used within Registry values of type REG_EXPAND_SZ. For example, the %SystemRoot% environment variable points to the root directory of the OS installation (it’s usually C:WINNT or something similar). If a Registry key has type REG_EXPAND_SZ and a value of %SystemRoot%Media, any caller who retrieves the value can expand the embedded variable to its true value. You might think, based on the name, that the Registry would expand the embedded variable itself; sadly, this isn’t the case. You have to do it yourself, as you’ll see in Chapter 8. In all other respects, this type is identical to REG_SZ.

Programmers often use binary representations directly. For example, using a mask of binary digits is a convenient way to represent features or flags that may or may not be set; each bit in the mask can represent a separate on-off flag, making it possible to pack 32 independent flags into a single DWORD. Of course, it’s often useful to store arbitrary binary data--pictures, cryptographic keys, encrypted passwords, and so on--in a binary format. RegEdt32 supports storing and editing binary values with the REG_BINARY type. Binary data is totally raw; there are no terminators, string expansion, or anything else. What you put in is what comes back out. Figure 2-3 shows the binary value editor; you’ll learn more about how to use it in Chapter 5 .

Figure 2-3. The binary value editor in RegEdt32

In Links earlier in this chapter, you learned that the Registry supports links that tie one subtree to another, much the same way you figure out that “Charles Windsor” and “Prince Charles” are actually the same person. These links have their own datatype, REG_LINK, which actually looks just like a REG_SZ. Let’s say you have an intranet application that stores its configuration information in HKLMSoftwareBigCorpNiftyAppversion, where version is the application’s version number. If you want to read the application’s settings without regard to what version was installed, you can create a new key named HKLMSoftwareBigCorpNiftyAppCurrentVersion and make it a REG_LINK; its link value would be HKLMSoftwareBigCorpNiftyAppversion. To reach the application’s communications settings, you can always refer to HKLMSoftwareBigCorpNiftyAppCurrentVersionCommSettings, no matter what the actual value of version is; the Registry API routines automatically resolves the link and takes you to the correct destination of HKLMSoftwareBigCorpNiftyAppversionCommSettings.

As a more immediate example, consider HKCU. Software written for Windows 2000 must be aware that there can be several different user accounts on a single machine, each with its own unique SID. Win9x applications may be aware that multiple users sometimes share a computer, but the Win9x Registry doesn’t have SIDs--making it impossible for a Win9x app to find the current user’s settings when run under Windows 2000. Enter HKCU, which is a link that Windows 2000 builds at logon time. Instead of having to know what the current user’s security ID is and how to resolve that to a name, the application can just look for settings under HKCU.

If a DWORD is a double word, it stands to reason that a QWORD would be a quad word, right? In fact, that’s exactly what it is: four 16-bit words, providing a way to store a 64-bit quantity in a single Registry value. You’ll probably see these values only in applications running on Windows 2000 Advanced Server or Datacenter Server, and then only on 64-bit hardware. You can create and manipulate QWORD values with the Registry APIs discussed in Chapter 8, but you can’t edit them with RegEdt32 or RegEdit.

REG_NONE is a nice antidote to the more complicated datatypes featured in this chapter; it’s just a big zero. It’s used to indicate the presence of a value only; since REG_NONE doesn’t store any values, you can’t use it to retrieve or store data in a key, but you can see whether the key is there or not. This is useful in some limited situations where the existence or absence of a key indicates something important, but it’s a much better idea to use actual value types, and REG_NONE is rare.

It’s an often-forgotten fact that Windows NT was designed to work well on other types of CPUs besides the ubiquitous Intel x86. At one point, NT actually ran on five different CPU families: Intergraph’s Clipper, the MIPS CPU family, DEC (now Compaq) Alphas, the Apple/IBM/Motorola PowerPC chip, and the x86. Windows 2000 is now available only for x86 CPUs, but its multiplatform heritage lives on.

Not all these platforms order their bytes in the same way, though. “Big-endian” platforms put the most significant byte of a quantity in the lowest address, while “little-endian” platforms put the least significant byte at the low address. Figure 2-4 shows how the hex number 12345678 is represented with both kinds of “endianness.”

Figure 2-4. The hex number “12345678” in big- and little-endian form

To mix data between little- and big-endian machines, one end or the other has to swap the byte ordering. Even though NT was originally designed for little-endian machines (the x86 and MIPS), Microsoft realized that it might be desirable to run it on big-endian platforms someday. In aid of that goal, they gave us REG_DWORD_BIG_ENDIAN, which is rarely if ever seen on little-endian machines. It stores DWORD values in big-endian order, without translating them back to little-endian order on little-endian machines. Unless you’re running Windows NT on a PowerPC or Alpha (or an early beta of Windows 2000 on an Alpha), you probably won’t ever see any values of this type in your Registry. In Windows 2000, there’s also a corresponding REG_QWORD_LITTLE_ENDIAN type.

Computers have finite resources; in particular, Intel-based PCs suffer from a limited number of IRQs and direct-memory access (DMA) address ranges. Someone has to be in charge of allocating this finite supply of goodies to requesters; in Windows 2000, it’s the hardware abstraction layer (HAL), which loads as part of the boot process, that provides this necessary service. The resource arbitration’s goal is (if at all possible) to keep two or more devices from fighting over the same resource.

To make this work, the Windows 2000 kernel stores information about what resources are available in HKLM HARDWARE; this information’s gathered at boot time and stored in RAM, which is then mapped to Registry keys. Completely describing a resource requires quite a bit of data, and the operating system aggregates all the data for a resource into a resource descriptor. The REG_FULL_RESOURCE_DESCRIPTOR datatype consolidates this data, as shown in Figure 2-5. (These fields may look familiar to you, since Microsoft’s old-schoolWinMSD diagnostic tool for Windows NT used a similar format.)

Figure 2-5. The resource descriptor display in RegEdt32

Even though the number of resources on a particular computer is finite, it can still be large. Instead of scattering many values of type REG_FULL_RESOURCE_DESCRIPTOR around, the Registry offers REG_RESOURCE_LIST, a type designed to group related resource descriptors into a single unit. Figure 2-6 shows a sample of RegEdt32 ’s display for this datatype.

Figure 2-6. The resource list viewer in RegEdt32