madasraka 0 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) Share this post Link to post Share on other sites
jaberwacky 327 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? Share this post Link to post Share on other sites
madasraka 0 Posted April 20, 2010 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
jaberwacky 327 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? Share this post Link to post Share on other sites
MHz 80 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. Share this post Link to post Share on other sites
madasraka 0 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 Share this post Link to post Share on other sites
smashly 12 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 Share this post Link to post Share on other sites
madasraka 0 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 Share this post Link to post Share on other sites
trancexx 1,013 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 Share this post Link to post Share on other sites
supersonic 4 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 Share this post Link to post Share on other sites
Anteaus 0 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. Share this post Link to post Share on other sites
JFX 10 Posted April 20, 2010 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
MHz 80 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. Share this post Link to post Share on other sites
JFX 10 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. Share this post Link to post Share on other sites
MHz 80 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. Share this post Link to post Share on other sites
Mecano 0 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/ Share this post Link to post Share on other sites