Blog
What is File Association?
File associations can be defined as the relationship between the file and the application that created it. They are what the Microsoft Windows operating system uses to open a file with the correct program. For example, a .doc file will open with Microsoft Word, and a .bmp will open by default with Microsoft Paint. These associations are retained in the registry. In Windows, the association is made by the file extensions, which are the last letters of the name preceded by a period, such as .DOC, .GIF and so forth. When a document is double-clicked, the extension identifies which application should be launched to open it.
If you click a file name and there is no association previously registered, the operating system will ask you to set up that relationship.
Why is File Association important?
A file association enables you to control certain aspects of the Shell’s treatment of different file types. These aspects include:
- Which application launches when a user double-clicks a file
- Which icon appears for a file by default
- How the file type appears when viewed in Microsoft Windows Explorer
- Which commands appear in a file’s shortcut menu
Apart from the above things, File Association has the following benefits: –
- File associations provide a straightforward and useful way for users and developers to customize the Shell’s treatment of defined file types.
- Application developers can use file associations to link an application to one or more desired file types, and customize the Shell’s treatment of that application’s file type. For example, when the application installs, it can check for the existence of the appropriate file associations and either create or override them as appropriate. The file association can then cause the Shell to display custom icons for files of the given types. The file association can also control how the Shell interprets user input for a file of a given type. For example, when a user double-clicks a file, the Shell launches the application and uses it to open the file. These are typical uses for file associations.
- Expert users can use file associations to customize their user interface. Users can modify file associations in three ways: by using the Edit File Type property sheet in Windows Explorer, by using the Open With dialog box, or by editing the registry.
How to implement File Association?
The registry stores the file extension keys under HKEY_CLASSES_ROOT. These keys have the general form: .extension=ProgID. It is important to include the leading period when creating file type key entries in the registry. For example, if you want a file type with the short extension .MYP and the long extension .MYP-image to open with an application called MyProgram, then you use the following syntax.
.MYP (Default) = vendor.MyProgram.1
.MYP-image (Default) = vendor.MyProgram.1
vendor.MyProgram.1 (Default) = MyProgram Application
File type extension entries in the registry have several optional sub keys and attributes. Those used by file associations are:
- Default Value- Set the default value of the extension key to the PROGID to which it is linked. This is a registry string (REG_SZ).
- PerceivedType– Set this string to the PerceivedType to which the file belongs, if any. This string is not used by Windows versions prior to Windows XP.
- Content Type- Set this string to the file type’s MIME content type.
- OpenWithProgids- This sub key contains a list of alternate PROGIDs for this file type. The programs for these PROGIDs appear in the Open With dialog box. Whenever a program takes over this file type by changing the default value, it should also add an entry to this list.
- OpenWithList- This sub key contains one or more application keys for applications to appear in the Open With dialog box entry for the file type.
The general form of a file extension key is then:
.ext (Default) = ProgID.ext.1 (REG_SZ)
PerceivedType= PerceivedType (REG_SZ)
Content Type= mime content type (REG_SZ)
OpenWithProgids
ProgID2.ext.1
ProgID3.ext.1
OpenWithList
AlternateProgram1.exe
AlternateProgram2.exe
ProgID.ext.1
Shellnew
How does File Association work?
A file association generally has a preferred action that is taken when the user double-clicks a file of this type. This preferred action is linked to a verb referred to as the primary verb. The primary verb is specified by the default value of the shell key, or the open key if the shell key has no default value. The most common primary verb is open. However, in media files, the most common primary verb is play. The primary verb is also referred to as the default verb. There are some standard canonical verbs as well as special verbs.
Standard Canonical Verbs
- Open- A typical primary verb that launches the associated application and uses it to open the invoked file.
- Opennew- Equivalent to open, but launches the content in a new window.
- Openas- Presents a dialog that allows the user to choose an application with which to open the file.
- Edit- Works the same way as open, but typically enables the user to edit the contents of the file.
- Play- Similar to open, but is typically invoked on media file types. This verb indicates that the associated application immediately begin, playing the contents of the file, rather than just opening the file and waiting for user direction.
- Print- The application prints the contents of the file and exits, displaying as little as necessary to complete the task.
- Preview- A quick, simple response that allows the user to rapidly preview and dismiss items.
Special Verbs
- Printto- Used by the Shell to support drag-and-drop to printers.
- Runas- Used by the Shell to expose the contents of a file in the context of a specific user. The Shell uses this verb to give the user a higher level of system privileges while executing a certain task.
How does the Shell invoke a Verb?
There are three ways that the Shell can invoke a verb.
- As a command line call, as specified in a command key.
- Through Dynamic Data Exchange (DDE), by using a ddeexec key.
- Through COM and IDropTarget, by using a DropTarget key.
Invoking a verb normally launches the application specified by the verb’s command sub key using CreateProcess. However, if your application supports DDE, you can have the Shell initiate a DDE conversation instead. To specify that invoking a verb should initiate a DDE conversation, add a ddeexec sub key to the verb’s key. Set the default value of ddeexec to the DDE command string that is sent with the WM_DDE_EXECUTE message. The ddeexec key has three optional sub keys that provide some control over the DDE process.
- Application- Set the default value of this sub key to the application name to be used to establish the DDE conversation. When the Shell calls DDEConnect to establish the DDE connection, a handle to this string is passed in the hszService parameter. If there is no application sub key, the default value of the verb’s command sub key is used as the application name.
- Topic- Set the default value of this sub key to the topic name of the DDE conversation. When the Shell calls DDEConnect to establish the DDE connection, a handle to this string is passed in the hszTopic parameter. If there is no topic sub key, System is used as the topic name.
- Ifexec- Set the default value of this sub key to the DDE command to be used if DDE conversation cannot be initiated. When initiation fails, the application specified by the default value of the verb’s command sub key is launched. If an ifexec key exists, its default value will then be used as the DDE command. If there is no ifexec sub key, the default value of the ddeexec key is used again as the DDE command.
The following example specifies that invoking the open verb for MyProgram.1 initiates a DDE conversation with a DDE command of Open (“%1”) and an application name of MyProgram.
HKEY_CLASSES_ROOT
MyProgram.1 (Default) = MyProgram
Shell
Edit
Command (Default) = “%ProgramFiles%\MyProgram.exe” “%1”
Open
Command (Default) = “%ProgramFiles%\MyProgram.exe” “%1”
Ddeexec (Default) = Open (“%1”)
Application= MyProgram
Support for Drag-and-Drop Features
On Microsoft Windows XP systems, enhanced support is added for applications that implement drag-and-drop features and expose their IDropTarget interface. With this method, the Shell communicates with the application through the Component Object Model (COM) subsystem. This method offers a significant performance gain over both the command line method and DDE. To use this method, add a DropTarget sub key under a verb’s key. Under the DropTarget, add a registry string named CLSID, and set the value of this string to a valid CLSID Key. For example:
HKEY_CLASSES_ROOT
Paint. Picture
Shell
Open
Command (Default)=rundll32.exe C:\WINNT\System32\shimgvw.dll,ImageView_Fullscreen “%1”
DropTarget CLSID= {E84FDA7C-1D6A-45F6-B725-CB260C236066}
Printto
command (Default)=rundll32.exe C:\WINNT\System32\shimgvw.dll,ImageView_PrintTo /pt “%1” “%2” “%3” “%4”
The CLSID for a DropTarget is defined normally, in this case:
HKEY_CLASSES_ROOT
CLSID
{E84FDA7C-1D6A-45F6-B725-CB260C236066}
InProcServer32 (Default) = “%SystemRoot%\System32\shimgvw.dll”
ThreadingModel= Apartment
In this example, only an in-process server is defined for the class identifier (CLSID). However, a CLSID referred to in a DropTarget key may specify a local server (LocalServer32), an in-process server (InprocServer32), or both. The DropTarget key takes precedence over both the ddeexec and command keys.
Supplemental Verbs
Apart from standard canonical verbs there are also Supplemental Verbs. Supplemental verbs are any verbs other than the standard canonical verbs, and are most often used to add custom behavior beyond what the default system verbs provide. On Windows XP or later, you can add supplemental verbs to the SystemFileAssociations extension, or to the Shell sub key for the PerceivedType key. For example, suppose MyTextEditor is a text editor and the developers of MyTextEditor want to add a supplemental verb that displays “Edit with MyTextEditor” when you right-click any file of the perceived type “text.” To accomplish this, a key named edit.MyTextEditor is added to the registry as follows:
HKEY_CLASSES_ROOT
SystemFileAssociations
Text
Shell
Edit
Command (Default) = “%SystemRoot%\system32\NOTEPAD.EXE” “%1”
Open
Command (Default) = “%SystemRoot%\system32\NOTEPAD.EXE” “%1”
edit.MyTextEditor (Default) = Edit with MyTextEditor
Command (Default) = “%ProgramFiles%\MyTextEditor\MyTextEditor” “%1”
The file name is passed as %1. After the edit.MyTextEditor key is added, the shortcut menu displays the new choice for any file belonging to the PerceivedType text as follows:

The registry typically stores verbs and the Shell uses them to invoke certain actions. These verbs are referred to as static because they vary based on the current selection, that is, they are unconditionally present and have no state. The Shell implements IContextMenu for applications when they register static verbs under the appropriate registry keys. Verbs that you implement using a custom IContextMenu rather than the registry are called dynamic verbs.
For example, a typical progID entry for the file .txt file is as follows:
HKEY_CLASSES_ROOT
Txtfile
DefaultIcon
Shell
Open
Command (Default) = “%SystemRoot%\system32\NOTEPAD.EXE” “%1”
Command (Default) = “%SystemRoot%\system32\NOTEPAD.EXE” /p “%1”
PrintTo
Command (Default) = “%SystemRoot%\system32\notepad.exe” /pt “%1” “%2” “%3” “%4”
Three static verbs are registered in this ProgID: open, print, and printto. When the user brings up a shortcut menu on this file type, open and print appear in the shortcut menu, while printto does not because it is a special system verb. If the user selects either open or print from the shortcut menu, the command stored in the corresponding command key executes. In this example, %1 represents the file name and %2 the printer name. The %3 and %4 arguments appear for legacy reasons, and represent the driver name and the port name on systems running Windows 3.1. These parameters are not used on systems running Windows 95 or later. Some applications may search the registry for verb keys that are no longer used. For that purpose, those keys can be left in the registry with the addition of the LegacyDisable value to the verb’s key, which tells the system that the verb is not an actual verb, but exists solely for the purpose of backward compatibility. Use of the LegacyDisable value is shown here. The value only needs to be present; it can be of any value type (though REG_NONE is most appropriate) and does not require any data to be associated with it. If data is present, it is ignored.
HKEY_CLASSES_ROOT
Application
Shell
Open (Default) = &Open
LegacyDisable
Command (Default) = command line
Programmatic Identifiers
The Shell uses a programmatic identifier (PROGID) registry key to associate a file type with an application and to control the behavior of the association. The PROGID entries used for file associations exist in the registry under HKEY_CLASSES_ROOT.
- PROGID Elements Used by File Associations
- Using Versioned PROGIDs
- System Reserved PROGIDs and Extensions
The proper format of a PROGID key name is [Vendor or Application].[Component].[Version], separated by periods and with no spaces, as in Word.Document.6. The Version portion is optional but strongly recommended
A PROGID key should include the following elements.
- Default Value– Set the default value of the PROGID key to a friendly name for that PROGID, suitable to display to the user. The use of this value to hold the friendly name is depreciated by FriendlyTypeName on systems running Microsoft Windows 2000 or later. However, you should set this value for backward compatibility.
- EditFlags– Set this optional value using flags from the FILETYPEATTRIBUTEFLAGS enumeration. The EditFlags value controls some aspects of the Shell’s handling of the file types linked to this PROGID. You can also use the EditFlags value to limit how much the user can modify certain aspects of these file types using a file’s property sheet. The FILETYPEATTRIBUTEFLAGS values used for EditFlags are binary values designed so that you can combine multiple attributes into a single value as in a bitwise OR operation. This is a REG_DWORD or REG_BINARY value.
- FriendlyTypeName– Set this value to a friendly name for the PROGID, suitable to display to the user. For consistency, this string should contain the same value as the default value of the PROGID key. This value can be either a REG_SZ or REG_EXPAND_SZ string, but it must be formatted as an indirect string (a fully qualified file name and resource value preceded by the “@” symbol), for instance @%SystemRoot%\shell32.dll,-154.
- InfoTip– Set this value to a brief help message that the Shell displays for this PROGID. The InfoTip displays as the contents of a mouse-over dialog box. This value can be either a REG_SZ or REG_EXPAND_SZ string but, like FriendlyTypeName, it must be formatted as an indirect string.
- Curver– Set the default value of this sub key to the most current version of this PROGID.
- DefaultIcon– Set the default value of this sub key to the default icon that you want to display for file types associated with this PROGID. This value can be either a REG_SZ or REG_EXPAND_SZ string, but it must be provided as a fully qualified file name with its attendant resource value, for instance %SystemRoot%\shell32.dll,-154.
The following is an example of a file association PROGID key node.
HKEY_CLASSES_ROOT
Vendor.comp.1 (Default) = My Friendly Name
EditFlags [REG_DWORD] = 0x00000001
FriendlyTypeName [REG_EXPAND_SZ] = @%SystemRoot%\shell32.dll,-154
InfoTip [REG_EXPAND_SZ] = @%SystemRoot%\shell32.dll,-54
Curver (Default) = Vendor.comp.1
DefaultIcon (Default) = %SystemRoot%\shell32.dll,-1
A versioned PROGID is one whose version is indicated in its name. You typically do this by adding a period and the version number to the name. For example, Word.Document.6, Word.Document.8. These are versioned PROGIDs, with versions 6 and 8 respectively. You should always use versioned PROGIDs, even if there is only one version of the PROGID. This helps avoid conflicts and enables different versions of an application to coexist without the need to overwrite PROGIDs.
The system reserves the following PROGIDs.
- CD Audio
- DVD/DVDVideo
- Directory
- Folder
- Drive
Arbitrary File Types
An arbitrary file type is one that does not have an application associated with its file extension. A user can launch a file that has an arbitrary file type by double-clicking the file or choosing the Open command in the file’s shortcut menu. When this occurs, the Open With dialog box appears and the user must make an association (either temporary or permanent) for that file type.
Handling Arbitrary File Types
The most common use of file types is to associate a file extension with the application that opens files of the given type. The user typically double-clicks a file or selects Open from the file’s shortcut menu to open it. In some cases, however, a user might attempt to open a file whose type is not registered. When this occurs, the user is prompted by an Open With dialog box that asks what action to take with the file. The following figure shows a typical Open With dialog box for a text file using Microsoft Windows 2000. Notice that all registered applications appear by default.

Windows XP takes a slightly different approach. Rather than display every registered application in the list, Windows XP displays only applications commonly used to open the given file type. This way, the user is presented with a short list of likely choices. The following figure shows a typical Open With dialog box for a file using Windows XP

This dialog box enables the user to select the application from the list, or browse for an application that is not in the list. The user can also type a description for the file type and make his or her selection permanent. If the user decides to make the selection permanent, Windows XP registers the file and creates a permanent file association. If the user decides not to make the selection permanent, an entry is created in the registry that indicates a user has used this application to open this file type. Next time, the application appears in the Open With dialog box. Typically, the user chooses an appropriate application to open a file. However, the user might choose an application that cannot open the file.
How are arbitrary files opened?
Applications can respond to a request to open arbitrary files in three ways.
- Open only those file types that have a registered association with the application. If the user attempts to have the application open any other file class, the application returns an error. Applications of this type are typically designed to work only with certain proprietary file formats.
- Use the same procedure to open any file. Only return errors for those files that the application cannot open. This type of application is typically designed to work with a public file type, such as text.
- Have one set of procedures for opening files that have a registered association with the application. For all other files, provide a default opening procedure. This type of application is a hybrid of the first two classes; it has one or more proprietary formats that need special handling, but can also handle some public formats.
The third method is the most difficult to deal with because, if the application expects a proprietary file type, it might have problems opening an alternate file type. However, using a general-purpose routine to open all files the same way can be inefficient. Instead, with Windows 2000 and later, the Shell enables you to register normal file associations for your proprietary formats and provides a default procedure for arbitrary file types. When a user opens one the proprietary files, the file opens as specified by the file association. If a user attempts to open an arbitrary file type, the file opens as specified by the default procedure. Giving users the ability to define a default file opening procedure also provides users with two new helpful features.
- If the user uses the Open With dialog box to associate a file extension with an application, that choice always takes priority. Because user-customized file association attributes take precedence over all other file association attributes, applications that are installed later cannot take over the file association.
- File associations roam with the user within a domain. For example, if a user associates a program with .HTM files on his or her primary computer, when the user opens an .HTM file on a different computer in the same domain, Windows XP uses that program, if it is available.
The Open with Dialog Box and Application Keys
The Shell maintains two levels of Open With lists. The first level is a global applications list, which displays when the user attempts to open an unregistered file type. The second level tracks Open With applications for each file type and displays these in the Choose the program you want to use to open this file list for the appropriate file type.
For an application to appear in the Open With dialog box, it must have an application key in the registry. Application keys appear in HKEY_CLASSES_ROOT\Applications. The name of the key is the name of the executable file for the application. For example:
HKEY_CLASSES_ROOT
Applications
MyProgram.exe
Application keys have several attributes and sub keys that are used by file associations. The string values in this key require some special consideration in formatting. These formats are described as XSZ_RESOURCE and XSZ_MUI_STRING. XSZ_RESOURCE is a REG_SZ or REG_EXPAND_SZ that is formatted as”%SYSTEMROOT%\shell32.dll, -154″. XSZ_MUI_STRING is a REG_SZ or REG_EXPAND_SZ. If it refers to a resource, it formats it as”@%SYSTEMROOT%\shell32.dll, -154″. Otherwise, use it as it is.
The following are application key attributes.
- NoOpenWith- If a registry string with this value is present, this application is excluded from the Open With dialog box list. This value has no data associated with it.
- FriendlyAppName- This value is a friendly name for this application, suitable to display to the user. This value is formatted as an XSZ_MUI_STRING. The application’s friendly name may also be extracted from its executable file, but only if this value is absent.
- SupportedTypes- This key contains a list of file extensions (with the leading ‘.’) that indicates the types of files that this application can use. The supported extensions are listed as value names under this key. If this key is present, the list of extensions acts as a filter for the Choose the program you want to use to open this file list.
The following is the general form of an application key.
HKEY_CLASSES_ROOT
Applications
MyProgram.exe
NoOpenWith
SupportedTypes
.ex1= REG_NONE
.ex2= REG_NONE
.ex3= REG_NONE
Shell
Open
FriendlyAppName= Friendly Name
Shellex
There are two ways for an application to appear in the Open With section of a file type’s context menu. The first way is to add a sub key for the desired application in the OpenWithList key for the file type. There are two benefits to this method. First, since the OpenWithList key is a sub key of the file type, this method works only for registered file types. Second, the application that appears in this list must have an Application Key entry in HKEY_CLASSES_ROOT\Applications.
This method is most useful when you want an application to appear in a file type’s Open With menu when the file type is first registered. For example, if you want to have Notepad appear in the context menu of an .HTM file, use the following keys.
HKEY_CLASSES_ROOT
.HTM
OpenWithList
Notepad.exe
Additionally, Notepad needs to have the following application key entry.
HKEY_CLASSES_ROOT
Applications
Notepad.exe
In some cases, an application should not be used to open a file that is not associated with it. In these cases, it is useful to exclude an application from the Open With dialog box. To do this, add a registry string (REG_SZ) entry named NoOpenWith to the application’s sub key. For example, the following entry excludes MyProgram.exe from the Open With dialog box.
HKEY_CLASSES_ROOT
Applications
MyProgram.exe
NoOpenWith
What are Darwin Descriptors?
Following an MSI based installation, some registry keys appear garbled and do not match the registry keys in the installation package. These registry keys are known as Darwin Descriptors, and enable self repair for file associations, COM objects, and other resources.
Application resiliency is also provided by the Windows Installer through File Associations. Windows Installer file associations are defined using the same mechanism that standard file associations use, with one exception. An extra value is listed under the typical “shell\Open\Command” registry key. The extra value (also known as “command”) is where Windows Installer looks any time you double- click on a file from within the Windows shell. This cryptic looking string, referred to as a “Darwin Descriptor” is actually an encoded representation of a specific product, component and feature. If this extra value exists, Windows Installer will decode the data, and use it to perform checks against that product and component. If the component is found to be missing or corrupt, Windows Installer will launch a repair to restore the missing file or data, and finally launch the referenced application as normal, passing the appropriate command line options to it.

Best Practices for File Associations
The following are recommended best practices you should use when working with file associations.
- Don’t Copy File Associations from the Registry- It is not recommended that you copy existing file associations from the registry. This often leads to the propagation of poorly formed file associations. Instead, you should follow the steps outlined in File Association Sample Scenario.
- Avoid Hard-Coding Paths into the Registry Where Possible- Just as hard-coding paths into programs can cause problems, hard-coding paths into the registry can also lead to problems. Instead, you should use registry expansion strings (REG_EXPAND_SZ) to provide path independence where applicable. For example, instead of using this method:
HKEY_CLASSES_ROOT
MyVendor.MyProgram.1
DefaultIcon
(Default) = C:\WINNT\hta.exe,1
You should use this method:
HKEY_CLASSES_ROOT
MyVendor.MyProgram.1
DefaultIcon
(Default) = “%SYSTEMROOT%\hta.exe,1”
- Always Wrap Expanding Strings in Quotation Marks- Expanding strings can contain spaces when they expand. Because spaces are often interpreted as argument delimiters, they cause problems under certain circumstances. For example, a command to invoke MyProgram can be stored in the registry as:
%SYSTEMROOT%\MyProgram %1 %2
MyProgram expects that %1 is the full path to a file name, and %2 is a switch to indicate some action. If this command is executed with arguments C:\Program Files\My Documents\document.txt and /print, and assuming a SYSTEMROOT of C:\WINNT, it expands to:
C:\WINNT\MyProgram C:\Program Files\My Documents\document.txt /print
In this case, MyProgram interprets that the first argument is C:\Program, and the second argument is Files\My, which is not the intended behavior. The arguments are interpreted correctly, however, regardless of whether they contain spaces, if the expanding strings are wrapped in quotation marks as follows:
“%SYSTEMROOT%\MyProgram” “%1” “%2”
- Don’t Confuse Autoplay/Autorun with File Associations- File Associations are similar to Autoplay/Autorun in some ways. However, Autoplay/Autorun offers separate and distinct facilities from those provided by file associations.
- Don’t Confuse the Internet Explorer MIME Database with File Associations- File Associations are similar to the Microsoft Internet Explorer Multipurpose Internet Mail Extensions (MIME) database, in that file types can (and should) include a MIME type definition. However, the Internet ExplorerMIME database is separate and distinct from file associations.
- Use Properly Formed and Versioned ProgIDs- Always use versioned ProgIDs, even if there is only one version of the ProgID. Versioned ProgIDs help to avoid ProgID conflicts and overwrites. They also enable different versions of an application to co-exist.
- Define Both Long and Short File Name Extensions- Defining long file name extensions offers the following advantages:
- The limited lengths of short extensions make them prone to extension collisions. An extension collision occurs when the same extension is used to classify multiple file types. Using long extensions significantly decreases the chances of a collision.
- Short file names tend to be somewhat cryptic. Long extensions tend to be more meaningful by allowing you to embed additional information in the extension.
- Register New File Types in the IANA MIME Database- The Internet Assigned Numbers Authority (IANA) keeps a public database of registered MIME types. When defining a new public file type, it is recommended that you also define a MIME type for the file type and register this type with the IANA. There is no cost for registration.
File Association Sample Scenario
In the following example, a hypothetical software development company called Litware, Inc. creates a new audio player called LitwarePlayer. Litware wants to design a file association between LitwarePlayer and its primary file type, which uses a newly developed audio format that enables an entire audio CD to be stored in less than 10 kilobytes of memory with no loss of quality. The company should take the following steps.
- Decide if the new file type should be treated as public or private. This new file type is a media type. Because users exchange media files across various platforms and there might be other applications that need to read the LitwarePlayer format, a public file type is the most appropriate.
- Determine if this file type is already defined. Check the Internet Assigned Numbers Authority (IANA) Multipurpose Internet Mail Extensions (MIME) database, and other public file type databases on the Internet to determine that no comparable file type has been defined. Because this is a new file format, you need to define a new file.
- Define long and short extensions for the new file type. The developers choose the first short and long extensions .op and .op-ltw-audio, incorporating their vendor abbreviation and a hint about what the file contains into the long extension. However, additional research determines that the extension .op is already in use for another file type. To avoid contention, Litware chooses an alternate extension, .OPA, which further research determines is not being used. The long extension is then adjusted to .OPA-ltw-audio for consistency.
- Define a MIME type for the file type and register with the IANA. Litware defines the new MIME type as audio/LitwarePlayer.1 and prepares a MIME type application, following the guidelines laid out in Request for Comments (RFC) numbers 2045, 2046, 2047, and 2048. They then submit the application to the IANA, who adds the new file type to the database of registered MIME types.
- Determine if a ProgID exists for the file type. Because this is a new file type, no ProgID exists for it. Litware sets about designing a new ProgID for LitwarePlayer. They decide on the friendly name “LitwarePlayer Audio Player” (which is stored as a resource in the LitwarePlayer.exe file) and design a default icon to use for files associated with LitwarePlayer (also stored in LitwarePlayer.exe). Because LitwarePlayer is a new application, this is a version 1 ProgID.
- Register the ProgID. When LitwarePlayer is installed, the installation program creates the following ProgID entry in the registry.
HKEY_CLASSES_ROOT
Litware.LitwarePlayer.1
(Default) = LitwarePlayer Audio Player
FriendlyTypeName= @LitwarePlayer, -120
CurVer
(Default) = Litware.LitwarePlayer.1
DefaultIcon
(Default) = LitwarePlayer, -142
shell
play
command
(Default) = “%ProgramFiles%\LitwarePlayer\LitwarePlayer.exe” “%1”
In the command key, %1 is passed as the path to the file to play.
- Register the long and short extensions for the file type. When LitwarePlayer is installed, the installation program creates the following entries in the registry for its custom file type extensions.
HKEY_CLASSES_ROOT
.OPA
(Default) = Litware.LitwarePlayer.1
PerceivedType= Audio
Content Type= audio/LitwarePlayer
.OPA-vwi-audio
(Default) = Litware.LitwarePlayer.1
PerceivedType= Audio
Content Type= audio/LitwarePlayer