James Finnigan : shell

The Shell Extensions Approved list is not a complete list of shell extensions on the system

jamesfinnigan — Sat, 08 Sep 2007 07:42:02 GMT

I've noticed that a number of different programs just look at the Approved list of shell extensions [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Shell Extensions\Approved] and figure that all shell extensions will be in that list. It's not true, because lots of folks don't really care about that policy. I don't know how often it's used - it doesn't really make your system more secure as far as I can tell. (It may reduce the TCO related to folks installing poorly written shell extensions.)

It also doesn't apply to all shell extensions. There are many of them (probably some of them with HKCU extensibility) that haven't been moved to the policy system yet. (So you should always register your shell extensions there, even if it doesn't seem to be necessary.)

(That said, it certainly does give you quite a few of them for very little work. On my system, it finds about 325/400 - about 80%. Because of that, if you're thinking about turning on this policy consider the fact that you'll be disabling 1 in 5 shell extensions; will that generate more or less support calls?)

Supplemental Registrations (aka. Context Menu Handers (etc) - where are they loaded from...)

jamesfinnigan — Thu, 06 Sep 2007 19:00:00 GMT

I've been thinking about the registration problem where you want to add a context menu (much of this applies to static verbs as well) to a file type (we'll say .ogg). You don't want the default verb, you just want to add some verbs. Because you don't want the default, you shouldn't put your progid in the HKCR\.ogg default value, so you put an entry under HKCR\.ogg\shellex\ContextMenuHandler. And this works great.. until someone comes along and puts a progid in HKCR\.ogg's default value. Look at the fallthrough logic below - #2 (where we registered), and #3 are only used if there is no progid!

Fallthrough logic when loading context menu handlers (static verbs and then context menu handlers are collected from the following places):

(DO NOT USE THIS LOGIC IN YOUR CODE - it is a simplification of the real logic and it will change. Instead, use IQueryAssociations or AssocQuery* for all these kinds of file association related things.)

HKCR\<ProgID>
HKCR\<.ext> (only if #1 does not exist)
HKCR\Unknown (only if #1 does not exist)
HKCR\SystemFileAssociations\<.ext>
HKCR\SystemFileAssociations\<PerceivedType>
HKCR\Folder (only used if the selected item has the SFGAO_FOLDER attribute, such as a folder, zip, cab, etc.)
HKCR\*
HKCR\AllFilesystemObjects

But there is a way! You can register supplemental verbs associated with the SystemFileAssociations key. Note that those keys (#4 and #5) are folded in regardless of the association having a progid registered. In our example, that would be HKCR\SystemFileAssociations\.ogg\shellex\ContextMenuHandler

The important thing here is that you should never put the registration under HKCR\<.ext>(!) because you should either be putting it under your progid (#1), or in SystemFileAssociations (#4). Why do we disable #2 and #3 in those cases? If folks are interested, I'll talk more about that later - or feel free to guess. :)

(A quick comment about #5 - I think it is often misused. Applications don't know how to handle very many perceived types (one exception is text). How are you going to handle the "video" perceived type? I guarantee that we'll come out with more codecs/container formats, etc. Unless you can guarantee that you can handle everything that will map into the perceived type, don't register for it - instead register for the individual associations that you really can handle.)

This technique is used for a lot of other things besides context menu handlers. It's also used for Property Handlers for Windows Search, Windows Imaging Component codecs, etc, etc, etc.

Cheers,
James

[Update: finished the sentence beginning "In our example, that would be..."]

Installing shell extensions - please complain here

jamesfinnigan — Sat, 11 Aug 2007 04:02:00 GMT

So... I've been looking more closely at Wix and I think I'm going to build some custom actions to do a really good job installing shell extensions. Which ones do you find most problematic? I realize this is a bit of a change of pace for the blog, so I'll probably hit a few other forums, but please feel free to add comments/complaints about which extensions are problematic.

Maybe you've already done the work to install these properly, but in some cases that can be quite complicated and I could see a lot of folks just accepting some minor bugs and moving on.

I'll start:

Protocol Handlers (http://msdn2.microsoft.com/en-us/library/bb266527.aspx) and Schema Extensions (http://msdn2.microsoft.com/en-us/library/ms647576.aspx). Both of these require custom actions to be installed correctly - and there's no standard for it so everyone is probably doing it themselves which is going to lead to some really inconsistent behavior. None of that is going to help system stability at all.

Another one I came across recently was installing a shell folder that should appear on the desktop. I added it to the desktop namespace but until the user refreshes the desktop it isn't going to appear. You need to send a SHChangeNotify to get it to show up without user intervention. Anyway, there's no standard action for that. So unless you can accept a shortcut to the shell folder (which sends a notification), you'll want a CA there as well. And there again, you want to send as minimal a notification as possible to avoid having the system reload everything when all that you needed is a new icon to show up.

File Associations:
This one is going to be a bit of a laundry list of issues, but I'll start off the first couple issues.

If previous handlers didn't register under openwith then your registration may blow away any record that they wanted to handle that file association.
If you register under a meta-type like TXTFile and then someone else claims .txt then you don't get invoked at all.
Man that thing is complicated. Way, way complicated. (I'm still learning the subtleties - feel free to correct me if I miss a beat.)

So there's a start - let me know as you come across other issues.

Cheers,
James

RegNamespace sample up on codeplex

jamesfinnigan — Sat, 17 Feb 2007 00:07:45 GMT

Scott, Jerry, Thayn and I have whipped up a sample of indexing the registry, as well as a shell folder (namespace extension) for viewing it. It's great to be able to search the registry via the index and it's great sample of how to create a shellfolder, protocol handler, and even an IFilter. So head on over to the codeplex site and check out the source code, or if you're more interested in having it than seeing how it's build, just download the binaries and enjoy!

This is something that we're looking to improve over time, adding features and generally fleshing it out to be a rich, complete experience. We're not yet to feature parity with Regedit, but it won't be too long.

If you're interested in samples related to shell programming also check out shellrevealed.

WMI Folder - codeplex project

jamesfinnigan — Thu, 11 Jan 2007 01:03:43 GMT

Well, I've put the WMI folder code up on codeplex. Please remember that this code is very much pre-alpha. I think that this will be a good way to share the code, allow others to contribute, etc. If it works well, then I will probably create codeplex projects for some of the other things that I'm putting together.

If you're interested in contributing, leave a comment here or via the codeplex project.
Happy new year!
James

Getting a Path from an IDList

jamesfinnigan — Fri, 01 Dec 2006 14:44:08 GMT

Not much to this - but I notice searches for this coming to my blog, so I might as well provide the answer.

Use SHGetPathFromIDList - as long as the pidl is part of the file system, this will succeed. If you don't need a file system path, you can pass something like PKEY_ItemFolderPathDisplay to IShellItem2::GetProperty (use SHCreateItemFromIDList to go from a pidl to an IShellItem2).

Incidently, if you want to surface search results in Windows Vista, make sure your IShellFolder also supplies PKEY_ItemFolderPathDisplayNarrow or you'll end up looking silly (if there's a difference between your parsing path and your display path).

Enjoy,

James

WMI Shell Folder GetDisplayNameOf - untangling the flags

jamesfinnigan — Tue, 07 Nov 2006 00:24:43 GMT

So I have a bit of a beef with GetDisplayNameOf - I don't like the flags. I understand that when it was created, the flexibility of flags made a ton of sense. It wasn't well understood what potentially wildly different uses might be needed, and flags are a good alternative to a giant enumeration. But I think there are really only about 4 possibilities that matter most of the time (caveat: I'm still pretty new to shell programming). It's a pain to figure out the flags and there are combinations that don't even make sense. It seems to make a lot more sense to me to use an enumeration (like in IShellItem).

Anyway, I ended up liking a solution that very similar to the one that was put into the Registry sample that a few of us are putting together (more on that later). I created four different functions for the different GetDisplayNameOf possibilities and hopefully the table that links them to the flags isn't too scary.

HRESULT CWMIFldr::GetDisplayNameOf(

/* [in] */ PCUITEMID_CHILD pidl,

/* [in] */ SHGDNF uFlags,

/* [out] */ STRRET *pName)

{

TRACEFNENTER();

HRESULT hr;

ZeroMemory(pName, sizeof(*pName));

if (!ILIsEmpty(pidl))

{

static const DisplayNameFn s_rgSIGDNMapping[2][2] =

{

// unfriendly // friendly

{{&CWMIFldr::_GetAbsoluteParsingName}, {&CWMIFldr::_GetAbsoluteDisplayName}}, // absolute

{{&CWMIFldr::_GetRelativeParsingName}, {&CWMIFldr::_GetRelativeDisplayName}}, // relative

};

bool fRelative = (uFlags & SHGDN_INFOLDER) == SHGDN_INFOLDER;

bool fFriendly = (uFlags & SHGDN_FORPARSING) != SHGDN_FORPARSING

|| (uFlags & SHGDN_FORADDRESSBAR) == SHGDN_FORADDRESSBAR;

PWSTR pszDisplay;

hr = (this->*s_rgSIGDNMapping[fRelative][fFriendly])(pidl, &pszDisplay);

if (SUCCEEDED(hr))

{

pName->uType = STRRET_WSTR;

pName->pOleStr = pszDisplay;

}

else

{

hr = E_NOTIMPL;

}

TRACEFNEXIT();

return hr;

}

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm