What can you use AutoHotkey_H for that would be difficult otherwise?

[sugoi]

AutoHotkey.dll opens the world of AutoHotkey to other programming and scripting languages.
It allows multi-threading by loading a dll multiple times and using its exported functions as well as build-in features like Alias, CriticalObject and other.

I'm gonna be honest, I have no idea what any of this means. Well, sort of? But not really. I thought I may as well just come and ask the people actually using it. What are you actually using AHK_H for?

[william_ahk]

In general, AHK_H encompasses all the necessary features required for a production-level AHK software to distribute to the masses, whereas AHK_L is more suitable for personal projects where you execute source script files instead of packaging them into an executable.

The dll allows languages like python or javascript to use AHK within the code of that language (interop). Interoperability is very useful because imagine if you can only call AHK scripts from another language externally through command line. The AHK executable is launched on every call and parameters are limited to strings, while with dll it is loaded once and you can pass/retrieve complex parameters like arrays and objects.

Besides that, H supports multi-threading, while L is single-threaded. In AHK_L, multi-threading can be emulated using SetTimer. But it does not create a new thread, it queues the fake threads and checks them periodically to decide when to run which, thus you cannot achieve added performance using this method. It is also unpunctual because the one thread can be busy at times.

There are also many useful extra built-in functions that is missing in L, where you have to look for third-party implementations.

One other big reason (probably the most important reason) a lot of people use H is because they want to hide the source code (for totally not malicious purposes ) since it supports script encryption when packing to exe.

[Hobby77]

In general, AHK_H encompasses all the necessary features required for a production-level AHK software to distribute to the masses, whereas AHK_L is more suitable for personal projects where you execute source script files instead of packaging them into an executable.

The dll allows languages like python or javascript to use AHK within the code of that language (interop). Interoperability is very useful because imagine if you can only call AHK scripts from another language externally through command line. The AHK executable is launched on every call and parameters are limited to strings, while with dll it is loaded once and you can pass/retrieve complex parameters like arrays and objects.

Besides that, H supports multi-threading, while L is single-threaded. In AHK_L, multi-threading can be emulated using SetTimer. But it does not create a new thread, it queues the fake threads and checks them periodically to decide when to run which, thus you cannot achieve added performance using this method. It is also unpunctual because the one thread can be busy at times.

There are also many useful extra built-in functions that is missing in L, where you have to look for third-party implementations.

One other big reason (probably the most important reason) a lot of people use H is because they want to hide the source code (for totally not malicious purposes ) since it supports script encryption when packing to exe.

Do you know ahk is gpl2, it means if anyone want to know your source code, you must show it.

[guest3456]

Do you know ahk is gpl2, it means if anyone want to know your source code, you must show it.

do you know that the GPL only applies to the interpreter itself, not to scripts written? no? read and google

[Hobby77]

Do you know ahk is gpl2, it means if anyone want to know your source code, you must show it.

do you know that the GPL only applies to the interpreter itself, not to scripts written? no? read and google

When compiling into exe, it references the entire autohotkey and will be contaminated by the GPL of autohotkey, unless it is in a form similar to autoit's a3x, only encrypting the script and separate it from the interpreter