# What exactly does an installer do and why might I need one?

this is probably the noob-question of the day:

So I've written this game.

Now there's the .exe file that does the work, a folder with my beautiful, beautiful assets and a bunch of .dll files and other stuff that I probably shouldn't touch. To run the game, I copy the whole lot to the desired computer, double-click the .exe file and start shooting some dudes. Yay!

But what exactly is the difference between that and using an installer? What else does an installer do besides copying files and looking more professional than a .zip-file? Is there generally a lot of patching/configuring involved when trying to make a game run on a different computer? I tested my game on all windows computers I could get my greedy fingers on and it works great.

• Well in XNA for example, you need XNA runtime. Or with SlimDX you need SlimDX.dll inside your game directory or in GAC. – Kikaimaru Sep 3 '12 at 10:20
• Hm, I understand that. But those .dll files that I need (in my case sdl.dll and its minions) are already in the same directory as the .exe file and they get copied as I copy the rest. What would an installer do differently? – HumanCatfood Sep 3 '12 at 10:22
• @Jan The end user doesn't have to worry about placing files and what not. It's something that gets done for them. – Sidar Sep 3 '12 at 16:05
• Something to think about - how 'big' is your game? I.e is it a little indie-style exe file, one or two DLLs and a few images, or is it some massive thing that needs all sorts of runtimes installing. If it's something relatively small, an exe file in a zip might be good enough and can help get over the user's reluctance to install random games that they might want to delete after five minutes of playtime. – Piku Sep 11 '12 at 11:31
• Talking about installers... something often overlooked is a good de-/uninstaller. I've lost count of how often I had to remove left over files and/or registry keys. Which is especially infuriating when said remains cause problems upon re-installing the game. – Exilyth Apr 19 '13 at 14:27

The installer is typically there to make things easier for the end user. It does some combination of the following:

• Unzipping
• Creation of directories
• Installation of required runtimes (redistributable like: .Net, Visual C++, Direct x)
• Registration with the OS (for later clean uninstall)
• Display beautiful, beautiful screenshots to prepare the player for your game while it works.
• Offering the user the chance to register their game
• Set correct permissions for various game directories (temp folder, save directory, etc.)
• Just install it already, allow the user to mindlessly click next and get to playing the game!
• Oh right, I hadn't thought about that it might need to install runtimes. Thank you! – HumanCatfood Sep 3 '12 at 10:25
• Also, don't forget setting up file access rights! Your game is not guaranteed to have write access to its folder (for savegames and such) unless an installer sets it up. – Nevermind Sep 3 '12 at 12:04
• +1 Most end-users aren't even comfortable with unzipping a file, so the installer should propose a sane default installation path and "just do it" for them. Many end-users don't know what a file-system is, or how to locate files outside of the default Documents paths that are presented to them. And frankly, why the heck should they even need to know? Think of the installer as a poor-mans app store, it should be one click to get playing, no more. – Oskar Duveborn Sep 3 '12 at 12:35
• Well, that really depends on your target audience. – API-Beast Sep 3 '12 at 13:36
• I'd also add consistency to the list of reasons. By providing an installer you ensure that the user gets a setup that's consistent with other users, otherwise you end up with crazy things such as somebody unzipping the game to their desktop and running it from there (yes, I've seen this happen). Using a consistent and known-good setup removes a lot of things that can go wrong, and eases the job of troubleshooting when things do go wrong. – Maximus Minimus Sep 3 '12 at 18:48

An installer abstracts the process of deploying complex pieces of software infrastructure, which is usually contained within an archive, through a convenient, self-sufficient user interface.

This UI can be graphical or based on text which is output on a command-line such as the unix shell (e.g. bash). In case of graphical installers, most often a so called installation-bootstrapper is used, in the latter case, installation scripts which can be bash-scripts, Microsoft batch scripts, or other any scripting language which runs on a command line.

In the simplest case an application is simply an executable file, with the operating system knowing what to do with the file in order to run it. The application file may reside in a folder with subfolders and other auxiliary files, packed into one archive. In this case no installer may be needed.

For complex software, entire software platforms and tight integration with the underlying operating system infrastructure may be desirable, for instance to enforce the copyright of a software product.

Many installers on Windows provide an /e or /extract flag. e.g. setup.exe /e to allow extraction of the archive's contents without the installer running its installation script. I recently needed to do just that.

Towards portability

Installers have almost become a norm for delivering professional software, no matter how simple the underlying software assets. With an increasing number of computer savvy users and the desire to migrate ones applications from one desktop to the next, portable software, often delivered in a simple archive, is becoming increasingly popular.

( I don't know how much time in total I have spent on installers, but it is definitely on the order of days. )

Tasks the installer may handle, are:

• unpacking (often using exotic, high compression archivers)
• ensuring system hardware requirements
• ensuring sufficient hard-disk space
• ensuring software platform runtime requirements (e.g. 'redistributables')