What Happened to the File Types Dialog?
Back in the old days of Windows 95, there was a page in the Folder Options property sheet called File Types that listed all the registered file types and their associated verbs. What ever happened to that guy?
Answer: The world changed and the information it displayed wasn’t really accurate any more.
Actually, the information it displayed wasn’t even entirely accurate even at the time it was written.
The File Types dialog supported only so-called static registrations; that is, verbs whose execution consists of either running a command line or executing a DDE command. In Windows 3.1, those were pretty much the only two ways of registering a verb for a file type, so the File Types dialog was at least current for a brief shining moment before the Windows 95 shell namespace showed up and added a whole new set of ways for doing things. For example, verbs added via shell context menu handlers (IContextMenu) were not displayed by the File Types dialog. You could see this if you went to view the verbs available for Drive: The only thing that showed up in the dialog was find. The Format and Copy Disk verbs were nowhere to be seen because they were provided programmatically by COM objects. (In particular, because those commands applied only to certain types of drives.)
Now, the File Types dialog is in a bit of a pickle. The context menu verbs aren’t actually stored anywhere; they’re generated at runtime by code inside the shell extension. There’s no way to ask a context menu extension, “Please give me a list of all the verbs you might add to an item.” Well, for one thing, the context menu extension might not know, either; some context menu extensions generate verbs based on the name of the file the user clicked on. Shortcuts don’t have a specific list of verbs, or even a pattern for verbs; they merely expose verbs that belong to some other file type. (For example, when you click on a shortcut to a text file, the context menu shows the text file verbs. If the shortcut context menu handler had to produce a list of all potential verbs, it would have to list all verbs from all file types!)
Even if there were a way to obtain the complete list of verbs associated with a file type, the interface for adding or modifying them would be decidedly unhelpful. Because shell extensions are COM objects, the registration is done by associating a GUID with the file type. Yeah, like you expect users are going to type in 32 hex digits with assorted punctuation to create a context menu verb. And that’s just registering the verb; they also have to create a DLL that implements the IContextMenu interface. Good luck writing the online help for that.
OK, so maybe it was a good idea that shell namespace extensions don’t show up in the File Types dialog. But what about that DDE stuff? DDE is short for Dynamic Data Exchange, but the name doesn’t really clarify anything. Dynamic Data Exchange is a data transfer mechanism developed in the days of Windows 3.0 that permits two programs to exchange data or send commands to each other. Establishing so-called DDE conversations requires a number of pieces of information, which the File Types dialog describes in cryptic terms such as DDE Message, Application (which, despite what the name suggests, is not the name of the executable that you want to run), DDE Application Not Running and Topic. None of these terms mean anything to a normal human being; they may as well have been called Magic 1 through Magic 4.
DDE is an ancient technology designed for the days of cooperative multi-tasking, back when you didn’t have to worry about applications that stopped processing messages, because the fact that your code was running meant that everybody else was processing messages. But with the transition to 32-bit Windows and pre-emptive multi-tasking, this assumption no longer held true. In particular, an application that stops processing messages prevents message broadcasts from completing, which is a problem for DDE, because the very first step in establishing a DDE conversation is broadcasting a message looking for a window that is willing to talk to you. One unresponsive program prevents DDE-based documents from opening. For this reason, DDE is no longer a recommended method for registering shell verbs.
The straw that broke the back of the File Types dialog was the introduction of User Account Control (UAC) in Windows Vista. Because file type registrations are global, modifying them required administrative privileges, which are disabled by default. As a result, the File Types dialog would have required elevation in order to do its job. Given that the File Types dialog was already known to be incomplete and unusable by normal human beings, and that applications generally did a good job of registering their file types anyway, the extra work to make the File Types dialog support elevation didn’t seem worth it. The functionality the File Types dialog used to provide is largely duplicated by the Open With menu and the new Associate a file type or protocol with a specific program control panel, both of which are far easier to use than typing in magic words into four cryptically named edit boxes.
But if you really want to create your file types the old-fashioned way, you can still run RegEdit. I hope you remember how to set those magic words.
Raymond Chen’s Web site, The Old New Thing, and identically titled book (Addison-Wesley, 2007) deal with Windows history, Win32 programming, and starting sentences with a question mark.