Windows Shell Architecture

Why yes, I have tried to write some shell extensions.  Would have been a lot easier if all of the interfaces were documented and I didn't have to resort to disassembling the stock implementations.

Since I'm on the topic of undocumented COM interfaces, it's worth mentioning that I very recently had to pull the same tricks to get a DirectShow source filter to work correctly with WMP. 

What is so hard about documenting the interfaces?  Is it some zany attempt at a competitive advantage, or is it just laziness?

Great conversation!

Does the download for this video work? Keeps dying after less than a meg for me. I tried downloading other older videos, and they're coming down fine...

Edit: Have tried it on 2 computers, same thing...

The Complete Idiot's Guide to Shell Extensions

The background noise in the video made it hard to listen and I am not quite sure whether this was answered or not:

Why could not the current shell be made a legacy option for those who have extensions that require it and for the rest of the world offer a WinFX based shell/desktop experience and extensibility.

I expect that Vista "R2" will offer optional (and in future the default) explorer/shell/desktop that is fully managed and if user needs to use legacy apps, the Hypervisor thing could be used to run an isolated "legacy shell".

I stopped watching after 60 seconds. I know why you don-t want extra mics - but know you know why I will not watch these either

Nice video, guys!

Yup, there's a lot of background noise, so it's hard to fully understand what they're saying, especially for non-native English speakers.

Keep up the good work.

yep, the background noise is a problem this time. i think the decision not to use extra microphones is a good one and things should stay that way. i 'd like to suggest, however, to add a post production step i.e. add some kind of software audio noise reduction filter (i'm sure you could find something like that around campus) and plug it into your workflow. that'd be a rewarding project for all of us.

content has been as fine as it's always the case (especiall in Going Deep).  sometimes it's good to hear that not all folks jump on the .net wagon as their existing solution does the job well. in this case it 's clear that with people wanting to extend the shell with managed code the time to throw the clr switch is near (yes, i know it's not that easy). just good to hear that people are still productive with native code (even if it's plain C), too. (looking forward to the native c++ videos on c9

cheers,
martin

Charles wrote:

We really need to get a mic to put on the table for interviews like this. And we will.

Yes, please. It's sad to see when people put effort into doing these interviews and the result is not as good as it could be because of such an easy to solve problem.

Charles wrote:

If you ... crank the volume in the player and on your system, you will be able to hear everything just fine.

Obviously that will just make the noise louder.

A better action (which should have been done by the publisher of the video when he noticed the noise) is to open the Graphic Equalizer and crank the 125 and 250 hz sliders all way down.


Though if I should take a guess, graphic equalizer can only found in the WMP, not the Movie Maker, right? The "WMP Way" though would be to click the Help in WMP, click "Troubleshoot / This video has constant noise" and let WMP work out the noise frequencies and cancel them out by analyzing the data in the buffer before playing it.

It could be that your system (speakers) attenuate those frequencies or that mine pronounces them, or both.

jmazner wrote:

Sparky, I don't have any experience myself with the history of shell SDK documentation, but I think there are explanations for quality of SDK beyond the two you propose (based on what I saw developing parts of the Sharepoint Portal 1.0 programmability model)

It all comes down to resources.  Every team has finite resources, and Microsoft is no different from any other company -- you can't just assume that you can magically double the size of a team overnight to cover all the work you'd ideally like to do.

Even with a court mandate, shell documentation is still minimalistic, missing important information, and in some cases downright incorrect.  With the DOJ settlement, a number of new shell interfaces and functions were "documented."  But this documentation is essentially useless: it basically amounts to function signatures, and leaves any idea of how to use it up to the developers' imaginations.

The shell is very powerful and holds a lot of potential for great integration with other apps.  But it means nothing if developers can't use it effectively.

PatriotB wrote:

With the DOJ settlement, a number of new shell interfaces and functions were "documented."  But this documentation is essentially useless: it basically amounts to function signatures, and leaves any idea of how to use it up to the developers' imaginations.

Function signatures and/or interface definitions would have been immensely helpful. Looking over my notes on shell extensions, I see that some of the interfaces that were undocumented at the time (around 2001) are now documented. But the interface "abcb3a00-1b2b-11cf-a49f-444553540000" still isn't documented at all. It has something to do with IShellFolder and/or IPersistFolder.

The DirectShow stuff I've done recently uncovered an interface "94bc0598-c3d2-11d3-bedf-00c04f612986" that is only mentioned on the web in a post where someone else ran into it previously. There is no documentation of any kind.

Why is it that I can sometimes crash explorer.exe when I double click on an MPEG? I'd then have to manually "run" explorer.exe to get the shell back.

PS, could've been a compelling interview at the time, but it didn't make it across the wire to us, I think. I was very hard to hear, and I don't just mean audio level. Cranking it up just gives louder noise. The sound was very choppy -- and the one gentleman never rises above a whisper. Talking about "emotional software", this was an annoying video.

I don't know to whom should I attribute blame, the shell guys or the BCL guys but one of the things that ticked me off (this was in the .net1.x timeframe, did something change since then?) when I tried to create a explorer type application was the inexistence of a nice wrapper to the  SHGetFileInfo, SHGetImageList and related methods so that we could have some sort of a dynamic image list that we can associate to our Controls. Also as ImageList was sealed it was very difficult to extend it and the closest thing I found to enable this kind of capability was this library but it had the drawback that once you use it you can't add custom images to it (at least I didn't understand if its possible, my c++ foo is not that good). So the question is, will you guys give us a nice managed wrapper to this kind of functionallity (both dynamic access to icon images and extensibility with custom icons)?
Second thing I wanted to ask, will the limit of 14 overlay icons exist in Vista (I hope not, applications like TortoiseSVN are hitting that limit already)?

sparky wrote:

PatriotB wrote: With the DOJ settlement, a number of new shell interfaces and functions were "documented."  But this documentation is essentially useless: it basically amounts to function signatures, and leaves any idea of how to use it up to the developers' imaginations.

Function signatures and/or interface definitions would have been immensely helpful. Looking over my notes on shell extensions, I see that some of the interfaces that were undocumented at the time (around 2001) are now documented. But the interface "abcb3a00-1b2b-11cf-a49f-444553540000" still isn't documented at all. It has something to do with IShellFolder and/or IPersistFolder.

The DirectShow stuff I've done recently uncovered an interface "94bc0598-c3d2-11d3-bedf-00c04f612986" that is only mentioned on the web in a post where someone else ran into it previously. There is no documentation of any kind.

Maybe those interfaces are strictly for internal use.  I did a lot of COM library programming in the 90's and we used plenty of private interfaces, even on objects that were publicly available to client code via public interfaces.  Sure, if a client happened to pass one of our private GUIDs to a QueryInterface call on one of our objects, then the client would receive a pointer to the object's corresponding private interface, but that doesn't mean that we meant for the client to be able to use that interface as if it were one of our public interfaces.

I've never understood the argument that a programmer should be able to use any private internal function, class, method, structure, interface, etc, just like one would use public functions, classes, methods, structures, interfaces, etc.  The difference between private code and public API is fundamental to programming, even if one has access to the source code. 

I personally don't think Microsoft should've been forced to document ANY internal code constructs in Windows, except those that may have been used by MS apps or MS "middleware" that has third party competitors (e.g. Internet Explorer).  For example, if different parts of the OS talk with each other through private COM interfaces, then those interfaces need not be documented (even if access to those private interfaces can be obtained by passing undocumented GUIDs to QueryInterface).  But if InternetExplorer ("middleware" whose OS-independence disputed), made use of internal COM interfaces to talk with the OS, then those interfaces should be documented so competitors to IE could use them.

Taking your example, if interface abcb3a00-1b2b-11cf-a49f-444553540000 isn't being used by "middleware", then it need not, and moreover should not, be publicly documented.  I'd say the same regarding the DirectShow interface 94bc0598-c3d2-11d3-bedf-00c04f612986.  You say that this has been "mentioned" on the web, but how is one to know that it's behavior won't change in future versions of DirectShow, or even if it will remain as part of DirectShow altogether?  There's a reason that interfaces meant for internal use aren't documented.

sparky wrote:

What is so hard about documenting the interfaces?  Is it some zany attempt at a competitive advantage, or is it just laziness?

I would say half of each. The standard of documentation for the .NET framework eclipses anything there is in windows, mostly because of the self documenting system c# has.

You look at the windows api and there are zero examples on MSDN, you usually have to crawl google groups to find examples where people have done it before.

The lack of documentation is no doubt laziness but it also seems that competitive advantage is motivating the project managers not to bother doing anything about the lack of documentation. Take Exchange server - it has the worst documentation you'll ever see. But if the Exchange team started doing exceptional documentation, a certain mail client may start finding it has competition from 3rd party mail clients, draining the money from Microsoft's biggest cash cow.

My view anyway

Escamillo wrote:

Maybe those interfaces are strictly for internal use.

That argument doesn't work here, since we're talking about what is supposed to be an extensible framework. It has been 5 years, but as far as I can remember, that interface was used to talk between an IShellFolder implementation and an IShellView implementation. If an extension is supposed to be able to replace either of those pieces, then it needs to be able to impersonate the stock implementation completely. If my replacement IShellView is to be used with the stock IShellFolder, then I need to be able to communicate with it like the stock IShellView would. If I can't do that, then either 1) things aren't going to work right, or 2) I am locked out and can't do everything that the stock IShellView can do. Those are both unacceptable outcomes.

that was nice

Not very satisfying video (too little too late) we need much more windows shell videos