C ++ ShellExecute专门不打开LNK文件

Question

-Windows 7 64-bit
-Visual Studio 2013 (v120)
-Unicode Enabled
-Target Build- Debug 32-bit

I would like to build a launcher (for personal use) however I can't get ShellExecute to work with all file types or paths, specifically shortcuts (LNK). I've researched and tried the following in many combinations...
-I'm using escape sequences
-I'm adding the file extension (and tried without)
-I've included Windows.h
-Printed directory FindFirstFile / FindNextFile to explicitly ensure the path has no typos
-Tried using both a literal and variable as file path argument
-Tried running VS with admin privileges
-Tried ShellExecute, ShellExecuteA, ShellExecuteEx, and System (with appropriate character sets)
-Tried NULL, "runas" and, "open" for the verb
-Launches fine from Command Line or explorer using same path
-Tried using %USERPROFILE% macro instead of user name (returns 2)
-Seems to work with EXE and URLs
-Does not seem to work with any LNK across any path including C:\\ directly

Suspected issue
-32bit/64bit discrepancy
-UAC / Privelages
-Character set
-File extension
-Anti virus interference (though AV isn't alerting me of any issues) and I've tested while silencing my AV

Here is one of the simplest programs I've tried...

#include "stdafx.h"
#include <iostream>
#include <Windows.h>
#include <atlstr.h>

int _tmain(int argc, _TCHAR* argv[])
{
    CoInitializeEx(NULL, COINIT_APARTMENTTHREADED | COINIT_DISABLE_OLE1DDE);

    // Variables below for testing as path argument
    // Paths that end with LNK are the only ones that I can't get to launch
    CStringW link("C:\\Users\\Home\\Documents\\Art\\blender.lnk"); // Doesn't work
    CStringW target("C:\\Program Files\\Blender Foundation\\Blender\\blender.exe"); // Launches software as expected
    CStringW url("https://stackoverflow.com"); // Launches browser with URL as expected

    int error = reinterpret_cast<int>(ShellExecute(
        NULL, 
        NULL, 
        L"C:\\Users\\Home\\Documents\\Art\\blender.lnk", // Using literal with LNK extension also does not work
        NULL, 
        NULL, 
        SW_SHOWDEFAULT
        ));


    // EVEN SYSTEM CAN NOT FIND THE PATH!!!
    // system("C:\\Users\\Home\\Documents\\Art\\blender.lnk");

    std::cout << error << std::endl; // Returns 3 "The specified path was not found.".

    // Free COM
    CoUninitialize();

    return 0;
}

Answer 1

First, check that your .lnk file is in the path.

Then (and the most probable cause of your problem) check that your .lnk filename is created correctly. To make sure it is not like "blender.lnk.lnk"(I can reproduce your issue if I have set as this).

You can also try to parse the path of the link file manually by yourself. Here is the sample:

void ShortcutToRealpath(LPWSTR pszString, LPSTR pdzString)
{
    IShellLink   *pShellLink;
    HRESULT hRes;

    ::CoInitialize(NULL);
    hRes = CoCreateInstance(CLSID_ShellLink, NULL, CLSCTX_INPROC_SERVER, IID_IShellLink, (void **)&pShellLink);
    if (SUCCEEDED(hRes))
    {
        IPersistFile   *ppf;
        hRes = pShellLink->QueryInterface(IID_IPersistFile, (void **)&ppf);
        if (SUCCEEDED(hRes))
        {
            hRes = ppf->Load(pszString, TRUE);
            if (SUCCEEDED(hRes))
            {
                pShellLink->GetPath(pdzString, MAX_PATH, NULL, 0);
            }
            ppf->Release();
        }
        pShellLink->Release();
    }
    ::CoUninitialize();
}

When I build as x86 Platform, the path will be parsed like: That's the reason your program can't find the path.

And if I select x64:

Put your target file to the corresponding file.

EDIT:

After I test it with the MS tool Procmom.exe , I have found something others, if run as 32-bit, it will show :

The key value is C:\\Program Files (x86) and if we run it as 64-bit, the key is reference to "HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\ProgramFilesDir" the key value is C:\\Program Files . After I check the registry: It seems that C:\\Program Files is not visible by default to the 32-bit registry(I am not sure about the specific reason). If you change the key ProgramFilesDir to C:\\Program Files in 32-bit registry, the issue will be fixed.