|Anonymous | Login | Signup for a new account||2020-02-20 01:35 PST|
|Main | My View | View Issues|
|Viewing Issue Simple Details|
|ID||Category||Severity||Reproducibility||Date Submitted||Last Update|
|0000039||[litestep core] core||minor||always||2008-01-12 08:44||2013-08-01 12:23|
|Summary||0000039: Shortcuts to 64-bit progams broken when running in WOW64|
On 64-bit Windows there are both 32-bit and 64-bit binaries for some programs like IE, Media Player, or Calculator, in "Program Files (x86)" and "Program Files", respectively.
A 32-bit Litestep cannot currently invoke shortcuts to the 64-bit versions because ShellExecuteEx appears to read out FOLDERID_ProgramFiles from the .lnk, which resolves to "Program Files (x86)" for 32-bit processes. Thus the 32-bit versions are launched. Note that if only a 64-bit version exists it is launched all the same.
|Additional Information||You could make a case that it's a bug in Windows setup as it should have set FOLDERID_ProgramFilesX64 in the .lnk files. However, FOLDERID_ProgramFiles may be correct for compatibility reasons. Anyhow, since we cannot change Windows setup and since the default Windows shell works correctly (it's a 64-bit process), we should try to find a workaround.|
|Tags||No tags attached.|
qwilk of xoblite passed this along:
"0000039: Shortcuts to 64-bit progams broken when running in WOW64"
check this one out: http://msdn2.microsoft.com/en-us/library/aa365743.aspx [^]
"The following example uses Wow64DisableWow64FsRedirection to disable file system redirection so that a 32-bit application that is running under WOW64 can open the 64-bit version of Notepad.exe in %SystemRoot%\System32 instead of being redirected to the 32-bit version in %SystemRoot%\SysWOW64."
"To restore file system redirection, call the Wow64RevertWow64FsRedirection function."
you'd need to IsWow64Process first of course
// Check if running under 64-bit Windows... (for future use)
// ("IsWow64Process determines whether the specified process is running under WOW64.")
typedef BOOL (WINAPI *LPFN_ISWOW64PROCESS) (HANDLE, PBOOL);
LPFN_ISWOW64PROCESS BBIsWow64Process = (LPFN_ISWOW64PROCESS)GetProcAddress(GetModuleHandle("kernel32"),"IsWow64Process");
pSettings->runningUnderWOW64 = FALSE;
if (BBIsWow64Process != NULL) BBIsWow64Process(GetCurrentProcess(),&pSettings->runningUnderWOW64);
if (pSettings->runningUnderWOW64) SendMessage(GetBBWnd(), BB_SETTOOLBARLABEL, (WPARAM)CONSOLE_INFORMATION_MESSAGE, (LPARAM)"64-bit Windows detected! (not officially supported but should work fine)");
|Wow64DisableWow64FsRedirection unfortunately does not apply to this specific case.|
edited on: 2010-08-31 16:06
ilmcuts posted a question about this on stackoverflow.com back in 2008. A year or so later someone posted a reply that might actually be what we need to solve this!
See http://stackoverflow.com/questions/386715/launching-shell-links-lnks-from-wow64 [^]
> Anytime you here something is impossible on a computer, think again... The key is to utilize the c:\windows\sysnative\ path to shut off the redirection.
> Here is very simple code that will do what you want:
> #include <windows.h>
> #include <ShellAPI.h>
> #include <stdio.h>
> int main(int iArgc, const char *pArgv)
> ShellExecute(NULL, L"open", L"C:\\windows\\sysnative\\..\\..\\Program Files\\Internet Explorer\\iexplore.exe", NULL, NULL, SW_SHOWNORMAL);
> BOOL bIAmWow64 = FALSE;
> IsWow64Process(GetCurrentProcess(), &bIAmWow64);
> printf("I am a wow64 process: %hs\n", bIAmWow64 ? "Yes": "No");
> return 0;
> I hope that is helpful.
I have not tested this. Someone with a 64-bit install of windows, please run the example code and report your findings.
As I just posted on stackoverflow, the sysnative folder does nothing that Wow64DisableWow64FsRedirection doesn't.
Also, perhaps it should be pointed out that when there is no mirrored file in %programfiles(x86)%, nothing will happen.
The only fix I see for this, aside from compiling LiteStep and all modules into 64bit, is to add a special case for .lnk files in LSShellExecute and LSShellExecuteEx. We would have to parse the link file ourselves and then call ShellExecute with the data we parsed from the link. For ShellExecuteEx we should also set the out members of the original SHELLEXECUTEINFO struct afterwards.
After a lot of looking at this and trying all sorts of weird approaches of twiddling with the environment variables and everything, I finally conclude that there are only 2 approaches:
1) Use a separate 64-bit gateway app to run the shortcuts...we run it and it runs the link...that way a 64-bit app would do it and everything would work. That kind of sucks because we have to build and deploy that app with litestep and it's just a kind of silly misdirect that shouldn't be needed.
2) Do custom parsing of the lnk files. That would be ok...but it turns out to be a huge pain. The lnk files are actually surprisingly complex. It'd be a decent undertaking to fully support all of the possibilities. I'm linking here a link to the Microsoft-released spec for the lnk files and also a couple of blog posts that detail some of the complexities of properly parsing them.
2a) http://download.microsoft.com/download/a/e/6/ae6e4142-aa58-45c6-8dcf-a657e5900cd3/[MS-SHLLINK].pdf [^]
2b) http://blog.0x01000000.org/2010/08/10/lnk-parsing-youre-doing-it-wrong-i/ [^]
2c) http://blog.0x01000000.org/2010/08/13/lnk-parsing-youre-doing-it-wrong-ii/ [^]
|Since we are doing 64bit builds now, which will work fine, I don't think this is necessary for 0.25.0|
|2008-01-12 08:44||ilmcuts||New Issue|
|2008-01-12 08:47||ilmcuts||Status||@10@ => feedback|
|2008-01-12 08:47||ilmcuts||Additional Information Updated|
|2008-01-12 08:48||ilmcuts||Relationship added||child of 0000032|
|2008-04-22 12:18||jugg||Relationship added||child of 0000042|
|2008-04-22 12:23||jugg||Relationship deleted||child of 0000032|
|2008-04-30 16:50||jugg||Note Added: 0000101|
|2008-12-31 04:04||ilmcuts||Note Added: 0000156|
|2009-03-05 14:46||ilmcuts||Assigned To||=> ilmcuts|
|2009-03-05 14:46||ilmcuts||Status||feedback => confirmed|
|2010-08-31 16:05||tobbe||Note Added: 0000274|
|2010-08-31 16:06||tobbe||Note Edited: 0000274|
|2010-09-01 18:59||alur||Note Added: 0000275|
|2011-11-16 20:46||Vyrolan||Note Added: 0000282|
|2013-08-01 12:21||alur||Relationship added||related to 0000070|
|2013-08-01 12:23||alur||Note Added: 0000300|
|2013-08-01 12:23||alur||Relationship deleted||child of 0000042|
|Copyright © 2000 - 2009 Mantis Group|