Too difficult: Microsoft difficult on purpose

Googling for a solution to Windows Installer custom action scripts starting executables which raise the Vista elevation prompt in the background I stumbled over Microsoft saying this:

For added security, the elevation prompt is designed to be difficult to script.

Sorry. I have a  blackout here. Someone please remind me why Microsoft takes extra effort to make something more complicated rather than as easy as possible? I can understand this notion in certain areas, perhaps the elevation prompt is one of them, but the casual way to admit that they invest effort into making stuff more complicated has an extremely bitter taste to it.

(And Microsoft calls that “security”? Oh dear.)

Too difficult: Shell context menus for files and folders

Most of us have gotten used to the context menus available in Windows Explorer on folders, files and folder backgrounds, the so called shell context menus.

In third party applications displaying these shell context menus can make a lot of sense, for example in alternative file managers such as FreeCommander, Windows Commander, etc. because it allows the user to use the functionality of tools that integrate into Windows Explorer, such as TortoiseSVN and others, directly in the third party application. A good example of this is the Eclipse ContextMenuPlugin: http://www.geocities.com/richard_hoefter/ContextMenuPlugin/

Because of this usefulness, the code for displaying shell context menus would ideally be very simple. All that would be needed would be the list of files and folders that the context menu should be displayed for and wether it should be the normal context menu or the folder background context menu.

And here is what Microsoft expects: http://www.codeproject.com/KB/shell/shellcontextmenu.aspx

This (partly broken) project demonstrates showing the (item) shell context menu – in ca. 380 lines of code (I didn’t count a few comfort methods) of relatively loaded C++ code using COM – and it doesn’t even do it correctly, despite it’s goal to provide a complete, ready to use drop-in solution for this.

The Eclipse ContextMenuPlugin author took the codeproject code and seemingly fixed it.

Both solutions only display the context menu for folders/files, not for folder backgrounds, however. Displaying the context menu for folder backgrounds I have not found any explicit documentation for. A support request to Microsoft about this ended up in generous hand waving in the direction of some menu related APIs.

Here is Microsoft’s take on showing the context menu for single files or folders only (!): http://www.microsoft.com/msj/0497/wicked/wicked0497.aspx

Too difficult: Windows Explorer Namespace Extensions

As I understand it, in Windows Explorer even the part that we use to browse around the contents of the C: drive is a namespace extension.

Namespace extensions are used by various vendors to display information related to their solution. web.de uses them to display the contents of the user’s WebDAV webspace at web.de. Mobile phone vendors can use them to display the contacts in mobile phones.

Filesharing solutions such as groove can use them to display the shared files in a way familiar to the user.

As we can see, namespace extensions have a wide range of applications, a lot of innovation around them seems possible.

Despite their usefulness and wide range of possible applications, developing namespace extensions is not trivial. This is due to the following points:

• They must be written in C++ for practical reasons (Delphi, Visual Basic and others are impractical as using them is not mainstream, so you have nowhere to go when stuck, and you’ll hardly find solutions for doing things that are common to do in C++, if only to access a certain Windows API function; writing namespace extensions in .NET is not a technically sound option, it is unstable by definition when two shell extensions demand different versions of the .NET runtime libraries)
• To write them Microsoft COM know-how is required
• To write them know-how about foreign, arcane concepts are necessary, such as PIDLs
• If you screw up (and unfortunately C++ makes that very easy), Windows Explorer crashes or becomes unusable

My current employer outsourced development of a custom namespace extension that displays the contents of a folder in it. The goal was to mimic Windows Explorer’s look & feel and functionality as closely as possible. The outsourcing partner has developed a helper framework for development of namespace extensions and has gathered a lot of C++ and Windows system programming know-how over the years.

Sounds like a safe bet? Nope. The partner had a lot of trouble preventing the namespace extension from plain crashing on Windows Vista. After several weeks and numerous updates to his core product and our customised solution based on it it even turned out that the problem existed on Windows XP, it just didn’t surface as easily yet. Eventually, he managed to fix the crashes. He has done a good job and in the process improved functionality and stability of his own product, so apart of the monetary benefit of working for us, he can walk away with a better product now, and a few new items in his know-how bag.

While the outcome is satisfactory, the process to get there raises a few questions:

• Why does it take a professional software product developer weeks to fix crashes in his core namespace extension?
• Why doesn’t Microsoft offer a way to write namespace extensions with something more productive than C++?
• Why doesn’t Microsoft offer a way to write namespace extensions with scripting languages?

Microsoft hinders innovation by making writing namespace extensions extremely hard, and by not offering to write namespace extensions with scripting languages.