Jump to content
  • Advertisement
  • entries
  • comments
  • views

Windows Installer is Terrible

Sign in to follow this  


As usual, this was copied from Ventspace.

I find Windows Installer to be truly baffling. It's as close to the heart of Windows as any developer tool gets. It is technology which literally every single Windows user interacts with, frequently. I believe practically every single team at Microsoft works with it, and that even major applications like Office, Visual Studio, and Windows Update are using it.

So I don't understand. Why is Installer such a poorly designed, difficult to use, and generally infuriating piece of software?

Let's recap on the subject of installers. An installer technology should facilitate two basic tasks. One, it should allow a developer to smoothly install their application onto any compatible system, exposing a UI that is consistent across every installation. Two, it should allow the user to completely reverse (almost) any installation at will, in a straightforward and again consistent fashion. Windows, Mac OSX, and Linux take three very different approaches to this problem, with OSX being almost indisputably the most sane. Linux is fairly psychotic under the hood, but the idea of a centralized package repository (almost like an "app store" of some kind) is fairly compelling and the dominant implementations are excellent.

And then we have Windows. The modern, recommended approach is to use MSI based setup files, which are basically embedded databases and show a mostly similar UI. And then there's InstallShield, NSIS, InnoSetup, and half a dozen other installer technologies that are all in common use. Do you know why that is? It's because Windows Installer is junk.

Let us start with the problem of consistency. This is our very nice, standard looking SlimDX SDK installation package:

And this is what it looks like if you use Visual Studio to create your installer:

Random mix of fonts? Check. Altered dialog proportions for no reason? Check. Inane question that makes no sense to most users? Epic check. Hilariously amateur looking default clip art? Of course.

Okay, so maybe you don't think the difference is that big. Microsoft was never Apple, after all. But how many of those childish looking VS based installers do you see on a regular basis? It's not very many. That's because the installer creation built into Visual Studio, Microsoft's premiere idol of the industry development tool, is utter garbage. Not only is the UI for it awful, it fails to expose most of the useful things MSI can actually do, or most developers want to do. Even the traditionally expected "visual" half-baked dialog editor never made it into the oven. You just get a series of bad templates with static properties. Microsoft also provides an MSI editor, which looks like this:

Wow! I've always wanted to build databases by hand from scratch. Why not just integrate the functionality into Access?

In fact, Microsoft is now using external tools to build installers. Office 2007's installer is written using the open source WiX toolset. Our installer is built using WiX too, and it's an unpleasant but workable experience. WiX essentially translates the database schema verbatim into an XML schema, and automates some of the details of generating unique IDs etc. It's pretty much the only decent tool for creating MSI files of any significant complexity, especially if buying InstallShield is just too embarrassing (or expensive, $600 up to $9500). By the way, Visual Studio 2010 now includes a license for InstallShield Limited Edition. I think that counts as giving up.

Even then, the thing is downright infuriating. You cannot tell it to copy the contents of a folder into an installer. There is literally no facility for doing so. You have to manually replicate the entire folder hierarchy, and every single file, interspersed with explicit uniquely identified Component blocks, all in XML. And all of those components have to be explicitly be referenced into Feature blocks. SlimDX now ships a self extracting 7-zip archive for the samples mainly because the complexity of the install script was unmanageable, and had to be rebuilt with the help of a half-baked C# tool each release.

Anyone with half a brain might observe at this point that copying a folder on your machine to a user's machine is mostly what an installer does. In terms of software design, it's the first god damned use case.

Even all of that might be okay if it weren't for one critical problem. Lots of decent software systems have no competent toolset. Unfortunately it turns out that the underlying Windows Installer engine is also a piece of junk. The most obvious problem is its poor performance (I have an SSD, four cores, and eight gigabytes of RAM -- what is it doing for so long before installation starts?), but even that can be overlooked. I am talking about one absolutely catastrophic, completely unacceptable design flaw.

Windows Installer cannot handle dependencies.

Let that sink in. Copying a local folder to the user's system is use case number one. Setting up dependencies is, I'm pretty sure, the very next thing on the list. And Windows Installer cannot even begin to contemplate it. You expect your dependencies to be installed via MSI, because it's the standard installer system, and they usually are. Except...Windows Installer can't chain MSIs. It can't run one MSI as a child of another. It can't run one MSI after another. It sure can't conditionally install subcomponents in separate MSIs. Trying to run two MSI installs at once on a single system will fail. (Oh, and MS licensing doesn't even allow you to integrate any of their components directly in DLL form, the way OSX does. Dependencies are MSI or bust.)

The way to set up dependencies is to write your own custom bootstrap installer. Yes, Visual Studio can create the bootstrapper, assuming your dependencies are one of the scant few that are supported. However, we've already established that Visual Studio is an awful choice for any installer-related tasks. In this case, the bootstrapper will vomit out five mandatory files, instead of embedding them in setup.exe. That was fine when software was still on media, but it's ridiculous for web distribution.

Anyway, nearly any interesting software requires a bootstrapper, which has to be pretty much put together from scratch, and there's no guidelines or recommended approaches or anything of the sort. You're on your own. I've tried some of the bootstrap systems out there, and the best choice is actually any competing installer technology -- I use Inno. Yes, the best way to make Windows Installer workable is to actually wrap it in a third party installer. And I wonder how many bootstrappers correctly handle silent/unattended installations, network administrative installs, logging, UAC elevation, patches, repair installs, and all the other crazy stuff that can happen in installer world.

One more thing. The transition to 64 bit actually made everything worse. See, MSIs can be built as 32 bit or 64 bit, and of course 64 bit installers don't work on 32 bit systems. 32 bit installers are capable of installing 64 bit components though, and can be safely cordoned off to exclude those pieces when running on a 32 bit system. Except when they can't. I'm not sure exactly how many cases of this there are, but there's one glaring example -- the Visual C++ 2010 64 bit merge module. (A merge module is like a static library, but for installers.) It can't be included in a 32 bit installer, even though the VC++ 2008 module had no problem. The recommended approach is to build completely separate 32 and 64 bit installers.

Let me clarify the implications of that statement. Building two separate installers leaves two choices. One choice is to let the user pick the correct installation package. What percentage of Windows users do you think can even understand the selection they're supposed to make? It's not Linux, the people using the system don't know arcane details like what bit-size their OS installation is. (Which hasn't stopped developers from asking people to choose anyway.) That leaves you one other choice, which is to -- wait for it -- write a bootstrapper.

Alright, now I'm done. Despite all these problems, apparently developers everywhere just accept the status quo as perfectly normal and acceptable. Or maybe there's a "silent majority" not explaining to Microsoft that their entire installer technology, from top to bottom, is completely mind-fucked.
Sign in to follow this  


Recommended Comments

I feel a tiny bit of your pain. At work I've recently been working on a web application installer for a web app we are developing. The Visual Studio deployment project really hasn't changed at all in the last 5 years. You'd think that some of the simple options would be readily available, but you'd be wrong.

How long will it be before someone creates a program for creating installers that is straightforward to use and actually works well?

Share this comment

Link to comment
I've used InnoSetup, and like the flexibility. InnoSetup makes it easy to build a simple installer, and allows you to expand the installer as you learn more about it's features. It includes scripting support, and can also be expanded with a custom DLL.

Share this comment

Link to comment
Original post by Promit
Alright, now I'm done. Despite all these problems, apparently developers everywhere just accept the status quo as perfectly normal and acceptable. Or maybe there's a "silent majority" not explaining to Microsoft that their entire installer technology, from top to bottom, is completely mind-fucked.
I don't know that I would call it a "silent majority"; every user of an alternative installer is expressing by their actions, that Windows Installer is a massive failure.

The real issue is that Microsoft apparently doesn't see this as a problem.

If it were any other software I would agree, but installing software is about as core to the OS experience as running it. You have to get those applications from somewhere!

Share this comment

Link to comment
On a related note, if you select "Administrative Tools" from the Windows 7 control panel, it takes you to a folder full of shortcuts to what look like the tools from Windows 95. Wherever MS is expending their considerable energies, it's not this kind of basic infrastructure.

Share this comment

Link to comment
I completely agree, we've been suffering windows installer because we have to support several legacy products which use it.

For new projects, we're working with WIX, it's painful, but it gives the flexibility and control we need.

I think there's a lot more people, even at microsoft, aware of this problem; Visual Studio installation also uses Wix:


And I've read somewhere there's a possibility that next versions of Visual Studio will end incorporating wix toolset.

So I think expending time with WIX is a good investment, and what's needed is more tools and visual to help simplify Wix project edition.

Share this comment

Link to comment
Now, I've never had to make any installers for my applications yet. But I've been doing a lot of work in linux, and the install process itself is a breeze compared to the windows installer.

With linux, I love that I can type "apt-get install foo" and get a streamlined process. I usually have one prompt of a "are you sure?" type, and then the only real time consuming part of the install is that it downloads everything fresh from the internet (using a package disk tends to be faster). One command, one "yes/no?" question, and within seconds I can be done with the install.

What a backwards feel the windows installer has after that.

Share this comment

Link to comment
Windows Installer has been an utter disaster since day one. It was supposed to (partly) solve DLL hell and dependencies, but the exact same thing is the core flaw of MSI: you need to install Windows Installer software to use installers based on it. Mind boggling. I also don't understand why most MSI installers require the MSI files to remain resident on the system to uninstall said software. I have had to re-install numerous Windows boxes just to be able to install software because MSI broke something during a previous attempt. For example if you have an older version of MSVC installed, and deleted it's installer, you cannot remove it. Sow when you attempt to install a newer version it will not allow you to continue it without removing the older version...which you can't.

As end user I've found MSI difficult to use, let alone attempt to use it to create installers for my own software. I favor distributing plain old ZIP files and manually installation. And when I want to appear professional, NSIS does a better job than MSI ever can, simply because MSI is fatally flawed by design.

(Just to dispel preconceptions that I'm a MS-basher; I think that VB6 is the best product MS ever created and still use it occasionally).

Share this comment

Link to comment
Original post by KulSeran
Now, I've never had to make any installers for my applications yet. But I've been doing a lot of work in linux, and the install process itself is a breeze compared to the windows installer.

While you're right about package managers making the experience easy for GNU/Linux users (Synaptic is a GUI that makes apt-get install even easier for the CLI-timid), there are two things to note:

1) Making an installer for a GNU/Linux is hairy by comparison to using one. Do you create .deb/.rpm files? Do you create a .sh script? Do you simply pass along a tar.gz file? Once you made the choice, except for the last one, good luck finding an easy way to do it. Debian and Ubuntu use slightly different formats for .deb (not enough to make a difference in most of the apps I have ever installed, but it's a warning I see enough of), and the creation requires intimate knowledge. If you give someone a tar.gz file, it's expected that they would do the trinity of ./configure && make && make install, and autotools has been a bear to get my head wrapped around, to the point that I think I'll have an easier time just paying someone else to create the installer for me.

2) Regardless what you offer, people will complain that you didn't offer what they prefer. Some people prefer installing apps using the package manager. Some prefer the autotools way. Some prefer a GUI installer so they could click Next over and over until they're done. Some prefer to install without a GUI. And if you offer all of them, you'll confuse some people you just want to download and install your game without complication.

I used NSIS to create an installer for a game, and while the actual config file was relatively straightforward to create, I was told that users found that their antivirus would see it was some kind of threat. I think it is because NSIS is probably so commonly used that viruses use them and so NSIS files become triggers.

Installers are definitely a pain. BitRock tends to show up at The Linux Game Tome often enough, and it seems to be a proprietary, cross-platform installer that is supposed to be intuitive. I've never used it, though.

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!