Upcoming Ahk2Exe Changes (2024)

Post your working scripts, libraries and tools for AHK v1.1 and older
lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: Upcoming Ahk2Exe Changes (2021)

Post by lexikos » 21 May 2021, 06:03

@TAC109
If you're parsing FileDescription, be aware that I recently removed the "Unicode" qualifier from v2 (commit ea63af2f).
(There's no v2 ANSI build and it's not likely that there will ever be one.)

I also removed InternalName, LegalCopyright and OriginalFilename (commit 2d086e9c).
TAC109
Posts: 1096
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2021)

Post by TAC109 » 21 May 2021, 15:31

Thanks. I’ll be checking that FileDescription contains ‘AutoHotkey’ for finding relevant .exe’s to use as Base Files.
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 » 21 May 2021, 20:15

I suppose that if Ahk2Exe is based on an exe, Ahk2Exe.exe /script /iLib can be used as a fallback when AutoHotkey.exe isn't available. If that's useful, checking SubStr(A_LineFile, 1, 1) = "*" or A_AhkPath = A_ScriptFullPath should be sufficient for determining whether the current exe can be used that way, but you would have to avoid passing /script when using an exe older than v1.1.34 or v2.0-a135.
User avatar
joedf
Posts: 8937
Joined: 29 Sep 2013, 17:08
Location: Canada
Contact:

Re: Upcoming Ahk2Exe Changes (2021)

Post by joedf » 21 May 2021, 23:11

+1
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
Drugwash
Posts: 850
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania
Contact:

Re: Upcoming Ahk2Exe Changes (2021)

Post by Drugwash » 27 May 2021, 11:00

lexikos wrote:
21 May 2021, 06:03
I also removed InternalName, LegalCopyright and OriginalFilename
Related to detection of original unaltered AHK executables vs compiled scripts in future no-bin AHK versions I'd say the compiler could automatically insert input script's name as either InternalName or OriginalFilename (or any other common field unused by original AHK exe) in compiled output's VersionInfo, in case there was no similar directive in the source script.

I'm partial to the priority of CLI bin/exe selection over the script directive. Although such situation might be rare, the script creator might have had strong reasons for choosing a specific version when creating the directive, and disregarding it may lead to unwanted behavior in the resultant executable. The solution could be adding a flag or something (think of the !important flag in CSS) that could enforce using strictly the directive version if available, else show a warning message (allowing override by manual validation or aborting the operation).

I'm thinking, the ability of selecting a specific range of bin/exe versions - either to use, to avoid, or both - in the directive might be useful in such corner cases, but that may be a bit of a stretch. The only good reason for the existance of such options would be known bugs and/or missing features in certain AHK versions, that the script creator would want to avoid.
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 » 27 May 2021, 20:50

@TheArkive @lexikos and other interested parties
I’m implementing handling the folder structure outlined here:

Code: Select all

(root) or AutoHotkey       (Select only AutoHotkeyA32.exe, AutoHotkeyU32.exe, AutoHotkeyU64.exe)
    \Compiler              (Contains THE Ahk2Exe.exe plus any .bin files and optional compressors)
    \AutoHotkey v1.1.32    (Select only AutoHotkeyA32.exe, AutoHotkeyU32.exe, AutoHotkeyU64.exe)
        \Compiler          (Select only .bin files. Any default .bin file ignored)
    \AutoHotkey v1.1.33    (etc)
        \Compiler          (etc)
    \AutoHotkey v2-a120
       (\Compiler)
    \AutoHotkey v2-a130
    \... and so on ...
The important bits are:
  • Ahk2Exe runs from the '\Compiler' directory shown on the second line above, which may or may not contain a default (AutoHotkeySC) .bin file. (It is gathered if found.)
  • Subdirectories at the same level as this '\Compiler' directory must start with 'AutoHotkey' in order to be considered for inclusion, and subdirectories are searched recursively.
  • Any default AutoHotkeySC.bin files found in these subdirectories are ignored.
  • Base files gathered are all .bin files and qualifying .exe files.
  • If the script contains 'Bin' compiler directives there will be an entry at the top of the 'Base file' list to allow for this to be selected, otherwise they will be skipped.
  • All AutoHotkey?*.exe files encountered are remembered separately, but not AutoHotkey.exe files as they may be version-selector programs.
  • The version of the .bin file selected by the user as the base file, is used to select the AutoHotkey .exe version to be used for the /ilib etc processing.
  • If a qualifying .exe file is selected as the base file, it is also used for the /ilib etc processing.
  • In the absence of a suitable AutoHotkey.exe for /ilib processing Ahk2Exe will be used if compiled with AutoHotkey v1.1.34+.
  • The /ahk parameter becomes largely superfluous, but will be retained in its present form for backwards compatibility.
@TheArkive I’m not sure how you intend to implement AutoHotkey_H. If you intend it to be included in this directory structure I’ll need to be able to exclude _H directories as _H is not compatible with standard AutoHotkey.

Edit: For clarity, when selecting possible AutoHotkey .exe's I’m looking for .exe's that have the property FileDescription containing ‘AutoHotkey' but not having a file name of 'AutoHotkey.exe' or 'Ahk2Exe.exe'.

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 » 28 May 2021, 03:39

@TAC109

All of those important bits look quite good to me. :+1:

To identify AHK_H, I always name my sub directories as "AutoHotkey_H", so that should be easy enough to detect by folder name.

I know you are dealing with challenges of backwards compatibility, and I'm not 100% sure what those challenges are, so please only take my words as suggestions, not expectations.

I was thinking, to identify AutoHotkey_H, wouldn't checking the Product Name field, or File Description field work? In the code below, I'm identifying the proper EXEs first, then using those folders, rather than relying on a folder name scheme to parse. I use the folder name scheme only for overall organization.

Code: Select all

Loop Files path "\*.exe", "R"
{
	If (ProductName = "AutoHotkey_H")
		Continue
	... use folder of "valid" exe
}

I figured using this method, you can then parse the collected "valid" folders then parse for BIN files (recursively or directly in the Compiler folder) inside each valid folder.

As far as how I implement AutoHotkey_H, I do have it in the same root folder as other normal AHK folders. I use something similar to the code above to be able to tell the difference between the type of AHK I'm working with.

As for the structure, I see that a "master AHK folder" is used as the root. For easier "swapping out" I have all AHK folders in the same root folder, and that root folder is nothing special, other than it is "the root" for the setup.

Code: Select all

Root folder
	\ _OLD_	<-- for old AHK versions that I want to put away
	\ Compiler
	\ Compiler_H
	\ AutoHotkey v1.1.32
	\ AutoHotkey v1.1.34
	\ AutoHotkey v2-a130
	\ AutoHotkey_H v1.1.33
	\ AutoHotkey_H v2-a122

Currently I don't actually use those compilers in the root folder, since I find more consistent compiling operation with a separate compiler folder in each AHK folder. But I am hoping this compiler setup will be functional some day.

If I use the newly proposed compiler in this manner would it function as intended without a master AHK folder at the root?

EDIT: I also use an _OLD_ folder to put away older versions of AHK that I don't plant to use in the near future. It would be cool to have something like this (maybe hard coded for simplicity?) to be able to move things out of the way without deleting. In my AHK Portable Installer, i have it set to ignore folders matching the regex pattern i)_?OLD_?.

If my structure causes too many issues while trying to maintain backward compatibility I can change it.
TAC109
Posts: 1096
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2021)

Post by TAC109 » 28 May 2021, 04:54

@TheArkive
Well, using the folder structure you have outlined, Ahk2Exe, while scanning only AutoHotkey directories, can additionally ignore anything in an AutoHotkey_H directory. This will enable the ignoring of _H .bin files by Ahk2Exe as well. This should fit in with your plans.

I’m sorry I’m not familiar with _H versions of AutoHotkey and Ahk2Exe to comment usefully on that side of things.

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 » 28 May 2021, 05:19

TAC109 wrote:
28 May 2021, 04:54
This will enable the ignoring of _H .bin files by Ahk2Exe as well. This will enable the ignoring of _H .bin files by Ahk2Exe as well. This should fit in with your plans.

That's perfect and all I need! Very cool, thanks :D :+1:

TAC109 wrote: I’m sorry I’m not familiar with _H versions of AutoHotkey and Ahk2Exe to comment usefully on that side of things.

I wouldn't say I'm "familiar" with AHK_H either. I've just been messing around with it to make sure it works with my AHK Portable Installer script.

I can use it if I need, and I can set it as the main EXE for executing scripts if I need to on my system. I've also messed around with compiling a few AHK_H scripts just for testing.

As far as AHK and _H coexisting, I think you have it covered perfectly, normal AHK just simply "ignores" AHK_H.



Actually, I think AHK and Ahk2Exe is starting to move in the direction of the AHK_H and the _H compiler. I know the BIN files are still part of the _H releases, but you can also select an EXE to compile/bundle a script into (the same as the changes being made by lexikos for normal AHK).

Of course the main differences in _H is supporting multi-threading and other super fancy tools.
lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: Upcoming Ahk2Exe Changes (2021)

Post by lexikos » 28 May 2021, 05:32

TAC109 wrote:
27 May 2021, 20:50
Subdirectories at the same level as this '\Compiler' directory must start with 'AutoHotkey' in order to be considered for inclusion, and subdirectories are searched recursively.
Is there a reason for this requirement? FYI, it's not how I plan for the installer or launcher to work, and some tools already expect a v2-alpha or v2 sub-directory.
lexikos wrote:
02 May 2021, 07:19
For the moment, assume something like AutoHotkey\v*\*.bin and AutoHotkey\v*\AutoHotkey*.exe. I'll probably remove the "U" from the v2 files to help distinguish v1 and v2 processes, and because there won't be an ANSI version. Assume there will only be one AutoHotkey.exe (without suffix), at AutoHotkey\AutoHotkey.exe, and it will actually be a compiled script (the version-selecting launcher), but that might be up to a user preference.
But feel free to do your own thing, and we'll see how it meshes with the launcher and installer once I've actually implemented them.
TheArkive wrote: I'm identifying the proper EXEs first, then using those folders, rather than relying on a folder name scheme to parse.
:thumbup:
TAC109
Posts: 1096
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2021)

Post by TAC109 » 28 May 2021, 18:31

@lexikos
So many posts it’s hard to keep track! Ok I’ll look for directories starting with ‘AutoHotkey' or 'v'.

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

Re: Upcoming Ahk2Exe Changes (2021)

Post by TAC109 » 01 Jun 2021, 19:40

lexikos wrote:
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
....

Please test it out and consider what changes are needed to support this in the GUI.
The straight forward way of implementing the compiling of the #2 resource would be to have a second 'Source script' line in the GUI Options area, and implement a /in2 parameter for the CLI. Is this how you anticipate this to be implemented? My take on this is that this change would add some confusion to the GUI for the user doing a simple compile. It is really quite a specialised option.

Another way would be for the user to compile these .exes as a two step operation, with the user compiling twice and feeding the first generated exe into the second compile as the base file. If the base file already contains a #1 resource, Ahk2Exe would add the new script as resource #2 (for example).

I'm sure there are other ways of achieving this as well, such as using utilities like Resource Hacker.

I guess I'm not keen on making the GUI unduly complicated just to handle a little-used option.

Your thoughts would be welcome.
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
TAC109
Posts: 1096
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2021)

Post by TAC109 » 01 Jun 2021, 20:05

@lexikos An additional question:-
If a 1.1.34 compiled .exe (e.g. Ahk2Exe) is run with the /ilib parameter, is the /script parameter needed (presumably with an empty script) to avoid executing the embedded script?
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 » 01 Jun 2021, 22:21

That can be tested with the test release. The /script switch enables AutoHotkey's normal/full command line processing (including passing a script filename) when there is an embedded script. It has no other effect, and must be specified before any other parameter that would normally be placed into A_Args. Just insert /script at the start.

Compiled.exe /script /ilib outfile infile
lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: Upcoming Ahk2Exe Changes (2021)

Post by lexikos » 01 Jun 2021, 22:34

I'm not concerned about Ahk2Exe supporting #2 directly.

The exe can have other resources which can be executed by specifying them on the command line. For this, I suppose Ahk2Exe could support 1) applying the compilation process to an exe which has already been "compiled" and 2) a way to override the resource name.
User avatar
TheArkive
Posts: 1027
Joined: 05 Aug 2016, 08:06
Location: The Construct
Contact:

Re: Upcoming Ahk2Exe Changes (2021)

Post by TheArkive » 02 Jun 2021, 06:23

In case it helps, as a regular user, I like the idea of the GUI not changing, or changing very little, supporting #1 by default, and when compiling an already compiled script, divert to #2, with a notification maybe (msgbox or status bar).

I like the idea of the new /in2 command line option. Straight forward and to the point.
lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: Upcoming Ahk2Exe Changes (2021)

Post by lexikos » 07 Jun 2021, 22:50

If the base file already contains a #1 resource, Ahk2Exe would add the new script as resource #2 (for example).
The purpose of #2 is not directly related to compiling, and a #1 resource is not required. The choice should be explicit, not based on which resources already exist. A command line option is fine.
TAC109
Posts: 1096
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2021)

Post by TAC109 » 25 Jul 2021, 20:44

1.1.34.00_Beta_1, 26 July 2021
  • Add preliminary support for using AutoHotkey executables as Base files.
  • AutoHotkey version used (as a utility) is selected to match the Base file version used.
  • Changed handling of defaults; priority now is:-
    1. CLI/GUI
    2. Compiler Directives
    3. Saved Defaults
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
User avatar
TheArkive
Posts: 1027
Joined: 05 Aug 2016, 08:06
Location: The Construct
Contact:

Re: Upcoming Ahk2Exe Changes (2021)

Post by TheArkive » 25 Jul 2021, 22:35

Very cool! Thanks TAC109! :D
Post Reply

Return to “Scripts and Functions (v1)”