Americas

  • United States

Windows registry magic

Opinion
Apr 07, 20034 mins
Enterprise ApplicationsMicrosoft

* Gearhead columnist Mark Gibbs takes a closer look at how Microsoft's registry is put together

“Centralized configuration database” is Microsoft’s long and rather more formal way of saying “registry” – that somewhat eccentric hierarchical database that now has a pivotal role in Windows architecture.

We’ve discussed some registry details in the past, but this week we’ll take a closer look at how the whole registry thing is put together.

First, where did the registry come from? Microsoft introduced it in Windows 95 to get away from INI file hell. Back in Windows 3.X days, system settings were stored in dozens of separate INI files, and figuring out which setting was stored where could be difficult. Thus it was that Microsoft, in its wisdom, invented something even more complicated: the registry.

Note that not all applications store all of their settings in the registry – some applications ignore it! So now we have the registry (a nightmare in and of itself) as well as configuration files. Oh joy.

So is life better? Arguably it is because you can back up the registry and be pretty certain that most of your key settings are safe. On the other hand, the registry is fragile, and if it should get damaged you could be in for a miserable time. Your system might not start, only partially start or be unstable in one of those “I know something is wrong with this computer but I’m damned if I know what it is” kind of ways. Such is the magic of Windows.

Microsoft has turned the registry into a mysterious object that it says is best left to uber-geeks. But let’s get real: Messing with the registry is as dangerous as messing with the file system. Just treat it with the respect it deserves. Anyway, let’s talk about how the registry is organized, and in doing so we’ll focus on Windows XP and 2000.

At its heart, the Windows registry is a hierarchical database. Under the root of registry hierarchy – called My Computer – are root keys that are like subdirectories and they can contain subkeys (sub-subdirectories) and values. Subkeys also can contain further subkeys and values. Finally, values have names (any characters other than “”, “*” or “?”), types (which we’ll get to in a second) and data.

You will note that all root key names start with HKEY. There is an extremely geeky reason for this: The root key names are Win32 (that’s Windows 32-bit) handles (that’s the “H” part) to keys (“KEY”).

Root key is an understandable concept but these entities also are called root handles, which is reasonable because they are, indeed, handles. But they also are called hives, which is not reasonable and merely adds gratuitous obfuscation for no apparent reason. Such is the magic of Microsoft development.

The root keys divide the registry data into categories – note that you can’t add new root keys or delete existing ones. Here are the root keys:

·HKEY_CURRENT_USER: data associated with the currently logged-on user.

·HKEY_USERS: information about all the accounts on the machine.

·HKEY_CLASSES_ROOT: file association and Object Linking and Embedding registration information.

·HKEY_LOCAL_MACHINE: system-related information.

·HKEY_CURRENT_CONFIG: information about the current hardware profile.

The values stored under keys are either the default, “value not set,” or one of the following data types (note that only the first five values were used in Windows versions before Windows 2000):

·REG_BINARY: binary data.

·REG_SZ: a fixed-length string.

·REG_DWORD: a 4-byte (DWORD) value.

·REG_MULTI_SZ: multiple REG_SZ strings.

·REG_EXPAND_SZ: an expandable string.

·REG_DWORD_LITTLE_ENDIAN: same as REG_DWORD.

·REG_DWORD_BIG_ENDIAN: a 32-bit number with the most significant byte is the rightmost, or low-order, byte. (Opposite of the order of REG_DWORD and REG_DWORD_LITTLE_ENDIAN.)

·REG_LINK: a symbolic link between system or application data and a registry value.

·REG_FULL_RESOURCE_DESCRIPTOR: nested arrays designed to store a resource list for a hardware component or driver.

·REG_RESOURCE_LIST: a group of REG_FULL_RESOURCE_DESCRIPTOR values for device configuration.

·REG_RESOURCE_REQUIREMENTS_DESCRIPTOR: binary list of required resources for a device.

There also are unused data types such as REG_NONE (a value with no data) and a series that starts REG_Q instead of REG_D for 64-bit values for some future 64-bit version of Windows.

Fair makes your head spin doesn’t it? Cries of “mercy!” to gearhead@gibbs.com.

mark_gibbs

Mark Gibbs is an author, journalist, and man of mystery. His writing for Network World is widely considered to be vastly underpaid. For more than 30 years, Gibbs has consulted, lectured, and authored numerous articles and books about networking, information technology, and the social and political issues surrounding them. His complete bio can be found at http://gibbs.com/mgbio

More from this author