My program -for Windows 7 and 8- scans an disk and shows the paths in a grid. 
Some link file does not have the right icon when the application is compiled *32 bit*.
When  the application is *64 bit* there are no problems.
I use "IShellLink" and "IExtractIcon". But also "SHDefExtractIcon", "ExtractIconEx" have the same problem.

The root of the problem is, that for a 32 bit application the link destination does not exists. 
"FileExists", "FindFirstFile", "CreateFile"  return an file not found error for the target.

An example is:
"C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Accessories\Snipping Tool.lnk"
destination: "%Windir%\system32\SnippingTool.exe, 0"

I do not like to make and test two versions of the program for this detail problem.

Raf

On 10/23/2014 2:36 PM, Remy Lebeau (TeamB) wrote:
> 2. disable the File System Redirectory temporarily via Wow64DisableWow64FsRedirection() 
> and Wow64RevertWow64FsRedirection().

This doesn't work for shell functions because it also affects the DLL
search path, so the system ends up trying to load 64-bit DLLs and failing.

-- 
Craig Peterson
Scooter Software

> {quote:title=raf bakker wrote:}{quote}

Thank you for your help.

After the "IExtractIcon.Extract" fails i test for 3 cases.
1. The icon location is known.
    In this case i replace "system32" with "sysnative" to get an icon handle with "ExtractIconEx"
2. Only an IDlist is present.
   I use "SHGetFileInfo" to get the handle.
3. There is no target, no IDList and no Icon location.
    I can get no icon handle.

Only this cases are present on my computer. Must be tested. 

Raf.

Just wrote:

> AFAIK, the WOW64 file system redirection control functions affect
> only for the calling thread.

I could have sworn I read somewhere on MSDN that the FSR was system-wide. 
 Oh well.

The documentation does say:

{quote}
Some functions, such as CreateProcessAsUser, do their work on another thread, 
which is not affected by the state of file system redirection in the calling 
thread.
{quote}

So you might still have to watch out, depending on which APIs you use.

Better to use the SysNative alias instead, since it is not affected by the 
FSR.

--
Remy Lebeau (TeamB)

On Thu, 23 Oct 2014 12:36:48 -0700, Remy Lebeau wrote:
> 2. disable the File System Redirectory temporarily via Wow64DisableWow64FsRedirection() 
> and Wow64RevertWow64FsRedirection().  This is not recommended since it is 
> a global setting that affects all processes.

AFAIK, the WOW64 file system redirection control functions affect only for
the calling thread. Here are the function description from the MSDN:

Wow64DisableWow64FsRedirection:
Disables file system redirection for the calling thread.

Wow64EnableWow64FsRedirection:
Enables or disables file system redirection for the calling thread.

raf wrote:

> The root of the problem is, that for a 32 bit application the link
> destination does not exists. "FileExists", "FindFirstFile",
> "CreateFile"  return an file not found error for the target.

That is because the destination file is in the 64bit system32 folder, which 
is protected by WOW64's File System Redirector:

File System Redirector
http://msdn.microsoft.com/en-us/library/windows/desktop/aa384187.aspx

{quote}
In most cases, whenever a 32-bit application attempts to access %windir%\System32, 
the access is redirected to %windir%\SysWOW64. 
{quote}

To avoid that, you need to either:

1. run your app elevated, which disables the File System Redirector.

2. disable the File System Redirectory temporarily via Wow64DisableWow64FsRedirection() 
and Wow64RevertWow64FsRedirection().  This is not recommended since it is 
a global setting that affects all processes.

3. check if the destination is pointing at %windor%\system32, and if so then 
replace it with %windir%\sysnative before accessing the file.  This is the 
preferred solution.

--
Remy Lebeau (TeamB)