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
Upcoming Ahk2Exe Changes (2024)
- JoeWinograd
- Posts: 2213
- Joined: 10 Feb 2014, 20:00
- Location: U.S. Central Time Zone
Re: Upcoming Ahk2Exe Changes (2019)
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
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
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
Re: Upcoming Ahk2Exe Changes (2019)
Joe, also are you generating Unicode? 32bit or 64bit? Does having compression = none change things?
TIA
TIA
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
- JoeWinograd
- Posts: 2213
- Joined: 10 Feb 2014, 20:00
- Location: U.S. Central Time Zone
Re: Upcoming Ahk2Exe Changes (2019)
> 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
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 88 times
Re: Upcoming Ahk2Exe Changes (2019)
Thanks, Joe.
I’m unable to look at it until tomorrow NZ time.
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
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
Re: Upcoming Ahk2Exe Changes (2019)
There has been one in my experimental GUI from the very beginning. See here.
Part of my AHK work can be found here.
- JoeWinograd
- Posts: 2213
- Joined: 10 Feb 2014, 20:00
- Location: U.S. Central Time Zone
Re: Upcoming Ahk2Exe Changes (2019)
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:
In an EXE compressed with MPRESS, the source code is not immediately visible, like this:
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
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:
In an EXE compressed with MPRESS, the source code is not immediately visible, like this:
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
Re: Upcoming Ahk2Exe Changes (2019)
JoeJoeWinograd 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.
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
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
- JoeWinograd
- Posts: 2213
- Joined: 10 Feb 2014, 20:00
- Location: U.S. Central Time Zone
Re: Upcoming Ahk2Exe Changes (2019)
> 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
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
Re: Upcoming Ahk2Exe Changes (2019)
just use AutoHotkey_HJoeWinograd wrote: ↑24 Oct 2019, 17:57However, 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
the source code is encrypted and there is no AUTOHOTKEY SCRIPT in the RCDATA
Re: Upcoming Ahk2Exe Changes (2019)
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.
Part of my AHK work can be found here.
Re: Upcoming Ahk2Exe Changes (2019)
I think you can maybe just use the AHK_H *.bin files instead of AHK_L / v1.1 *.bin files.
Windows 10 x64 Professional, Intel i5-8500, NVIDIA GTX 1060 6GB, 2x16GB Kingston FURY Beast - DDR4 3200 MHz | [About Me] | [About the AHK Foundation] | [Courses on AutoHotkey]
[ASPDM - StdLib Distribution] | [Qonsole - Quake-like console emulator] | [LibCon - Autohotkey Console Library]
Re: Upcoming Ahk2Exe Changes (2019)
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.
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.
Part of my AHK work can be found here.
Re: Upcoming Ahk2Exe Changes (2019)
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?
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?
Windows 10 x64 Professional, Intel i5-8500, NVIDIA GTX 1060 6GB, 2x16GB Kingston FURY Beast - DDR4 3200 MHz | [About Me] | [About the AHK Foundation] | [Courses on AutoHotkey]
[ASPDM - StdLib Distribution] | [Qonsole - Quake-like console emulator] | [LibCon - Autohotkey Console Library]
- JoeWinograd
- Posts: 2213
- Joined: 10 Feb 2014, 20:00
- Location: U.S. Central Time Zone
Re: Upcoming Ahk2Exe Changes (2019)
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.guest3456 wrote:just use AutoHotkey_H
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:Drugwash wrote:But does the AHK H compiler sport all the changes and improvements present in this TAC109 version of the compiler?
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!")
That seems to be the case for the icon resources — 160, 206, 207, 208.Drugwash wrote: Because if not, the new/changed directives found in users' scripts will not work in that compiler.
Interesting idea. Has anyone tried this?joedf wrote:I think you can maybe just use the AHK_H *.bin files instead of AHK_L / v1.1 *.bin files.
Regards, Joe
Re: Upcoming Ahk2Exe Changes (2019)
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.
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.
Part of my AHK work can be found here.
Re: Upcoming Ahk2Exe Changes (2019)
@JoeWinograd
Joe, re RCData I have a possible way forward with this. More soon.
Cheers
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
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
- JoeWinograd
- Posts: 2213
- Joined: 10 Feb 2014, 20:00
- Location: U.S. Central Time Zone
Re: Upcoming Ahk2Exe Changes (2019)
My experiment shows that your opinion is correct. I ran TAC's Ahk2Exe via command line with this param:Drugwash wrote:My opinion is it wouldn't work
/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.
That would be superb! I think that this is the only issue keeping the solution from being perfect for my intended use. Thanks much, JoeTAC109 wrote:re RCData I have a possible way forward with this
Re: Upcoming Ahk2Exe Changes (2019)
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.
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.
Re: Upcoming Ahk2Exe Changes (2019)
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 compilerJoeWinograd wrote: ↑25 Oct 2019, 16:51My experiment shows that your opinion is correct. I ran TAC's Ahk2Exe via command line with this param:Drugwash wrote:My opinion is it wouldn't work
/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.
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 (v1)”
Who is online
Users browsing this forum: No registered users and 79 guests