The UseUrl attribute in the App Paths key indicates that your application can accept a URL on the command line

Setting the UseUrl attribute in your App Paths key indicates that your application can accept a URL on the command line as the document to be opened. The documentation for this attribute is a confusing blend of raw documentation, guidance, history, and an example. Let’s tease the parts apart so you won’t confuse the example with the contract.

The raw documentation is simple: Setting UseUrl indicates that your application can accept URLs on the command line.

The guidance is that programs like Web browsers should set this attribute because opening URLs is the primary reason for their existence. But it’s not just Web browsers; any program which can open documents directly from the Internet can set this attribute. Another category of programs that often falls into this category is media players, since it is common for media players to play content directly from a URL as well as playing content from a file.

The example given in the documentation of a component which uses this attributes is Web Folders: If you are browsing a WebDAV folder and right-click on a file stored on the Web server, the Open command will be made available if the application registered to handle the file marks itself as UseUrl. If not, then the user will have to download the file and open the downloaded copy.

The history is that this attribute was invented by the Web Folders team, and for a long time, they were the only component which used it. The UseUrl attribute went under-documented for a long time because the shell documentation team didn’t know that this attribute existed. The Web folders team simply made it up and didn’t tell the shell team that they were extending a shell feature.

The Internet Explorer team discovered this “feature from another planet” when they went about implementing the “Edit” button in their toolbar and wondered why some HTML editors worked and others didn’t. The shell team also discovered this feature and retroactively added support for it in a few places, such as in the Shell­Execute function if you try to open a document via URL. If the handler is not marked as UseUrl, the Shell­Execute function will download the document to a local file and invoke the handler on the local copy.

Comments (6)
  1. Adrian says:

    I was curious as to which applications set the UseUrl attribute, so I peeked in regedit.  It seems none of the browsers I have installed (IE, Firefox, Chrome) set this attribute.  In fact, no application installed on any of my machines (XP, Vista, and Windows 7) has UseUrl.  There are a couple of other undocumented attributes, but no UseUrl.

  2. 640k says:

    Only a single param url?

    Or can the args be more complicated with multiple urls, embedded urls, and parts of urls?

  3. Gabe says:

    Embedded URLs? Parts of URLs? What would that even mean?

  4. josheinstein says:

    I guess SharePoint had nothing to do with it. :)

    But I wish other browsers would pass the URL to Office apps when opening SharePoint docs. It's a show stopper for using Chrome in our company.

  5. Troll says:

    Shocking! People who work on the OS don't know things about it. That's why features get lost probably in "upgrades". Absolutely shameful. The Web Folders team (does it even exist now) didn't even create a 64-bit Web Folders component when creating XP Professional x64/Vista x64. They have "deprecated" the component codenamed Rosebud.

  6. Anhel Strauke says:

    Wonderful! This story reminds me my current job! When I was browsing our subversion repository some days ago, I've found undocumented classes that was similar to ones I've written in my current project) Interesting that our organisation has two (!) wiki sites with developers' documentation, and there is no any mention about that lost classes.

Comments are closed.