Upcoming Ahk2Exe Changes (2024)
Re: Upcoming Ahk2Exe Changes (2022)
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
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
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 (2022)
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...
Re: Upcoming Ahk2Exe Changes (2022)
@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.
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
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 (2022)
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.
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.
Re: Upcoming Ahk2Exe Changes (2022)
@lexikos
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
Sorry, no, other than by PostExec.Is there a way to specify using a directive that a compiled script should be compressed
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
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 (2022)
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
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 (2022)
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.
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.
Re: Upcoming Ahk2Exe Changes (2022)
@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?
https://www.autohotkey.com/docs/commands/_Requires.htm
Along with the Ahk2Exe directives such as the ignore keep or begin /end?
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 (2022)
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.
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.
Re: Upcoming Ahk2Exe Changes (2022)
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...?
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 (2022)
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.
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.
Re: Upcoming Ahk2Exe Changes (2022)
Ahh okay I see. Understood.
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 (2022)
Part of my AHK work can be found here.
Re: Upcoming Ahk2Exe Changes (2022)
Update - 1.1.34.04a, 08 Sep 2022
- Fix AHK Std lib when compiling 32-bit.
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 (2022)
Thanks, good to know it wasn't me or the system.
Part of my AHK work can be found here.
Re: Upcoming Ahk2Exe Changes (2022)
Pleased to be of service.
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
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
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 (2022)
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...
AHK works in mysterious ways...
Part of my AHK work can be found here.
Re: Upcoming Ahk2Exe Changes (2022)
edit:
nvm. The icon cache fooled me
[AHK] v2.0.18 | [WIN] 11 Pro (23H2) | [GitHub] Profile
Re: Upcoming Ahk2Exe Changes (2022)
Yes, I put a 'Refresh Windows Icons' entry in the 'File' menu recently, expressly for this purpose.
Cheers
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