Command line apps from the store: How does that work?

[ad_1]

I had talked about the Windows Package Manager, WINGET.EXE, in a previous blog, but one thing always made me wonder: How do those actually work? I mean certainly the app packages contain the actual executables, but those executables aren’t placed in C:WindowsSystem32 (that would be a bad practice). Whether these apps are packaged as an APPX (like WINGET) or as an MSIX package (something you can easily do yourself with Visual Studio to package up your own command-line app), when installed they just seem to magically work.

Not believing in magic, I tried the obvious test:

OK, so that’s pointing to a user-specific app installation folder. And if I look at the path:

Alright, that explains how it is working: The user-specific app installation folder has been added to the path, and the executable is found there. So let’s look at that folder:

OK, that’s interesting: Yes, the files are there, but they are zero bytes in size. What do those point to? That’s a surprisingly hard question to answer – until you try it with PowerShell 7.0:

Great, now you know where the “real” executables reside. And you see a few nice shortcuts:

wt.exe will launch Windows Terminal. (That’s what I use 99% of the time now – there are a few utilities, e.g. IntuneWinAppUtil.exe, that don’t like the new terminal, but otherwise, it’s definitely worth using it.)
winget.exe runs the Windows Package Manager.
ICD.exe runs the Windows Configuration Designer (which I installed from the store – that version is often more recent than the version installed with the ADK).

Interestingly, the “python.exe” and “python3.exe” apps just take you to the store to install Python as an app, so in effect they are “bootstrapper” apps.

So I see how it works once the app is installed, I dug into the Microsoft.DesktopAppInstaller APPX to see how WINGET.EXE was defined, and that led to this part of the manifest:

<Application Id=”winget” Executable=”AppInstallerCLI.exe” EntryPoint=”Windows.FullTrustApplication”>

   <uap:VisualElements DisplayName=”Windows Package Manager Client” Square150x150Logo=”AssetsAppPackageMedTile.png” Square44x44Logo=”AssetsAppPackageAppList.png” Description=”ms-resource:appDescription” BackgroundColor=”#0078d7″ AppListEntry=”none”/>
   <Extensions>
     <uap3:Extension Category=”windows.appExtensionHost“>
       <uap3:AppExtensionHost>
         <uap3:Name>com.microsoft.winget.source</uap3:Name>
       </uap3:AppExtensionHost>
     </uap3:Extension>
     <uap3:Extension Category=”windows.appExecutionAlias”>
       <uap3:AppExecutionAlias>
         <desktop:ExecutionAlias Alias=”winget.exe”/>
       </uap3:AppExecutionAlias>
     </uap3:Extension>
   </Extensions>
</Application>

Searching for that appExecutionAlias term took me to an article from 2018 that adds another interesting twist: There’s a Settings page that shows them: