Wow64redirection has no effect

[madasraka 0]

I know there are many similar posts, but i cant figure out why i still have this problem with getting the right program files folder.

I have this at top of my code

If $OSbit = "X64" Then
    DllCall("kernel32.dll", "int", "Wow64DisableWow64FsRedirection", "int", 1)
EndIf

Then

$Var = @ProgramFilesDir

MsgBox(0,'',$Var)

says:C:\Program Files (x86)

What am i doing wrong ?

Here is full code together to test.

$OSbit = @OSArch
If $OSbit = "X64" Then
    DllCall("kernel32.dll", "int", "Wow64DisableWow64FsRedirection", "int", 1)
EndIf
$test = @ProgramFilesDir
MsgBox(0,'',$test)

[jaberwacky 310]

I believe that is the correct behavior, because when running an x64 OS, when you install a 32bit program, it installs it into C:\Program Files (x86)

[madasraka 0]

so how do i bypass it in the 32bit based script so it would get to 64bit program files folder ?

[jaberwacky 310]

so how do i bypass it in the 32bit based script so it would get to 64bit program files folder ?

Why would you want to?

[MHz 71]

What am i doing wrong ?

Here is full code together to test.

$OSbit = @OSArch
If $OSbit = "X64" Then
    DllCall("kernel32.dll", "int", "Wow64DisableWow64FsRedirection", "int", 1)
EndIf
$test = @ProgramFilesDir
MsgBox(0,'',$test)

You are not accessing the filesystem which the DllCall handles. The redirection is done at filesystem level.

You may also find that some macros are populated at execution of the script and never change like the @ProgramFilesDir you show.

[madasraka 0]

so how (am sorry i dont see any clues at this point) do i get my 32bit script to get to 64bit folder (C:\program files) ?

There has to be a way

1st i would like to commend on 64bit behavior.

Program Files (X64) is what had to be used for 64bit programs instead of Program Files.

If later on Windows would evolve into 128bit, then creating another Program Files (X128) would be easy and previous versions would not have to be changed ever thus making it a way way better alternative instead of this stupid redirections.

To bad bill gates is not around anymore, otherwise i would kick his nuts for doing this to me (he lives just an hour away )

EDIT:

Am gonna start going with @HomeDrive & "\Program Files" instead of this (at this point) useless macro

Edited April 20, 2010 by madasraka

[smashly 11]

The @ProgramFilesDir macro is not to balme, even if using windows default Environment variable %PROGRAMFILES% the same result happens.

Even though there is a default %PROGRAMFILES(X86)% environment variable in x64 windows.

ConsoleWrite(EnvGet("PROGRAMFILES") & @LF)

Using a 32 bit app then windows maps it as 32 bit.

Windows is the culprit and not the @ProgramFilesDir

Another approach to your hard set "Program Files" that will work on x86 or x64:

$ProgramFilesDir = StringReplace(@ProgramFilesDir, ' (x86)', "")
MsgBox(0, "Program Files", $ProgramFilesDir))

Edited April 20, 2010 by smashly

[madasraka 0]

$ProgramFilesDir = StringReplace(@ProgramFilesDir, ' (x86)', "")
MsgBox(0, "Program Files", $ProgramFilesDir))

Would require same amounf of If's.

@HomeDrive & "\Program Files" seems to do the job

[trancexx 892]

1st i would like to commend on 64bit behavior.

Program Files (X64) is what had to be used for 64bit programs instead of Program Files.

If later on Windows would evolve into 128bit, then creating another Program Files (X128) would be easy and previous versions would not have to be changed ever thus making it a way way better alternative instead of this stupid redirections.

To bad bill gates is not around anymore, otherwise i would kick his nuts for doing this to me (he lives just an hour away )

Ahh, but you are wrong. All makes perfect sense, it's just you are not able to see it.

There will never be 128bit windows. Unfortunately by saying that you showed your current level to be pretty low.

[supersonic 2]

Hi!

This works for me pretty well:

Func ___WOW64_FsRedirection($iVal = True)
    Local $RetVal = 0
    If @AutoItX64 = 0 And StringInStr(@OSArch, "6", 0) > 0 Then
        Switch $iVal
            Case False ; Disables the file system redirector for a 32-bit process running on a 64-bit OS.
                DllCall("kernel32.dll", "int", "Wow64DisableWow64FsRedirection", "int", 0)
            Case True ; Reverts the file system redirector for a 32-bit process running on a 64-bit OS.
                DllCall("kernel32.dll", "int", "Wow64RevertWow64FsRedirection", "int", 0)
        EndSwitch
        Switch @error
            Case 0
                ConsoleWrite("___WOW64_FsRedirection(" & $iVal & ") -> [" & @error & "]" & @CRLF)
                Return SetError(@error, 0, 1)
            Case Else
                ConsoleWrite("___WOW64_FsRedirection(" & $iVal & ") -> [" & @error & "]" & @CRLF)
                Return SetError(@error, 0, -1)
        EndSwitch
    EndIf
    Return $RetVal
EndFunc

I found it here: http://www.autoitscript.com/forum/index.php?showtopic=111647 .

Sometimes it's useful to be able to check files with 'FileGetVersion()' when your script is 32-bit-compiled on a 64-bit OS.

When using this function you have to change '@SystemDir' into '@WindowsDir & "\system32"' in order to work properly.

Greets,

-supersonic.

Edited April 20, 2010 by supersonic

[Anteaus 0]

Ahh, but you (madrasaka) are wrong. All makes perfect sense, it's just you are not able to see it.

Actually, the need for two system folders makes sense, as a lot of 64-bit DLLs have the same names as the 32-bit equivalents. The need for two Program Files folders is another matter, and I've never seen any convincing explanation for this.

There will never be 128bit windows.

No, by that time we'll have all seen the unholy mess Microsoft are getting into with this kludged code, and switched to Linux.

-I'm only half-joking there too, when you consider the mess of cyclic junctions inside userprofiles along with this, things are getting totally out-of-hand. It's time we got back to a computer where code does what it says on the tin.

[JFX 10]

Redirection makes no sense as theres nothing to redirect

MsgBox(0,'nativ ProgramFiles', EnvGet('ProgramW6432'))

[MHz 71]

$ProgramFilesDir = StringReplace(@ProgramFilesDir, ' (x86)', "")
MsgBox(0, "Program Files", $ProgramFilesDir))

Would require same amounf of If's.

@HomeDrive & "\Program Files" seems to do the job

%HomeDrive% is where the home folder is (the user profiles). %ProgramFiles% folder can be located on another partition/drive so using %HomeDrive% is not reliable. Nether is %SystemDrive% as that is where the system folder is located on. So smashly has a more reliable method.

Redirection makes no sense as theres nothing to redirect

MsgBox(0,'nativ ProgramFiles', EnvGet('ProgramW6432'))

Introduced in Win7 so only Win7 is valid for use.

[JFX 10]

Introduced in Win7 so only Win7 is valid for use.

Depend on who you trust more, a wrong ms article or on user of xp x64 for years.

the variables %ProgramW6432% and %CommonProgramW6432% are there in all x64 version of windows

however the 'sysnative' variable came with vista and is not availably on xp x64 without hotifx.

[MHz 71]

JFX,

Thanks for the info. It would not be the 1st time that a MS article was incorrect. I did test %ProgramW6432% earlier on Win7 and it appeared good until I read the MS article which destroyed the idea. But appears good now with your assurance.

[Mecano 0]

A nice article about redirection can be found here:

http://www.sepago.de/helge/2009/06/04/where-is-the-hosts-file-on-windows-x64/