Registering File Extensions

If your application creates and maintains files, register entries for the file types that you expose directly to users and that you want users to be able to easily differentiate. For every file type you register, include at least two entries: a filename-extension key entry and an application (class) identification key entry.

If you do not register an extension for a file type, it will be displayed with the system's generic file object icon, as shown in Figure 10.1, and its extension will always be displayed. In addition, the user will not be able to double-click the file to open it. (Open With will be the icon's default command.)

Figure 10.1 System-generated icons for unregistered types

The Filename Extension Key

The filename extension entry maps a filename extension to an application identifier. To register an extension, create a subkey in the HKEY_CLASSES_ROOT key using the three-letter extension (including a period) and set its value to an application identifier.

HKEY_CLASSES_ROOT
.ext = ApplicationIdentifier

For the value of the application identifier (also known as programmatic identifier or Prog ID), use a string that uniquely identifies a given class. This string is used internally by the system and is not exposed directly to users (unless explicitly exported with a special registry utility); therefore, you need not localize this entry.

Avoid assigning multiple extensions to the same application identifier. To ensure that each file type can be distinguished by the user, define each extension such that each has a unique application identifier. If you have utility files that the user does not interact with directly, you should still register an extension (and icon) for them, preferably the same extension so that they can be identified. In addition, mark them with the hidden file attribute.

The system provides no arbitration for applications that use the same extensions. So define unique identifiers and check the registry to avoid writing over and replacing existing extension entries, a practice which may seriously affect the user's existing files. More specifically, avoid registering an extension that conflicts or redefines the common filename extensions used by the system. Examples of these extensions are shown in Table 10.1.

Table 10.1 Common Filename Extensions Supported by Windows

It is a good idea to investigate extensions commonly used by popular applications so you can avoid creating a new extension that might conflict with them, unless you intend to replace or superset the functionality of those applications.

The Application Identifier Key

The second registry entry you create for a file type is its class-definition (Prog ID) key. Using the same string as the application identifier you used for the extension's value, create a key, and assign a type name as the value of the key.

HKEY_CLASSES_ROOT
.ext = ApplicationIdentifier
ApplicationIdentifier = Type Name

Under this key, you specify shell and OLE properties of the class. Provide this entry even if you do not have any extra information to place under this key; doing so provides a label for users to identify the file type. In addition, you use this entry to register the icon for the file type.

Define the type name (also known as the MainUserTypeName) as the human-readable form of its application identifier or class name. It should convey to the user the object's name, behavior, or capability. A type name can include all of the following elements:

1. Company Name
   Communicates product identity.
2. Application Name
   Indicates which application is responsible for activating a data object.
3. Data Type
   Indicates the basic category of the object (for example, drawing, spreadsheet, or sound). Limit the number of characters to a maximum
   of 15.
4. Version
   When there are multiple versions of the same basic type, for upgrading purposes, you may want to include a version number to distinguish types.

When defining your type name, use title capitalization. The name can include up to a maximum of 40 characters. Use one of the following three recommended forms:

1. Company Name Application Name [Version] Data Type
   For example, Microsoft Excel Worksheet.
2. Company Name-Application Name [Version] Data Type
   For cases when the company name and application are the same — for example, ExampleWare 2.0 Document.
3. Company Name Application Name [Version]
   When the application sufficiently describes the data type — for example, Microsoft Graph.

These type names provide the user with a precise language for referring to objects. Because object type names appear throughout the interface, the user becomes conscious of an object's type and its associated behavior. However, because of their length, you may also want to include a short type name. A short type name is the data type portion of the full type name. Applications that support OLE always include a short type name entry in the registry. Use the short type name in drop-down and pop-up menus. For example, a Microsoft® Excel Worksheet is simply referred to as a "Worksheet" in menus.

To provide a short type name, add an AuxUserType subkey under the application's registered CLSID subkey (which is under the CLSID key).

Note
For more information about registering type names and other information you should include under the CLSID key, see the OLE documentation included in the Win32 SDK.

HKEY_CLASSES_ROOT
.ext = ApplicationIdentifier
...
ApplicationIdentifier = Type Name
CLSID = {CLSID identifier}
...
CLSID
{CLSID identifier}
AuxUserType
2 = Short Type Name

If a short type name is not available for an object because the string was not registered, use the full type name instead. All controls that display the full type name must allocate enough space for 40 characters in width. By comparison, controls need only accommodate 15 characters when using the short type name.