What's the best way for an app on Windows to assocaite itself with a particular file type, such as .xml, .txt, etc., but share that association with other apps that support that extension?

Question

If I create a new app, and associate with, say, the .xml file extension on a particular computer, when someone double clicks the .xml file, it will launch my app and pass the file as parameter. But Windows seems to know what other files have the ability to work with that file type. How is that set up?

Also, when I save a Microsoft Word file as an .xml file, then later double-click on the file, it will launch Microsoft Word, even though the .xml file type is associated with something else, such as Internet Explorer. Seems like there may be a stub associated with .xml file type which when invoked looks at the content and launches the appropriate app.

Is there a Windows API, or some kind of a standard way to do that?

What I wanted to create an app to do exactly what Word is doing -- i.e. save file in the .xml format, but when double-clicked, launches the my app instead of Internet Explorer.

Answer 1

In Windows Explorer click on Tools->Folder Options->File Types. By clicking on "New" or "Advanced" you can create/change your own application associations with various file types that will appear when you right click on the file.

EDIT: I don't know if there's a stub that redirects specific files. You can check My Computer\HKEY_CLASSES_ROOT in the registry and see what it's putting in there.

Answer 2

The following article cover this very nicely.

Answer 3

Well, all file associations are stored in the registry. There's an article, "Understanding MS Windows File Associations" that may help.

Beyond that, there are many ways to create file associations programmatically. Though most often this is done in the installer. For example, my favorite installation system NSIS has a macro to handle this: http://nsis.sourceforge.net/FileAssoc

But then there's the challenge of setting a default program to open a certain file type. I don't know what language or install system you're planning on using to do this but it appears that question is answered here for NSIS. Surely Microsoft also has documentation for their way of doing this with Windows Installer. But as you can probably guess, I'm more of an NSIS guy. ;)

Answer 4

Sorry guys, I guess I wasn't clear about my question. I'm not asking about how files are associated with extensions. I understand that. My question has to do with multiple applications being associated with the same extension, and how is it possible that when when I double click on an .XML file, it launches Microsoft Word if that .XML file was created in Word, and otherwise it opens it in Internet Explorer.

I looked in the .xml file produced by word, and located the keyword which let me to this article: http://blogs.msdn.com/brian%5Fjones/archive/2005/07/07/436647.aspx which discuss the msoxev.dll that's installed by Microsoft Office. It's a component that sniffs the .xml file and looks for that Processing Instruction at the top of the .xml that looks like this: based on that it launches word.

There's a similar thing with .zip files that contain a file called mimetype.

So it looks like there really isn't an OS standard. Microsoft Office does something specific.

Answer 5

Mechanism for opening Office .xml Documents

For Word documents saved in XML and having an .xml extensions Microsoft implemented a special handler to open these files in the corresponding application (This mechanism is not only used for Word documents, but also Excel spreadsheets, InfoPath forms and some other formats).

If you check the Registry you will see that the file type for files with a .xml extension is set to xmlfile:

HKEY_CLASSES_ROOT\.xml (Default) = "xmlfile"

The command that is executed when this file type is opened is specified under

HKEY_CLASSES_ROOT\xmlfile\shell\open\command = ""C:\Program Files\Common Files\Microsoft Shared\OFFICE12\MSOXMLED.EXE" /verb open "%1""

So when an XML file is double-clicked in Explorer, Windows will launch MSOXMLED.EXE. This application is now looking inside the XML file and searches for an XML processing instruction. This processing instruction named mso-application can specify a ProgId:

<?mso-application progid="Word.Document"?>

If this processing instruction is found and the ProgId is one of the supported values MSOXMLED.EXE searches the Registry for the open command specified for that ProgId. For Word.Document there is actually another redirect to Word.Document12 (if Office 2007 is installed) using the CurVer subkey of Word.Document, so we end up with:

HKEY_CLASSES_ROOT\Word.Document.12\shell\Open\command = ""C:\Program Files\Microsoft Office\Office12\WINWORD.EXE" /n /dde"

So finally MSOXMLED.EXE will start the appropriate Office application or launch the default XML application which is specified under

HKEY_CLASSES_ROOT\XEV.GenericApp\shell\open\command

You can actually try this out by calling MSOXMLED.EXE from the command line:

MSOXMLED.EXE /verb OPEN "SampleWordMLDocument.xml"

If you would like to implement the same behavior you would have to implement a handler like MSOXMLED.EXE which looks inside the file for a pre-defined processing instruction and then routes the document to the appropriate application.

Icon handling

Above we looked at the way how document opening and editing is handled. Another mechanism is responsible for displaying a specific icon depending on the processing instruction inside the XML document: an icon handler.

Icon handlers are a type of Explorer Shell extensions which are in-process COM objects which can be associated with certain file types. The one used for XML files is specified in the Registry under

HKEY_CLASSES_ROOT\xmlfile\ShellEx\IconHandler = "{AB968F1E-E20B-403A-9EB8-72EB0EB6797E}"

This GUID is refering to the MSOXEV.dll which will - similarly to MSOXMLEX.EXE inspect the XML file for the ProgId and then provide the correct icon.

As all this is a rather complicated mechanism you should consider carefully if you want to go this way. In my opinion it is far simpler to register a new unique file extension. It is also limited as it will only work with file types that allow you to include some custom information (as the ProgId) in the header of file.

Microsoft does not use this method anymore and uses file extensions instead for their new OpenXML formats (see Why do Office ".xml" files behave differently from other ".xml" files?).