Registry Conventions

[Previous] [Next]

This section discusses conventions for registry usage, focusing on the portions specifically applicable to server software designed for Windows.

The integrity of the registry is maintained through the marriage of system-enforced rules and convention. Convention keeps the registry from becoming a general-purpose database engine for a piece of software, and also helps avoid undue clutter and traffic in this shared system resource.

The first decision you should make regarding storing configuration information for your software is whether the information applies to the machine (or all users) or to a specific user of the system. Said another way, if the information maps to a feature of your software, do you want the feature's configuration to be the same regardless of the user involved, or do you want the information to be configured differently for each user?

In the typical case, information stored in the registry when software is installed applies to all users of the system. This process is much like hardware being installed on the system. In contrast, user settings and configuration changes made at software run time are commonly stored for a specific user.

Machine-Specific Registry Settings

When an application (or service) needs to store data specific to the configuration of the machine it is running on, convention mandates that it store its keys and values in this hierarchy:

 HKEY_LOCAL_MACHINE Software Your Company Name Your Product Name Your Product Version (optional) Key1 Value1 Value2                     Key2                     

Following this structure helps avoid registry clutter and makes your software-specific information easier to find. Typically, server software doesn't store configuration information for specific users. Its configuration is machine-specific; it has no need or opportunity to adjust its behavior based on a specific user.

User-Specific Registry Settings

The subkeys under HKEY_USERS represent user configuration information. The system automatically maps HKEY_CURRENT_USER to the subkey for the current user—that is, the subkey for the user associated with the current process. If a thread is impersonating another user (impersonation is covered in detail in Chapter 11), all references to HKEY_CURRENT_USER by that thread will refer to the impersonated user.

If your software will be accessing user-specific registry information, it should follow a convention similar to that used with HKEY_LOCAL_MACHINE:

 HKEY_CURRENT_USER Software Your Company Name Your Product Name Your Product Version (optional) Key1 Value1 Value2                     Key2                     

Of course, you can access this hierarchy directly via the HKEY_USERS root key, but this is not recommended. If you really feel the need to do this, you can use the RegOpenCurrentUser function. Understanding the way in which HKEY_CURRENT_USER relates to the data found under HKEY_USERS involves the understanding of tokens and user context, which are discussed in detail in Chapter 11.