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')
• checking for newer software updates
• downloading the software from a remote repository
• creating and/or updating program files and folders
• create configuration files, registry entries or environment variables
• install sofware drivers, mount or unmount devices
• increase accessibility for everyday users, by explaining installation steps, creating links, shortcuts
• promote the own sofware through bookmarks, etc...
• create incentive for the user to actually startup the software, by presenting the keypoints of the software during the installation, slide by slide
• create additional revenue, through software-bundling
• configure kernel-modules and automatically running components (e.g. daemons, windows-services)
• automatic patching of the sofware
• setting folder, file and user permissions
• creating GUIDs to couple the software to a specific installation-instance and for instance, prevent portability

... If you can think of other points, let me know and I will incorporate them.

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')
• checking for newer software updates
• downloading the software from a remote repository
• creating and/or updating program files and folders
• create configuration files, registry entries or environment variables
• install sofware drivers, mount or unmount devices
• increase accessibility for everyday users, by explaining installation steps, creating links, shortcuts
• promote the own sofware through bookmarks, etc...
• create incentive for the user to actually startup the software, by presenting the keypoints of the software during the installation, slide by slide
• create additional revenue, through software-bundling
• configure kernel-modules and automatically running components (e.g. daemons, windows-services)
• automatic patching of the sofware
• setting folder, file and user permissions
• creating GUIDs to couple the software to a specific installation-instance and for instance, prevent portability

... If you can think of other points, let me know and I will incorporate them.