Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

AutoHotkey64: 64-bit AutoHotkey_L [updated 6/24/10]


  • This topic is locked This topic is locked
40 replies to this topic
fincs
  • Moderators
  • 1662 posts
  • Last active:
  • Joined: 05 May 2007
Note: AutoHotkey64 has been merged into AutoHotkey_L

Hello,
This is a native build of AutoHotkey_L for AMD64 processors (32-bit version also available with all additions such as COM).

Posted Image

Download (r8)

Demo script: AhkRss (requires Unicode-enabled XPath)

This was built with Visual C++ 2010 Express using the Windows 7.1 SDK. Currently only the 'Release' and 'ReleaseAnsi' targets are supported for both processors.

Changelog:[*:13m4u4nd]r8: Added Lexikos' DllCall() changes. Merged latest changes from AutoHotkey_L repository. 64-bit binaries are now compressed with MPRESS. Added A_Is64bitOS which returns 1 if the script is running under 64-bit Windows, regardless of the AutoHotkey version.
[*:13m4u4nd]r7: Upgraded to AutoHotkey_L L52.
[*:13m4u4nd]r6: Fixed typo in NumGet()/NumPut().
[*:13m4u4nd]r5: Fixed bug in RegisterCallback() and made pointer types unsigned (thanks Sean).
[*:13m4u4nd]r4: Implemented DllCall() and RegisterCallback(). Fixed some misc issues in the GUI code.
[*:13m4u4nd]r3: Added Sean's COM additions. The debugger is now enabled. VC++ 2010 Express is now used.
[*:13m4u4nd]r2: All warnings gone and some more INT_PTR to int cast errors fixed. Variable list now works properly. ANSI/Unicode builds now both available.
[*:13m4u4nd]r1: Initial release.

sunday
  • Guests
  • Last active:
  • Joined: --
Sounds great!!
I look forward to the implementation of DllCall function.

fincs
  • Moderators
  • 1662 posts
  • Last active:
  • Joined: 05 May 2007
New release now available.

infogulch
  • Moderators
  • 717 posts
  • Last active: Jul 31 2014 08:27 PM
  • Joined: 27 Mar 2008
No lazy-person-accessible changelog? :(

Sean
  • Members
  • 2462 posts
  • Last active: Feb 07 2012 04:00 AM
  • Joined: 12 Feb 2007
Excellent. Although I haven't tried it yet, this is the one that I've been constantly feeling the need of recently.

PS. I added COM support to AutoHotkey64. See here.

fincs
  • Moderators
  • 1662 posts
  • Last active:
  • Joined: 05 May 2007
New release now available. It adds Sean's COM stuff and reenables the debugger.
Screenshot of both things in action (click for full size version):
Posted Image
Yes, SciTE4AutoHotkey v2.1 will be released someday :p
Speaking of it, I've tweaked the AutoComplete and calltip features to add AutoHotkey_L stuff.

Sean
  • Members
  • 2462 posts
  • Last active: Feb 07 2012 04:00 AM
  • Joined: 12 Feb 2007
Great! I redirected the link for AutoHotkey64_COM to this thread.

fincs
  • Moderators
  • 1662 posts
  • Last active:
  • Joined: 05 May 2007
New release available.

After some research and crazy hours of coding and debugging DllCall() and RegisterCallback() are working now.
The catch? Exceptions don't seem to work properly. That's all.

I've used some ASM code from DynCall to implement the dynamic function calling, so props to the guys that worked on it!

Paulo_Guest
  • Guests
  • Last active:
  • Joined: --
Congratulations Fincs, the 64bit version is very welcome.Thanks.
Tested both (unicode and ansi) and everything seems OK.

Just one minor bug.
The ansi versions interpretes the "‹" char as "?" char.The unicode is OK.
‹var := "bla"
msgbox, %‹var%


fincs
  • Moderators
  • 1662 posts
  • Last active:
  • Joined: 05 May 2007

Just one minor bug.
The ansi versions interpretes the "‹" char as "?" char.The unicode is OK.

‹var := "bla"
msgbox, %‹var%

That actually has nothing to do with AutoHotkey64.
The latest release of AutoHotkey_L (on which AHK64 is based) changed the default encoding for BOM-less scripts, it's now UTF-8 instead of the system default codepage. As you probably used it to save the script it gives an error because the codepage representation of '‹' is not valid UTF-8.
The Unicode build is not affected because the invalid character becomes the replacement character � (which is a valid variable character, probably not a good idea):
0[1 of 3]: 0
ErrorLevel[1 of 3]: 0
�var[3 of 3]: bla
In order to fix the problem save the script as UTF-8 or use the /CP0 switch.

sunday
  • Guests
  • Last active:
  • Joined: --
Wow, this is what I wanted. Thanks, fincs!!

I have just one thing I want to figure out to move to the 64 bit version.
The following script shows "1" if you use Synaptics Touchpad and touch it.
hSynTP := DllCall("CreateFile", "Str", "\\.\SYNTP", "UInt", 0xC0000000, "UInt", 3, "UInt", 0, "UInt", 3, "UInt", 80, "UInt", 0)
InBuf := DllCall("GlobalAlloc", "UInt", 0x40, "UInt", 16)
OutBuf := DllCall("GlobalAlloc", "UInt", 0x40, "UInt",  8)
NumPut(0x01000000 |  10, InBuf + 4 * 0)
NumPut(0x01000000 | 729, InBuf + 4 * 1)
NumPut(0xFFFFFFFE      , InBuf + 4 * 3)
DllCall("DeviceIoControl", "UInt", hSynTP, "UInt", 0x80006004, "UInt", InBuf, "UInt", 16, "UInt", OutBuf, "UInt", 8, "UInt", 0, "UInt", 0) ; <- This doesn't respond.
TouchPad := NumGet(OutBuf + 1) > 0
MsgBox % TouchPad
This doen't work on the 64w.exe while it works well on the original AHK_L or the 32w.exe.
I figured out that DllCall for DeviceIoControl in this particular setting doesn't respond, but I have no idea beyond this.
Do you or anyone have any suggestion for this issue?

fincs
  • Moderators
  • 1662 posts
  • Last active:
  • Joined: 05 May 2007
Exactly.
Pointers in 64-bit processors are 8 bytes long instead of 4 bytes.
A new type was added to AutoHotkey_L (ptr) that represents a pointer. It can also be used for size_t parameters.
There's also A_PtrSize.
My attempt at a 32-bit/64-bit compatible version of the script:
hSynTP := DllCall("CreateFile", "Str", "\\.\SYNTP", "UInt", 0xC0000000, "UInt", 3, "[color=red]ptr[/color]", 0, "UInt", 3, "UInt", 80, "[color=red]ptr[/color]", 0, "[color=red]ptr[/color]")
InBuf := DllCall("GlobalAlloc", "UInt", 0x40, "[color=red]ptr[/color]", 16, "[color=red]ptr[/color]")
OutBuf := DllCall("GlobalAlloc", "UInt", 0x40, "[color=red]ptr[/color]",  8, "[color=red]ptr[/color]")
NumPut(0x01000000 |  10, InBuf + [color=red]A_PtrSize[/color] * 0, 0, "[color=red]ptr[/color]")
NumPut(0x01000000 | 729, InBuf + [color=red]A_PtrSize[/color] * 1, 0, "[color=red]ptr[/color]")
NumPut((~0) - 1, InBuf + [color=red]A_PtrSize[/color] * 3, "[color=red]ptr[/color]")
DllCall("DeviceIoControl", "[color=red]ptr[/color]", hSynTP, "UInt", 0x80006004, "[color=red]ptr[/color]", InBuf, "UInt", 16, "[color=red]ptr[/color]", OutBuf, "UInt", 8, "[color=red]ptr[/color]", 0, "[color=red]ptr[/color]", 0)
TouchPad := NumGet(OutBuf + 1) > 0
MsgBox % TouchPad

The next version will make ptr the default type for NumPut() and NumGet() to ease porting (ex: COM.ahk because of some still useful functions like COM_QueryInterface).

tank
  • Administrators
  • 4345 posts
  • AutoHotkey Foundation
  • Last active: May 02 2019 09:16 PM
  • Joined: 21 Dec 2007
because ahk is aimed at non expert non programers how bout instead of showing WIN_VISTA show WIN_VISTA32 and WIN_VISTA64 same of win7

<!-- m -->http://social.msdn.m... ... a19892ca53<!-- m -->
more to the point
is64bit()
{
	EnvGet,pa,PROCESSOR_ARCHITECTURE
	Return InStr(pa,"64")
}

MsgBox % "OS is "  A_OSVersion (is64bit() ? "64" : "32")
ExitApp

Never lose.
WIN or LEARN.

fincs
  • Moderators
  • 1662 posts
  • Last active:
  • Joined: 05 May 2007
It would break scripts.
In order to detect 64-bit Windows you just have to check if A_PtrSize is 8.

sunday
  • Guests
  • Last active:
  • Joined: --
Thank you very much, fincs.
Now the message box shows up, although the script doesn't respond to the touchpad when run on the AHK64.
However, since it seems a matter of the device driver but of the AHK64, I'm looking for some more information to fix it.

If anyone could help fix this script, it would be greatly appreciated.