Ask HN: Why are Microsoft software installations so slow?
Hello,
I'm really interested why almost every Microsoft installation and uninstallation is so slowly compared to other programs?
I'm really interested why almost every Microsoft installation and uninstallation is so slowly compared to other programs?
The Windows software system has different tradeoffs than Linux where distributions are compatible with specific versions of software -- i.e. if the distro doesn't have a package there may not be binary compatibility. With Linux changes to the kernel can require cascading upgrades to packages or make packages obsolete or break packages.
Windows' tradeoffs are also different than those made by BSD and similar systems that eschew binary distribution --- systems where everything gets compiled from source on the user's machine. In terms of speed, compiling a large application from source can take significant time though it will probably require few if any reboots.
This is the exact opposite of Linus's well known and ranted about position on kernel compatibility with user space.
https://lkml.org/lkml/2012/12/23/75
https://unix.stackexchange.com/questions/235335/why-is-there...
A handful of Windows calls can be used to detect the version, if necessary.
What new Microsoft software will install on ancient windows anyway?
E.g. Office 2016 system requirements: https://support.microsoft.com/en-ca/help/4026853/office-offi...: Windows 7 or newer, or Server 2008 or newer.
Do we need deep analysis to sort out whether we're on 7, 8, or 10?
https://blogs.technet.microsoft.com/askperf/2008/04/23/under...
https://blogs.technet.microsoft.com/joscon/2010/06/15/servic... https://blogs.technet.microsoft.com/joscon/2010/07/06/servic...
Windows installers are designed to fail if they detect software piracy. For instance a machine with MS Office installed, install Delphi, uninstall Delphi and Office refuses to run. Presumably because it thinks it's been copied from another machine.
Installations and uninstallations of software aren't as well tested as most people think, and keeping metrics of how fast you can install or uninstall aren't really a thing for most software. For office, if it installs 10% faster, and saves you a few minutes, would that sell more copies? Probably not. Making uninstall faster? Almost certainly not going to help.
If you don't benchmark something and care about its performance, it's unlikely to get better, but pretty likely to get worse over time, as code accretes.
One classic perf bug was in the a very old visual C++ installer (I think it was 6.0). Drawing the progress bar and printing out each filename as it was installed felt good to the user - it was doing something. But drawing that and having to update textboxes took a non-trivial amount of time. The fix? If you minimized the installer, it would run a LOT faster, like minutes faster.
Installers are more worried about correctness, especially when having to deal with multiple OS platforms. Sometimes there are a lot of extra system calls just to make sure things are going well that might not be absolutely necessary all the time, but fixed a bug "that one time." Those kinds of repeated checks, especially to the filesystem, can really slow things down in unexpected ways.
That said, many VMs on Azure are Linux anyway so Microsoft may not have too much incentive to improve their Windows VM provisioning perf.
In another interesting case I've run into in the past, the installation of World of Warcraft is insanely good and had a lot of effort put into it (a little bit by me, even). This was important as being able to start the game as soon as possible, even before you've downloaded the entire thing, is a way to actually increase conversion to paid users (or really, to not take so long that a person goes off and does something else and forgets to play WoW). This is one reason why there's an incremental install process for Blizzard games that involves a lot more tricks than most people realize.
With that being said, Visual Studio 2017 was incredibly quick to install on a fresh system (no VS installed previously), to the point where I assumed that I'd done something wrong or missed something during the install.
I remember hearing Scott Hanselman discuss this on a podcast (.NET Rocks, maybe?), and he said that one of the selling points of the latest versions of Visual Studio was how they were planning on splitting individual components out, making them easier to install, easier to port (a nod to .NET Core), and making the IDE experience faster. It may be that the reason why Microsoft tools take so long is because you're installing one large chunk, whereas the more they modularise the software the quicker it is to set things up.
I've never developed anything in Go, but I have used Hashicorp's Consul, Nomad, and Vault all written in Go - they are each one relatively small executable, with no dependencies that you can run either in client, server, or dev mode.
The only slightly irritating thing is that there is no built in support to run them as a Windows service. I had to use NSSM.
That's what an installation should be.
https://insider.windows.com/en-us/articles/were-listening-to...
One of the other issues is the Windows Update model, where some updates "unlock" other updates. You start with a fresh Server 2008 R2 install, it takes ~130 updates. 1 of those is the SP1 upgrade, which unlocks another ~130 updates. Another is SP2, unlocking another ~60. A third is a .NET version upgrade, which unlocks another 10 updates.