madasraka Posted April 20, 2010 Share Posted April 20, 2010 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) Link to comment Share on other sites More sharing options...
jaberwacky Posted April 20, 2010 Share Posted April 20, 2010 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) Helpful Posts and Websites: AutoIt3 Variables and Function Parameters MHz | AutoIt Wiki | Using the GUIToolTip UDF BrewManNH | Can't find what you're looking for on the Forum? Link to comment Share on other sites More sharing options...
madasraka Posted April 20, 2010 Author Share Posted April 20, 2010 so how do i bypass it in the 32bit based script so it would get to 64bit program files folder ? Link to comment Share on other sites More sharing options...
jaberwacky Posted April 20, 2010 Share Posted April 20, 2010 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? Helpful Posts and Websites: AutoIt3 Variables and Function Parameters MHz | AutoIt Wiki | Using the GUIToolTip UDF BrewManNH | Can't find what you're looking for on the Forum? Link to comment Share on other sites More sharing options...
MHz Posted April 20, 2010 Share Posted April 20, 2010 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. Link to comment Share on other sites More sharing options...
madasraka Posted April 20, 2010 Author Share Posted April 20, 2010 (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 (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 Link to comment Share on other sites More sharing options...
smashly Posted April 20, 2010 Share Posted April 20, 2010 (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 April 20, 2010 by smashly Link to comment Share on other sites More sharing options...
madasraka Posted April 20, 2010 Author Share Posted April 20, 2010 $ProgramFilesDir = StringReplace(@ProgramFilesDir, ' (x86)', "") MsgBox(0, "Program Files", $ProgramFilesDir)) Would require same amounf of If's. @HomeDrive & "\Program Files" seems to do the job Link to comment Share on other sites More sharing options...
trancexx Posted April 20, 2010 Share Posted April 20, 2010 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. ♡♡♡ . eMyvnE Link to comment Share on other sites More sharing options...
supersonic Posted April 20, 2010 Share Posted April 20, 2010 (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 April 20, 2010 by supersonic Link to comment Share on other sites More sharing options...
Anteaus Posted April 20, 2010 Share Posted April 20, 2010 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. Link to comment Share on other sites More sharing options...
JFX Posted April 20, 2010 Share Posted April 20, 2010 Redirection makes no sense as theres nothing to redirect MsgBox(0,'nativ ProgramFiles', EnvGet('ProgramW6432')) Link to comment Share on other sites More sharing options...
MHz Posted April 20, 2010 Share Posted April 20, 2010 $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. Link to comment Share on other sites More sharing options...
JFX Posted April 20, 2010 Share Posted April 20, 2010 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 windowshowever the 'sysnative' variable came with vista and is not availably on xp x64 without hotifx. Link to comment Share on other sites More sharing options...
MHz Posted April 20, 2010 Share Posted April 20, 2010 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. Link to comment Share on other sites More sharing options...
Mecano Posted September 25, 2010 Share Posted September 25, 2010 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/ Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now