This article is part number 12 of 13 of the completed A year on Windows series.


Can you believe that Windows ships with something that looks like a package manager? By default since Windows 11? I know, right? Let’s take a look.

Installing software on Windows has typically been a very different experience than what you get in a typical Linux or BSD system. The reason, I think, is simple: most Windows software was distributed via physical media (floppies, CDs and DVDs) and most of it was commercial. Such software was very slow to install, so the vendors used the installer’s screen space to hype up ther product features. Take a look at just one example:

Microsoft Word 6.0 Setup touting the AutoFormat feature while it copies files. A fairly typical installation program from the days of Windows 3.x.

Software distribution has changed quite a bit with commonplace broadband connections, but the mess of custom installers remains. Having to visit arbitrary web sites to download installers and going through their snowflake wizards one by one is time consuming. Plus it is risky if you don’t pay attention to where you are downloading those executables from. People will type nvidia drivers in a search engine or, worse, in a file sharing service (I’ve seen that), download the very first thing that shows up, and execute the binary without a second thought. Ta-da! Malware successfully acquired.

Furthermore, some of those installers remain as obnoxious as ever. I’m looking at you, graphics drivers. I don’t understand why something as “simple” as that must pollute the whole machine, ranging from the notification area in the taskbar to the context menus on the desktop, passing by system-wide keyboard shortcuts. Obviously, their installers are equally “on your face”. But anyway…

Microsoft tried to fix this by introducing the Microsoft Store and UWP apps. These apps are “secure-er” and are all installed in a common way via the Store desktop app… which is great, but whether an app is available in the Store or not is a hit or miss. If you want to do any “real work” on your computer—S mode didn’t last even a day on my Surface Go 2—you will have to break free from the Store and go back to using scary-looking installer executables. Or do you?

Chocolatey

There have been unofficial package managers for Windows for quite a while. Chocolatey, which launched in 2011, is the prime example. I’ve used it since I got into Windows a year ago because the convenience of doing choco install whatever vs. the process I described earlier is very valuable. Additionally, if you opt into using the PowerShell startup scripts that Chocolatey provides, the tools you install will seamlessly be available in the PATH, so after a choco install vim, typing vim in the terminal just works.

But Chocolatey feels bloated: it’s slow to run and the hooks it adds to the PowerShell user profile make launching new PowerShell sessions slow. PowerShell has this neat feature to warn when $PROFILE delays startup, and I often get warnings claiming that the script took between 1 to 2 seconds to finish. This makes opening new PowerShell sessions feel even more bloated than what I mentioned in a previous post, which is no bueno.

winget

Chocolatey is all fine and dandy, but it’s one more thing to install. And didn’t I say in the opening that Windows now comes with its own package manager? That’s right, it does, and it is called Windows Package Manager or winget for short:

winget's built-in usage message.

I did try winget as soon as it launched in 2020 but couldn’t avoid Chocolatey because winget’s software catalog was pretty limited. Things have improved over time, as expected. With my most recent Windows install, I’m trying to stay Chocolatey-free and so far I’m succeeding. There are some notable tools missing though, like less, ripgrep or fd-find, which I’ve had to install on the side. But so far so good.

winget definitely feels faster than Chocolatey and having one less tool in the system is nice. But it also has downsides. The biggest one is that you must manually configure the PATH to point to newly installed software. And fiddling with environment variables on Windows just feels wrong. The UI is much better than it used to be, but still… a UI? Just give me a file to edit or a package-friendly .d directory like macOS has in /etc/paths.d!

The Environment variable editor showing my PATH contents and how I had to add a bunch of directories after using winget to make Git, Vim and Emacs usable.

Uninstallation

OK, so software installation is now great. What about, you know, uninstallation? Having reliable uninstallation procedures is critical for peace of mind: knowing that you can clean up any piece of software you install “just for a test drive” is powerful. And I’m not sure that Chocolatey or winget are there.

Whenever you use these package managers for Windows to install software, you quickly realize that, for the most part, they are just command-line wrappers around the original ad-hoc installers. These executables can still do whatever they want and there is zero guarantee that their uninstaller counterpart will do the right thing. Will the uninstaller truly remove all files littered through the system? What about Registry entries?

Compare this to the package managers you find on Linux or the BSDs. These package managers do not (typically) run installers: they are the installers. Tools like dpkg or rpm are responsible for extracting a package’s files and putting those where they belong, and because they did that, they know exactly what files were installed. When the time comes to uninstall a package, these systems can just walk the list of files they previously registered and remove those.

Of course, these Unix-y package managers can also run arbitrary scripts at package installation and uninstallation time, so they cannot be trusted to be completely clean either. However, the culture around these systems means that the people creating their packages go to great extents to ensure that this is true. And there is a difference there. I still remember one of my proudest contributions to Gnome, which was to extend GConf to support cleaning up the system-wide database when removing a package. Wow, 2003 called.

Anyway. In the case of winget, this situation is even more confusing because winget is a facade over both old-style installers and Store-based software. Take a look and notice the Source column over to the right:

GO2 C:\Users\jmmv> winget search spotify
Name                         Id                   Version              Match                   Source
------------------------------------------------------------------------------------------------------
Spotify - Music and Podcasts 9NCBCSZSJRSB         Unknown                                      msstore
Spotify                      Spotify.Spotify      1.1.80.699.gc3dac750                         winget
...

If you use winget to uninstall software that came from the msstore source, the uninstallation will be clean. But for software that came from the winget source… good luck because then you are subject to “regular” uninstaller executables.


To recap, it’s awesome to see winget as a standard tool in Windows because this is a huge step forward in system usability and administration. However, I’m not fully convinced that this tool can be trusted to do the right thing when uninstalling software, so I’m still wary of installing random stuff.

Tomorrow, it’s time to wrap up this series (unless some other topic I did not think about comes up). I’ll briefly touch upon the much-hated telemetry and conclude with a brief summary.


This article is part number 12 of 13 of the completed A year on Windows series.