Now, granted, I’m no impartial observer. I’ve hated Windows since the 1998 iteration, and haven’t looked back. I used Linux as my primary OS from 1999 to 2002, then finally ended up buying an iBook and switching to Mac OS X (which was at version 10.1 at the time.) So I am confused by the outrage generated by drag-and-drop “installation” that is the method that Apple recommends to all developers. The article itself discusses the rationale for these guidelines, which I won’t regurgitate, but which I will refer to.

I do have to use Windows once in a while at work. But luckily I have no power to install or uninstall apps, and am glad to let the IT guys do their job. I do have a burning hatred for the pile of excrement known as IE 6, but unfortunately, one of the key apps we run depends on Active X, and the IT guys are (I think justifiably) paranoid about migrating en masse to IE 7.

Still, I was (until they stopped allowing writing to the Desktop, which makes it rather awkward to read research papers in PDF format, but that’s an entirely different rant altogether) able to download and install Firefox rather easily, since the installer allows me to arbitrarily choose any folder and doesn’t require write-privilege to C:\WINDOWS. Once I got into the habit of taking my USB Flash Drive with me everywhere, I just installed Firefox onto that.

But there are plenty of crappy Windows apps out there that require write privileges to C:\WINDOWS. And many of their installers have no way of specifying an alternate directory from which to run. Personally, I think this sucks.

In those barbaric pre-Windows days when I ran MS-DOS 4.01(!), I grew into the habit of creating my own custom file system hierarchy. C:\UTILITIES was in my PATH and held all my commonly used utilities, like PKZIP and grep. C:\WORDPRO contained WordPerfect and MS Word 5.5 for DOS. C:\PASCAL contained Turbo Pascal 7.0, which was my language of choice at the time. (Of course, there was GW-BASIC, and with MS-DOS 5.0, QBasic, but you couldn’t really write command-line utilities with those.) And of course, there was C:\GAMES.

So when Windows 3.0 forced me to stick all my crap in C:\WINDOWS, that made me unhappy. I tried to fight it as much as I could, but in the end, I gave up. Worthless apps, their directories, and their DLLs accumulated as I upgraded to Windows 3.11 and then eventually Windows 95, and very quickly DLL hell forced me to reformat and reinstall. Little did I know that this would become standard procedure for dealing with those damned BSODs.

My experience with uninstallers have pretty much been mostly unhappy ones. They’ve deleted DLLs I needed to run other apps. They’ve munged my registry so that I couldn’t easily boot back into Windows. They leave all sorts of worthless cruft all over the place. In an era where 120 MB of hard drive space was capacious, all those random useless files made a big difference. Especially since a 4-byte long file would consume an entire cluster. The thought of all those hours I wasted pruning my C:\WINDOWS directory to gain a few megs of hard drive space makes me feel nauseated.

But the back-breaker was DLL hell. I think this is the main reason why I hate Visual Basic and anyone who uses it as their primary development language. VB apps proliferated like E. coli in a Petri dish, and each app thought it would be best to install their own version of key DLLs, frequently rendering my system unusable. (Can someone tell me if they finally decided to do DLL versioning in Vista?) Random crashes from old and incompatible DLLs made me scared to install new programs. Although I guess it wouldn’t really matter all that much. The next reboot-and-reinstall cycle was only a few days away anyway.

Eventually, I grew weary of it, wiped my hard drive, and installed Red Hat Linux 6.0. Granted, it took me about a week to get PPP working and get back on the Internet, but installing X and Netscape was actually not too bad. I would break my system frequently by screwing around with configuration files, but I figured that if I had to deal with frustration, at least I was learning something.

Interestingly, it was Windows that made me decide to get a Mac. I figured I needed to get a laptop, but in 2002, there were very few laptops that would actually run Linux reasonably well. And the idea of buying an x86 laptop and have to pay for Windows, even if I wanted to run Linux, made me sick. So it was inevitable.

Now packaging systems are all well and good. I wrestled mostly with RPM back in the day, and these days I mess around with the apt-get-derived Fink Project (a system of ports of open source packages to Mac OS X) There is great satisfaction in being able to confidently uninstall an app you don’t want anymore, despite its files being scattered across the multiple directories of the file system hierarchy standard. A single command and it’s gone. No obsolete dynamic libraries to worry about. No cruft you need to get rid of manually, except maybe in your home directory.

Still, you can easily run into dependency hell, particularly if you downloaded stuff from third-party repositories because you had the burning need to run bleeding-edge software. You could avoid all this if you stuck to your distribution’s standard repo, but there was a lot of cool stuff you’d be missing.

The other solution was just to roll your own. Write your own spec files and build your own packages. Nice if you’re willing to do it, but probably not newbie-level kind of stuff. While the standard UNIX incantation should be easy enough for a newbie who doesn’t have a phobia of the CLI, the problem with ./configure; make; make install is that you just can’t easily uninstall that.

So: the concept of bundles. Like most of the nice things about Mac OS X, this was actually already a feature of NEXTSTEP. Everything you need to run an application is stored in the bundle. Don’t like the app? Toss it into the Trash Can. Or type rm -rf Random.app if you like. No harm, no foul. No accidentally deleting system-critical DLLs or trashing the registry. No having to uninstall all the apps that happen to depend on the library you want to get rid of.

In other words: simple.

Now you may wonder just how efficient this is, to require every single app to contain every single library that it needs to run. In terms of disk space, not very. But when the smallest hard drive you can buy on the market is about 300 GB, who really cares?

In terms of RAM, apparently the OS is smart enough to recognize when a required shared library is already running and to make sure that it’s actually compatible with the app. So: most of the benefits of shared libraries. None of the potential for versioning disasters.

If you’re telling me that dragging an icon into your Applications folder (which happens to be standard in every Finder window, and as many have pointed out, is usually symlinked in the DMG file itself) is more complicated than running through an opaque installer, then clearly your definition of “complicated” does not coincide with mine.

In the end, I think it’s just a culture of groupthink amidst most Windows users, given that they happen to be mostly in the corporate sector. There is something “official” about an installer. It makes people feel like your app is legitimate. That the developers know what they’re doing, and who are we to question the developers? Never mind the fact that it’s all too easy to perform nefarious deeds in the name of installation. Or that most installers are putrid piles of feculent vomit that generally do the wrong thing and end up violating the integrity of your OS (and Mac OS X does not, by any means, escape this tendency.)

These are the same guys who will turn around and bend over and pull their pants down just because someone flashes a badge.

Although I guess it does explain why America is as fucked up as it is, but, again, that’s another rant entirely.