Upcoming Ahk2Exe Changes (2024)

[JoeWinograd]

TAC,
On point 1, I should have mentioned that I was using MPRESS compression. Please see if that allows you to reproduce it. It is 100% reproducible here.

On point 2, to be clear, the file paths/names stay in the Source, Destination, and Custom Icon boxes, but when hitting the Browse buttons, they do not go to the correct folder...that is, not to the folder where the previous files are located. Regards, Joe

[TAC109]

Joe,
Yes, I tried uncompressed and compressed with Mpress, too.
Can you zip up the .exe's and source, please, and arrange for me to download them?
Thanks

[TAC109]

Joe, also are you generating Unicode? 32bit or 64bit? Does having compression = none change things?
TIA

[JoeWinograd]

> Can you zip up the .exe's and source, please, and arrange for me to download them?

The source is one line:
msgbox hello world
ZIP file attached. The EXE files are in it as TXT files, just in case EXEs are blocked.

> are you generating Unicode? 32bit or 64bit?

Base File drop-down is v1.1.31.1 Unicode 32-bit.

> Does having compression = none change things?

No...that fails, too. Also in ZIP file with nocomp in file names. Regards, Joe

[TAC109]

Thanks, Joe.
I’m unable to look at it until tomorrow NZ time.

[Drugwash]

Additionally, I think this needs a 'Default' button.

There has been one in my experimental GUI from the very beginning. See here.

[JoeWinograd]

Hi TAC (or anyone else who would like to jump in),

A question about the AddResource directive. After compiling a script, there's a resource definition called RCData that has an entry called >AUTOHOTKEY SCRIPT<, which is the source code of the script. In an uncompressed EXE, the source code is immediately visible, like this:

RCData uncompressed.png (67.62 KiB) Viewed 3957 times

In an EXE compressed with MPRESS, the source code is not immediately visible, like this:

RCData compressed with MPRESS.png (64.73 KiB) Viewed 3957 times

However, even when compressed, the RCData resource still has the >AUTOHOTKEY SCRIPT< name. Is there a way to use the AddResource directive to rename the >AUTOHOTKEY SCRIPT< resource so that AUTOHOTKEY SCRIPT is not in the name? I did a rename with ResourceHacker on an uncompressed EXE, but, of course, got the "Could not extract script from EXE" error dialog when running it. Obviously, any renaming would have to be coordinated so that the executable knows the name of the RCData resource that contains the AutoHotkey script (and also so that it works when compressed).

I see the 10 (RT_RCDATA) resource type in the AddResource documentation and am hoping that it's possible to utilize that to replace the >AUTOHOTKEY SCRIPT< name (along the same lines as replacing the icons via AddResource 160/206/207/208), but I don't know how to do that, or even if it's possible. Thanks for ideas on this. Regards, Joe

[TAC109]

(1) If you compile the same file twice with the Beta_7 GUI while specifying a custom icon, the EXEs created are not identical.

Joe
This is to do with the icon you added. Using Resource Hacker, you can see that this icon occupies 5 'ordinal names'. In the first .exe these are 1,2,3,48,49 and in the second these are 1,2,3,50,51. As to why this has happened, it seems this is a Windows thing - the process is managed by the 'UpdateResource' set of Windows API's. I don’t propose to investigate this further as we have an explanation for the .exe differences, and, although different, they will both run correctly.
Cheers

[JoeWinograd]

> In the first .exe these are 1,2,3,48,49 and in the second these are 1,2,3,50,51.

Ah, that is a brilliant catch!

> As to why this has happened, it seems this is a Windows thing - the process is managed by the 'UpdateResource' set of Windows API's.

Very interesting! Beyond my knowledge of the Windows APIs.

> I don’t propose to investigate this further as we have an explanation for the .exe differences, and, although different, they will both run correctly.

Agreed! And they do, indeed, all run correctly.

Thanks for figuring this out...it had me perplexed. Cheers, Joe

[guest3456]

However, even when compressed, the RCData resource still has the >AUTOHOTKEY SCRIPT< name. Is there a way to use the AddResource directive to rename the >AUTOHOTKEY SCRIPT< resource so that AUTOHOTKEY SCRIPT is not in the name? I did a rename with ResourceHacker on an uncompressed EXE, but, of course, got the "Could not extract script from EXE" error dialog when running it. Obviously, any renaming would have to be coordinated so that the executable knows the name of the RCData resource that contains the AutoHotkey script (and also so that it works when compressed).

I see the 10 (RT_RCDATA) resource type in the AddResource documentation and am hoping that it's possible to utilize that to replace the >AUTOHOTKEY SCRIPT< name (along the same lines as replacing the icons via AddResource 160/206/207/208), but I don't know how to do that, or even if it's possible. Thanks for ideas on this. Regards, Joe

just use AutoHotkey_H
the source code is encrypted and there is no AUTOHOTKEY SCRIPT in the RCDATA

[Drugwash]

just use AutoHotkey_H
the source code is encrypted and there is no AUTOHOTKEY SCRIPT in the RCDATA

But does the AHK H compiler sport all the changes and improvements present in this TAC109 version of the compiler?
Because if not, the new/changed directives found in users' scripts will not work in that compiler.

[joedf]

I think you can maybe just use the AHK_H *.bin files instead of AHK_L / v1.1 *.bin files.

[Drugwash]

Doesn't the H compiler do the whole resource obfuscation job in coordination with the H binary (or regardless of it)? I haven't checked the H compiler code (if the obfuscation part is even available) but it may not even change the resource name - it could just do something similar to what the original AHK 1.0 was doing (and that part is missing from the 1.0 code so it can't be checked).

So yeah, one could use the H binary and rename the RC_DATA script resource (assuming the H compiler does that), but to what exactly?
Nope, I don't think it would work. But please feel free to try.

[joedf]

Possible, havent tested. Either way, I think "code protection" is not within the scope of this Ahk2Exe. It was in the original v1.0 but the password feature is gone since v1.1... Forgot the exact reasons why, but that said...

Maybe Ahkcode encrypt is a better idea?
https://www.autohotkey.com/boards/viewtopic.php?t=42494

Or even implement your own exe with a specific key to decrypt the source to allow it to run?

[JoeWinograd]

just use AutoHotkey_H

I never tried AutoHotkey_H. I've had it on my "to experiment with" list for a long time, but it's never made it to the top of the list...now might be the right time.

But does the AHK H compiler sport all the changes and improvements present in this TAC109 version of the compiler?

Good question! I don't know how AutoHotkey_H works, but in the downloaded ZIP file there's a Directives.ahk file that seems to support the following directives:

Directive_SetName(state, txt)
Directive_SetDescription(state, txt)
Directive_SetVersion(state, txt)
Directive_SetCopyright(state, txt)
Directive_SetOrigFilename(state, txt)
Directive_SetCompanyName(state, txt)
Directive_SetMainIcon(state, txt := "")
Directive_PostExec(state, txt)
Directive_UseSeparateTrayIcon(state)
Directive_SetConsoleApp(state)
Directive_OutputPreproc(state, fileName)
Directive_UseResourceLang(state, resLang)
Directive_AddResource(state, UseCompression, UsePassword, rsrc, resName := "")

However, the following code in there indicates that it does not yet support icon resources:

Code: Select all

 else if (resExt = "ico")
   Util_Error("Error: Icon resource adding is not supported yet!")

Because if not, the new/changed directives found in users' scripts will not work in that compiler.

That seems to be the case for the icon resources — 160, 206, 207, 208.

I think you can maybe just use the AHK_H *.bin files instead of AHK_L / v1.1 *.bin files.

Interesting idea. Has anyone tried this?

Regards, Joe

[Drugwash]

I don't know how AutoHotkey_H works [...]

Actually AHK H was the pioneer for this Directives improvement, but TAC109 took this a little bit further and there's now a mismatch between the two. Therefore some L directives would still work in H but others won't. That's the problem.

Interesting idea. Has anyone tried this?

Not me. My opinion is it wouldn't work but since I'm on Linux results may not be accurate anyway.
You may wanna try JoeDF's suggestion.

[TAC109]

@JoeWinograd
Joe, re RCData I have a possible way forward with this. More soon.
Cheers

[JoeWinograd]

My opinion is it wouldn't work

My experiment shows that your opinion is correct. I ran TAC's Ahk2Exe via command line with this param:

/bin "c:\ahkdll-v1-release-master\x64w\AutoHotkeySC.bin"

That is the 64-bit .bin from the AutoHotkey_H ZIP file. The compile appears to be successful, but running the EXE gives a dialog box that says:

Could not extract script from EXE.

Tried it again with the 32-bit .bin from the AutoHotkey_H ZIP file:

c:\ahkdll-v1-release-master\Win32w\AutoHotkeySC.bin

Same result — could not extract script. Furthermore, MSE flagged (and quarantined) the 32-bit attempt with this:

Detected item: Trojan: Win32/Zpevdo.B
Alert level: Severe
Items: file:C:\ahkdll-v1-release-master\Win32w\AutoHotkeySC.bin

Interesting that it did not flag the 64-bit one.

re RCData I have a possible way forward with this

That would be superb! I think that this is the only issue keeping the solution from being perfect for my intended use. Thanks much, Joe

[lexikos]

If you search script.cpp in the AutoHotkey source code for ">AUTOHOTKEY SCRIPT<", you will find the code that retrieves the script text. To change the names, all you would need to do is change the strings in the source code and rebuild (or you could probably change them with a hex editor or script, keeping in mind they are UTF-16 strings in Unicode builds).

The other resource name, ">AHK WITH ICON<", was used to indicate that the script has a custom tray icon and therefore we should use the main icon resource (IDI_MAIN), even on Win9x/2k, where normally the low-colour icon was used. The low-colour icon was removed in v1.1.19.02, so now this resource name is redundant.

These names were also used in v1.0, which used the proprietary "EXEarc" library by the author of AutoIt. The names would not appear in a resource editor because the EXEarc library did not use Win32 resources. The /NoDecompile option never worked in AutoHotkey_L because the source code for that option was never released. The move from EXEarc to the resource API is what enables Ahk2Exe.ahk to work.

For the other reasons EXEarc was removed, you may search the old forum.

@TAC109, it might be best to change Ahk2Exe to use ">AUTOHOTKEY SCRIPT<" regardless of whether there's a custom icon, when compiling for v1.1.19.02 or later. ">AHK WITH ICON<" will be removed, though probably only for v2.

[guest3456]

My opinion is it wouldn't work

My experiment shows that your opinion is correct. I ran TAC's Ahk2Exe via command line with this param:

/bin "c:\ahkdll-v1-release-master\x64w\AutoHotkeySC.bin"

That is the 64-bit .bin from the AutoHotkey_H ZIP file. The compile appears to be successful, but running the EXE gives a dialog box that says:

Could not extract script from EXE.

of course this wouldn't work by just dropping in the .bin file... AHK_H encrypts the source code of the script, so this compiler would need to implement the same encryption as the AHK_H compiler

if you really need icon resources that bad you might be better off trying to add those to the AHK_H compiler