The registry's HKEY_CLASSES_ROOT subtree contains a large majority of the Windows settings. In particular, this registry subtree stores all the settings and preferences for Windows Explorer and the Windows shell. For this reason, the integrity of this portion of the registry is extremely crucial for the Windows OS to work properly.
You must pay particular attention to what you write in the HKEY_CLASSES_ROOT subtree because incorrect data is a potential source of trouble. Incorrect changes can break existing applications or disable standard system features in a way that you can fix only by reinstalling applications or the OS software. However, if you're knowledgeable about this subtree's contents and use the techniques I show you, you can safely make changes.
The registry keys in the HKEY_CLASSES_ROOT subtree fall into two main categories:
- Keys containing information about file classes and system objects—The contents of these keys determine the special support that the OS provides for groups of files and groups of system objects (e.g., printers, drives).
- Keys containing information about COM objects—The contents of these keys enable the use of COM objects in scripts and programs.
This month, I examine the keys containing data about file classes and system objects. I show you how the HKEY_CLASSES_ROOT subtree structures this information and how you can add and customize file classes and system objects through the registry. Next month, I'll examine COM objects.
Understanding File Classes
When you double-click a file in Windows Explorer, the system launches a specified application. People often say that the system is launching the application that created the file, but more precisely, the system is launching the application registered to handle all the files with that file class.
A file class is a group of files that have logically related content and structure. For example, all bitmap files constitute a class, as do all Microsoft Word files. Unfortunately, when the system is determining a file's class, it doesn't have a reliable way to analyze the file's content. Thus, the file's extension is the only parameter the system uses to determine the class. In other words, despite the file's actual content, the system reacts only to the file's extension. So, for example, the system blindly considers a bitmap file with an incorrect extension of .txt as a text file.
All file classes must be registered in the HKEY_CLASSES_ROOT subtree. A file class is registered when the subtree contains a key named after the file extension. For example, the class for text files has a key called HKEY_CLASSES_ROOT\.txt. This class key, however, doesn't include the settings for that class. Instead, the value of this key's default entry points to a descriptive key that stores the class settings. For example, the default entry for the HKEY_CLASSES_ROOT\.txt key points to the HKEY_CLASSES_ROOT\txtfile key, which contains the class settings. This setup lets different applications more easily use the same file classes. For example, it lets both Word and Notepad more easily use .txt files.
Adding File Classes
You can easily add file classes to the registry with Windows Script Host (WSH). Before you add a class or make any other change to the registry, though, you need to make a backup of the registry in case a problem arises.
Suppose you want to create the XYZ class. You need to create two keys: HKEY_CLASSES_ROOT\.xyz and HKEY_CLASSES_ROOT\xyzfile. As I described in "VBScripting Solutions: The Windows Registry Structure and Tools," December 2000, you use the WScript.Shell object's RegWrite method to write to the registry.
Listing 1 shows the code to write these keys and thus create the class. First, you write the descriptive key HKEY_CLASSES_ROOT\xyzfile. Two settings are common to all files in a system: descriptions (i.e., file type in Windows Explorer) and icons. In this case, you want the file type to be Unknown document and the icon to be a green tree.
To write the file type, you specify the registry key as the first argument ("HKCR\xyzfile\") and the value you want to write ("Unknown document") as the second argument. The file type must be the descriptive key's default value, so you need to place a final backslash after the key's name.
To assign the class an icon, you need to create the DefautIcon subkey under the HKEY_CLASSES_ROOT\xyzfile key. The default value of the DefaultIcon subkey must be a comma-separated string that specifies where the system can find this icon. The string's first segment contains the path to the file containing the icon. The second segment is an index number that identifies the ordinal position of the icon in that file. (The position of the icons is determined by the order in which they've been declared in the file's resources.) For example, the string "C:\winnt\system32\shell32.dll,41" tells the system you want the 41st icon in the C:\winnt\system32\shell32 file. Icons can reside in .dll, .exe, and .ico files. Typically, a .ico file contains just one icon. In this case, the index number is 0.
After creating the descriptive key, you can write the class key to the registry. Remember that the default value of the class key must point to the descriptive key to establish the association between them. So, as Listing 1 shows, you specify the registry key ("HKCR\.xyz\") as the first argument and the value you want to write ("xyzfile") as the second argument. Because the pointer must be the .xyz key's default value, you place a final backslash after the key name.
If an application replaces the settings for a file class, it doesn't overwrite the existing settings. Instead, the application creates and fills a second descriptive key and replaces the pointer in the class key. For example, when Microsoft Internet Explorer (IE) and Netscape Navigator replace each other as the default browser, they don't overwrite each other's respective settings. Instead, they use their respective descriptive key and write the name of that key as the default value of the HKEY_CLASSES_ROOT\.htm key.
Customizing the Context Menu
In addition to using WSH to add new file classes, you can use WSH to customize existing file classes. For example, you can customize the context menu for a file class by writing additional settings to the class's descriptive key.
When you right-click a file in Windows Explorer, a context menu like that in Figure 1 pops up. Since Windows 95, all Windows OSs support context menus. Although a few menu options are common to all files, most of the menu options depend on what's written in the HKEY_CLASSES_ROOT subtree for the file class to which the selected file belongs.
The system decides the default options that appear in each file class's context menu; you can't change these defaults. However, you can add extra menu options. For example, the code in Listing 2 adds the Open this with Notepad option to the context menu for XYZ files. This added option appears at the top of the context menu in Figure 1. When you select this option, Notepad opens the file you selected (i.e., the file you right-clicked to obtain the context menu).
A subkey called shell is the root of all user-defined options in a context menu. Each subkey under shell defines a new menu option. For example, in Listing 2, the \xyzfile\shell\MyCommand subkey defines a new menu option for XYZ files. By default, this subkey's name (i.e., MyCommand) is also the name of the command that will perform the intended task and the name of the option in the menu. Although you can't change the command name, you can change the option name by specifying new text in the default value of the MyCommand subkey. In this case, you're specifying the text Open this with Notepad as the new option name.
Each command must have a subkey whose mandatory name is Command. The Command subkey's default value is the code you'd normally type at the command line to perform the intended task. If an external program will be performing the task, you use the pseudo argument %1 to specify that you want the external program to work with the selected file. Thus, putting the string "notepad %1" as the default value of the \xyzfile\shell\MyCommand\Command subkey forces Notepad to open the selected file.
Understanding System Objects
File classes are groups of files characterized by the same extension. Sometimes, you need to associate context menu options or other special behaviors to groups of items that don't have the same file extension. For this reason, the HKEY_CLASSES_ROOT subtree defines system objects.
System objects represent groups of related system elements (e.g., files, folders, directories, printers, drives). The HKEY_CLASSES_ROOT subtree defines the settings for the system object that represents all files in the system, no matter the files' extensions or location. Thus, all the settings you apply under the HKEY_CLASSES_ROOT subtree apply to all the files in the system.
Under the HKEY_CLASSES_ROOT subtree are keys that also contain settings for system objects. For example, the HKEY_CLASSES_ROOT\Folder key contains the settings for the system object that represents all the folders in the system and the HKEY_CLASSES_ROOT\Directory key contains the settings for the system object that represents all the directories in the system. Thus, all the settings you apply in the Folder and Directory keys apply to all folders and directories, respectively.
Folders and directories aren't the same. A directory must have an entry in the file-system tables, whereas a folder doesn't. All directories are folders but not all folders are directories. However, in Windows 2000, Microsoft added a new system object—AllFileSystemObjects—that represents all system elements that have an entry in the file-system table, so the object represents both files and directories.
You manipulate the keys containing settings for system objects the same way you manipulate the keys containing settings for file classes—you use the RegWrite method. For example, you can use the RegWrite method to customize the text that infotips, a type of system object, displays.
As Figure 2 shows, the system displays an infotip when the mouse hovers over a file in the Windows shell. Only Win2K and Win98 natively support infotips. If you're running Windows NT or Win95, you must install IE 4.0 or later with the Active Desktop update to support infotips. (For information about the Active Desktop update, see the article "Customizing the Windows 2000 Active Desktop," August 2000.)
The string value written to the HKEY_CLASSES_ROOT\*\Infotip entry determines the infotip's content. Because the HKEY_CLASSES_ROOT\* key represents all file classes in the system, the value in the Infotip entry applies to all file classes by default.
The standard string value in the Infotip entry is "prop:Type;Author;Title;Subject;Comment;Size". The prefix prop: has special meaning in the shell. Basically, it states that the system must parse and interpret the text that follows instead of displaying the text as is. Semicolons separate the remaining elements in the string. These elements specify the file properties that the infotip must display and the order in which they must appear.
An infotip can display a maximum of six lines (i.e., a line for each of the aforementioned properties). Not all files will have all the properties defined, so the infotip might display fewer lines. For example, if only the Type and Size properties are defined for a file, the infotip will display only two lines, as Figure 2 shows.
You can customize the infotip content by adding or deleting properties and by switching the order in which the properties appear. Remember, though, if you modify the Infotip entry under the HKEY_CLASSES_ROOT\* key, the changes will affect all files, no matter their extension, in all folders. If you want to change the infotip content only for a specific file class, you can create a custom Infotip entry under the descriptive key for that class. For example, if you want the infotip to display only the file type when the mouse hovers over .xyz files, you can create an Infotip entry under the HKEY_CLASSES_ROOT\xyzfile key and specify "prop:Type;" as its value.
You can customize infotips both manually and programmatically. In most cases, tweaking the registry manually with an interactive graphical tool (i.e., regedit or regedt32) is the best approach.
Be Cautious, Not Afraid
The HKEY_CLASSES_ROOT subtree is extremely important for the health of your Windows system. However, this importance doesn't mean that you should never open the registry. Now that you know how the HKEY_CLASSES_ROOT subtree structures its data about file classes and system objects, you can customize this data with minimal risk. And next month, I'll show you how the HKEY_CLASSES_ROOT subtree structures its data about COM objects so that you can customize that data as well.