Flying back to Redmond, I jot down some of the key things I consistently heard from developers, in no particular order:
- "We want more/better command module extensibility." The term "command module" here refers to that toolbar that goes across the top of the Explorer view and replaces the "folder tasks" area in XP.
In the current POR, the command module for Windows Vista actually will have a limited extensibility model, but some of the feedback that I received makes me think we’re not going far enough. Let me explain. In the Explorer architecture, the shell folder object being viewed tells the command module object which commands to display via an interface to be released in Beta-2. So a third-party could come along with its own shell namespace extension and then have complete control over the commands displayed when viewing that shell folder.
However, there is no way currently to extend the commands displayed by other shell folders. In particular, the most compelling shell folder you would want to party on would be the shell-folder-over-filesystem, or what shell developers call "file folder". It would be great, for example, for a third-party photo application to add commands like "remove red-eye".
Providing the correct extensibility model that we will want to live with for the next decade or more is a very challenging problem, however: How do we deal with competing and conflicting registration? How can we make it less attractive for unscrupulous ISV’s to spam this very valuable screen real-estate? So I think its understandable that we’ve been reluctant to commit to solving this extensibility problem in the most general way, but on the other hand there could be a tremendous amount of end-user value-add to enabling some better extensibility story in this space.
It’s much more likely IMHO that instead individual command implementations will provide their own extensibility points. Imagine (for example) the "Show slideshow" command allowing third-party slideshow viewers, etc.
- "We want to be able to write Explorer extensions in managed code." This is complicated. The short answer is "you can", the medium-sized answer is "don’t do it!" and the long answer is "you can, if you try really hard".
The API for Windows Explorer consists of two major chunks. First is the set of reusable functionality that is provided for use in your own applications. Examples of this would be the Common File Dialog or the soon-to-be-documented ExplorerBrowser control, which indeed let you host an entire explorer "instance" inside your application. The second set of API consists of extensibility points which you can install in order to extend or customize the behavior of explorer in various ways. Examples of this include context menus, namespace extensions, property and tooltip handlers, etc.
There is no technical or philosophical reason that I know of why you can’t consume the first set of API from managed code, and indeed WinFx has several places where shell functionality is called, like SHGetFolderPath, GetSaveFileName, etc.
No, it’s that second set of API, the shell extensions, which are tricky. I wasn’t able to attend his talk, but I understand that the very articulate Jim Miller gave a talk about this very subject. Briefly, the problem is rooted in the fact that only one CLR can run in a process and, while CLRs are tested for backward compatibility, they are not of course guaranteed to be forward-compatible. So now imagine that your managed shell extension is loaded in some third-party process that is already locked-back to an older version of the CLR than what you targeted. You clearly don’t want this to happen.
My best guess is the explorer.exe process itself will avoid this issue by shipping with a startup call to the EE which tells it to always load the latest CLR version, but of course we can’t control other people’s processes and by the time they call that first set of APIs to, say host the common file dialog, then its too late to ensure a later version of the CLR than what’s already loaded.
One option that I hesitate to mention because its really quite difficult – much more so than it probably sounds – is to implement your extension point in managed code but register it such that it gets instantiated out-of-process. There are a number of tricks that you can play, depending on circumstances like the structure of your underlying data source, to mitigate the performance problems inherent in the chatty cross-process remoting that you would get with such an approach. An example of this would be a small native-side proxy which has in-process caching of your data and services the chatty calls, and then behind-the-scenes does more "chunky" calls back to the data source.
- "We want a better migration path to Windows Vista Common File Dialog". Windows Vista is deprecating the old common file dialog API in favor of a long-overdue COM API complete with callback sink objects, the ability to do metadata-stamping (and therefore the ability for the user to save into a virtual folder!), the ability to return item object that are part of the extended shell namespace – not just the file system, etc. It also includes a much more formal declarative customization model and removes support for the old-style template-driven customization.
I sincerely believe that the direction this new API takes is goodness, since it enables a lot of really cool end-user features, but some feedback I’ve heard is that perhaps it asks ISVs to bite off a little more than they’re willing to chew for this first release. Under the current plan, ISVs are faced with a dilemma: either don’t support the new API and therefore deliver a more-limited-then-my-competitor’s-application experience, or support the new API through two vastly-divergent code paths: one for downlevel and the other for Windows Vista.
One thing that might be possible, for example, is to plumb parts of the new API through the old API – thus allowing some of the features like saving to virtual folders, but degrading gracefully in a downlevel experience.
- "We want Microsoft to provide the forum for community schema coordination." In my PRS310 talk I spoke about two different types of properties: those provided by the system and those provided by ISVs. The system ones have the naming convention System.Groupname.PropertyName like System.Media.FNumber, and the ISV properties have the form ISVName.ApplicationName.PropertyName.
The problem is that this naming convention implies no coordination among ISV schema since each application gets its own namespace of properties. Will experiences with heterogeneous data sets therefore be suboptimal for like documents that would otherwise share common non-system properties? This question was asked in a much more understandable way by someone in the audience: "will two different CAD document types created by two different companies ever be able to share common non-system but CAD-specific properties?" Clearly, in order to pull this off you need some consensus on the schema, and the ask here is for Microsoft to set the table at which others can sit down and negotiate schema. Perhaps we can bring them drinks. I mean, Microsoft doesn’t necessarily have to be the moderator of such a community forum, but could at least provide the infrastructure for the community to make decisions on its own. Maybe even, as a coworker suggested, ratification by the community of schema could result in that schema shipping in the next update or version of Windows, or at least the universal search engine redist.
- "We would be interested in being able to host the reading pane in our own applications." This one is pretty self-explanatory; I was just surprised that I heard this piece of feedback from several people independently.
