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 (2022)

Post by TAC109 » 15 Aug 2022, 17:12

No issue as far as I know. I have compiled beta.7 launcher and it shows the new H icon correctly. See up-thread (and later) for a discussion of a possible problem, and a range of fixes.

Cheers

Edited
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

toralf
Posts: 868
Joined: 27 Apr 2014, 21:08
Location: Germany

Re: Upcoming Ahk2Exe Changes (2022)

Post by toralf » 17 Aug 2022, 03:55

TAC109 wrote:
14 Aug 2022, 17:41
In recent versions, Ahk2Exe supports the following parameters for :arrow: PostExec
Thanks a lot. I got it working
ciao
toralf

lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: Upcoming Ahk2Exe Changes (2022)

Post by lexikos » 19 Aug 2022, 07:45

Apparently any resource file which has a filename extension beginning with "ah" is assumed to be an AutoHotkey script, and is preprocessed as a script if added by ;@Ahk2Exe-AddResource. It seems the only way to prevent this is to use a resource type other than RCDATA, such as by preceding the filename with *256 or *ABC (and space). I suppose that's sufficient...

TAC109
Posts: 1096
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2022)

Post by TAC109 » 19 Aug 2022, 17:55

@lexikos
I was attempting to be consistent. Elsewhere Ahk2Exe recognises AutoHotkey scripts by the leading 'ah' in the extension, to handle cases of .ah2, .ahk2, .ahv2, etc. Now that v2 has an installer and a scheme to handle the standard .ahk extension it may be better to just recognise the .ahk extension only.
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 (2022)

Post by lexikos » 19 Aug 2022, 19:06

I assumed that it would perform preprocessing based on the extension, and at first I thought I might be able to fool it by using ADS syntax to specify the default data stream, but in that case the "filename extension" is seen as .ahk::$DATA. Of course, it really was a script, so it's not wrong. However, specifying any other alternate data stream (which could be any data at all) would still be seen as a script, perhaps incorrectly. I might be the only one who would think of using alternate data streams in this way, though. And overriding the resource type is probably a better workaround.

I ended up using FileInstall and #include anyway.


Is there a way to specify using a directive that a compiled script should be compressed, without making that the default? I have used directives for every other parameter of compilation. I suppose I could use PostExec, but it seems redundant to specify the path and switches for UPX when Ahk2Exe knows what they are.

TAC109
Posts: 1096
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2022)

Post by TAC109 » 19 Aug 2022, 19:43

@lexikos
Is there a way to specify using a directive that a compiled script should be compressed
Sorry, no, other than by PostExec.

The implementation of this is something I have avoided, as, to be consistent with other directives that can be overridden by the CLI and GUI, it would become needlessly complicated. Instead I have regarded compression as purely an environment issue, to be specified via CLI or GUI only.

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 (2022)

Post by TAC109 » 23 Aug 2022, 18:59

Update 1.1.34.04, 24 Aug 2022
  • Add 'File' menu item 'Refresh Windows Icons'.
  • AddResource scripts must have extension = .ahk.
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
Drugwash
Posts: 850
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania
Contact:

Re: Upcoming Ahk2Exe Changes (2022)

Post by Drugwash » 24 Aug 2022, 00:40

An idea came to mind; might be a stupid one or a good one, may have even been discussed before without my knowledge.
Here goes nothing. Standardize AHK scripts by providing all of them with a sort of file header that would allow for:
- a clear distinction between various AHK target versions (1.0/1.1/2.0/etc) - info usable in Ahk2Exe and AHK itself (at runtime)
- a way for the scripts to be easily and definitely recognized by other software - possibly future recovery apps in case of drive failure

This could also solve the problem of using various inventive file extensions for basically the same language, ease the task of Ahk2Exe when it comes to file processing and/or inclusion (see the AddResource requirement above), provide an early way to detect incompatibilities between AHK versions used to run the scripts, and solve who knows what other issues currently faced by coders.

The so-called header would be simple, something in the form of a comment, right at the beginning of the file - such as:
;AHK<2.0 (any version lower than 2.0, which would be 1.0 and 1.1)
;AHK=1.1 (any of the subversions in the 1.1 series only, or a single specific version such as 1.1.34.01)
;AHK>1.0 (any version higher than 1.0, which would be 1.1 and 2.0 currently)
;AHK+1.1.20-1.1.29 (any version between, and including, 1.1.20 and 1.1.29) note these version numbers were randomly chosen

Optionally the script files could end with a simple ;AHK footer that would help in the eventuality of a recovery process acting like EOF (End Of File). Do not use EOF literally as that would have unforeseen/unwanted consequences when script files are stored/run under a Linux system.

This suggestion may not belong here but this is where it popped to mind after seeing the AddResource requirement. If necessary a moderator could move it to a different section.
Part of my AHK work can be found here.

User avatar
joedf
Posts: 8937
Joined: 29 Sep 2013, 17:08
Location: Canada
Contact:

Re: Upcoming Ahk2Exe Changes (2022)

Post by joedf » 24 Aug 2022, 08:11

@Drugwash unless I am misunderstanding, I believe you could do something like that using #Requires:
https://www.autohotkey.com/docs/commands/_Requires.htm

Along with the Ahk2Exe directives such as the ignore keep or begin /end?
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 (2022)

Post by Drugwash » 24 Aug 2022, 08:36

That has a limited scope. A file header (plus optional but recommended footer) would much better fit multipurpose, such as recovery software, text search patterns across the system, and any other usage purposes yet to be identified.

Recently I had a partition screwed up by a defrag software which left 40GB of file debris, among them lots of AHK scripts. Certain recovery software may recognize them as simple text files or other kind of scripts but there would be no clear distinction between file types (i.e. they may be recovered as .txt or .js or whatever) and more importantly there would be no guarantee that the files are complete. Either start or end portions can be missing and only a header and a footer could provide the necessary hints.
Think of the code sequences that identify a JPEG image internally.
Part of my AHK work can be found here.

User avatar
joedf
Posts: 8937
Joined: 29 Sep 2013, 17:08
Location: Canada
Contact:

Re: Upcoming Ahk2Exe Changes (2022)

Post by joedf » 24 Aug 2022, 10:25

I see, so you want this for executables or for script files? I am sure it makes sense for scripts since this isn't really done for any languages I know of... Perhaps it can be done manully by adding your own headers and footers for all of your scripts? and for executables, I would be surprised that there's support for that...?
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 (2022)

Post by Drugwash » 24 Aug 2022, 10:35

For script files (.ahk files). Executables have their own MZ header.
Obviously every coder would have to manually add those headers and footers to their own scripts. The idea was to first agree upon a standard.

Many years ago after a similar drive disaster I began to build a recovery script in AHK. Back then it didn't occur to me the addition of such header/footer for AHK scripts otherwise would've presented and implemented it much earlier, and now would've had a chance to recover and sort scripts much more easily.

Plus, if adopted on a large scale this could offer the chance of registering ahk as a MIME type in Linux which is known to not give much of a damn on file extensions and insists on detecting MIME types by the file headers.
Part of my AHK work can be found here.

User avatar
joedf
Posts: 8937
Joined: 29 Sep 2013, 17:08
Location: Canada
Contact:

Re: Upcoming Ahk2Exe Changes (2022)

Post by joedf » 24 Aug 2022, 12:16

Ahh okay I see. Understood.
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 (2022)

Post by Drugwash » 24 Aug 2022, 12:29

:thumbsup:
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 (2022)

Post by TAC109 » 07 Sep 2022, 19:52

Update - 1.1.34.04a, 08 Sep 2022
  • Fix AHK Std lib when compiling 32-bit.
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
Drugwash
Posts: 850
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania
Contact:

Re: Upcoming Ahk2Exe Changes (2022)

Post by Drugwash » 07 Sep 2022, 20:01

Thanks, good to know it wasn't me or the system. :D
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 (2022)

Post by TAC109 » 07 Sep 2022, 20:28

Pleased to be of service. :thumbup:

Edit: Actually this was an interesting one, as the error only occurred when the Ahk2Exe version number didn’t include an alpha suffix, that is, it only occurred with the version of Ahk2Exe that was included in the official release of AutoHotkey!

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

Re: Upcoming Ahk2Exe Changes (2022)

Post by Drugwash » 07 Sep 2022, 23:16

Yep, that's the one. I had just updated the AHK package to latest, and yesterday when compiling a script it complained about a helper file that I knew was in the main Lib. Didn't bother to search further, just dragged a copy of that file to script's own Lib folder and it went through smoothly.
AHK works in mysterious ways... :D
Part of my AHK work can be found here.

User avatar
jNizM
Posts: 3183
Joined: 30 Sep 2013, 01:33
Contact:

Re: Upcoming Ahk2Exe Changes (2022)

Post by jNizM » 15 Sep 2022, 07:57

The compiler uses the ahk_l icon and not the new one (with icon on default). Tested with v2.0-beta.9 U64 (v1.1.34.04 is also installed alongside beta.9.)

edit:
nvm. The icon cache fooled me
[AHK] v2.0.5 | [WIN] 11 Pro (Version 22H2) | [GitHub] Profile

TAC109
Posts: 1096
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2022)

Post by TAC109 » 15 Sep 2022, 21:23

Yes, I put a 'Refresh Windows Icons' entry in the 'File' menu recently, expressly for this purpose.

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

Post Reply

Return to “Scripts and Functions (v1)”