Going Deep: Richard Ward - Engineering security into Windows Vista

Comment removed at user's request.
Harlequin wrote: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 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
We really need to get a mic to put on the table for interviews like this. And we will.
I'm sorry about the bad audio. If you watch the video in Media Player (as opposed to the inline player in the web page) and crank the volume in the player and on your system, you will be able to hear everything just fine.
C
Charles wrote:We really need to get a mic to put on the table for interviews like this. And we will.
Charles wrote:
If you ... crank the volume in the player and on your system, you will be able to hear everything just fine.
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.
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.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.
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.sparky wrote: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.
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.
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.
sparky wrote:
What is so hard about documenting the interfaces? Is it some zany attempt at a competitive advantage, or is it just laziness?
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.Escamillo wrote:Maybe those interfaces are strictly for internal use.
Not very satisfying video (too little too late) we need much more windows shell videos