How do I extract the path to Control Panel from this shortcut so I can launch it?


A customer explained that they had a program that used the IShell­Link::Get­Path method to extract the program that is the target of a shortcut. They found that this didn't work for certain shortcuts, namely, shortcuts whose targets are not physical file paths.

The one that they were specifically having trouble with was the Control Panel shortcut. For example, if you open the classic Control Panel, then drag any of the Control Panel items to the desktop, this will create a shortcut to that Control Panel item. If you view the properties on that shortcut, the Target will be grayed out instead of showing a path.

"We want to get the target path of the shortcut so that we can launch the application. How can we get the target path from IShell­Link::Get­Path? Is there a special Windows API to get the path?"

They can't get the target path because these are shortcuts to virtual objects. There is no target path to begin with.

But if you look past the question to their problem, you can see that they don't need to know the path in the first place. All they want to do is launch the target application. The way to do this is simply to pass the shortcut to the Shell­Execute function. You can take this simple program as inspiration. Pass "open" as the verb and the full path to the shortcut as the file.

As a bonus: Your program will also respect the other settings in the shortcut, like the Start In folder, the shortcut key, the preferred window state (normal, maximized, etc.), the custom application user model ID.

And to answer the question (even though it isn't needed to solve the problem): Use the IShell­Link::Get­ID­List method to obtain the shortcut target regardless of whether it is a physical file or virtual namespace item.

Comments (15)
  1. DWalker says:

    Interesting that the customer was going to extra work, trying to find the target of a shortcut in order to launch the program.  To be fair, passing the shortcut to ShellExecute is something that never crossed their mind; after all, in the documentation and samples for using ShellExecute, I'll bet the target is always a program (Notepad.exe is a favorite) and rarely or never a shortcut.

  2. skSdnW says:

    One thing you need to remember when dealing with control panel idlists is that not all of them roundtrip to a parsing-name and back. (Mouse is one of them IIRC)

  3. Martin says:

    BTW: Why I cannot create shortcut to shortcut ? (Please do not ask why I need it, just curiosity)

  4. Kemp says:

    Martin: almost any question that starts with "why can't I" and ends with "don't ask why I need it" probably has the answer "because the designers didn't think anyone would need it or it never occurred to them as a feature in the first place".

  5. skSdnW says:

    @Martin, you can, sort of. Win7 added the SLDF_ALLOW_LINK_TO_LINK flag. The normal way you create shortcuts does not use it for some reason. Create a shortcut to a dummy .lnX file and hex edit the .lnk or create an app that calls the API directly. (Pinning a link to a link to the startmenu will resolve the first link for some unknown reason)

  6. Dan Bugglin says:

    They likely wanted the CPL file, but yeah, this is a case of "how do I do this the way we've always done it" rather than "what is the proper way to do this". Some CPL files can hold multiple control panels IIRC.

    I have to wonder if the customer's actual root problem involved a shortcut, or if a shortcut was the result of them solving the "easy part" of the problem themselves. (Maybe the problem was more like "How do I invoke a specific control panel?").

  7. Martin says:

    @skSdnW: I already tried to hex edit shortcut to point to another shortcut, it didn't work.

  8. skSdnW says:

    @Martin: You need to add the flag I mentioned to the lnk header. The lnk binary format has been documented, look for [MS-SHLLINK] on MSDN.

  9. sense says:

    By the way, what's the meaning of respecting "shortcut key" in launching by ShellExecute?

    What's the significance/effect of shortcut key when you've already decided to execute the link? Or is it a typo?

    [The shell will apply the shortcut to the app that got launched, so you can use the shortcut to switch back to the app quickly. -Raymond]
  10. @sense says:

    I had the same question in mind: Whats the meaning of shortcuts in lnk files in general? What if 5 lnks use the same shortcut? Will the shell deep-search C: to know all shortcuts of all lnk files?

  11. Someone says:

    "The shell will apply the shortcut to the app that got launched, so you can use the shortcut to switch back to the app quickly."

    Is there any user who knows about this? "Normal" shortcuts like Win+E also launch the app which seems impossible with shortcuts in lnk files.

    [You can set the hotkey in a shortcut on your desktop or Start menu, and Explorer will also use it to launch the app. -Raymond]
  12. GunSmoker says:

    Why pass "open", shouldn't it be just NULL?

  13. skSdnW says:

    @GunsSmoker: Yes it should. NULL means: Users preferred verb > "open" > First found during RegEnum > "openwith". (The RegEnum step is missing on Win9x IIRC)

  14. Skyborne says:

    I've known about shortcut keys since forever, but I had no idea they were also a magic switch-to-app button.

    I'm also failing to grasp the point of shortcut-to-shortcut-to-thing or deeper. The chain becomes ever-more-fragile with each step that gets added, and it's not at all clear how the settings (specified per shortcut) would layer. Even if rules were designed, there's a nontrivial chance they'd be the wrong rules for some users...

    I thought Win9x was stupid for having .lnk files that weren't clean and simple symlinks, but they turned out to have more features, and then Linux sprouted .desktop files. Hmm.

  15. Joshua says:

    @Skyborne: How about hard link to relative symbolic link in a different directory. The mind boggles.

Comments are closed.

Skip to main content