I think the idea of having a system to manage installed packages is very helpful when running your operating system. Linux has different forms of repositories, and different methods like snaps and flatpacks. Runtimes and languages might have their own package managers. They have their ups and downs, but generally I find them easier to use than on windows where you have to manually download and run installers.

So when I was setting up a Windows PC I figured I could install Inkscape from the app store and it would all work, just fine. And for the most part, it does. It can update easily, it launches the gui from the start menu exactly as expected, and there were no issues.

Until I faltered when attempting to run something using the command line version of Inkscape. Windows never adds programs to the system path normally, so you mostly need to do that manually unless the installer does it for you. Of course, something installed from the MS App store will never do that, so you need to find the executable and add the location yourself if you need it.

Programs from the MS App Store do not go into the normal locations. They go into some strange directory where the OS does it’s best to keep you out of. I guess for regular users this makes sense? But it’s very annoying trawling through the C: drive trying to find this.

Then I decided to use Process Explorer to find the real, true, folder where it exists. For reference, Inkscape on Windows when installed from the store exists here:

C:\Program Files\WindowsApps\25415Inkscape.Inkscape_1.3.2.0_x64__9waqn51p1ttv2\VFS\ProgramFilesX64\Inkscape\bin

I added this to the path and even that doesn’t work. It simply says “Access Denied”, and I suspect this is a fake link added for compatibility and isn’t the real way to access the program.

Another way often suggested online to find where the executables are stored is to use a shell command. This requires opening a special folder that lists the apps by opening shell:AppsFolder. Here you can drag a link to the desktop, then right click the app shortcut to get the target executable name. Except, it many cases the app IDs are so long, they don’t fit inside the fixed width window.

Except when using the command in this way, when you try to actually do something with it in the command line, it doesn’t seem to have the right current directory path. For example, the export command should saved relative to the current directory, but when I tried to export some images, I can’t even find where it ends up saving. It’s possible it’s just broken completely.

I think the moral of this story is that despite the Windows Store, despite WinGet, Window still doesn’t have proper apps management.