» home
» bugs
» git

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0000039 [litestep core] core minor always 2008-01-12 08:44 2013-08-01 12:23
Reporter ilmcuts View Status public  
Assigned To ilmcuts
Priority none Resolution open  
Status confirmed   Product Version
Summary 0000039: Shortcuts to 64-bit progams broken when running in WOW64
Description 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.
Attached Files

- Relationships
related to 0000070resolvedilmcuts 64-Bit startup items are not run 

-  Notes
(0000101)
jugg (manager)
2008-04-30 16:50

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
http://msdn.microsoft.com/en-us/library/ms684139(VS.85).aspx [^]

// 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)");
(0000156)
ilmcuts (manager)
2008-12-31 04:04

Wow64DisableWow64FsRedirection unfortunately does not apply to this specific case.
(0000274)
tobbe (developer)
2010-08-31 16:05
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 [^]

Quote:

> 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.

(0000275)
alur (developer)
2010-09-01 18:59

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.
(0000282)
Vyrolan (reporter)
2011-11-16 20:46

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/ [^]
(0000300)
alur (developer)
2013-08-01 12:23

Since we are doing 64bit builds now, which will work fine, I don't think this is necessary for 0.25.0

- Issue History
Date Modified Username Field Change
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
Powered by Mantis Bugtracker