wt.exe vs WindowsTerminal.exe

[AdreKiseque]

Curiosity of mine I've had for a while—just what's the deal with these two files? One might expect them to work as aliases of each other, but would also realize that wt.exe is neither a shortcut nor a symlink to WindowsTerminal.exe... however, they're not hard links to the same data either, and in fact wt.exe is just under a fifth the size of its contemporary. So... what's going on here?

[DHowett]

This is an excellent question that points to a terrible truth. Here's the pull request that introduced wt as a totally separate executable: #6860

Excerpting some of its body. I've added notes inline with ed:.

Due to a shell limitation, Ctrl+Shift+Enter will not launch Windows Terminal as Administrator. This is caused by the app execution alias (ed: wt) and the actual targeted executable (ed: WindowsTerminal) not having the same name.

In addition, PowerShell has an issue detecting app execution aliases as GUI/TUI applications. When you run wt (ed: aliased to WindowsTerminal) from PowerShell, the shell will wait for WT to exit before returning to the prompt. Having a shim that immediately re-executes WindowsTerminal and then returns handily knocks this issue out (as the process that PS was waiting for exits immediately.)

[AdreKiseque]

Honestly quite incredible.
But... why a shim? Certainly a hard link would suffice while being more elegant, no?

[DHowett]

It almost certainly would, but unfortunately our two deployment mechanisms--which are either a zip file or a dressed up zip file (MSIX)--do not universally support writing hardlinks.

We don't distribute an MSI, nor can we run any custom filesystem actions on install. The Windows App Platform takes all of that out of our hands for the MSIX distribution.

[AdreKiseque]

A tragedy beyond proportions. Thanks for explaining!

[DHowett]

Thanks for asking!