Upcoming Ahk2Exe Changes (2019)

Post your working scripts, libraries and tools
User avatar
Drugwash
Posts: 720
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania

Re: Upcoming Ahk2Exe Changes (2019)

20 Jul 2019, 04:47

In regard to the added directives - extremely useful - I'd like to suggest a couple of enhancements:
- allow extraction of icon from an EXE or a DLL, besides the regular ICO
(i.e. ;@Ahk2Exe-SetMainIcon path\to\random.exe`,3 would extract and set third icon from random.exe)
- allow changing of two fields in the existing manifest: version and name, in assembly > assemblyIdentity (not to be confused with dependency > dependentAssembly > assemblyIdentity )
(i.e. ;@Ahk2Exe-SetManName Author.Company.SampleAppName and ;@Ahk2Exe-SetManVersion 1.2.3.4)

At least the latter may reduce the chances of such compiled executables being wrongly flagged as infected or potentially unwanted, if some so-called antivirus checks the name field and finds AutoHotkey there. But beyond that, it would make a complete identity in conjunction with the VersionInfo fields. Just my humble opinion.

Otherwise it's a great improvement, I know AHK_H has been using this system for quite a while and it was time to catch up. No need for ResHacker anymore (if the two suggestions above get implemented). The compression selection is also a welcome improvement. Good job! :thumbup:
I've deleted my CloudMe account because of GDPR - the now legal base for privacy invasion and data theft.
TAC109
Posts: 345
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2019)

21 Jul 2019, 18:50

@Drugwash

Thanks for your feedback!

With regard to modifying properties in the manifest, currently there is the ability to replace the manifest with one of your own choosing by means of the directive ;@Ahk2Exe-AddResource *24 filename, 1. You could use a utility such as ResourceHacker to extract the current manifest, alter it as required, and replace it using the above directive. As the manifest does not alter for different AutoHotkey compilations, the one altered manifest could be used for all your programs.

Regarding your icon suggestion, I’ll look at the feasibility of implementing this. Personally I just use an icon manipulation program (such as the free version 1.6.4 of IcoFX) to extract any required icons first.

Thanks again for responding :thumbup:
My programs:-
ReClip - a Text Reformatting and Clip Management utility
XRef - Produces Cross Reference lists for scripts
User avatar
Drugwash
Posts: 720
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania

Re: Upcoming Ahk2Exe Changes (2019)

22 Jul 2019, 09:48

TAC109 wrote:
21 Jul 2019, 18:50
[...] currently there is the ability to replace the manifest with one of your own choosing [...]
As the manifest does not alter for different AutoHotkey compilations, the one altered manifest could be used for all your programs.
I know about the ability to replace an entire manifest, and that would be useful if all manifests were to be the same. However, if you reread carefully my suggestion you will see that the info in each manifest would contain data specific to the currently compiled script, namely script name (Author.Company.SampleAppName) and script version (1.2.3.4). For each compiled script there will be different name and version, therefore a single manifest file would not be feasible for all scripts.
TAC109 wrote:
21 Jul 2019, 18:50
Personally I just use an icon manipulation program [...] to extract any required icons first.
Sure, that would always work, but it's an extra manual step to be performed.There is also a slight possibility that the user moves the script between different OS versions and may want specific system icons which may also be different from one OS version to another, or the application to retrieve the icon from may change its icon from one version to another. Since AHK is mostly about automation, wouldn't it be nice to have a few things... uhm... automated? ;)

Anyway, those were just suggestions. The manifest one would be more important, it would be great if it were implemented (first).
Thank you for considering my suggestions. :wave:
I've deleted my CloudMe account because of GDPR - the now legal base for privacy invasion and data theft.
TAC109
Posts: 345
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2019)

22 Jul 2019, 18:45

@Drugwash Regarding the manifest fields you mentioned:- I’m not aware these are externally visible (except by directly checking the manifest of course). The user can see the fields set by the Setprop directives by checking the properties of the executable, but not the fields in the manifest? (I’m not a Windows programming expert by any means, so please correct me if I’m wrong.)
My programs:-
ReClip - a Text Reformatting and Clip Management utility
XRef - Produces Cross Reference lists for scripts
User avatar
Drugwash
Posts: 720
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania

Re: Upcoming Ahk2Exe Changes (2019)

23 Jul 2019, 13:34

True, those manifest fields are not directly visible by the user, but they would stand out for certain tools that may check them against the VersionInfo fields. Therefore it may be more than an aesthetic fix. I used to change those fields in my recent compiled scripts, just for completeness sake.
But yes, it's not a critical point, so if it's too much trouble to implement it then just drop it low on the priority list or just discard it.
I've deleted my CloudMe account because of GDPR - the now legal base for privacy invasion and data theft.
TAC109
Posts: 345
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2019)

24 Jul 2019, 19:47

@Drugwash The next beta may have something you can use for your individualised manifests, if the idea works out. It would involve using a single standardised external manifest file, but will allow the insertion of data, defined in compiler directives.
My programs:-
ReClip - a Text Reformatting and Clip Management utility
XRef - Produces Cross Reference lists for scripts
User avatar
Drugwash
Posts: 720
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania

Re: Upcoming Ahk2Exe Changes (2019)

25 Jul 2019, 04:17

Ah, I think I understand. The generic external manifest should be the same as the standard one built into the official AHK binary, right? And the directives would allow its modification prior to being added as a resource replacement at compilation time, right? Could work.

One thing I'm not clear about, though: are both 32bit and 64bit manifests identical in their respective binaries? If yes then it'd be alright; if not then we may have a problem, if one has to build subsequently (and quickly) both 32bit and 64bit versions of the same script.
I don't have a 64bit binary at hand to check against a 32bit one. It's kinda crazy with these WINE prefixes in Linux...

Thank you for working on this! :thumbup:
I've deleted my CloudMe account because of GDPR - the now legal base for privacy invasion and data theft.
TAC109
Posts: 345
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2019)

25 Jul 2019, 05:13

@Drugwash
I’ve exported the manifests from .exe's generated by Ahk2Exe with the 3 values of the bin parameter (ANSI, U32, and U64) and the manifests are all identical, so no problem there.
My programs:-
ReClip - a Text Reformatting and Clip Management utility
XRef - Produces Cross Reference lists for scripts
User avatar
Drugwash
Posts: 720
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania

Re: Upcoming Ahk2Exe Changes (2019)

25 Jul 2019, 06:50

That's great, we're one step closer to perfection. :)
I've deleted my CloudMe account because of GDPR - the now legal base for privacy invasion and data theft.
lexikos
Posts: 6488
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Upcoming Ahk2Exe Changes (2019)

26 Jul 2019, 18:17

TAC109 wrote:
24 Jul 2019, 19:47
It would involve using a single standardised external manifest file,
The manifest may change (and has changed) between releases. Why not extract it from the target executable file during compilation? EnableUIAccess uses MSXML to both load the manifest from the executable file and modify it. (This file was missing from git until just now, but its content is also included in Installer.ahk, which is installed along with AutoHotkey. It is based on an older script by the same name.)

The manifest source is source/resources/AutoHotkey.exe.manifest.
User avatar
Drugwash
Posts: 720
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania

Re: Upcoming Ahk2Exe Changes (2019)

26 Jul 2019, 20:34

Yes, that would be the safest procedure. My suggestion implied it but didn't want to push it when an alternative was offered.
Hopefully it wil be easy to implement. Wish I could help but I'm a fish out of the water lately.
I've deleted my CloudMe account because of GDPR - the now legal base for privacy invasion and data theft.
lexikos
Posts: 6488
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Upcoming Ahk2Exe Changes (2019)

26 Jul 2019, 21:05

In case it wasn't clear, the EnableUIAccess_SetManifest function in the file I linked to loads the manifest, changes one attribute and updates the manifest resource. That should be trivial to adapt for changing other attributes.
TAC109
Posts: 345
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2019)

26 Jul 2019, 22:25

@lexikos
Thanks, I’ll check it out. Looks like a cleaner solution than mine. :)
My programs:-
ReClip - a Text Reformatting and Clip Management utility
XRef - Produces Cross Reference lists for scripts
User avatar
Drugwash
Posts: 720
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania

Re: Upcoming Ahk2Exe Changes (2019)

27 Jul 2019, 10:55

lexikos wrote:
26 Jul 2019, 21:05
That should be trivial to adapt for changing other attributes.
Thank you for your help. :thumbup:

@ TAC109: Today I had to compile a script and looking at its older compiled version I noticed a few VersionInfo fields that I had changed and are not currently supported in this version of Ahk2Exe, at least not separately:
- Comments
- InternalName
- ProductVersion

First one is missing altogether while the other two are combined with other fields (FileVersion == ProductVersion ==> Version, and ProductName == InternalName => Name). Usually such fine-grain separation of details may not be necessary but since those items do exist separately maybe it would be best to allow them as such here as well.
For example I mark InternalName as <script_filename>.ahk while ProductName is <script_name>. ProductVersion may be a generic 1.2 while FileVersion would be a more specific 1.2.59.6, for example.
Last but not least, the Comments field would at least help differentiate locally between builds (ANSI/Unicode/x64, and/or AHK versions).
Related to that, I didn't see A_AhkVersion among the native built-in variables recognized by this script. This would be important for certain VersionInfo field(s) - see Comments (Compiled in...):
Screenshot from 2019-07-27 14-22-27.png
Screenshot from 2019-07-27 14-22-27.png (117.78 KiB) Viewed 716 times
Also, in the screenshot there is one field (LegalCopyright) containing a backslash. Can't remember what compiler or editor converted the © sign to that notation, but when using your script to add that field the backslash is getting escaped so that the resulting field will contain two backslashes, which breaks the display of the © sign. Hopefully this can be fixed.

This may seem like nitpicking but I feel details can sometimes be important. At least I've stated my opinion, we'll see how it all goes. ;)
I've deleted my CloudMe account because of GDPR - the now legal base for privacy invasion and data theft.
TAC109
Posts: 345
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2019)

27 Jul 2019, 19:22

@Drugwash

Re copyright symbol:- Perhaps this should be entered directly as © in the source directive and the file saved as UTF8 (or 16) with BOM? Failing that, there’s always the old ASCII fallback of (c). There’s no escape handling in this part of the Ahk2Exe code apart from what is documented.

Re your other comments:- I'm thinking of expanding this area so that extra user-defined field names can be specified. This should cover your requirements?
My programs:-
ReClip - a Text Reformatting and Clip Management utility
XRef - Produces Cross Reference lists for scripts
User avatar
Drugwash
Posts: 720
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania

Re: Upcoming Ahk2Exe Changes (2019)

28 Jul 2019, 04:29

TAC109 wrote:
27 Jul 2019, 19:22
Re copyright symbol:- Perhaps this should be entered directly as © in the source directive and the file saved as UTF8 (or 16) with BOM?
It used to be like that but something changed it to that format - can't remember what tool exactly. Then I just copied the text as it was in the old compiled file's VersioInfo and pasted it in the script directive.
Besides, that script has been built initially on an ANSI system and it should be able to compile in both ANSI (on Win9x systems) and Unicode (on Win2000+ systems) versions, so it'll have to remain an ANSI script.

Thing is, anybody could use that particular format for whatever reason, and this compiler should be able to deal with it in a graceful manner. There may be some documentation on how to deal with backslashes (and any other possibly problematic characters, if any) in VersionInfo fields.
TAC109 wrote:
27 Jul 2019, 19:22
I'm thinking of expanding this area so that extra user-defined field names can be specified. This should cover your requirements?
Well, first step would be to cover all the officially recognized fields. Many tools may only check for those fields, and some not even for all of them. User-defined fields would be a bonus.
There is a plug-in for Total Commander called FileInfo which shows all possible fields plus many other details that can't usually be seen in File Properties or in other tools. I believe at least the Private Version and Debug Version (and maybe also Special Build) bits may be of interest for some users.
Screenshot from 2019-07-28 12-19-50.png
Screenshot from 2019-07-28 12-19-50.png (97.28 KiB) Viewed 607 times
I've deleted my CloudMe account because of GDPR - the now legal base for privacy invasion and data theft.
TAC109
Posts: 345
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2019)

31 Jul 2019, 00:05

@Drugwash Just a note that the manifest changes are coming along well.

Regarding (c) and it’s hex variants, I’ll leave that up to you to sort out. You’ll be aware that it has a different hex value in Unicode and ASCII. Safest would be to use as I have here.
My programs:-
ReClip - a Text Reformatting and Clip Management utility
XRef - Produces Cross Reference lists for scripts
User avatar
Drugwash
Posts: 720
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania

Re: Upcoming Ahk2Exe Changes (2019)

31 Jul 2019, 12:26

Good to hear about the manifest. :)

The problem with backslashes may pop up at any time, in any field, with any hex character, not only for the hex variant of ©. And it doesn't even have to be a hex value, just random text that includes them. Wouldn't have bothered mentioning it if it was only that one exception.
Real life got me cornered and I'm ashamed to say I didn't even have time to pick up the code and see if I can find anything related to the backslash issue.
I've deleted my CloudMe account because of GDPR - the now legal base for privacy invasion and data theft.
TAC109
Posts: 345
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2019)

09 Aug 2019, 22:11

New version available:-
Beta_2, 10 August 2019 -
  • The command line parameter /mpress has been changed to /compress. (/mpress is still accepted, though.)
  • Directive parameters can reference the various 'A_' built-in variables as listed under the #Include directive.
  • In addition the new 'A_WorkFileName' variable contains the temporary name of the processed .exe file.
  • The new 'A_PriorLine' variable contains the source code line immediately preceding the current compiler directive.
  • The value returned from variables can be manipulated using regex code.
  • The new 'Let' directive enables the creation of special 'U_<name>' variables.
  • Other new directives are 'SetLanguage', 'Set', 'UpdateManifest', and 'Debug'.
See the updated documentation in the .zip for more information.
Also included in the .zip are 2 demonstration script groups which show how the directives can be used.

Download from here
Last edited by TAC109 on 31 Aug 2019, 18:07, edited 1 time in total.
My programs:-
ReClip - a Text Reformatting and Clip Management utility
XRef - Produces Cross Reference lists for scripts
User avatar
Drugwash
Posts: 720
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania

Re: Upcoming Ahk2Exe Changes (2019)

10 Aug 2019, 06:11

Hi, great work! Almost everything I need works. There's still the backslash issue, and apparently subsequent directives can't overlap each-other.
For example I had ;@Ahk2Exe-SetVersion 4.4.0.4 and somewhere below I had ;@Ahk2Exe-Set ProductVersion, 4.4. The expected result was that ProductVersion would be updated to 4.4.0.0 in both places, while keeping FileVersion at 4.4.0.4. Unfortunately it didn't work - both ProductVersion remained unaltered at 4.4.0.4. That's why I previously asked for separate FileVersion and ProductVersion directives.
Anyway, that's a relatively minor issue.

Manifest update works fine, thank you for adding it. You may wanna add A_AhkVersion to the list of accepted built-in variables in the documentation - it's not listed there but it does work, and some people may get confused if they don't see it there.

There's one thing I'm not sure how to put it: could this work with the older ANSI AHK 1.0 binary? I mean, use this compiler to compile a script by binding it to the old AHK 1.0. Reason I'm asking it is that newest ResHacker corrupts an AHK 1.0 compiled script (at least under Linux/Wine) if trying to edit it (to add a bitmap, edit VersionInfo etc).
That would require an extra [Custom binary] option in the binary dropdown list, allowing the user to select a different binary than the default ones. Might be too much to ask but thought I'd try. Nevertheless, thank you very much for all the work so far and for listening to user requests!
I've deleted my CloudMe account because of GDPR - the now legal base for privacy invasion and data theft.

Return to “Scripts and Functions”

Who is online

Users browsing this forum: kkleinfelter, sinkfaze, teadrinker and 41 guests