Easy shell extensions

Posted on 12 Sep 2002 at 16:37

Shell extensions are one of the more esoteric aspects of Windows programming. You're probably aware that Windows Explorer is very versatile and can support a number of types of shell extension or plug-in. Thanks to Microsoft's excessive (and, in my opinion, unwarranted) fondness for the COM object model, shell extensions have to be written as small COM servers - DLLs that need to be registered with the system before they can be used. Once that's done, Explorer will transparently call your extensions as required.

As an example of what can be done with shell extensions, I've a small utility called Merlin installed on my main development machine. The company Merlin is, sadly, now defunct, but I still find the program useful. You can find out more about Merlin at http:// ourworld.compuserve.com/ homepages/mikes
From Windows Explorer, with Merlin installed, I can right-click on a Pascal source file (extension PAS) and see a context menu appear that contains the item Funcs and Procs. Clicking this item brings up a small dialog that lists all the functions and procedures defined within the selected source file. Similarly, right-clicking on an EXE file or a Delphi package file (extension BPL or DPL) produces a couple more context-menu items - Executable Viewer and Resource Explorer.
The first runs a small applet that lets me examine the DLLs required by a particular program, discover which Delphi units have been linked into the application, and so on. The second launches the wondrous Merlin Resource Explorer, which allows me to examine and extract resources from an executable file.
In the screen shot above, I'm looking at the coreide60.bpl file, which contains the bulk of the Delphi IDE implementation. Since the IDE is itself written in Delphi, all the various IDE windows are standard Delphi forms; in this instance, I'm eyeballing the streamable form data for the Property Inspector window itself. Although five years old, Merlin is still a great utility for poking around inside other people's executables, all from the comfort of a Windows Explorer window.
Of course, the foregoing is all seen from a software developer's perspective. More typically, an application developer will want, perhaps, to use the shell extension mechanism to simplify the end user's interaction with their custom document types. For example, let's suppose you're writing a to-do list application. Although your end users will interact with the document files primarily through your main application, it's convenient to provide shortcuts that enable them to recognise different document types without having to fire up the main program.
Suppose you want to-do items that are overdue to be associated with an eye-catching 'you're-about-to-be-fired' icon, while normal to-do items use a more innocuous low-priority icon. Ordinarily, a requirement like this would be difficult to achieve. Why? Because in the normal scheme of things you can only associate one icon with one particular file extension in the Windows Registry, and to display two icons you'd need to have two document types and file extensions defined. When you create your to-do item, it will initially be associated with the low-priority icon, so how can the overdue item be automatically associated with the high-priority icon if the user doesn't run your software again for a couple of weeks? Tricky, eh?
This is the sort of situation where shell extensions really come into their own. By creating a specific type of shell extension called an icon handler, you get complete control over the icon that's used to display each of your documents, and this control is applied on a per-file basis. Thus, even if all your documents have the same file extension (let's called it TODO for argument's sake), different files can be assigned different icons as appropriate.
Normally, creating shell extensions is a pain. You have to fool around with COM interfaces and all those weird and wonderful data structures and types that Microsoft developed specifically to torture any Windows developer arrogant enough to try to augment the already perfect functionality of Windows Explorer. If you've never played around with this stuff - and you have a strong enough stomach - I invite you to look at the shell extension programming information at http://msdn.microsoft.com. This is truly the API from hell.