Upcoming Ahk2Exe Changes (2024)

Post your working scripts, libraries and tools for AHK v1.1 and older
TAC109
Posts: 1096
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2021)

Post by TAC109 » 23 Mar 2021, 03:43

@lexikos
Good point! I’ll sort out a fix.
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
User avatar
joedf
Posts: 8937
Joined: 29 Sep 2013, 17:08
Location: Canada
Contact:

Re: Upcoming Ahk2Exe Changes (2021)

Post by joedf » 23 Mar 2021, 09:02

Good catch, makes me wonder if any of the other directives might need patching for v2... :think:
Image Image Image Image Image
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]
User avatar
TheArkive
Posts: 1027
Joined: 05 Aug 2016, 08:06
Location: The Construct
Contact:

Re: Upcoming Ahk2Exe Changes (2021)

Post by TheArkive » 17 Apr 2021, 07:35

I know i asked a question similar to this before, but this general idea is slightly different.

Is it possible to setup Ahk2Exe as a "standalone" compiler, and not require any specific AutoHotkey.exe version in the parent folder... AND be able to cater to multiple previous versions of AutoHotkey?

Or is it possible to setup the parent folder to have multiple named versions of AutoHotkey.exe and have Ahk2Exe be able to pick which exe to use?

I'm also trying to apply this to a scenario where one Ahk2Exe folder is used across multiple versions of AutoHotkey (if possible).

EDIT: I'm guessing that it might be best to have a separate Compiler folder for each version of AHK a user wants to use?
TAC109
Posts: 1096
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2021)

Post by TAC109 » 17 Apr 2021, 16:44

I guess the only requirement for the version of AutoHotkey.exe used by Ahk2Exe is that it accepts the syntax of the AutoHotkey script being compiled. A recent version of AutoHotkey U32 should satisfy this requirement in most cases, although it is possible that in rare cases an ANSI script might need an A32 version.
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
User avatar
joedf
Posts: 8937
Joined: 29 Sep 2013, 17:08
Location: Canada
Contact:

Re: Upcoming Ahk2Exe Changes (2021)

Post by joedf » 17 Apr 2021, 22:39

you could modify ahk2exe. Not much modification should be needed to do this. :think:
Image Image Image Image Image
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]
User avatar
TheArkive
Posts: 1027
Joined: 05 Aug 2016, 08:06
Location: The Construct
Contact:

Re: Upcoming Ahk2Exe Changes (2021)

Post by TheArkive » 18 Apr 2021, 04:57

@joedf
Hm, thanks for the idea! I'm trying to think of the most efficient way to be able to manage multiple versions of AHK on the same system. This was one of my trains of thought.

Does choosing the .bin determine which EXE is used?

Once I understand this aspect, then I'd have a better idea of how to make those changes. I'd implement it as an option though, not the default. Probably in the menubar.
TAC109
Posts: 1096
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2021)

Post by TAC109 » 18 Apr 2021, 17:30

@TheArkive
The rare case I am aware of that needs the ANSI version of AutoHotkey is where the script uses the Transform command with a second parameter of Unicode. This is flagged as invalid when compiling with a Unicode version of AutoHotkey.

@joedf
I can amend Ahk2Exe to cater for this in the future but this won’t help with the current released version.
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
User avatar
joedf
Posts: 8937
Joined: 29 Sep 2013, 17:08
Location: Canada
Contact:

Re: Upcoming Ahk2Exe Changes (2021)

Post by joedf » 18 Apr 2021, 18:11

@TheArkive not sure if you know of this, but I think this might of interest to you. Perhaps even as a staring point.
https://github.com/ahkscript/AHK-EXE-Swapper
Image Image Image Image Image
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]
User avatar
TheArkive
Posts: 1027
Joined: 05 Aug 2016, 08:06
Location: The Construct
Contact:

Re: Upcoming Ahk2Exe Changes (2021)

Post by TheArkive » 19 Apr 2021, 02:49

@joedf
Yah I'm aware of this solution. I have coded my own version (in my signature). Currently the structure of multiple versions requires that each one have a Compiler folder. I have been experimenting with ways to have only one compiler folder, or at least fewer. In the case of AutoHotkey_H, of course I need to use the compiler that comes with it.

@TAC109
Is there a direct correlation between selecting a .bin and the version of EXE that is used? In which case, if Ahk2Exe were changed to look up one folder and down recursively, then the correlation of bin files to EXE files would be amended accordingly? I plan to look at the source code just to mess around with it and learn from it.
TAC109
Posts: 1096
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2021)

Post by TAC109 » 19 Apr 2021, 05:13

@TheArkive
Not sure what you’re getting at here. As far as I’m aware, apart from the Transform,..,Unicode command (which is used rarely if at all) an ANSI script can be compiled quite happily in conjunction with AutoHotkey U32. For the future I’ll implement a change to Ahk2Exe so that it looks for AutoHotkeyA32.exe in the .\.. directory when compiling a script with an ANSI .bin file, but this won’t help with older versions of the AutoHotkey package.

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
User avatar
TheArkive
Posts: 1027
Joined: 05 Aug 2016, 08:06
Location: The Construct
Contact:

Re: Upcoming Ahk2Exe Changes (2021)

Post by TheArkive » 19 Apr 2021, 05:52

@TAC109
Sorry for being unclear.

I'm thinking of a setup where (hypothetically) Ahk2Exe looks up one level, and down recursively (like AHK_H compiler).

parenthetical...

In this case I'm thinking of a folder structure like this:

Code: Select all

root\
    \Ahk2Exe
    \AutoHotkey v1.1.32
    \AutoHotkey v1.1.33
    \AutoHotkey v2-a120
    \AutoHotkey v2-a130
    \... and so on ...

In this setup, in theory, a separate "Compiler" folder in each AHK subfolder would be unnecessary. But I'm not sure what role the .bin files play in relation to the version of EXE that is packed into a compiled script.

I'm not only thinking of what "version", as in ANSI/UNICODE/64-bit/32-bit, but also as in v1.1.32 and v1.1.33. Does that make more sense?

My main end goal is to be able to compile any specific version of AHK (in both senses of the word "version") with a single Ahk2Exe setup, assuming such a thing would be reasonably easy to setup/create, and reasonably easy to manage. I have accomplished a type of solution for this, but it requires every folder of AHK (as shown above) to have it's own complete "Compiler" folder.
User avatar
Drugwash
Posts: 850
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania
Contact:

Re: Upcoming Ahk2Exe Changes (2021)

Post by Drugwash » 23 Apr 2021, 05:38

One idea:
- modify Ahk2exe by adding a Multiversion option.
- when enabled it would ask for a root folder where all AHK versions are installed as per your schematic above.
- at startup it would enumerate each exe + bin(s) available in each subfolder and add them to a multiselect listbox (or checked listview) while storing their paths in an array.
- at compile time the user selects all the number/encoding versions to be used for that session.
- Ahk2exe would then start compiling the current script with each of the selected bin + matching exe, one pair at the time.
- optionally a unique output folder could be designated where all compiled executables would be placed after succesful compilation, using a simple naming schema such as <script name> [< script version number>] (<AHK version number> <encoding type>), i.e. myScriptName 1.2.5.0 (1.1.30.08 U32).exe.

All done. Well, in theory at least. :)
Part of my AHK work can be found here.
TAC109
Posts: 1096
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2021)

Post by TAC109 » 30 Apr 2021, 22:00

Update 1.1.33.09_Beta_1
  • Gui - Last .bin file used is now remembered.
  • Gui - Default .bin in drop-down now shows type.
See this post for download details.
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
lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: Upcoming Ahk2Exe Changes (2021)

Post by lexikos » 02 May 2021, 07:26

TAC109 wrote:
19 Apr 2021, 05:13
For the future I’ll implement a change to Ahk2Exe so that it looks for AutoHotkeyA32.exe in the .\.. directory when compiling a script with an ANSI .bin file, but this won’t help with older versions of the AutoHotkey package.
FYI, your fix doesn't work if AutoHotkey.exe is present (and is not an ANSI version), due to the order of the checks. I moved that code to fix something of more immediate concern to me (fix stdlib), but chose not to change the order in the same commit.

TheArkive wrote:
19 Apr 2021, 05:52
In this case I'm thinking of a folder structure like this:
So am I, for future AutoHotkey installers. So it would be helpful if you all consider how best to support it in Ahk2Exe (and then implement it ;)).

I posted some thoughts in that topic, although I ended up writing more that relates to compiling than the installer.

But I'm not sure what role the .bin files play in relation to the version of EXE that is packed into a compiled script.
The .bin file is the version of EXE that is packed into the compiled script. I mean, the script is packed into the bin file, which is just an exe file renamed. You can actually rename .bin to .exe and run the file (but it won't do anything useful). It is built from the same source code as AutoHotkey.exe, but excluding some code via preprocessor macros, and including some code that's normally excluded.
I have accomplished a type of solution for this, but it requires every folder of AHK (as shown above) to have it's own complete "Compiler" folder.
For the bin files, you can just put them all in one folder, or do as I've done - create symbolic links. For instance, AutoHotkey\Compiler\v2 64-bit.bin is a symbolic link to AutoHotkey\v2-alpha\Unicode 64-bit.bin, which is where I dump the latest v2 alpha release. It could just as easily be pointing to files from different release directories, or the output files of the VC++ project.

The remaining problem is that Ahk2Exe must be explicitly told which EXE to use for validation of the script (and discovering auto-include files, if applicable) via the command line. As far as I am aware, this EXE is only really necessary for auto-includes (which have been removed from v2) and "Obey" directives (or defining the location of the stdlib folder). Whichever EXE is used has to accept the syntax of the script being compiled, because Ahk2Exe helpfully reports any syntax errors that the EXE outputs.

One solution for this, without even modifying Ahk2Exe, is to make an EXE that takes the parameters that Ahk2Exe passes, determines which version of AutoHotkey the script requires, locates the appropriate AutoHotkey.exe and invokes it.

The launcher script I mentioned in another topic actually does this, although I didn't consider its use with Ahk2Exe at all until I had compiled and installed it into my AutoHotkey directory. (It turned out that Ahk2Exe had included a file from the wrong Lib directory, so while I was trying to fix Ahk2Exe and recompile the script, Ahk2Exe was running another copy of the script, which was spitting out syntax errors.) However, my script currently only distinguishes between v1 and v2.

Another solution, but only for future versions (or maybe AutoHotkey_H?), is to eliminate the bin files and use a single exe file both to validate the script and as the base binary of the final exe. Then you just select the exe (instead of a bin) and compile (with a future version of Ahk2Exe).
User avatar
TheArkive
Posts: 1027
Joined: 05 Aug 2016, 08:06
Location: The Construct
Contact:

Re: Upcoming Ahk2Exe Changes (2021)

Post by TheArkive » 02 May 2021, 12:11

lexikos wrote:
02 May 2021, 07:26
The .bin file is the version of EXE that is packed into the compiled script. I mean, the script is packed into the bin file, which is just an exe file renamed. You can actually rename .bin to .exe and run the file (but it won't do anything useful). It is built from the same source code as AutoHotkey.exe, but excluding some code via preprocessor macros, and including some code that's normally excluded.
Thanks for that. That orients my brain better on what I can expect when I finally dive into Ahk2Exe source and start learning.
lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: Upcoming Ahk2Exe Changes (2021)

Post by lexikos » 02 May 2021, 19:33

When you select a bin in the GUI, the selection is remembered both for the next time you use the GUI, and when you use the command line or Explorer context menu. I have found this to be generally inconvenient and unexpected, as I occasionally compile a v2 script using the GUI, and then expect the context menu to compile with v1. (For instance, I just recompiled Ahk2Exe and ended up with an error due to "#NoEnv" being invalid.) If you're not using the GUI, there's obviously no visual cue that (ironically) a "non-default" bin will be used.

Drag-dropping a bin onto the GUI has the opposite problem: it specifically forgets the bin after a single compile (not when you close the GUI), and warns that you that it will do that. Why? So far every time I have used the GUI that way, I have needed to drop the bin onto the GUI more than once. I can understand why it would not be saved for the next run, but I do not understand why it retains all of the other selections but specifically forgets the bin after one compile.

I take it the Bin directive overrides the command line? I think it should be the other way around: if /bin was specified, ignore all Bin directives and only generate the one output file based on /bin.

The AutoHotkey release script uses /bin to specify the new release file, which is in the output directory, not the directory of the Ahk2Exe being executed. If the Bin directive was used in Ahk2Exe (and overrides /bin), it would be compiled with a previous release.
TAC109
Posts: 1096
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2021)

Post by TAC109 » 02 May 2021, 23:03

lexikos wrote:
02 May 2021, 19:33
When you select a bin in the GUI, the selection is remembered both for the next time you use the GUI, and when you use the command line or Explorer context menu. I have found this to be generally inconvenient and unexpected, as I occasionally compile a v2 script using the GUI, and then expect the context menu to compile with v1. (For instance, I just recompiled Ahk2Exe and ended up with an error due to "#NoEnv" being invalid.) If you're not using the GUI, there's obviously no visual cue that (ironically) a "non-default" bin will be used.
While what you experienced is annoying, it is performing as documented! (In fact, many Ahk2Exe parameters have their CLI defaults set by the GUI in this way.) What I do (if I remember) after using any non-standard parameters in the GUI, is to set them back to 'standard' prior to dismissing the GUI. I suppose I could alter Ahk2Exe to always use AutoHotkeySC.bin for CLI if no /bin is specified, but this would have the downside of loosing the ability to set a different default /bin file for the CLI.
Drag-dropping a bin onto the GUI has the opposite problem: it specifically forgets the bin after a single compile (not when you close the GUI), and warns that you that it will do that. Why? So far every time I have used the GUI that way, I have needed to drop the bin onto the GUI more than once. I can understand why it would not be saved for the next run, but I do not understand why it retains all of the other selections but specifically forgets the bin after one compile.
I'll make this alteration.
I take it the Bin directive overrides the command line? I think it should be the other way around: if /bin was specified, ignore all Bin directives and only generate the one output file based on /bin.

The AutoHotkey release script uses /bin to specify the new release file, which is in the output directory, not the directory of the Ahk2Exe being executed. If the Bin directive was used in Ahk2Exe (and overrides /bin), it would be compiled with a previous release.
Yes, Bin directive currently overrides anything else. While there is a Bin directive in Ahk2Exe it is commented out, and thus just acts as a visual reminder of the .bin to use when self-compiling.

I can change Ahk2Exe to allow the Bin directive to be overridden by the CLI. For consistency if I’m going to implement this I should also allow the ExeName and SetMainIcon directives to be overridden as well.

Edit: Should the GUI be allowed to override directives as well? For this to happen, we’ll need to be able to specify a .bin of (none) in the GUI, which could lead to the compile failing if there is no Bin directive. It all becomes rather complicated.
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
lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: Upcoming Ahk2Exe Changes (2021)

Post by lexikos » 09 May 2021, 06:34

I have uploaded a test build based on v1.1.33.09 which supports compiling using one of the provided exe files instead of a bin file:
AutoHotkey_1.1.34-compile+g8025f57b.zip

To compile, use Ahk2Exe commit 5fff25e5 (which I've pushed to master) from the command line, specifying /bin EXE_PATH.

Details of the test build:
  • The main script resource is expected to have ID 1, not >AUTOHOTKEY SCRIPT< (but the latter would still be used for bin files).
  • If the command line switch /execute is present, the main script resource is ignored; otherwise the switch has no effect. It is necessary only when the main script resource is present.
  • Any RCDATA resource can be executed or included by using *resourcename in place of a filename.
  • Unlike compiling with a bin file, A_LineFile contains the resource name; *#1 for the main script resource.
  • Menu Tray, NoMainWindow and Menu Tray, MainWindow now work in uncompiled scripts.
  • When the script is loaded from a resource, it behaves as any compiled script, except:
    • A_AhkPath is always the current exe.
    • If the script is loaded from a resource other than #1, - *resourcename is appended to the window title for identification purposes (#SingleInstance and Reload).
  • A_IsCompiled reflects whether the main script was loaded from an embedded resource.
  • FileInstall acts in "compiled mode" if the main script file was loaded from any embedded resource, and in "uncompiled mode" if an external file is loaded by using the /execute switch.

Please test it out and consider what changes are needed to support this in the GUI.
User avatar
joedf
Posts: 8937
Joined: 29 Sep 2013, 17:08
Location: Canada
Contact:

Re: Upcoming Ahk2Exe Changes (2021)

Post by joedf » 09 May 2021, 15:38

So eventually, there will be no need to distribute the *.bin files? :think:
Image Image Image Image Image
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]
TAC109
Posts: 1096
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2021)

Post by TAC109 » 09 May 2021, 17:13

I am currently making changes to the Ahk2Exe Gui to accommodate some recent requests. In this version the defaults will be loaded and shown as before, but will only be saved when the save button is pressed. The rest should be self-explanatory.

There will be a new optional /stop CLI parameter with bit settings for ExeName, SetMainIcon and Bin (4, 2, 1).

Cheers
.
.
Ahk2Exe01.png
Ahk2Exe01.png (75.76 KiB) Viewed 4473 times
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
Post Reply

Return to “Scripts and Functions (v1)”