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

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.)

  1. HKCR\<ProgID>
  2. HKCR\<.ext> (only if #1 does not exist)
  3. HKCR\Unknown (only if #1 does not exist)
  4. HKCR\SystemFileAssociations\<.ext>
  5. HKCR\SystemFileAssociations\<PerceivedType>
  6. HKCR\Folder (only used if the selected item has the SFGAO_FOLDER attribute, such as a folder, zip, cab, etc.)
  7. HKCR\*
  8. 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.


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

Comments (7)

  1. ak says:

    well, if you have a mediaplayer that uses directshow, you can probably play the file, so the video type makes sense for that

    What I hate the most is how Windows Media Player cheats (Its always at the top of the openwith list, even if you never use it, the rest of the list is sorted by last use) and it sticks its useless menus everywhere (how often do you burn something by right clicking on a folder? And both play and add to playlist, so useless)

  2. What you say is true, but it turns out that media player doesn’t even try to handle associations that it doesn’t /know/ that it can handle.  So I have to hack the registry a bit to get it to index my video files properly (e.g. maybe I had to do this for .mp4 files?).

    Some examples of this .

    I was looking at openwith and didn’t see anything that would allow it to "cheat".  It probably has to do with the order the registry locations are searched.  Media player is registered for SPAD, under the RegisteredApplications (aka Default Programs – a best practice) key, App Paths, OpenWithList, OpenWithProgids, etc.  I don’t know that behavior off-hand but it sounds like an interesting article for another day.

  3. ak says:

    When I said player, I did not mean WMP, I was thinking about 3rd party apps. Take MediaPlayer Classic for example, it uses direct show, but it also supports real & quicktime if they are installed and it even comes with a bunch of filters&codecs built it. VLC is another example of something that would probably be able to handle anything that is perceived to be video (and audio)

    And we all know the reason why WMP doesnt support mp4/AAC/h264/XViD/Ogg/FLAC/etc. out of the box, MS wants to push their own formats

  4. @ak – I buy your argument somewhat (and it annoys me because I like MP4 and I think it’s likely a very stable format for a while so a good choice for video of my kids, etc since every reencoding is data loss).  I wonder, though, if there wouldn’t be a lot of legal questions involved.

    (Some of these are mostly the same thing (not sure about the container formats).  XViD is an "MPEG-4 ASP" encoder, which is also "H.264", which is also "ISO MPEG-4 part 10"  Not sure why we need so many names – H.264 and the ISO is two different standards bodies, but MPEG-4 ASP?)

  5. ak says:

    XviD/DivX (aka Mpeg4 ASP aka MPEG-4 Part 2) is not the same as h.264 (aka Mpeg4 AVC aka MPEG-4 Part 10)

    h.264 is the "new" kid on the block and offers better quality compared to the older Mpeg4 ASP based codecs

    XviD/DivX mostly comes in the avi container, but can also be seen in MKV and OGG. h.264 will hopefully mostly come in just the mp4 container

    As for the legal questions, FLAC, OGG are 100% open, XviD is GPL IIRC but MS now supports in in Media Center extenders, so I don’t see why they can’t support it in WMP (And you don’t need to use the XviD or DivX decoders, any Mpeg4 ASP decoder will do, MS could even code their own (First version of DivX was a hacked version of WMV so I’m sure they could decode it if they wanted) )

    Got a bit off topic there, sorry


  6. Fine with me – I don’t mind understanding this stuff better.  Although I don’t do a lot with it, I do a fair amount of home videos and like to know what I’m doing with those memories.

    Do you happen to know what specific codec is used on HD-DVD/Blueray/DVD?  Whatever all the popular media (movies) is encoded into is probably going to be most stable over time due to hardware support requirements.

  7. ak says:

    HD-DVD and Blueray use the same formats, and they are; MPEG-2 (same as plain DVD), h.264 and VC1 (aka MS’s WMV9)

    (Players need to support all 3 formats)

    I’m not sure what the container format(s) are

Skip to main content