AHK v2 Store Edition support

[Descolada]

Hello,
As the title says, I wish for better/native support for the AHK v2 Store Edition. It's possible the Store edition is going to get more popular in the future, because AHK often has problems with false virus alerts when installing, so in Discord some users are being redirected to install the Store version instead in such cases. Currently using the Store version with the AHK++ extension is a bit tricky because of problems I'll describe later on.

If you're not familiar with Store apps, then a short overview first. Microsoft Store has two types of apps: one type is pretty much just hosting a normal installer but there is a security review before accepting it to the Store, the second type are MSIX apps that have strict standards to be accepted and nuances of how Windows runs them. AHK Store Edition is the second type, because having it that way allows it to be installed in restricted environments such as Windows 10S or corporate settings, and is generally more secure. It also receives a certificate from Microsoft, meaning to virus alerts.
MSIX apps are installed in the extra-secure C:\Program Files\WindowsApps folder, which can't even be viewed by normal users. All the base files are shared between users, while user-specific settings are stored in the AppData folder (C:\Users\user\AppData\Local\Packages). Windows does that by detecting read-writes to AppData folder (and some other locations as well) and also registry read-writes, and dynamically merges the C:\Users\user\AppData\Local\Packages contents and actual target location together - achieving filesystem write virtualization and registry virtualization. Doing it this way means that packages can be cleanly uninstalled, and cannot influence each-other (eg by rewriting another packages registry settings).
For this virtualization to be possible, the apps need to be ran from a special hard-link that gets installed in the C:\Users\user\AppData\Local\Microsoft\WindowsApps folder. This hard-link executes the executable inside the C:\Program Files\WindowsApps folder with the proper user credentials, whereas if the executable were ran directly then no virtualization would happen and the app would run as a normal desktop app. Store apps also create Start menu shortcuts that point to those hard-links.

AHK v2 Store Edition creates three of such hard-links: AutoHotkeyV2.exe, AutoHotkeyV1.exe, and AutoHotkey.exe. Additionally, it registers app execution aliases with the same name, which means users can run AHK scripts from the terminal with the command AutoHotkey.exe script.ahk (omitting the location of the executable). The versioned executables start the corresponding packaged AHK version, whereas AutoHotkey.exe starts the script via launcher.ahk, making automatic version detection easily possible. For the versioned ones virtualization is not important, but AutoHotkey.exe requires virtualization, and if it detects that it's not in a virtualized environment then it re-runs itself from the AppData folder hard-link.

Currently the problem is that Typescript existsSync function returns false for the hard-links/symlinks, meaning the extension throws an error saying the executable is not found. It's difficult to specify the real executable path, because normal users can't view the WindowsApps folder directly, thus currently it's quite hard to set AHK++ up to use the Store edition. thqby's extension resolves both the app execution alias as well as the hard-link to the actual target executable, meaning that also the debugger doesn't throw errors and everything works correctly. I've previously made PR's about possible fixes, for example here.

I think setting the defaults for v1 as AutoHotkeyV1.exe and for v2 AutoHotkeyV2.exe should be fine. The down-side is that there is no automatic version detection, and no install prompt for a required newer AHK version (eg using #Requires AutoHotkey v2.1-alpha.14, both of which are supported with the AutoHotkey.exe alias. The alternative is using AutoHotkey.exe /RunWith v1 and /RunWith v2, which forces launcher.ahk into either v1 or v2, but also allows the install prompt.

Help files are a bit trickier. They are located relatively in the same locations as a native installation, just in the WindowsApps folder: C:\Program Files\WindowsApps\53721Descolada.AutoHotkeyv2StoreEdition_2.0.16.0_x64__m6g97a4f38wd4\VFS\ProgramFilesX64\AutoHotkey\AutoHotkey.chm and and C:\Program Files\WindowsApps\53721Descolada.AutoHotkeyv2StoreEdition_2.0.16.0_x64__m6g97a4f38wd4\VFS\ProgramFilesX64\AutoHotkey\v2\AutoHotkey.chm. Of course this path changes with version updates, but you can dynamically get it by resolving the hard-link in the AppData folder. The Store Edition instead uses helper files in the UX folder to launch help files: AutoHotkey.exe "C:\Program Files\AutoHotkey\UX\LaunchHelpV2.ahk" and correspondingly LaunchHelpV1.ahk.

Ahk2Exe doesn't have a hard-link, but is included in the package. It can be ran from the Dash, or by right-clicking a script and selecting Compile, or by running AutoHotkey.exe /compile target.ahk. The last could be used by the extension I think?

Do you think you could look into this?

[mark-wiemer]

Currently the problem is that Typescript existsSync function returns false for the hard-links/symlinks, meaning the extension throws an error saying the executable is not found.

I've learned a lot in the past month, I should be able to resolve this :)

Thanks for the detailed report