AutoHotkey 64-bit/32-bit differences

[jeeswg]

POINTERS / DLLCALL

- To make 32-bit scripts, 64-bit/32-bit two-way compatible, you have to make changes to DllCall, NumGet/NumPut, VarSetCapacity (and struct sizes/offsets).
- The result of SendMessage may need to be handled differently.
- A_PtrSize is 8 on 64-bit, 4 on 32-bit.
- Ptr is Int64 on 64-bit, Int on 32-bit.
- UPtr is UInt64 on 64-bit (but stored as Int64), UInt on 32-bit.
- In DllCall, Cdecl has no effect on 64-bit builds of AutoHotkey.
- Any external dll files must match the bitness of AHK.
- When dealing with the memory of an external program, you may have to use offsets/sizes appropriate for the bitness of that program.

FILES

- The bitness will effect which folder is used. This line is often useful for 32-bit scripts on 64-bit PCs:
DllCall("kernel32\Wow64DisableWow64FsRedirection", "Ptr*",0)
- E.g. C:\Windows\System32 (64-bit).
- E.g. C:\Windows\SysWOW64 (32-bit). WoW64 (Windows 32-bit on Windows 64-bit).
- The path of A_ProgramFiles can be affected.

REGISTRY

- Use SetRegView, to determine whether the RegXXX functions operate on the 64-bit or 32-bit registry. SetRegView changes the value of A_RegView.
- E.g. on 64-bit PCs, there are 32-bit 'Wow6432Node' registry keys.

OS

- A_Is64bitOS is 1 on 64-bit PCs, 0 on 32-bit PCs.

BITWISE-NOT

- In this example, the behaviour is consistent across 64-bit/32-bit, but differs between AHK v1/v2:

Code: Select all

MsgBox, % Clipboard := ~0 ;4294967295 ;for both AHK v1 64-bit/32-bit
MsgBox(Clipboard := ~0) ;-1 ;for both AHK v2 64-bit/32-bit

;for reference:
MsgBox, % Clipboard := 0 ^ -1 ;-1 ;for both AHK v1 64-bit/32-bit
MsgBox(Clipboard := 0 ^ -1) ;-1 ;for both AHK v2 64-bit/32-bit

- The AHK v1 documentation has a note re. bitwise-not.
Variables and Expressions - Definition & Usage | AutoHotkey
https://autohotkey.com/docs/Variables.htm#Operators

Bitwise-not (~): This inverts each bit of its operand. If the operand is a floating point value, it is truncated to an integer prior to the calculation. If the operand is between 0 and 4294967295 (0xffffffff), it will be treated as an unsigned 32-bit value. Otherwise, it is treated as a signed 64-bit value. For example, ~0xf0f evaluates to 0xfffff0f0 (4294963440).

FURTHER

- The displayed precision is different:

Code: Select all

MsgBox(Clipboard := 2.0 ** 112) ;5192296858534827600000000000000000.0 ;AHK v2 (32-bit)
MsgBox(Clipboard := 2.0 ** 112) ;5192296858534827628530496329220096.0 ;AHK v2 (64-bit)

- Microsoft's ScriptControl is not available to 64-bit programs.
- In AHK basic objects. AHK 32-bit supports -2147483648 (-0x80000000) to 2147483647 (0x7FFFFFFF). AHK 64-bit supports 64-bit signed integers: -9223372036854775808 (-0x8000000000000000) to 9223372036854775807 (0x7FFFFFFFFFFFFFFF).

- Are there other differences? Or other things worth mentioning re. AHK and bitness?
- What explains the displayed precision difference, I couldn't find it documented.

MORE ADDITIONS

- (Thanks Helgef.)
- CallbackCreate [AHK v1: RegisterCallback].
- OnMessage.

[Helgef]

- Precision is different:

There is no difference in the precision of the calculation, only in the string conversion. Both strings represent the same binary number.

Are there other differences

callbackcreate and onmessage comes to mind.

Cheers.