A shell extension is a guest in someone else’s house; don’t go changing the carpet


A customer was running into this problem with a shell extension:

I am writing a shell namespace extension. I need to get data from a COM server, which requires impersonation via CoInitializeSecurity with RPC_C_IMP_LEVEL_IMPERSONATE. As I am just writing an extension into explorer.exe, I am not able to call CoInitialize, CoInitializeSecurity anymore from my extension. Is there a way I can start explorer.exe by setting RPC_C_IMP_LEVEL_IMPERSONATE in its COM initialization? I was browsing through web, and explorer.exe seems to take some settings from registry, but couldn't find anything related to this one.

First of all, who says that the host process is explorer.exe? If I open Notepad, then do a File.Open, and then navigate to your shell extension, boom, your shell extension is now loaded into Notepad, and I doubt you told Notepad that you wanted it to initialize COM in a special way, just for you. Same goes for Quicken, Lotus Notes, all those other programs that use the shell. Even if you solved the problem for Explorer, that doesn't solve your problem in general.

Second, what if two shell extensions did this? Your shell extension requires RPC_C_IMP_LEVEL_IMPERSONATE, but another one requires RPC_C_IMP_LEVEL_DELEGATE. Who wins? Or are those shell extensions mutually incompatible? And what about the effect your decision has on the other shell extensions hosted by Explorer? Now they are running with RPC_C_IMP_LEVEL_IMPERSONATE even though they didn't ask for it. Will that introduce a security vulnerability? Will those other shell extensions stop working or even crash?

A shell extension is a guest in the host process's house. You don't go and change the color of the carpet when you are invited over for dinner.

This question is yet another example of using a global setting to solve a local problem. To solve your local problem (I need this specific COM interface to run with impersonation), use a local solution.

Comments (21)
  1. Brian says:

    This reminds me of a former co-worker of mine.  I re-formatted his code to match our coding style conventions and he accused me of walking into his house and rearranging everything.  At the time I had been working there for years and him months.  Go figure he didn’t last very long.

  2. benjamin says:

    Developers with an attitude like the one presented in this article are the primary reason I try my hardest to keep my shell extensions as close to stock standard as I can. Inevitably when I come across someone complaining about Explorer’s stability they’ll have a million new entries in their context menus.

  3. Mike Dunn says:

    After following the "use a local solution" link, I nominate "QueryBlanket" as the best method name ever.

  4. porter says:

    > Go figure he didn’t last very long.

    Ah, but consider that he had at least accepted ownership!

  5. Teo says:

    Another very hard-to-grasp concept is that when shipping 64-bit product which has shell extension, you really want to ship both 32 and 64-bit shell extension dlls. After the third time I got the replay "but on 64 bit Windows Explorer is 64-bit, so a 32-bit shell extension is useless", I stopped trying to educate people.

    People do believe that Explorer is the only entity that has the holy right to touch shell extensions.

  6. Yuhong Bao says:

    "People do believe that Explorer is the only entity that has the holy right to touch shell extensions."

    Not to mention that you can run Explorer in 32-bit mode by manually going to %windir%syswow64explorer.exe.

  7. Jeff Tyrrill says:

    @Teo: "Another very hard-to-grasp concept is that when shipping 64-bit product which has shell extension, you really want to ship both 32 and 64-bit shell extension dlls."

    In fact, this is a good idea when shipping 32-bit product too.

  8. Koro says:

    I understand it was probably a good idea at the time, when programmers could be expected to actually know what they were doing and memory was limited, but wouldn’t it be time to move shell extensions outside Explorer again?

    Some sort of "ShellExtensionProvider.exe" that would be started by explorer (sort of like MSN Messenger always starts ctfmon.exe or TortoiseSVN always starts TSVNCache.exe) and would answer to "shell extension requests" from explorer views hosted in all processes, 32 or 64-bits.

    Of course, because of backwards compatibility, the current shell extension model would have to stick around for another 10 years, but slowly all major extensions would be migrated to the new model.

  9. Jonathan says:

    @Koro: And maybe we’ll finally get to write managed-code shell extensions.

    BTW, ctfmon.exe is a Windows process that has something to do with sound. It’s not a part of Messenger.

  10. porter says:

    > when programmers could be expected to actually know what they were doing and memory was limited, but wouldn’t it be time to move shell extensions outside Explorer again?

    I can see the cycle. As you speed up the machines, you can then dumb down the programmers and still end up with the same responsiveness of machines twenty years ago. Then despite upgrading your machine every couple of years the machine still feels as slow. Brilliant!!!! That’ll keep us on the gravy train for life!

  11. someone else says:

    @porter

    Did you actually use a computer, say, 20 years ago? Those things were slow compared to an adequate machine running 7 or XP (I won’t touch Vista here …), if only because of I/O. Actually, that’s still the most limiting factor.

  12. anon says:

    Since MS pwns the house, they don’t care about whether changing the carpet could make the guests fall or not visit their house again. With this same mentality, I guess was why IColumnProvider was removed citing pseudo performance reasons. I have loyally stuck with XP because of this (Extensible column handlers are far too valuable to me than fancy Aero or Peek). How the hell can I display certain info like extension or size (especially folder size) thru extensions? Not possible with the Property system which only allows extracting static metadata from files. I hope Windows 8 or Windows 7 SP1 brings back IColumnProvider. Whatever happened to giving choice to users/developers?

  13. someone else says:

    "Since MS pwns the house, they don’t care about whether changing the carpet could make the guests fall or not visit their house again."

    Unless said guests are important enough. Now, in the open source world …

  14. Médinoc says:

    A problem is that not all shell extensions can be out of process. Notably icon handlers, the only type of shell extension I’ve written yet.

  15. Gabest says:

    "Not to mention that you can run Explorer in 32-bit mode by manually going to %windir%syswow64explorer.exe"

    Not anymore in Windows 7 x64. Anyone knows why?

  16. benjamin says:

    Years of playing FPSes have left me unable to see ctfmon as anything other than ‘Capture The Flag Monitor.’

  17. porter says:

    > @porter: I posit that having ONE copy of the shell extension running in a separate process,

    Why stop there, why not have a separate process for every shell extension?

  18. Koro says:

    @porter: I posit that having ONE copy of the shell extension running in a separate process, instead of having a copy of it loaded into each process that shows an Open/Save dialog box, would have net memory savings in the end, as it would not need to allocate its per-instance data for each process. It would also remove the need for shell extension helper processes like TSVNCache.exe.

    It would also have the benefit of not "polluting" the list of DLLs loaded into a process as soon as an Open/Save dialog would be shown.

    @Jonathan: Actually, ctfmon.exe is related to msctf.exe, which I *think* is related to IME’s and advanced text input… which MSN indirectly uses since it uses windowless RichEdit’s for its input.

  19. Ken White says:

    @anon: "Since MS pwns the house"

    Thanks for starting with that at the beginning of your long post. It let me know it was troll spam, and I didn’t have to waste my time reading it.

    To the other trolls: Please be as courteous in future posts as @anon was in this thread.

  20. anon says:

    @Ken White, how exactly is a troll defined? One who complains about useful features lacking in Windows which were there in the past? My tone is because Microsoft doesn’t listen, this way or that way. The shell team and the Windows Media team at MS need to be crucified under a guillotine.

  21. Neil says:

    I have a problem with a product M’s DLL that gets loaded into my process (seems to be some sort of create window hook?) and initialises COM in such a way that my call to OleInitialize fails with CO_E_OLE1DDE_DISABLED…

Comments are closed.