Comments

LOL @ 32:42
Are they saying what I think they're saying?

This brings up one of the things I have always wondered about win32.  Why on earth can't you do an overlapped CreateFile?  It doesn't sound like this is going to be changing in Vista either.  I've *wanted* to use overlapped IO on many occasions, but I've always been very turned off by this omission.  Also, why is it that some overlapped IO calls block for hundreds of milliseconds?  Shouldn't asynchronous really mean asynchronous?

I also have one question about user-mode drivers.  You talked a little about how we don't want user-mode drivers to host a GUI, etc.  But I wasn't sure if you mean that it is impossible for them to do that.  Do user-mode drivers run in win32, or are they in a separate subsystem?

OK, one more question and I'm done.  In general you can only cancel an operation that is sufficiently started, and not sufficiently finished.  Those two restrictions lead directly to the two main classes of bugs associated with "cancel" type API calls.  Namely, that you can't be sure you aren't trying to cancel it too early, and that you can't be sure you aren't trying to cancel it too late.  The case of trying to cancel it too early can be handled carefully by the application with retries and synchronization, to avoid turning it into a problem.  But I can't see how you can, in general, solve the second class of problem, trying to cancel an operation that has just finished, and accidentally cancelling a different operation.  Is this something that you have looked into?

Charles wrote:

Yep. It works for me. Is it timing out on you? 404? What's up?
C

It goes through when I try it from home.  I should have known it was those nice network guys at work protecting me from the internet again.

Charles wrote:

"To signup for the WDK beta program please go to the http://connect.microsoft.com/" href="http://connect.microsoft.com/"> http://connect.microsoft.com website ..."

That is what I tried to do.  The website http://connect.microsoft.com does not respond.  Does it work for you?

Where can I get a copy?  I tried to sign up for the WDF beta, but the web site doesn't seem to be responding.

Me thinks it's annoying when people say cutesy crap like "me thinks".  Take responsibility and credit for your own thoughts -- say them in the first person!

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.

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 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?

Excellent video.  I think my company read his book upside-down.