Upcoming Ahk2Exe Changes (2020)

Post your working scripts, libraries and tools
User avatar
JoeWinograd
Posts: 1590
Joined: 10 Feb 2014, 20:00

Re: Upcoming Ahk2Exe Changes (2019)

23 Oct 2019, 22:26

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
Posts: 573
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2019)

23 Oct 2019, 23:14

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
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
TAC109
Posts: 573
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2019)

23 Oct 2019, 23:26

Joe, also are you generating Unicode? 32bit or 64bit? Does having compression = none change things?
TIA
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
User avatar
JoeWinograd
Posts: 1590
Joined: 10 Feb 2014, 20:00

Re: Upcoming Ahk2Exe Changes (2019)

23 Oct 2019, 23:42

> 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
Attachments
HelloWorld.zip
(1.48 MiB) Downloaded 47 times
TAC109
Posts: 573
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2019)

24 Oct 2019, 00:22

Thanks, Joe.
I’m unable to look at it until tomorrow NZ time.
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
User avatar
Drugwash
Posts: 752
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania

Re: Upcoming Ahk2Exe Changes (2019)

24 Oct 2019, 02:48

TAC109 wrote:
23 Oct 2019, 21:51
Additionally, I think this needs a 'Default' button.
There has been one in my experimental GUI from the very beginning. See here.
I've deleted my CloudMe account because of GDPR - the now legal base for privacy invasion and data theft.
User avatar
JoeWinograd
Posts: 1590
Joined: 10 Feb 2014, 20:00

Re: Upcoming Ahk2Exe Changes (2019)

24 Oct 2019, 17:57

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
RCData uncompressed.png (67.62 KiB) Viewed 2603 times

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

RCData compressed with MPRESS.png
RCData compressed with MPRESS.png (64.73 KiB) Viewed 2603 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
Posts: 573
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2019)

24 Oct 2019, 22:13

JoeWinograd wrote:
23 Oct 2019, 19:10
(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
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
User avatar
JoeWinograd
Posts: 1590
Joined: 10 Feb 2014, 20:00

Re: Upcoming Ahk2Exe Changes (2019)

24 Oct 2019, 22:56

> 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
Posts: 3134
Joined: 09 Oct 2013, 10:31

Re: Upcoming Ahk2Exe Changes (2019)

24 Oct 2019, 23:26

JoeWinograd wrote:
24 Oct 2019, 17:57
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

User avatar
Drugwash
Posts: 752
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania

Re: Upcoming Ahk2Exe Changes (2019)

25 Oct 2019, 08:24

guest3456 wrote:
24 Oct 2019, 23:26
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.
I've deleted my CloudMe account because of GDPR - the now legal base for privacy invasion and data theft.
User avatar
joedf
Posts: 7730
Joined: 29 Sep 2013, 17:08
Facebook: J0EDF
Google: +joedf
GitHub: joedf
Location: Canada
Contact:

Re: Upcoming Ahk2Exe Changes (2019)

25 Oct 2019, 08:40

I think you can maybe just use the AHK_H *.bin files instead of AHK_L / v1.1 *.bin files.
User avatar
Drugwash
Posts: 752
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania

Re: Upcoming Ahk2Exe Changes (2019)

25 Oct 2019, 09:08

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. ;)
I've deleted my CloudMe account because of GDPR - the now legal base for privacy invasion and data theft.
User avatar
joedf
Posts: 7730
Joined: 29 Sep 2013, 17:08
Facebook: J0EDF
Google: +joedf
GitHub: joedf
Location: Canada
Contact:

Re: Upcoming Ahk2Exe Changes (2019)

25 Oct 2019, 12:52

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?
User avatar
JoeWinograd
Posts: 1590
Joined: 10 Feb 2014, 20:00

Re: Upcoming Ahk2Exe Changes (2019)

25 Oct 2019, 12:59

guest3456 wrote: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.
Drugwash wrote: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!")
Drugwash wrote: 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.
joedf wrote: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
User avatar
Drugwash
Posts: 752
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania

Re: Upcoming Ahk2Exe Changes (2019)

25 Oct 2019, 13:10

JoeWinograd wrote:
25 Oct 2019, 12:59
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.
JoeWinograd wrote:
25 Oct 2019, 12:59
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.
I've deleted my CloudMe account because of GDPR - the now legal base for privacy invasion and data theft.
TAC109
Posts: 573
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2019)

25 Oct 2019, 14:53

@JoeWinograd
Joe, re RCData I have a possible way forward with this. More soon.
Cheers
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
User avatar
JoeWinograd
Posts: 1590
Joined: 10 Feb 2014, 20:00

Re: Upcoming Ahk2Exe Changes (2019)

25 Oct 2019, 16:51

Drugwash wrote: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.
TAC109 wrote: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
Posts: 7057
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Upcoming Ahk2Exe Changes (2019)

25 Oct 2019, 18:18

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
Posts: 3134
Joined: 09 Oct 2013, 10:31

Re: Upcoming Ahk2Exe Changes (2019)

25 Oct 2019, 18:30

JoeWinograd wrote:
25 Oct 2019, 16:51
Drugwash wrote: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


Return to “Scripts and Functions”

Who is online

Users browsing this forum: No registered users and 20 guests