WOW64 woes (.lnk shortcuts)

Question

I'm using Windows 7 (x64) and Delphi 2010.

I'm writing a component that will emulate the start menu. However, I've run into the following problems:

If I attempt to open a shortcut (.lnk file) with ShellExecute, this will fail whenever %ProgramFiles% is part of the target path of the shortcut (it will then look at the C:\Program Files (x86) folder instead of C:\Program Files);
ShGetFileInfo fails to extract the correct index of the icon in the system image list if %ProgramFiles% is part of the path to the icon file (same problem as above).

Is there any workaround to the above issues or do I have to wait for native 64-bit Delphi to become available for this to work?

score 2 · Answer 1 · edited Jun 26 '10 at 21:04

2

I think you should call Wow64DisableWow64FsRedirection before and Wow64RevertWow64FsRedirection aftyer.

edited Jun 26 '10 at 21:04

RRUZ

134,889
20
356
483

answered Jun 26 '10 at 18:28

Giel

2,066
20
22

Ok, this is very annoying. While Wow64DisableWow64FsRedirection does not solve my initial problem, it solves the problem whenever %windir% is used as part of the path name. One would expect that this would adjust/redirect all environment variables! – Mattias Andersson Jun 26 '10 at 20:14
I don't think that's going to work. All that does is disable redirection so that accesses to c:\windows\system32 (as an example) from a Wow64 program don't get redirected under the covers to c:\windows\syswow64. As far as I know this doesn't do anything to help you with environment variables. You'll either have to compile as native 64-bit or handle environment variables yourself. – Luke Jun 26 '10 at 22:48
Ok, SetEnvironmentVariable('ProgramFiles', 'C:\Program Files') fixes the problem for ShGetFileInfo, but the problem still remains for ShellExecute. – Mattias Andersson Jun 27 '10 at 00:34

score 1 · Answer 2 · answered Jun 27 '10 at 13:08

1

Ok, a small example that demonstrates the problem.

I invoke ShellExecute with the following parameters:

ShellExecute(Handle, 'open', 'C:\Users\...\Internet Explorer (64-bit).lnk', nil, nil, SW_SHOWNORMAL);

The target of Internet Explorer (64-bit).lnk is:

C:\Program Files\Internet Explorer\iexplore.exe

However, the 32-bit version of iexplore.exe is opened nonetheless. In this case the path doesn't even use %ProgramFiles%, so somehow ShellExecute will translate C:\Program Files to C:\Program Files (x86) internally. I have no idea how to make it open the 64-bit version of iexplore.exe instead.

Another problem, after calling Wow64DisableWow64FsRedirection, ShellExecute will no longer open folders.

answered Jun 27 '10 at 13:08

Mattias Andersson

383
3
11

This is *not* an answer to the question. Please add additional details in the question instead. – Andreas Rejbrand Jun 27 '10 at 13:13
Sorry, I'm newly registered, when I added openid to my account I lost the identity that I used when posting the question... – Mattias Andersson Jun 27 '10 at 14:28
1

More info on this issue can be found here: http://stackoverflow.com/questions/386715/launching-shell-links-lnks-from-wow64 – Tobbe Aug 31 '10 at 22:57

score 1 · Answer 3 · answered Jun 27 '10 at 13:40

The following environment variables will always point to the right direction on a 64-bit machine, and will be undefined on a 32-bit machine:

from a 32-bit shell on a 32-bit architecture:

C:\>echo %processor_architecture%
x86
C:\>echo %programfiles(x86)%
%programfiles(x86)%
C:\>echo %programw6432%
%programw6432%
C:\>echo %programfiles%
C:\Program Files

from a 32-bit shell on a 64-bit architecture:

C:\>echo %processor_architecture%
x86
C:\>echo %programfiles(x86)%
C:\Program Files (x86)
C:\>echo %programw6432%
C:\Program Files
C:\>echo %programfiles%
C:\Program Files (x86)

from a 64-bit shell:

C:\>echo %processor_architecture%
AMD64
C:\>echo %programfiles(x86)%
C:\Program Files (x86)
C:\>echo %programw6432%
C:\Program Files
C:\>echo %programfiles%
C:\Program Files

Try substituting them before running the application.

WOW64 woes (.lnk shortcuts)

3 Answers3

Linked