Too difficult (for Microsoft): Windows SpecialFolders/Shell Folders consistency & documentation

In WSH you can retrieve the path of special folders via the WScript.Shell.SpecialFolders Property. Similar APIs exist for .NET based languages.

Unfortunately neither is the documentation of the existing special folders complete, nor is the list of special folders available via the SpecialFolders property complete.

Some of the special folders are available as environment variables. Unfortunately only few though.

And also, still unfortunately, the names for the special folders differ in WScript.Shell.SpecialFolders and the .NET API.

Also, unfortunately the Enumerator in WSH JScript does not offer a way to retrieve the name/key of the value. So while 16 names are documented, the enumerator/the SpecialFolders property gives access to 18 values at the moment. But you have to guess the names of the undocumented two names.

Is this Microsoft’s way to say “Gee, forget about these APIs, go use the native Windows API dude, this other stuff is nothing we care about much, isn’t it obvious?”. This would fit into the “keep pushing C++ for any solution that tries to do something creative” school of thought that Microsoft so happily sticks to (shell extensions in .NET? Definitely not a good idea nor supported…)

Sad that MS still expects us to write software which handles the difference between local and roaming application data while on the other hand being so lax about documentation and consistency and availability of required information.

Too difficult: Alternative GUI Shells for Windows

Alternative GUI shells can be developed for Windows, their usefulness however would be severely limited if they couldn’t incorporate extensions written for Windows’ default GUI shell, Windows Explorer.

I only know of one GUI shell replacement for Windows which fully supports the standard shell context menus for files, folders and multiple selections of files and folders (including third party entries into these context menus, like the ones from TortoiseSVN), and folder background context menus (right click on a folder’s background), xplorer² (XYplorer looks like an xplorer² clone, but it seems it isn’t. It supports icon overlays, but not namespaces, yet). Total Commander (and/or FreeCommander) might also offer this functionality, but I have not yet seen this functionality in it. (However I do not know wether these two tools display third party namespace extensions like their are used by web.de and others.)

The problem with writing a GUI shell replacement is not only the size of the task. You have to implement drag and drop, efficient file copy, and a lot of other things, but you also have to support shell extensions that display custom entries in context menus, icon overlays, namespaces, etc.

As if that wouldn’t be large enough a job, you also have to know your way around C++ and COM, because that is what shell extensions are (typically) written in, and those aren’t trivial, at least not in my opinion.

Because this is how things are, it takes people with considerable knowledge to write a replacement shell.

Would shell extensions be implemented by simpler basic mechanisms and languages than C++ and COM even application developers might manage the task.

Speaking of which, which standards for GUI shell extensions exist on other platforms? If any, how complex is the task of simply implementing a shell extension for example for displaying a few custom icon overlays (does the shell support icon overlays in the first place?) or a namespace (like Windows Explorer does)? Shouldn’t the Unix/Linux world define a few simple mechanisms/standards for things like this so there is at least a remote chance to write a GUI shell extension like TortoiseSVN that can be used in any full fledged GUI shell for Unix/Linux?

(PS: Possibly related: 15 Windows Explorer alternatives compared and reviewed)

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.