Upcoming Ahk2Exe Changes (2019)

[Drugwash]

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!

[TAC109]

@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

[Drugwash]

[...] 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.

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.

[TAC109]

@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.)

[Drugwash]

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.

[TAC109]

@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.

[Drugwash]

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!

[TAC109]

@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.

[Drugwash]

That's great, we're one step closer to perfection.

[lexikos]

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.

[Drugwash]

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.

[lexikos]

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]

@lexikos
Thanks, I’ll check it out. Looks like a cleaner solution than mine.

[Drugwash]

That should be trivial to adapt for changing other attributes.

Thank you for your help.

@ 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 (117.78 KiB) Viewed 603 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.

[TAC109]

@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?

[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?

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.

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 (97.28 KiB) Viewed 494 times

[TAC109]

@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.

[Drugwash]

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.

[TAC109]

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

[Drugwash]

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!