Compatibility with AHK v1 Microsoft Store version

[Descolada]

I'm trying to get this extension working with AHK Microsoft Store version, which is a sandboxed variant where the real exe is stored in a protected folder in Program Files, but an user-accessible "dummy" exe is created in C:\Users\user\AppData\Local\Microsoft\WindowsApps\HaukeGtze.AutoHotkeypoweredbyweatherlights\AutoHotkey.exe.
When I add that path to "runtime" in launch.json, I get an error that "runtime must be a path that exists". AHK scripts run just fine with that exact path, so I figure that the exe being a "dummy" one might be the cause and zero-plusplus is having trouble detecting it because of it?

[zero-plusplus]

Thanks for the report.

AutoHotkey in the Microsoft Store is probably unofficial. So I will not deal with problems arising from it.

But I may be able to find the cause of that problem.

This extension will run a simple script that simply outputs the AutoHotkey version to the console at the specified runtime.
If version cannot be retrieved from the console the extension will display an error. This is probably the error you are seeing.

My guess is that the dummy AutoHotkey.exe is not passing the messages output by the script to the extension.

In this case, you should ask the administrator of the store version of AutoHotkey to improve it.

If the problem occurs for other reasons, there is nothing I can do.

Last but not least, the easiest solution to this problem is to install AutoHotkey using the installer on the official website.

[Descolada]

Hey,
Sorry for the late response: I think your guess is correct and that certain implementation isn't properly passing on the messages. I'll need to do some more debugging to narrow down the issue because thqby's AHK v2 extension is also having trouble with MSIX packages.
AutoHotkey in the Microsoft Store is indeed unofficial, but alas in some cases it's not possible to install AutoHotkey with the official installer nor use the stand-alone version. Namely in some corporate environments the user is locked down and only Microsoft Store apps might be installable (since they are trusted, verified by Microsoft).

[zero-plusplus]

It may be that security restrictions prevent access to the debugger port.
Try using attach. If you can't connect with it, it may be a security limitation.

[Descolada]

I tried using attach, but the issue persists. I actually think the problem isn't in the attaching, but instead nodeJs fs.existsSync (used here and might be related to this issue. Namely I think that the MSIX hardlink is pointing to a restricted folder and that's why the hardlink size is shown as 0 bytes, so existsSync fails (while the hardlink actually works fine). Using statSync instead might fix it, but I can't test that myself at the moment. Would it be possible for you to try it out by installing the Store version and setting runtime to C:/Users/user/AppData/Local/Microsoft/WindowsApps/AutoHotkey.exe?

I hope to get this working because it would simplify AHK usage in restricted corporate environments where only Microsoft Store apps are allowed. VSCode is installable from Store and I have plans on getting both AHK v1 and v2 available there as well. Running scripts through a VSCode extension already works, but getting the debugger working would be a good step forward...

EDIT: I got it working by using runtime path C:/Program Files/WindowsApps/HaukeGtze.AutoHotkeypoweredbyweatherlights.com_1.1137.101.0_x64__6bk20wvc8rfx2/AutoHotkey.exe, both launch and attach modes work! The only problem is that the path can't be figured out easily because that folder can't be viewed by normal users. It would still be preferable if the hardlinks worked and/or executable aliases were allowed (eg running simply AutoHotkey.exe from Command Prompt works, but can't be used as a runtime path).

[zero-plusplus]

I am unable to address this issue immediately as I am currently prioritizing the creation of another extension for AutoHotkey.

Also, I am avoiding installing unofficial apps due to security issues (As is the case with Chrome's store, etc., it is not completely secure. For this reason, it is better to be especially careful when using it in a company).

If you want to address the issue yourself, check out the commit tagged 1.11.0 and replace it with statSync, then run the following command prompt command to create a vsix file, which is the extension package file.

1. npm install
2. npm run package

The created vsix file can be installed using the command palette. Press F1 and type vsix.

[Descolada]

Checking for a valid runtime was fixed by replacing the mentioned existsSync call by the following commandOrFileExistsSync:

const commandExistsSync = require('command-exists').sync;
const commandOrFileExistsSync = (path: string): boolean => {
  try { // if config.runtime is not a command, then check whether statSync throws a ENOENT error
    if (!commandExistsSync(path)) statSync(path);
  }
  catch (err) {
    if ((err as any)?.code === 'ENOENT') return false;
  }
  return true;
};

This requires npm install command-exists, as well as import { existsSync, readFileSync, statSync } from 'fs';

Replacing existsSyn with commandOrFileExistsSync in if (!existsSync(config.runtime)), if (!existsSync(config.program)) and if (!existsSync(config.openFileOnExit)) in extension.ts file fixed the issue and also allows specifying a command as the path. I'll try to create a pull request later for it, unless you see some glaring issues with it?

[zero-plusplus]

Thanks for the verification.
Unfortunately I do not accept pull requests.

I personally don't want to be too aggressive in responding to unofficial AutoHotkey.exe.
So for now, please use your own modified vsix.

If I decide to improve the verification process for AutoHotkey.exe in the future, I will comment here again.

[Descolada]

Okay, thank you for considering this! This isn't too critical of an issue because the current version also works with the direct path to the exe, simply that it's rather opaque and more complex to use. And support for commands is more of a end-user comfort thing.

I didn't address the security concerns of Microsoft Store before, so perhaps a few short comments.
Firstly, a developer needs to register with his/her real name and contact info to become a Microsoft Partner to add apps to the Store. This means that any malware can be directly linked to the developer, it's not anonymous.
Second, all Store apps go through a certification process which includes scanning for viruses and testing for compliance for the MSIX format.
Third, the MSIX format is quite security-focused: all executables are contained in the restricted WindowsApps folder; the installer can't create anything "extra" than specified in the installer manifest (for example, it can't create Desktop shortcuts!); packages are sandboxes so there is limited read-only access to system files; there are certain runtime restrictions such as UIAccess not being available.
All-in-all it's quite a security-focused process, and furthermore I have plans on contacting the maintainer of the AHK store edition to remove their non-AHK executables from the package so the exes themselves could be verified to be "original" via SHA1 hash.

[zero-plusplus]

By command do you mean the exe file in the directives specified in the environment variable?

If you specify "autohotkey" in the current runtime attribute, it looks for it in the installation directory, but I plan to change it in the future so that if the environment variable points to the AutoHotkey directory, that will take precedence.

---

Thanks for sharing the details about Microsoft store security.
I didn't know much about it so this is very useful information.

[Descolada]

By command I meant in this case App Execution Alias which are created for MSIX apps, but they work the same as environment variables. This means that when the Store version of AHK is installed, running AutoHotkey.exe or AutoHotkey as a command from Command Prompt or Powershell runs the exe from whereever the alias points to (in this case, WindowsApps folder), similarly as if it were defined as an environment variable. You can inspect all commands with the corresponding paths in PowerShell using Get-Command *.

Support for commands (which includes environment variables I think) could be permitted by using the commandExistsSync function from command-exists package in the previously mentioned places (eg if (!existsSync(config.runtime)) becomes if (!existsSync(config.runtime) && !commandExistsSync(config.runtime)), unless you need to extract Information directly from the executable instead of just running it with arguments.
I haven't yet figured out how to get the exe path from a command...

[zero-plusplus]

Thanks for letting me know.

I haven't yet figured out how to get the exe path from a command...

It seems that I am using the windows where command to get the exe path from the command.

For example, where notepad at the command prompt will get the following list of paths. After getting the path, it seems to determine if the file exists or not.

C:\Windows\System32\notepad.exe
C:\Windows\notepad.exe
C:\Users\{USER_NAME}\AppData\Local\Microsoft\WindowsApps\notepad.exe