HN Explorer

Ask HN: Why are Microsoft software installations so slow?

35 points by zipotm ↗ HN
Hello,

I'm really interested why almost every Microsoft installation and uninstallation is so slowly compared to other programs?

31 comments

[ 1030 ms ] story [ 1289 ms ] thread
some_account
Because the technology is badly designed and users of their software think it's normal.
xor_null
Which software do you mean? windows and visual studio 2017 do install fast, also office 2016. Also, "slowly" compared to what? I mean visual studio does install slowly compared to notepad++ for example, but this is due to different package size..(of course)
simongr3dal
Office does NOT install fast in my experience. I have downloaded the offline installer in order to not have to download office each time I need to reinstall it, but the installer often spends several minutes using 0% cpu and 0 I/O just saying “we’re getting things ready for you”
my123
Office these days uses App-V with Click to Run for the online installations. The Windows Store version (full) installs really fast tho.
buraktamturk
I don't know about the "new versions" of Visual Studio 2017. But VS from 2008 to 2015 installs very slowly (IO wasn't the bottleneck), triple the installation time if the iso file has service packs (I remember that they are applied in "Finalising your setup" progress with bars showing 100%). The latter one is also applies to Office setup.
megaman22
2017 installs pretty quickly, mostly, I think because you can customize the install for the bits you need. But even then, it's much improved, which is good, because they are pushing large updates almost weekly at this point.
brudgers
On Windows, software installation/removal involves a deep analysis of machine configuration state. This takes time but accounts for the high probability of binary compatibility between the operating system and third party software of arbitrary functionality and variable engineering quality that might be a decade old.

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.

zipotm
Thank you, that's good answer!
thwarted
With Linux changes to the kernel can require cascading upgrades to packages or make packages obsolete or break packages.

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...

slavik81
His philosophy is "don't break user space" but the cascading changes are mostly related to kernel modules, which are not user space. Proprietary graphics and wifi drivers seem to be the cause of a lot of that.
nextos
Different Linux distributions have different tradeoffs. For example, NixOS won't break your binaries.
kazinator
What third-party software? This is about Microsoft software on Microsoft Windows.

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?

my123
AppX is a neat way to fix the issues,
blablabla123
Some years ago, when Vista was still a thing I had to package a .Net application. I think the tool was called Wix and creating an .msi package meant to declare each file separately in a giant XML file. A quite crazy task to do this manually, but I guess this speaks for the system and also that Microsoft learned from the past. (I remember using Windows 3.1 and I was aware of 3 significantly different version I could install for this Winsock.dll...)
Precrime
> On Windows, software installation/removal involves a deep analysis of machine configuration state ..

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.

captainbland
I'm sure it must have something to do with extracting many individual cabinet files not being the most efficient thing in the world.
ahartmetz
Part of it is probably that NTFS and / or the Windows generic filesystem layer are incredibly slow per operation compared to the same stack on Linux. You can easily see a difference when doing things like unpacking an archive with many small files or running a build with few changed files. Or even when deleting thousands of files.
tinus_hn
It also doesn’t help that on Windows, typically opening a file involves another process opening the files and scanning it first.
nbsd4life
Because it's bad.
austinshea
It’s a shame people like you come to this site.
[deleted]
(comment deleted)
cbanek
Probably because it doesn't need to be fast, and being fast at installing doesn't sell more copies. You've already bought it at that point, and you only do it once.

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.

wenc
Installation speed will help you provision more VMs faster on Azure, and make the Azure infrastructure much more resource-efficient.

That said, many VMs on Azure are Linux anyway so Microsoft may not have too much incentive to improve their Windows VM provisioning perf.

cbanek
I'm not saying that slow installs are good or bad, and as you point out, there are sometimes good reasons for making installs faster. (Although for VMs, a lot of people use docker or premade VM images just for this reason)

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.

scarface74
Hashicorp fanboy alert:

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.

stephengillie
Some updates are modifying "side-by-side" files. The Windows SxS system allows for multiple versions of the same DLL to live in the OS, so programs can get the version they need. And analyzing which DLLs need to be duplicated is I/O limited.

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.

EnderMB
This was always a running joke for the .NET devs I've worked with. If you need a fresh install of Visual Studio, SQL Server, or anything from Microsoft then you'll be waiting a while, so go make the dev team a round of tea/coffee. Every other bit of nontrivial software installed in less than half the time of an official Microsoft product.

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.