Creating a shell extension that applies only to files with a very specific name

Today's Little Program isn't even a program. It demonstrates how to register a shell context menu command that applies only to files with a specific name.

Let's say that you want a special context menu command, let's call it Party!, on any file called party.txt. If invoked, it runs CharMap because everybody knows that CharMap is a total party animal.

Now, if you wanted the command to apply to any text file, you would use the following registration:


But this offers the Party! command on humorless files like readme.txt.

Fixing this is a special case of getting dynamic behavior for static verbs by using Advanced Query Syntax. In this case, we create an Advanced Query Syntax filter that selects an exact file name.

Comments (12)
  1. Mason Wheeler says:

    The link on the words “getting dynamic behavior for static verbs by using Advanced Query Syntax” is broken.

    1. The link forwarding on the old site is broken. I opened a ticket.

      1. Kevin says:

        Oh good. I was afraid I’d have to run through my entire backlog of Stack Overflow answers and fix all the links to your blog.

        (Yes, I know that your blog is for entertainment purposes only. No, I don’t care, because entries like your “finalizers are evil and cannot be relied upon” post are simply too useful not to link.)

  2. Brian_EE says:

    I think this is the correct link:

    Also, do you mean to use two different registry paths in the example above? (…\txtfile\… and …\.txt\…)

    1. Ron O says:

      Since it is known the target file is a .txt, there’s no point in making this registration against the entire class of text files (which includes other extensions). If the filter were to apply to any text file that started with Party, then it would be appropriate to use the larger class.

      1. Brian_EE says:

        Sure…. but then shouldn’t the [HKEY_CLASSES_ROOT\txtfile\shell\Party!\command] @=”charmap.exe” also be on the .txt node?

        I don’t understand why you would add the context handler command on the txtfile node but the “Applies To” qualifier on the the .txt node.

        I would think they should both be on the .txt node, unless there is something I am missing.

  3. Seems like using advanced query syntax could significantly impact performance, especially using conditions like file size or exclusion criteria (from your link)… and even more-so if the data source is remote / offline (and in this case, would the recall operation be UI blocking for the context menu?)

    1. AQS may be slower than a strcmp in a custom handler, but the cost of loading the custom handler is far greater than executing an AQS expression.

      1. so in the case of remote files, where the file contents provide clues about the file type (infopath being the first example which comes to mind, since it’s just a .xml, but IE knows that it’s infopath, which I suspect is due to the XML directives in the contents), wouldn’t the performance be a huge issue, or are special tricks employed (perhaps indicating that parts of the file need to be kept in the local file stub, to be accessible to the shell extension)?

  4. Josh B says:

    It’d be extremely nice if this could be used to clean up some of those extensions that hog up or even hang up Explorer just to put an icon on the desktop’s context menu.

  5. DWalker says:

    “Today’s Little Program isn’t even a program.”

    Strictly speaking, I think that string “AppliesTo”=”System.FileName:=Party.txt” meets the criteria of a program! It is formatted to meet certain rules; it specifies an algorithm; it is interpreted by … something deep in Windows’ code.

  6. Joshua says:

    The days probably never aligned, but doing this to config.sys in the Windows 9x days would have made a lot of sense.

Comments are closed.

Skip to main content