It's a bird, it's a plane, it's

Everything here is my opinion. I do not speak for your employer.
July 2007
August 2007

2007-07-25 »

The horrors of Setup.exe

Recently Jeff Atwood wrote about Mac software installation, complaining that it's not as easy as Windows setup.exe. There followed a barrage of comments, but I think most of them miss the point.

The point is that "installing" software is a very suspicious exercise anyway. What exactly is it doing to my computer that takes half an hour or more to install Microsoft SQL, for example? Why can't it just copy some files around and then run the server daemon?

Installers are arbitrarily slow

Since the ancient DOS days, this question has always been very mysterious to me. Once upon a time long long ago, I was installing a game (Wing Commander II, I think) from floppies on my 386, and wondering why it took absurdly long to do compared to, say, good old diskcopy.exe. There was no good reason; a few months later, I built an installer for an app I wrote, and it could copy itself from a floppy in a fraction of the time. And I didn't do anything special to achieve it; I just used plain fread() and fwrite().

To this day, programs like InstallShield continue to astonish me. Have you ever watched the installation log messages as they scroll by? They sometimes say things like "Creating registry key HKEY_LOCAL_blah\blah\blah\blah" - one per registry key. That's fine, but why do I have time to read them as they go by? On a dual-core 2 GHz processor, creating registry keys happens in a timeframe humans can see? How? I'm sure it's the same reason as Wing Commander II was slow, so many years ago.

InstallShield, by the way, is the worst offender I've ever seen. For some reason, it's also the most common installer platform. If you're writing an installer, take my advice: just use NSIS instead. It's awesome. We used it to build the ExchangeIt Plugin installer for Outlook. It writes registry keys during the installation process too. Know how long it takes? Me neither - it's immeasurably fast.

Actually, the entire ExchangeIt install process takes as long as it takes you to press Enter-Enter-Enter-Enter. I can't quite figure out what I'm doing right.

"Install" is the wrong concept

But there's another, more fundamental problem with all this: installers are doing too much stuff. "Install" is completely the wrong word for the operation we want to be doing. I don't "install" a toaster or a TV - I plug it in and push the button and it works. Anybody can do it. But you "install" a kitchen sink - and it's a scary operation, best done only by experts, because it involves plumbing and might spew water everywhere and ruin your whole house if you do just one thing wrong.

There's a reason people are scared to install Windows software - because it is like plumbing, and you might screw up and ruin your whole computer if you do it wrong. That's scary!

On Windows, installing software involves copying DLLs around (sometimes into the Windows directory where it overwrites ones from other apps), changing registry keys (sometimes ones that conflict with other apps), and creating Start Menu shortcuts. The installation process takes forever and has lots of unfriendly status messages just to underscore the fact that you should thank goodness for setup.exe, because you sure don't want to have to do all that stuff by hand.

On a Mac, most of those problems are solved. An application is actually a "package" folder containing all the app's critical files; most applications don't need to put any files outside that package. The "Start Menu" is the same thing as the Applications folder; unlike Windows, there's no need to create "shortcuts" to make the program visible. No user should ever have trouble figuring out the new application is in the Start Menu, because they're the person who put it there.

And you know what's cool? If they don't put it there - if they don't drag it anywhere at all - clicking on the application will work just fine. They never actually need to install it. And furthermore, they can drag it anywhere they want - to another disk, to their desktop - and it'll work fine there too. It's right where they left it.

Okay, how does uninstalling work? Well, you go to the applications folder and delete it, just like any other file. In Windows, users try that too: deleting the icon from the Start Menu to make the application go away and free up some disk space. In fact, they must have tried it a few too many times, because when you try it in Windows XP, a dialog pops up warning you that it won't work. Yeah, too bad about that.

The whole Mac thing with the .dmg files and virtual disks and needing to "eject the application" afterwards is mysterious to me, though. The design of application packages is extremely clever - but the front end to it is clunky. Why does the package need to be in a virtual disk at all? I'm not sure. At least it's just a UI issue and can be fixed in a future version.

(Incidentally, in .NET Microsoft is trying to do roughly the same thing as Mac packages: they call it Xcopy Deployment.)

Next time, some advice on how to write a better setup.exe. Because it doesn't really matter if setup.exe is a good idea or not; we're stuck with it.

I'm CEO at Tailscale, where we make network problems disappear.

Why would you follow me on twitter? Use RSS.

apenwarr on gmail.com