Windows 2000 Registry: Latest Features and APIs Provide the Power to Customize and Extend Your Apps

By default the value is set to 0; the system dynamically calculates and sets the optimal value based on the total amount of physical memory. In this case the registry size is set to one-third of the paged pool size.
The registry size limit, if not automatically determined by the operating system, is read from the RegistrySizeLimit entry under:
 

This entry is not defined by default.
In no case can the registry size limit be less than 4MB or greater than 80 percent of the paged pool size. It's worth noting that when the paged pool size changes, however, the registry size limit is not automatically updated. Furthermore, the maximum amount of registry space is only an upper limit; it does not cause space allocation, nor does it ensure that the space will be made available on demand.
The Knowledge Base articles Q94993 and Q124594 describe in detail how to get and set the registry size limit programmatically. Don't forget, however, that you need to restart the machine for the changes to take effect.

Windows 2000 Registry Data
The Windows 2000 Application Specification document (http://msdn.microsoft.com/library/specs/w2kserve.htm) states that the use of the registry must be limited to storing configuration and initialization data. In addition, all the information for the registry should be divided into computer-specific and user-specific data. This distinction allows applications to easily support multiple users and promotes location-independence for user profile data. In other words, once you've separated user-specific information from the rest of the application's data, and once you've made such information available over a network, you've provided full support for roaming users—users who connect to a distributed application from different locations and machines across the same organization.
The registry has not always been the perfect repository for all application data as depicted in the Windows 95 Logo Program. For example, unless you take specific measures, it's difficult to move or access user configuration data from different machines, and it's potentially harmful to save or restore particular program settings. In the old days, if your users had problems with some program settings, you could suggest that they locate and delete a certain INI file. Usually the result would be the restoration of the standard settings. Deleting the wrong file was rather unlikely. But you can't suggest deleting a registry subtree, unless you're advising a power user. Even for experts, deleting a registry subtree is potentially dangerous because there's no undelete feature for the registry.
For all these reasons, and to improve the overall efficiency, the Windows 2000 Application Specification reduces the circumstances in which you need to use the registry. The specification suggests that you use files instead of entries when the amount of data is larger than 2KB. To allow user roaming, you should create these files under a hierarchy of folders like this:
 

You should use those files—whether they are INI, XML, or binaries—as appendices of the registry and insert an entry that points to them.
The registry can take up a large amount of space, and a very large registry can slow the overall system performance. So to save space, you should minimize the number of keys because a key consumes more space than a simpler entry. If you need to store a logically related group of data, you should figure out a way to describe them in as flat a structure as possible and use as many entries as possible. Once again, XML is the perfect tool to describe your data in a way that is both flat and structured. XML data is flat because it remains simple text, but it's structured because you can parse it into a powerful object model.

Special Keys and Entries
Registry data is grouped into root nodes roughly following the schema depicted in Figure 8. In most cases, the same information can be set and read through API functions without directly accessing the registry. However, this is not necessarily true of all the information you might want to access. Knowing where to search for useful information can save you time and allow you to better integrate with the rest of the system.
All the available information about registered file types and system objects is stored in the HKCR hive. This is also the hive to explore if you need to verify whether a certain COM object exists and is correctly installed. HKCR contains a node with all CLSIDs and ProgIDs. In the remainder of the article, I'll examine a few stumbling blocks and provide tips to accomplish tasks that would be impossible without modifying the registry. In doing so, I'll discuss little-known keys and entries. I'll talk about access to file classes, current settings for system objects, infotips, and regedit's lastkey behavior. Let's start with the * key.
As I just mentioned, HKCR contains information about file types. You can refer to the article "Fusing Your App to the System Through the Windows 95 Shell" by Jeffrey Richter in the April 1996 issue of MSJ for basic information on file types and their registration. This has not changed since Windows 95.
Due to limitations inherent in the file system architecture, the only way to group files into classes is by the file extension. All the files with a given extension belong to a certain class, regardless of their actual content. A Windows file type is identified by a HKCR node whose name matches the file's extension. For example, HKCR\.bmp identifies the node for bitmap files.
Not all the class information for bitmaps is stored under the .bmp node, however. For a more flexible programming interface, an extension node points to another node that gathers all the information about the file class. The name of the file class for a certain file extension is stored in the unnamed default entry for the file type. For example, the file class for bitmap files is usually Paint.Picture. This is where you should search for information about bitmap images such as the icon, description, context menu, and shell extensions. The decoupling of extension and class allows different programs to register as the default handler for those files by changing a single entry and without overriding other programs' settings.
Along with file classes and COM objects, the HKCR hive also contains the current settings for a number of system objects such as folders, directories, drives, and printers. You can update the standard configuration of any of these objects individually, but you can also apply the same changes to groups of objects. The * key is a pseudo system object that groups together all files of all possible classes. The Folder key includes both folders and file system directories. The Directory key refers only to file system directories. Windows 2000 introduces a new system object called AllFileSystemObjects, under which you can enter configuration information for both files and directories.
You've probably noticed that infotips abound in the Windows 2000 Explorer, and not only for those file classes for which an infotip shell extension has been registered. Explorer, in fact, provides standard infotips for any file that appears in the shell view. The text displayed doesn't come from a systemwide infotip extension; it's read from various locations within the registry. Figure 9 shows the standard infotip for a VBScript file (.vbs). For more details and source code about infotip shell extensions, please refer to my article "Enhance Your User's Experience with New Infotip and Icon Overlay Shell Extensions" in the March 2000 issue.


Figure 9 Standard Infotip for VBScript Files

Once the Windows 2000 shell detects the file type, it attempts to locate and load an infotip shell extension for that class. If it fails, it then searches for an Infotip entry under the file class node. For example, the default file class for ASP files is aspfile. An Infotip entry under HKCR\aspfile (see Figure 10) results in the behavior shown in Figure 11. If it fails again, the standard infotip is used.


Figure 10 ASP Infotip Settings



Figure 11 Simple Infotip

Interestingly, the standard infotip is customizable. It is defined by the Infotip entry of the HKCR\* node. Its text looks like this:
 

The prop: prefix tells Explorer that the following text must be interpreted. The final infotip is up to six lines long and shows the type of the document, the author, the title, and so forth. If any of this information is not available for the file, it is simply omitted. For most files, in fact, only type and size are known, as you saw in Figure 9. Author, title, and subject are usually available for Office documents and for all compound files that expose a SummaryInformation block. With Windows 2000, if you have an NTFS partition, you can associate author, title, subject, and comment information with any file type, including text files. In that case infotips change accordingly (see Figure 12).


Figure 12 Extended Infotip

On an NTFS volume, extra fields such as Author and Subject are stored through multiple data streams for any type of file that doesn't contain a SummaryInformation block in its own body. More information on this can be found in my article, "A Programmer's Perspective of NTFS 2000: Streams and Hard Links" in the March/April 2000 issue of MSDN® News.
The structure of the HKCR\* Infotip entry is customizable and can be adapted to your own needs. In particular, you can alter the order in which the information is rendered and you can add new fields as well. For example,
 

creates a tooltip like the one shown in Figure 13. The fields you can display within an infotip are those listed in the View | Choose Columns dialog box in Windows Explorer. Notice that the dialog may also include custom columns created through a column handler shell extension. Custom columns aren't supported in infotips, presumably because it would be rather complex for the shell to associate the column name with a CLSID.


Figure 13 New Custom Infotip

If you use the Registry Editor on a daily basis there's another feature that you might find annoying over time: the automatic selection of the last accessed key. The name of the last key is stored in the LastKey entry under the Regedit node. Deleting this key is of no help since the key is overwritten or created upon exit. A partial solution is using regedt32.exe to change the permissions on the Regedit key. In particular, you can deny write access to the key to any users or groups you want, as shown in Figure 14. Make sure you apply the restriction to the Regedit key only, not to all of its subkeys. If you restrict the subkeys, you'll be unable to add and delete items to and from the favorites list.


Figure 14 Regedit Permissions

At this point, you've successfully stopped the Registry Editor from selecting the last accessed key, but you also introduced a couple of predictable side effects. Since write permissions to the registry can be granted or denied only at the key level, there's no way to lock individual registry entries. Blocking the Regedit node also prevents the application from using the other two entries defined at the same level of LastKey: FindFlags and, more importantly, View. FindFlags maintains the state of the Find dialog, whereas View remembers the size and position of the program's window. This information will become unavailable once you deny writing permissions to the Regedit node. Henceforth, the program can't reopen where you closed it, nor can it remember the last find settings. You'll have to decide if these settings are important for you to maintain.

Working with File Types
In this section I'll explain how to selectively set the visibility of file extensions (show or hide), set default behavior for double-clicking, control the Open With menu behavior, and manage connected HTML files, which I'll define later.
As you know, there are folder properties to hide or show the extension for known file types. There might be circumstances, however, in which you don't want the same setting to apply to all file classes. For example, suppose you want to hide the extension for the majority of files, but not for a couple of classes, say, .xyz and .abc. By defining an AlwaysShowExt entry in the class node, you force the shell to override the current setting and always show the extension for those files. There's no need to assign a value to the entry, but you must create it as type REG_SZ. Conversely, if you always want to show the file extension except in a few instances, create a NeverShowExt entry in the appropriate class node.
For a practical demonstration of this feature, consider shortcut files. By design, Explorer never shows the .lnk extension regardless of the shell-wide setting for known (registered) file types. If you look in the registry under HKCR\lnkfile, you'll find a NeverShowExt REG_SZ entry. In Figure 15 you can see that if you remove the entry, the .lnk extension is displayed on the Start menu. Note that for NeverShowExt/AlwaysShowExt changes to take effect, you need to reboot or at least log off.


Figure 15 Start Menu

Another way to use registry entries to set behavior is to define the action of a double mouse click. The Windows 2000 Application Specification documentation recommends that you always associate an action for double clicking on a file. This usually means defining an Open command for the file. If you don't want users to open files of a given type, you should designate those files as NoOpen. When someone attempts to open a NoOpen file, a message box like Figure 16 will appear.


Figure 16 NoOpen Message

To enable this feature, locate the class file in the registry and add a NoOpen REG_SZ entry with the custom text you want to be displayed in the caution message box. The NoOpen clause will be in effect only if there are no other shell commands defined for the file class. Furthermore, the NoOpen entry is ignored as soon as you define the first shell command.
Another interesting feature in Windows 2000 is the Open With popup menu that allows you to choose which program should handle a certain document type. Once again, you can programmatically control those lists through the registry. The subtree is:
 

To define a new OpenWith list for a file type, you first must make sure that the file type is properly registered. Suppose you want to change the OpenWith list for .xyz files. Create a .xyz\OpenWithList subtree under the FileExts node. Any entry in the menu must be qualified by a progressive letter: a, b, c, and so forth. The order in which the items appear in the menu is set through an additional MRUList entry. It contains the sequence of the letters that define the order of the items, for example, "abc". Figure 17 presents two simple VBScript scripts to create and destroy a minimal OpenWith list for XYZ files. Figure 18 shows the menu in action.


Figure 18 Open With Menu

To add an item to an existing list, you should determine the first letter available, then modify the MRUList entry. Notice that deleting registry nodes is different under Windows 9x, Windows NT, and Windows 2000. Deletion is automatically recursive under Windows 9x and deletes the entire subtree. Under Windows 2000, however, you can delete a registry node only if it doesn't contain child nodes. Entries don't affect node deletion.
You can also change the behavior of connected files (which I'll define in a minute) through the registry. You've probably already run into a rather intriguing feature using HTML files in Windows 2000. Open an HTML page with Microsoft Internet Explorer 5.0 and then save it locally using the Save As menu command. Internet Explorer 5.0 saves only the main HTML page in the folder you specified, and creates a subdirectory where it stores all other files such as images, scripts, Cascading Style Sheets, and so on. It also automatically provides for redirecting internal tags to the newly created subfolder. The child folder has the name of the default page followed by _files. Interestingly, if you delete the default page or the subfolder, both disappear from the disk. The HTML page and its child folder are connected; the Windows 2000 shell is aware of this and acts accordingly. This feature is enabled only for HTML files, and only if you make your deletion through the shell or programmatically through the SHFileOperation function. It doesn't work if you delete either the page or the folder via the DeleteFile API function or the MS-DOS DEL command.
This HTML auto-delete feature is controlled by a new flag supported by the Windows 2000 version of SHFileOperation. While calling the function, you can now employ the FOF_NO_CONNECTED_ELEMENTS flag. The effect is that the function doesn't move or delete connected files as an individual file; it only moves or deletes the specified files. Windows 2000 designates HTML pages as connected files since they often have a number of associated files that you need to copy, move, or delete as a whole to avoid breaking links. Such a feature is enabled by default and can be disabled as needed by setting the FOF_NO_CONNECTED_ELEMENTS flag before calling SHFileOperation. If you want to turn it off altogether, then go to
 

and make sure that a REG_DWORD entry called NoFileFolderConnection exists and set it to 1. Deleting the entry or setting its value to 0 turns the special HTML support back on.
At the moment, only files with an extension of .htm or .htm can be connected files. Their associated files are those contained in a child folder with a particular name. (The _files suffix is subject to localization.) Unfortunately, there is not a documented way to create custom connections and relationships between other groups of files.

Advanced Application Customization
You can use the registry to customize application behavior. For example, through the registry you can get Windows 2000 and Windows 98 to use the same Outlook® Express e-mail folders and rename Favorites links. In this section, I'll show you how.
The registry is the recommended place to store configuration data for both the system and applications. In general, an application should provide users with a public interface (such as an MMC snap-in or a Customize dialog box) to set all possible preferences. This approach often turns out to be a bit impractical, however, because of the large number of settings, time constraints, or because developers don't want certain parameters to be easily configured by users. Nevertheless, understanding an application's registry data can help you implement features that would otherwise be impossible to implement. I'll provide two examples of how tweaking the registry can help to enhance the user's experience of Windows 2000.
One of my clients had multi-boot computers and wanted to use the same e-mail archives from both Windows 2000 and Windows 98. By default, on a multi-boot machine you'll have two completely separate installations of Outlook Express using separate folders. Outlook Express utilizes the registry to persist all sorts of parameters, including the store root directory—the path of the folder where all messages are kept. To solve both problems, I had to figure out the physical path for Outlook Express archives and devise a way to redirect it. On my machine Outlook Express stored lots of configuration information under:
 

Here the CLSID is simply the ID of one of the possible identities you're using to send and receive messages through Outlook Express. The REG_SZ entry named StoreRoot contains the path name where all the archives are kept. You can change this entry to share Outlook Express archives among multiple installations.
Another example of how registry tweaking can make your life easier makes use of the Windows 2000 Registry Editor. I like the Favorites menu that allows you to define shortcuts to frequently visited subtrees. However, I soon realized that it doesn't allow you to rename an existing link. You can rename a link, however, with the Registry Editor. To get to the Favorites subtree I just added another favorite link to:
 

Now I can go there with a click and rename items through the Registry Editor's user interface.

The Windows 2000 Open File Dialog
With Windows 2000, the common Open File dialog changed its look and now shows a vertical toolbar (also known as a places bar) from which you can switch directly to frequently visited folders. Wouldn't it be great if you could programmatically specify which folders to display in the places bar and the number of folders to display? To date, the Windows 2000 SDK doesn't provide much of an opportunity for full customization. The only thing you can do on a per-program basis is hide the places bar by properly setting the new (Windows 2000) FlagsEx member of the OPENFILENAME structure:
 

You could also turn the places bar off for all applications by setting a particular policy for common dialogs. Go to
 

and make sure there is a NoPlacesBar REG_SZ entry set to 1. For this change to take effect you don't need to reboot or shut down any applications. The relevant registry settings, in fact, are never cached and are always reread before displaying the dialog.
The registry also specifies the icons for the commonly used folders that populate the places bar. The folders that appear there by default are History, Desktop, My Documents, My Computer, and My Network Places.
To insert your own list of favorite folders, go to the same ComDlg32 node and create a new key called PlacesBar. You can specify up to five folders. Each folder is identified by an entry called Place0, Place1, and so forth, up to Place4. The value of these entries can be either a fully qualified path name or a CSIDL value that identifies a special folder independent of the particular machine. CSIDLs are numeric values that shell functions such as SHGetFolderLocation use to identify system-dependent or virtual folders such as My Documents, My Computer, Windows, My Network Places, and to find folders that reside in different locations on different machines.


Figure 19 Custom Places Bar

If you want to specify an absolute file system path, create a REG_SZ or REG_EXPAND_SZ entry. If you plan to use a CSIDL, then a REG_DWORD entry is mandatory. CSIDL values are defined in shlobj.h. Make sure you get the one that ships with the latest Platform SDK if you want the new IDs specific to Windows 2000. The PlacesBar key does not exist by default. In this case GetOpenFileName displays the usual five folders. Figure 19 shows a new places bar that displays the folders I have chosen (Articles, WINNT, My Documents, Favorites, My Computer).

Registry API Flavors and New Functions
There are basically three ways to program the registry: the Win32 API functions (advapi32.dll), the more recent Shell Lightweight API (shlwapi.dll), and various object models accessible mostly from Visual Basic® and Windows Script Host. If Visual Basic is your favorite development tool, I recommend taking a look at the RegObj library available from http://msdn.microsoft.com/vbasic/downloads. It is an object model that emulates the full Win32 API for working with the registry.
The original set of registry functions provides you with the greatest flexibility. It requires you to open a key, to read or write to it, and then close it; the three basic operations for reading or writing an individual entry.
The Shell Lightweight library—also available with Windows 98, Windows 95, and Windows NT 4.0 plus Internet Explorer 5.0 or higher—comes with some new functions that internally open and close the specified key when asked to read or write values. You just call SHGetValue or SHSetValue and let the function deal with the registry. In addition, the new API provides a SHDeleteKey function that recursively deletes non-empty keys. As explained earlier, this is the standard behavior in Windows 9x, but not in Windows NT or Windows 2000.
The Windows 2000 SDK introduces three new functions that work with the registry: RegOpenUserClassesRoot, RegOpenCurrentUser, and RegDisablePredefinedCache. RegOpenUserClassesRoot returns a handle to HKCR for the specified user. You identify the user through an access token. The token can be returned by functions like LogonUser, and allows you to log onto the system as if you were another user.
RegOpenCurrentUser retrieves a handle to HKCU. Notice that by default all the values stored in HKCU are cached for all threads in a process. To disable this practice and force the API to read and write from disk, remember to call RegDisablePredefinedCache.
IQueryAssociations is another tool for working with the registry. It simplifies the information retrieval from HKCR and HKCU. You obtain a reference to the interface through IShellFolder's GetUIObjectOf or a new API function called AssocCreate. The IQueryAssociations methods allow you to set the root key and query for data, as shown in the following code:
 

You can force the interface to work on the portion of the HKCR that contains information about the specified file class. Alternatively, you could specify a ProgID or specify the HKEY handle to be the root. All the subsequent calls to IQueryAssociations methods (GetData, GetString) will use this root as the starting point for searching information.
Other functions, such as AssocQueryKey and AssocQueryString, retrieve file information in a single shot and can be considered a more compact and direct replacement for repeated calls to RegOpenKeyEx, RegQueryValueEx, or SHGetValue.

Overriding Predefined Keys
To improve setup programs and, more importantly, their interaction with the rest of the system, Microsoft introduced a new API called RegOverridePredefKey. Its purpose is to temporarily remap one of the registry's root nodes to a user-defined subtree. In this way, a setup program can check—and possibly deny—all the registry settings that an installing component might want to create. Remapping HKCU or HKLM to a temporary key doesn't change anything for the component; it doesn't even realize it is writing to a different key. For all purposes, the remapped key evaluates to the original one. Once the component finishes updating the registry, the setup program can control—and possibly fix—the entries before restoring the original root node and copying the entries from the temporary key to the right place.
While the MSDN documentation emphasizes its use mostly within installation programs, I think that RegOverridePredefKey could be just as effectively used to accomplish less noble, but necessary tasks such as subclassing, discovery of program internals, and customization of existing programs—all the dirty tasks that your users often ask for, but which aren't well documented. I'll explain how this works.
The prototype of the function is rather straightforward:
 

The hKey parameter is the handle to any of the predefined root nodes such as HKCR, HKCU, and HKLM. The hNewHKey argument is the handle to the key to the hive where all access will be automatically redirected. By remapping a node you can sometimes force existing programs to read the settings you want, instead of those they were supposed to read. Different settings may result in a different behavior (subclassing).
This code remaps HKCU to HKCU\Dino:
 

From now on, any attempt to read or write under HKCU transparently occurs under HKCU\Dino. To restore the original mapping, do the following:
 

Once you called RegOverridePredefKey, you can safely close your handle to the mapping key—in this case, hkMyCU.
The mapping is not a global setting; it takes place only within the context of the process that calls RegOverridePredefKey. So if you plan to use this feature to customize the behavior of existing programs, remember that you cannot spawn them from your own program. Instead, you should be able to "invade" the address space of the target app and call RegOverridePredefKey from there.
Earlier, you may recall, I mentioned regedit.exe and the LastKey entry. Well, once you've successfully hooked up the Registry Editor process, you just call:
 

Then Regedit will try to access a subtree like this under what it thinks is HKCU: