HKCR is the backbone of the OLE/ActiveX subsystem. The shell, the Explorer, and many applications depend on the data stored here for prosaic tasks such as deciding which icon to display with a file or what to do when the user double-clicks a file. OLE applications need this data to determine what servers to start when a user embeds or links a foreign object into a document, and the Distributed OLE and DCOM systems need it too.
In Windows NT 4.0 and previous versions of NT, this root key got its data solely from the software classes subkey under HKLM, that is HKLMSoftwareClasses. This worked fine, although the system could register program classes only on a per-machine basis. In Windows 2000, the software classes under HKCUSoftwareClasses are merged with the HKLM software classes to make up HKCR. Defined as per-user class registration, this allows program classes to be registered independently for each user.
The original Win3.x scheme for linking a file with the application that created it was to associate the file’s extension with the name of an executable. With the introduction of OLE, though, it became necessary to associate file contents with DLLs, since an OLE server might be a DLL instead of a standalone application. The Win 3.x File and Program Managers were primitive at best, and to improve them Microsoft needed a lot more information about files, their creators, and their types.
The starting point for these improvements is the set of filename-extension keys that live under HKCR. These keys are named after file extensions: HKCR.txt, HKCR.html, and so on. The default value of each of these keys contains a string called the application identifier such as “textfile” or “htmlfile.” This value is used to look up an HKCR subkey of the same name.
While it’s possible to add other values to file association keys, no part of the system will use them, and they’re subject to being overwritten, so don’t count on your values being available if you keep them here.
For each file association key, there is usually a single key whose name matches the application identifier. These keys are called class-definition keys. Continuing the previous example, let’s say there’s a key named HKCRhtmlfile. To figure out what to do with a file when the user double-clicks it, the shell follows three steps:
Strip the extension from the file and use it to find a file association key such as HKCR.doc or HKCR.pl.
Open the file association key and get its default value, then use that value to look for a key with the same name. For example, if HKCR.pl’s default value is “Perl script,” the shell looks for HKCRPerl script and tries to open it. This subkey is called the application identifier key.
The application identifier key contains values the shell parses to figure out how to open or edit a file, or to create a new copy of a particular file type or object.
Each application identifier key can have a number of values and subkeys. Which ones a particular application’s key has varies. Here are the most common subkeys:
- CLSID
This subkey’s default value contains the class ID, or CLSID, assigned to an OLE object. OLE applications (including Explorer and the shell) can use this CLSID to keep track of a file or object’s type.
- DefaultIcon
The default value of this subkey contains the path to an executable or DLL and a resource ID. When it needs the icon for a file, the Explorer looks up the application’s class-definition key, gets the DefaultIcon value if it exists, and loads that icon. By changing this value, you can alter the icons displayed for a particular file type.
- Shell Edit, ShellOpen, and ShellPrint
These subkeys each have a further subkey: Command. When the system sees one of the ShellXXX keys, it knows that this class type can be opened, printed, or edited. The value of the Command subkey gives the actual command that performs the requested action.
- shellex
The shellex subkey makes it possible for clever programmers to add items to the Properties dialog for a particular file type. The value of the shellexPropertySheetHandlers can specify a CLSID; when the shell looks up the CLSID’s key, it can figure out which property sheet or dialog to open for that item.
This subkey contains all the CLSIDs for classes installed on the system. Each CLSID key contains a value that provides a human-readable name for the class (which appears in the Insert Object dialog of most OLE-compatible applications). There are a variety of other subkeys that can be attached to a particular entry under HKCRCLSIDclsid. The most important ones are InprocServer32 and InprocServer. These specify which DLL implements the code to create or edit objects of this CLSID’s type.