Autohotkey within the Microsoft Store

[JnLlnd]

It seems that the consultant stopped updating the AHK Store Edition (last update March 2020).

Are you aware of any AHK compiled script that was made available on Windows Store? Do you think it is technically feasible without AHK Store Edition? I was asked from a QAP user if this could be made available on that platform in order to give access to users in companied with strict IT policies.

[TAC109]

It seems that the consultant stopped updating the AHK Store Edition (last update March 2020).
…

The Microsoft Store version you are referencing indicates that it contains AutoHotkey v1.1.37.01, which is the latest version, so the date you quoted is probably when this item first appeared in the Store. The recent post by @Descolada refers to a separate item 'AutoHotkey v2' in the Store which also includes v1.

Cheers

[JnLlnd]

The Microsoft Store version you are referencing indicates that it contains AutoHotkey v1.1.37.01, which is the latest version, so the date you quoted is probably when this item first appeared in the Store.

You are probably right about the release date.

Sorry, I missed the 2nd page of this thread and was under the impression that the OP was inactive on this forum for some time. I'll catch up with the remaining of this thread now.

[TAC109]

@Descolada
Thanks for your new store edition of AutoHotkey v2. I’ve been checking it out with regards to the Ahk2Exe compiler and have some comments regarding this:

• I see that you have included the compiler that was issued with AutoHotkey v1.1.37.01. Unfortunately this is not the latest version, which is 1.1.37.01c at time of writing, and is obtainable through this link. It would be best to always include the latest version of Ahk2Exe when you generate a new version for the Store.
• The right-click context menu for an AutoHotkey script does not include the usual 'Compile Script' and 'Compile Script (GUI)…' entries to allow easy compilation of scripts.
• There is no shortcut link to Ahk2Exe in the Windows menu (task bar Windows icon).
• Compilations currently fail because there is no execute permissions to any of the AutoHotkey executables in the apps directory. It is necessary to allow these to be executed in order for the compile to succeed. Also Ahk2Exe.exe must be able to be executed in the same way. All these files are available to be selected as a 'base file' for the compilation, and this base file will be executed to validate the script, etc, during the compilation process.
• It would be useful if the MPRESS and UPX executables could be included in the Compiler directory to allow compression of the .exe during compilation. These would also need to be executable as per the previous bullet point.
• Also useful would be to include in the Compiler directory a compiled version of BinMod compiled with latest v1.1+ U32 exe base file. This would also need to be executable as above.
• I have a 'Check for updates' facility in the Ahk2Exe gui that will obviously not be able to succeed in the Store version. Is there any way for Ahk2Exe to programmatically detect that it is being run as an app and then suppress this option? If so, I’ll include this in Ahk2Exe and produce a new version for inclusion.

Well, this is quite a list of items to consider. I hope it will not be too difficult to get these implemented. Let me know if I can help in any way.

Cheers
(Edited for clarity)

[Descolada]

@TAC109, thank you for your feedback! I have to admit, Ahk2Exe was sort of an afterthought for me because I first wanted to get the Store version just up and running, but it does deserve more attention.

Compilations currently fail because there is no execute permissions to any of the AutoHotkey executables in the apps directory. It is necessary to allow these to be executed in order for the compile to succeed. Also Ahk2Exe.exe must be able to be executed in the same way. All these files are available to be selected as a 'base file' for the compilation, and this base file will be executed to validate the script, etc, during the compilation process.

I'm not sure the problem is in execution permissions. I did my testings in a Win 11 standard user environment, and compiling a v1 script with both AHK v1 U64 .bin and .exe created an executable that was runnable without errors. However, when I tried it in a Win 10 environment then I got an error with "Error code 1". Further testing showed that probably the cause is ScriptParser.ahk line 170 where RunWait with comspec seems to fail with ErrorLevel 1, but without CMD it seemed to work. Thus maybe one option would be to change that line to if (ErrorLevel) instead?

I see that you have included the compiler that was issued with AutoHotkey v1.1.37.01. Unfortunately this is not the latest version, which is 1.1.37.01c at time of writing, and is obtainable through this link. It would be best to always include the latest version of Ahk2Exe when you generate a new version for the Store.

The store version is based on the latest AHK v1 and v2 setup files downloaded from the main page, so I'm guessing that the v1 installer includes an older version? I'll see whether I can update my autoinstaller/packager script to also check your GitHub latest version page and download the latest Ahk2Exe from there. I didn't see .bin files in your repo, so those probably don't need to be specifically updated?

The right-click context menu for an AutoHotkey script does not include the usual 'Compile Script' and 'Compile Script (GUI)…' entries to allow easy compilation of scripts.
There is no shortcut link to Ahk2Exe in the Windows menu (task bar Windows icon).

I'll add the Compile Script context menu items in the next update (which I plan to release when AHK v2 gets an update). However, I don't have plans on adding a shortcut link to Windows menu. Namely since the Store environment allows to associate one app with one app execution alias, and console apps are not allowed in the Store, then I had to add three Windows menu items already: one for Dash (which also creates an alias for AutoHotkey.exe), and one for both v1 and v2 (AutoHotkeyV1.exe, AutoHotkeyV2.exe). Since this already litters the Start menu and the different tools are accessible through the Dash, then I decided not to add shortcuts for the additional tools such as Window Spy and Ahk2Exe.
Addendum: well, actually console Store apps are possible, but it requires special permission from Microsoft which weatherlights was denied so I haven't even attempted...

It would be useful if the MPRESS and UPX executables could be included in the Compiler directory to allow compression of the .exe during compilation. These would also need to be executable as per the previous bullet point.

Agreed, it would be useful and the option to select these already exists (and fails currently). I could probably use the GitHubDwnldUrl function from Update.ahk to download the latest of Ahk2Exe, MPRESS and UPX.

Also useful would be to include in the Compiler directory a compiled version of BinMod compiled with latest v1.1+ U32 exe base file. This would also need to be executable as above.

This one is a bit more difficult. It's easy to add it to the package, but I don't want to add it to the Start menu, which brings the question of how to start it? The WindowsApps folder is inaccessible to the user, so some other part of the package needs to start it. For example, Ahk2Exe can be opened from the Dash, which in turn is launched by AutoHotkey.exe. Since Dash is in that case virtualized, it can access the virtualized "C:\Program Files\AutoHotkey" folder and open Ahk2Exe from there. How do you propose to open BinMod.exe? Does Ahk2Exe autodetect BinMod.exe and offer a button to open it?

I have a 'Check for updates' facility in the Ahk2Exe gui that will obviously not be able to succeed in the Store version. Is there any way for Ahk2Exe to programmatically detect that it is being run as an app and then suppress this option? If so, I’ll include this in Ahk2Exe and produce a new version for inclusion.

Since A_AHKPath outputs the unvirtualized path, you can check whether it starts with "C:\Program Files\WindowsApps". This would probably be the safest bet, since it would work with other Store versions as well if anybody decided to make them?
Alternatively, this one has compared to normal AHK a few additional files in the UX folder: UX\LaunchHelpV1.ahk, UX\LaunchHelpV2.ahk, UX\Templates\Minimal for v1.ahk. This means that FileExist("C:\Program Files\AutoHotkey\UX\LaunchHelpV1.ahk") will be true for Store Edition.

[joedf]

Redistributing the mpress and upx binaries is probably fine, but just double just in case.
I have the mpress license here. and the upx one is here: https://github.com/upx/upx/blob/devel/LICENSE

Code: Select all

MPRESS	Matcode comPRESSor
Copyright (c) 2007-2009, Vitaly Evseenko, MATCODE Software
All rights reserved.

This program is free for commercial and non-commercial use as long as
the following conditions are aheared to.

Copyright remains Vitaly Evseenko (MATCODE Software), and as such any
Copyright notices in the code are not to be removed.

Redistribution and use, without modification, is permitted and reproduce
the above copyright notice  and the following disclaimer in the
documentation and/or other materials provided with the distribution.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

The licence and distribution terms for any publically available
version of this program cannot be changed. i.e. this program
cannot simply be copied and put under another distribution licence

[Descolada]

@joedf, as I have very little experience with software licensing, I would like to confirm that I understood correctly: since both UPX and AHK fall under GNU, then UPX is fine (though I'd still have to add the UPX license as well since it has some exceptions for the stubs in compressed files), and MPRESS is also fine if I include its original license? Additionally, any scripts compressed with MPRESS have no additional license requirements since the compression stub (aka binary blob?) isn't covered by a license.

[joedf]

No expert here, but I think MPRESS is fine as long as you include the license somewhere without changing the binary or applying a new license to it.
GPL is a bit more complicated but essentially you have to include the license as well, no relicensing etc. but general, I doubt there is much risk if you're trying your best to respect the license as far as your understanding of it. Especially on free software where you're not profiting from it anyway. Most people don't speak "legalese"... so I like to use https://www.tldrlegal.com/ to help. Anyway, we will very likely not pursue if that helps

[TAC109]

Thanks for your reply. I guess I should have stated that I'm running Windows 10 (my system is too old for Win 11).

I'm not sure the problem is in execution permissions. I did my testings in a Win 11 standard user environment, and compiling a v1 script with both AHK v1 U64 .bin and .exe created an executable that was runnable without errors. However, when I tried it in a Win 10 environment then I got an error with "Error code 1". Further testing showed that probably the cause is ScriptParser.ahk line 170 where RunWait with comspec seems to fail with ErrorLevel 1, but without CMD it seemed to work. Thus maybe one option would be to change that line to if (ErrorLevel) instead?

Unfortunately Ahk2Exe has to use CMD here so that stderr can be captured. When errorlevel = 2 this indicates that there is a syntax error in the script being compiled. I installed Weatherlights version from the Store and Ahk2Exe works correctly with his version. I saw that his version has hard links for Ahk2Exe.exe, AutoHotkey.exe AutoHotkeyA32.exe & AutoHotkeyU64.exe in the WindowsApps directory so I made an assumption that these hard links were what enabled this process. I hope you can find a way around this problem.

The store version is based on the latest AHK v1 and v2 setup files downloaded from the main page, so I'm guessing that the v1 installer includes an older version? I'll see whether I can update my autoinstaller/packager script to also check your GitHub latest version page and download the latest Ahk2Exe from there. I didn't see .bin files in your repo, so those probably don't need to be specifically updated?

The .bin files are included with AutoHotkey and are generated from the source.

I'll add the Compile Script context menu items in the next update (which I plan to release when AHK v2 gets an update). However, I don't have plans on adding a shortcut link to Windows menu. Namely since the Store environment allows to associate one app with one app execution alias, and console apps are not allowed in the Store, then I had to add three Windows menu items already: one for Dash (which also creates an alias for AutoHotkey.exe), and one for both v1 and v2 (AutoHotkeyV1.exe, AutoHotkeyV2.exe). Since this already litters the Start menu and the different tools are accessible through the Dash, then I decided not to add shortcuts for the additional tools such as Window Spy and Ahk2Exe.
Addendum: well, actually console Store apps are possible, but it requires special permission from Microsoft which weatherlights was denied so I haven't even attempted...

Ahk2Exe is not a console app, however this is fine with me.

Also useful would be to include in the Compiler directory a compiled version of BinMod compiled with latest v1.1+ U32 exe base file. This would also need to be executable as above.

This one is a bit more difficult. It's easy to add it to the package, but I don't want to add it to the Start menu, which brings the question of how to start it? The WindowsApps folder is inaccessible to the user, so some other part of the package needs to start it. For example, Ahk2Exe can be opened from the Dash, which in turn is launched by AutoHotkey.exe. Since Dash is in that case virtualized, it can access the virtualized "C:\Program Files\AutoHotkey" folder and open Ahk2Exe from there. How do you propose to open BinMod.exe? Does Ahk2Exe autodetect BinMod.exe and offer a button to open it?

BinMod is never used directly from the menu system, so that's not a problem. It is used in code such as:

Code: Select all

V1 := "V2"
MsgBox V1

;@Ahk2Exe-Obey U_Bin,= "%A_BasePath~^.+\.%" = "bin" ? "Cont" : "Nop" ; .bin?
;@Ahk2Exe-Obey U_au, = "%A_IsUnicode%" ? 2 : 1 ; Base file ANSI or Unicode?
;@Ahk2Exe-PostExec "BinMod.exe" "%A_WorkFileName%"
;@Ahk2Exe-%U_Bin%  "1%U_au%2.>AUTOHOTKEY SCRIPT<. RANDOM"
;@Ahk2Exe-Cont  "%U_au%.AutoHotkeyGUI.RANDOM"

You could compile this code as a test that MinMod is accessable if you wish.

I have a 'Check for updates' facility in the Ahk2Exe gui that will obviously not be able to succeed in the Store version. Is there any way for Ahk2Exe to programmatically detect that it is being run as an app and then suppress this option? If so, I’ll include this in Ahk2Exe and produce a new version for inclusion.

Since A_AHKPath outputs the unvirtualized path, you can check whether it starts with "C:\Program Files\WindowsApps". This would probably be the safest bet, since it would work with other Store versions as well if anybody decided to make them?

Thanks, I'll use this in Ahk2Exe.

Cheers

[Descolada]

@TAC109,

Unfortunately Ahk2Exe has to use CMD here so that stderr can be captured. When errorlevel = 2 this indicates that there is a syntax error in the script being compiled. I installed Weatherlights version from the Store and Ahk2Exe works correctly with his version. I saw that his version has hard links for Ahk2Exe.exe, AutoHotkey.exe AutoHotkeyA32.exe & AutoHotkeyU64.exe in the WindowsApps directory so I made an assumption that these hard links were what enabled this process. I hope you can find a way around this problem.

Okay, so the problem was related to how Windows treats file system virtualization for Store apps. Namely my shell wrapper AutoHotkey.exe was, among other things, trying to preserve virtualized paths when accessing the AHK directory itself, meaning that for example that if an argument C:\Program Files\WindowsApps\53721Descolada.AutoHotkeyv2StoreEdition_2.0.10.0_x64__16ny5jw0c3c86\VFS\ProgramFilesX64\AutoHotkey\UX was passed to AutoHotkey.exe, it was converted to C:\Program Files\AutoHotkey\UX instead. My thinking was that this would provide better compatibility for scripts that expect the regular path, and since scripts launched through AutoHotkey.exe have file system virtualization enabled then that path gets devirtualized properly to the actual path. The virtualization tokens get passed along through Run/RunWait/ShellExecute/CreateProcess, so new launched scripts also have proper virtualization. However, it seems that certain applications launched through these functions do NOT get the virtualization tokens such as cmd.exe and explorer.exe. This meant that ScriptParser.ahk command RunWait,"%comspec%" /c ""%AhkPath%"... was failing because cmd.exe wasn't able to localize AhkPath C:\Program Files\AutoHotkey, because it's virtualized and doesn't actually exist! RunWait, "%AhkPath%" on the other hand doesn't have that problem and was able to proceed normally, which is why the change of if (ErrorLevel = 2) to if (ErrorLevel) would've worked.
Weatherlights version didn't attempt such path manipulations and thus AhkPath was pointing to the actual non-virtualized location, which meant RunWait comspec was able to work normally.

I will remove the attempts at preserving virtualization in the next version, so your code should work unchanged then. However, keep in mind that if you launch Ahk2Exe through RunWait comspec, then virtualization will be disabled which means that registry read-writes won't work among other things.

Ahk2Exe is not a console app, however this is fine with me.

I meant that if I wanted to create a hardlink Ahk2Exe.exe but *not* create a Start Menu item, then it would be considered a console application by Microsoft and the restrictions would apply.

I have a 'Check for updates' facility in the Ahk2Exe gui that will obviously not be able to succeed in the Store version.

I've thought and researched about this a little bit more and found that there's an option to enable installed location virtualization for Store apps. It appears that this enables virtualized read-writes to the WindowsApps folder which get redirected to the users AppData folder. Then subsequently reads from WindowsApps get dynamically merged with the AppData changes, which means that you could implement updates via this system.

For example, after running FileDelete("C:\Program Files\WindowsApps\53721Descolada.AutoHotkeyv2StoreEdition_2.0.10.0_x64__16ny5jw0c3c86\VFS\ProgramFilesX64\AutoHotkey\Compiler\Ahk2Exe.exe"), this redirects Windows to delete a hardlink from the AppData folder C:\Users\USER\AppData\Local\Packages\53721Descolada.AutoHotkeyv2StoreEdition_16ny5jw0c3c86\LocalCache\Local\Microsoft\WritablePackageRoot\VFS\ProgramFilesX64\AutoHotkey\Compiler and subsequently Ahk2Exe is no longer runnable from AutoHotkey Dash. File replacements will work as well, so you could update Ahk2Exe this way. I don't yet know whether this would work in Windows 10S as well which only allows executables to be run from inside the WindowsApps folder, but I'm sceptical about it and wouldn't recommend implementing auto-updates.

Currently of course this doesn't work because I haven't updated the package yet... When I do then your autoupdater still doesn't work, because the Store version doesn't include AutoHotkeyUX.exe (maybe it should though?). And even when I include it, then I still get an unspecified error which is most likely related to the RunWait comspec calls in Update.ahk which try to do unvirtualized read-writes which of course fail

This method has some quirks. FileAppend("mytext", "C:\Program Files\AutoHotkey\testfile.txt") doesn't work (throws an error). FileRead("C:\Program Files\AutoHotkey\UX\launcher.ahk") DOES work, most likely because it's located in the VFS directory. FileAppend("mytext", SubStr(A_AhkPath, 1, -StrLen("v2\AutoHotkey64.exe")) "\testfile.txt") creates the virtualized file in the AppData folder, and reading it with FileRead(SubStr(A_AhkPath, 1, -StrLen("v2\AutoHotkey64.exe")) "\testfile.txt") works, but FileRead("C:\Program Files\AutoHotkey\testfile.txt") doesn't work. I wish Windows had made this stuff simpler...

[TAC109]

I will remove the attempts at preserving virtualization in the next version, so your code should work unchanged then. However, keep in mind that if you launch Ahk2Exe through RunWait comspec, then virtualization will be disabled which means that registry read-writes won't work among other things.

Thanks. Registry access for Ahk2Exe when run through comspec shouldn't be needed.

I have a 'Check for updates' facility in the Ahk2Exe gui that will obviously not be able to succeed in the Store version.

I've thought and researched about this a little bit more and found that there's an option to enable installed location virtualization for Store apps.

It would be great if this is possible! I believe it would mean that it would not be necessary for you to include any updated version of Ahk2Exe, and you would not need to include MPRESS, UPX, or BinMod, if I understand you correctly. These could all be included by the user via the Ahk2Exe Updater as is done currently.

The Updater currently only uses AutoHotkeyUX.exe in order to update the 'installed-files.csv' file with the new hashes so that the regular uninstall process will work correctly. I assume that you don't use this file when uninstalling the Store version, in which case I can bypass this process completely.

The Updater does the actual updating using a long DOS command line, mainly to avoid any file contention. For each file to be updated it deletes the file from the target, copies the new file from a temp location to the target, then if the copy succeeds deletes the file from the temp location. Any files left in the temp location represent a failed update. Hopefully virtualisation will take care of the actual target location? Otherwise I could calculate and include the actual target location in the DOS command line, if that would work.

I feel we are making real progress with this!
Cheers

[TAC109]

I wrote:

The Updater does the actual updating using a long DOS command line, mainly to avoid any file contention. For each file to be updated it deletes the file from the target, copies the new file from a temp location to the target, then if the copy succeeds deletes the file from the temp location. Any files left in the temp location represent a failed update. Hopefully virtualisation will take care of the actual target location? Otherwise I could calculate and include the actual target location in the DOS command line, if that would work.

I’ve checked my Updater code and I believe that the above updating could be done in a AutoHotkey script using sequences of 'FileDelete…' , Try {'FileCopy…', 'FileDelete…'} for each file to be updated, so the updates hopefully will redirect to the AppData folder automatically. This should simplify matters, if I understood your previous post correctly.

Cheers

[Descolada]

@TAC109

It would be great if this is possible! I believe it would mean that it would not be necessary for you to include any updated version of Ahk2Exe, and you would not need to include MPRESS, UPX, or BinMod, if I understand you correctly. These could all be included by the user via the Ahk2Exe Updater as is done currently.

The Updater currently only uses AutoHotkeyUX.exe in order to update the 'installed-files.csv' file with the new hashes so that the regular uninstall process will work correctly. I assume that you don't use this file when uninstalling the Store version, in which case I can bypass this process completely.

Yes, I think this would be the best option and I wouldn't have to include MPRESS, UPX, nor BinMod, just like the regular AHK installation doesn't. 'installed-files.csv' isn't used in the Store version, but I think I'll include AutoHotkeyUX.exe in future releases to provide better compatibility for scripts that rely on it existing (perhaps checking for existance of "C:\Program Files\AutoHotkey\UX\AutoHotkeyUX.exe", which would return true in the Store version as well then). Changes to 'installed-files.csv' would be written to the virtualized file in AppData.

Hopefully virtualisation will take care of the actual target location? Otherwise I could calculate and include the actual target location in the DOS command line, if that would work.

That might even work: at least when I manually created a file in the AppData folder then it was properly virtualized to WindowsApps folder. However, I am still unfamiliar myself with that particular virtualization method so we might get surprises in the future... What I do know is that DOS will not be working in a virtualized environment, so if copying to WindowsApps then the sequence of 'FileDelete…' , Try {'FileCopy…', 'FileDelete…'} would have a better chance of working.

[Descolada]

Update 2.0.12
The v2 Store Edition has been updated to v2.0.12!

Changes/fixes:
1. The package contains AHK v2.0.12, v1.1.37.02, and Ahk2Exe v1.1.37.01c1.
2. Multiple bug fixes such as Explorer right-click new file context menu now containing AutoHotkey Script option
3. Multiple fixes to AutoHotkeyShell.exe (mostly involving command-line parameter passings).
4. In good cooperation with @TAC109 it's now possible to install MPRESS, UPX, and BinMod, as well as update Ahk2Exe via its update mechanism. Due to this, MPRESS, UPX nor BinMod are included in the package.
5 If Windows isn't running in S-mode, then automatically installing required AutoHotkey version now works as expected: eg v2.1-alpha.9 can be installed by running a script that contains #Requires AutoHotkey v2.1-alpha and clicking Yes in the prompt.

I'll be updating the GitHub repo shortly with the changes.