Sign in to follow this  
Followers 0
madasraka

Wow64redirection has no effect

16 posts in this topic

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)

Share this post


Link to post
Share on other sites



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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

#6 ·  Posted (edited)

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 :idea: (he lives just an hour away :) )

EDIT:

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

Edited by madasraka

Share this post


Link to post
Share on other sites

#7 ·  Posted (edited)

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 by smashly

Share this post


Link to post
Share on other sites

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

Would require same amounf of If's.

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

Share this post


Link to post
Share on other sites

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 :idea: (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.


♡♡♡

.

eMyvnE

Share this post


Link to post
Share on other sites

#10 ·  Posted (edited)

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 by supersonic

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

Redirection makes no sense as theres nothing to redirect

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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/

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0