This request summarizes some information from other forum threads (which I'll try to link), but its purpose is to crystalize and address the remaining issues facing a (necessarily 32-bit) AHK program attempting to operate in a fully 64-bit-aware fashion on a 64-bit platform, by which I mean a program that wishes to access every area of the 64-bit environment's file system and Registry unfettered by sneaky File System and Registry redirection on the part of the OS.
As I see it, there are three aspects to writing 64-bit-aware AHK programs, only one of which (the third listed) seems to require additional support from AutoHotkey (see, this is going to be easy ):
(1) Identification: For a 32-bit program to be 64-bit-aware, it first needs to be able to identify the fact that it is running on a 64-bit platform in order to take appropriate measures where necessary. This is made very easy by the 64-bit operating system automatically providing 32-bit processes with the PROCESSOR_ARCHITEW6432 environment variable (typically set to AMD64). If an AHK program retrieves an empty value for this variable, then it's running on a 32-bit platform, otherwise it's running on a 64-bit platform. (I'll ignore the possibility of a perverse joke being played on a program by creating this variable on a 32-bit platform! ) See http://www.autohotke...pic.php?t=46927
(2) File System access: Although a 64-bit OS takes some "mild" steps to keep 32-bit programs away from certain 64-bit areas of the file system, they are easily worked around once the program knows it's running on a 64-bit platform: (a) the automatic redirection of %SystemRoot%\System32 to %SystemRoot%\SysWOW64 is easily circumvented by instead accessing the "pseudo-folder" %SystemRoot%\SysNative (see also the Lexicos Wow64DisableWow64FsRedirection suggestion at http://www.autohotke...topic44049.html) and ( the presentation of the ProgramFiles and CommonProgramFiles environment variables as their "(x86)" versions can be ignored by accessing instead the %ProgramW6432% and %CommonProgramW6432% locations when wishing to operate on the 64-bit folders.
Which brings us to
(3) Registry access: Here the issue is that the 64-bit OS will redirect a 32-bit program's attempt to access HKLM\Software to HKLM\Software\Wow6432Node instead, and this time there's no "magic pseudo-key" available (HKLM\SoftNative ) nor any API call to temporarily disable this redirection. The official Microsoft answer -- see the links at http://blogs.msdn.co.../05/107433.aspx -- is to use the KEY_WOW64_64KEY flag with the RegCreateKeyEx, RegDeleteKeyEx and RegOpenKeyEx API functions. tomte provides AHK functions RegRead64() and RegWrite64() at http://www.autohotke...topic39560.html, which is a great help for now, but (and this finally is my actual request), it would be tremendous if AutoHotkey itself provided a way to direct the Registry functions to use (or stop using) the flag in question at any point in a script (this would include not only RegRead, RegWrite and RegDelete, but also Registry loops). How hard or easy the implementation of this suggestion would be probably depends on whether AHK already utilizes the "Ex" variants of the Registry API functions -- if so, then it's just a matter of adding/removing the flag, otherwise ... well it's a little more work. :wink:
As always, Chris, I thank you for merely considering the idea.
Enabling 64-bit-aware AutoHotkey programs
No replies to this topic