Based on past experience, I wouldn't trust any app to mess with the associations for scripts. I would only associate non-script files types, such as TXT and CSV to an editor and use right-click to edit scripts. In general, I see no reason to touch the associations when you can right-click to edit and double-click to run.

I downloaded and installed Notepad++ on Windows 11 and had no issues. After installing Notepad++, I could right-click a CMD, BAT, or HTA file and select Edit with Notepad++. Double-clicking the CMD, BAT, or HTA still launched it correctly.

It sounds like you want all editable files to load in the editor when double-clicked, but offer the correct option to run them (if it's a script) via right-click and Open with. That should be okay in theory, but very few people do that, so it's not surprising that it's an approach that has flaws.

// Microsoft might disagree that this is a glitch, but I feel an opportunity for exploit here. Why are different interpreters handled differently? Why is overriding things that behave like exec() ever necessary or appropriate?

착불상품이 있습니다. 착불상품은 결제시 포함되는 배송비와 별도로 물건을 수령하실 때 택배기사분께 배송비를 지급하셔야 합니다. 주문하시겠습니까?

Yes, I can replicate the first issue with both VBS and HTA extensions. The easy fix is to go back to Notepad++ in admin mode and remove VBS and HTA extensions from its associations. The interesting behavior is that if I then add HTA and VBS back to the Notepad++ association list, nothing appears to change. That is, they remain associated with mshta.exe and wscript.exe. But then I tried logging out and logging in and VBS was then associated with Notepad++ and Windows Script Host remained available under Open with. HTAs, however, remained associated with Microsoft (R) HTML Application host. I could force HTAs to be associated with Notepad++ (via Open with) and after doing that, Microsoft (R) HTML Application host remained as an Open with option.

This also happens with other interpreted file types like CMD and BAT if an "edit" action is added Windows File Explorer by application software. I reported this bug to Microsoft earlier, and it seems to affect HTA files too.

Glad to hear you got it working and that you got File Explorer set up to your taste. Can you let me know the exact file name of that ISO? Maybe I can investigate further. If non-retail Windows 11 ISOs come preset with HTAs associated with Edge, that's a concern for me. At the very least, I will update the download and quick start guides with instructions for associating with mshta.exe. Thanks so much for posting an issue and following up. Much appreciated!

Is there a way to disable the security check or otherwise force the Edge browser to open the HTA files on recent Windows 11 builds?

I don't think Microsoft will agree that it's a glitch. They'll probably be of the position that Notepad++ took over the associations, so it's up to Notepad++ to provide the correct context menus. And the Notepad++ developers will say that it's just a text editor. That is, if you choose to associate scripts with an editor, you can't expect them to retain their full capability as scripts. I don't think Notepad++ should include script extensions in its File Association option or, at least, pop up a warning that this could break things.

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

And invoke the first through COMMAND and/or CMD. This will express inconsistently, but it will completely break any non-trivial script when it happens.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Based on the icon, it appears that the HTA extension is associated with Edge on your computer. It must be associated with mshta.exe in order to work.

In my testing (in a VM) after making all those associations to Notepad++, some file types were okay, such as VBS, which still offered Microsoft Windows Based Script Host under Open with. However, CMD had no Open with options. My test HTA did still had Open with Microsoft (R) HTML Application host, but that may be because I had previously intentionally broke and fixed that association. But even if it works for manually running a single script, it's still going to break when one script runs another, unless the run command is prefixed with the host exe for that script type.

I installed this Windows 11 instance from a non-retail ISO today, so this computer is fresh and there are no GPOs or anything like Active Directory installed on it.

I didn't realize that this particular design mistake in Windows File Explorer could be fixed. Thanks for doing the heavy lifting by figuring out how to mitigate the bad default column layout. The "File Type" column greatly annoys me, and this is a good way to hide it in Windows 11 everywhere.

By default, Windows does not block HTAs. The block may be set as a GPO on your machine. Is that a company owned computer (i.e. is it centrally managed)?

I tried your test with the batch files while BAT and CMD extensions were associated with Notepad++ (double-clicking files with either extension opened them in Notepad++). But running them in CMD prompt, they consistently showed ALPHA BRAVO.

Login as a different user and try to change the .HTA association back to the HTA Host. On my test machine, the HTA Host doesn't appear in the "open with" dialog and cannot be manually or programmatically selected by the second user.