When all Windows O/S's were 32 bit, having a single system variable such as "A_ProgramFiles" made sense.
However, now that we have O/S's that are 64 bits, with seperate directory branches for 32 and 64 bit apps/components, does AHK support variables that allow you to specify which one exactly you want? Or do you have to give an explicit path?

Variables to differentiate between 32 and 64 bit?
Started by
Mgrep
, Dec 22 2009 07:22 AM
4 replies to this topic
#1
-
Posted 22 December 2009 - 07:22 AM

If you're specifically interested in getting the Program Files paths, it can be done with EnvGet.
If you want to detect whether the OS is 64-bit, you may use something like this:
The following should continue to work (and can be used to retrieve other system information):
EnvGet, ProgFiles32, ProgramFiles(x86) if ProgFiles32 = ; Probably not on a 64-bit system. EnvGet, ProgFiles32, ProgramFiles EnvGet, ProgFiles64, ProgramW6432 MsgBox % "32: " ProgFiles32 "`n64: " ProgFiles64I am running Windows 7 64-bit. If I type "set program" into a 64-bit command prompt (Start, type "cmd.exe"), it lists these variables:
ProgramData=C:\ProgramData ProgramFiles=C:\Program Files ProgramFiles(x86)=C:\Program Files (x86) ProgramW6432=C:\Program FilesTyping the same into a 32-bit command prompt (Start, type "C:\Windows\SysWow64\cmd.exe"), lists this:
ProgramData=C:\ProgramData ProgramFiles=C:\Program Files [color=red](x86)[/color] ProgramFiles(x86)=C:\Program Files (x86) ProgramW6432=C:\Program FilesThe environment variable ProgramFiles appears to be consistent with AutoHotkey's A_ProgramFiles (A_ can be omitted), which actually uses the registry value ProgramFilesDir in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion. There are also other registry values containing the 32-bit and 64-bit paths, but I suppose the environment variables are easier to use.
If you want to detect whether the OS is 64-bit, you may use something like this:
if DllCall("IsWow64Process", "uint", DllCall("GetCurrentProcess"), "int*", isWow64process) && isWow64process MsgBox This OS is 64-bit.However, this method will not work if AutoHotkey is ever ported to 64-bit.

VarSetCapacity(si,44) DllCall("GetNativeSystemInfo", "uint", &si) if ErrorLevel { MsgBox Windows XP or later required. ExitApp } arc := NumGet(si,0,"ushort") MsgBox % arc=0 ? "x86" : arc=9 ? "x64" : arc=6 ? "IA64" : "UNKNOWN"
#2
-
Posted 22 December 2009 - 08:51 AM

Well, it's not just that. I'm referring to working with the system variables in general.
For example, using your test of which Command Prompt is being run, if I set up a script to do this:
...even though the Title Bar shows that what's loaded is the cmd.exe in system32, running "set program" shows it as the 32 bit version.
For example, using your test of which Command Prompt is being run, if I set up a script to do this:
!F7::Run %A_WinDir%\system32\cmd.exe
...even though the Title Bar shows that what's loaded is the cmd.exe in system32, running "set program" shows it as the 32 bit version.
#3
-
Posted 22 December 2009 - 05:32 PM

For that specific issue, refer to File System Redirector, How Run msconfig using AutoHotKey? or one of the other threads where it has been discussed.
I suppose there isn't much in general that is related to system variables in this context. Just note that 32-bit applications do not run directly on 64-bit Windows, but inside WOW64. They are essentially running in a 32-bit environment, so will not have direct access to the 64-bit environment variables. As for other system information, it's a matter of finding the appropriate Windows API.
I suppose there isn't much in general that is related to system variables in this context. Just note that 32-bit applications do not run directly on 64-bit Windows, but inside WOW64. They are essentially running in a 32-bit environment, so will not have direct access to the 64-bit environment variables. As for other system information, it's a matter of finding the appropriate Windows API.
#4
-
Posted 23 December 2009 - 08:38 AM

I think there needs to be variables to handle scripts so that they can run as expected whether on 32-bit Windows or 64-bit Windows. The workarounds are just too cumbersome and should just be integrated into AHK. There should perhaps be a flag like "#Redirect64 Off|On". Example:
Alternatively or in addition, there could be special variables and commands that default to the normal version if the script is run on 32-bit Windows:
ComspecW6432
A_ProgramFilesW6432
A_WindirW6432 (Would not redirect from System32 subdirectory)
RegReadW6432
RegWriteW6432
EnvGetW6432
#Redirect64 Off ; Bypasses File System & Registry Redirection for Scripts run on 64-bit Windows RunWait, %comspec%, %A_ProgramFiles% ; Will run C:\Windows\Sysnative\cmd.exe (rather than C:\Windows\SysWOW64\cmd.exe) in the directory C:\Program Files (rather than C:\Program Files(x86) ) RegWrite, REG_SZ, HKEY_LOCAL_MACHINE, Software, Valuename, Value; is not redirected to HKEY_LOCAL_MACHINE\Software\Wow6432Node
Alternatively or in addition, there could be special variables and commands that default to the normal version if the script is run on 32-bit Windows:
ComspecW6432
A_ProgramFilesW6432
A_WindirW6432 (Would not redirect from System32 subdirectory)
RegReadW6432
RegWriteW6432
EnvGetW6432
#5
-
Posted 15 February 2010 - 08:42 PM
