Inside the Installer: What Really Happens When You Install Software
Even as a technology professional, I rarely give much thought to the process that brings new software to my computer, phone, or tablet. Most of us don’t, as long as it works. We download a piece of software, double-click on the icon, and away we go! The action of double-clicking that installer, as simple as it seems, launches a sequence of events that puts bits of code into place, stores libraries of information and images, and gets everything ready for you to use. There’s a lot that goes into making all of that happen, though. Your program may have started out as millions of lines of code, which you’ll never see.
Software installers are programs themselves, and their purpose is to —well, install software. In most cases, we could run a program without using an installer if we knew where to place all the files, if we knew how to manually configure dependencies, environment variables, Windows registry settings, and system paths, and if we had sufficient permissions to make all those changes. It’s enough to make my head spin – and that’s why software is packaged into those installers.
Software installation packages provide convenience, consistency, and a pleasant user experience (in most cases). They protect the system and us from incorrect placement of files, and they make it so we don’t have to figure out what else might be required for the program to run. That’s what we’re exploring in this piece – the behind-the-scenes activities of a software installer.
What Happens When You Run an Installer
You first need to launch the installer. You do that by double-clicking on an icon, most of the time. However, you can also run it from the command line, by typing in the path to the executable – the program that will run. The installer then starts the process by extracting files into temporary directories. It places the actual program files, configuration scripts, and other components, into a holding pen.
Next, the installer program checks for system compatibility – the operating system, the hardware architecture (processor, RAM, etc.), and system permissions required and existing. When the installer receives confirmation that the program is appropriate to the environment, it starts writing files to the correct locations, making the required registry edits, setting the environment variables as needed, and putting the configuration files into place.
The last few steps of the process include creating shortcuts for your desktop if you want one, and adding an entry to your launch menu. Then it does one more check, and does some cleanup. Well, the well-written ones do some cleanup. That temporary location and the files stashed there? A good installer gets rid of those.
Common Types of Installers
Platform 2339_8a6e52-e1> |
Installer Type 2339_ba741b-4c> |
Description 2339_df3247-e6> |
Windows 2339_68ec7d-e6> |
.exe (executable) 2339_d82cd5-29> |
Custom-built installer using frameworks like NSIS, Inno Setup, or InstallShield. May include wizard-style UI. 2339_a0e1e5-f3> |
Windows 2339_72842b-9e> |
.msi (Microsoft Installer) 2339_79eb40-f2> |
Standard Windows Installer package. Often used for enterprise deployments; integrates with Group Policy. 2339_92bb9e-45> |
Windows 2339_84a5a9-96> |
Microsoft Store App 2339_34dc04-79> |
Apps distributed via the Microsoft Store. Installed in a sandboxed, user-space environment. 2339_ce8c7c-f1> |
Windows 2339_02cd7b-32> |
Portable Apps 2339_70ae93-a7> |
No installer required—just unzip and run. Doesn’t modify system files or registry. Useful for USB use. 2339_a3828d-72> |
macOS 2339_5e8592-ee> |
.dmg (disk image) 2339_aecfc6-f0> |
Most common; user mounts the image and drags the app to the Applications folder. 2339_fb924b-ce> |
macOS 2339_631b2b-9f> |
.pkg (installer package) 2339_e166c2-b8> |
Used for system-wide installs or apps requiring elevated permissions. May install background services. 2339_382270-e4> |
macOS 2339_effd2c-1a> |
Mac App Store App 2339_75e735-6b> |
Installed and updated via the App Store, sandboxed and vetted by Apple. 2339_d1d6a5-6a> |
Linux 2339_6c750d-b6> |
.deb (Debian-based) 2339_c5f2f1-50> |
Used by Debian, Ubuntu, and related distributions. Managed with apt. 2339_985383-6e> |
Linux 2339_7aebfb-d1> |
.rpm (Red Hat-based) 2339_ef9ca7-72> |
Used by Fedora, CentOS, and RHEL. Managed with yum or dnf. 2339_54601b-09> |
Linux 2339_215eec-5f> |
AppImage/Flatpack/Snap 2339_6f7332-b8> |
Universal, self-contained installers with better cross-distro compatibility. 2339_3d4560-e5> |
Linux 2339_c7583a-73> |
Source Code/Scripts 2339_c0d18b-7d> |
Compile-and-install via terminal using make or custom shell scripts. Often used by developers. 2339_92d48d-db> |
Android (Phones & Tablets) 2339_a0fbe6-39> |
.apk (Android Package) 2339_b5ab9f-22> |
The actual install file; used internally by the Play Store or sideloaded directly. 2339_a8ba41-a6> |
Android (Phones & Tablets) 2339_67ad17-bf> |
Google Play Store App 2339_686515-5e> |
User-friendly interface for discovering, installing, and updating apps. 2339_2e96b9-23> |
Android (Phones & Tablets) 2339_4dacaa-33> |
.aab (Android App Bundle) 2339_afff8e-f6> |
Used by developers; Play Store builds .apks from this format for devices. 2339_f7ee26-91> |
iOS 2339_b78c11-2c> |
App Store App 2339_06806e-79> |
All apps must be installed through the App Store unless using developer tools. 2339_41f240-ce> |
iOS 2339_1414dc-23> |
TestFlight Build 2339_dd556c-dd> |
Used by developers for beta testing before public release. 2339_2a3a66-34> |
iOS 2339_afa6d4-5c> |
Enterprise/MDM Installers 2339_0b252f-a7> |
Used in corporate environments to deploy in-house apps outside the App Store. 2339_9300ae-a8> |
Components of a Good Installer
I mentioned above that good installers clean up after themselves, but that’s only one aspect of a good installer. To be fair, most installer packages are “good installers,” meaning that they perform the tasks I’m about to enumerate. Pre-installation checks help identify the operating system and its version, any required pieces of code it may need to install separately from its own installation, the required disk space, and any unusual permissions. Most installations require administrative permissions; that’s standard, not unusual. You may see an option to change the install destination from the default location, and you may have some optional components to install.
Very often, you’ll see a progress indicator, letting you know how long you’re going to have to wait for the installation to complete. You may not see error handling, but hopefully it’s going on behind the scenes. It will likely be signed digitally by the developer, and it will display any security warnings. It may provide support for different geographical locations and languages.
A really good installer program will also provide clean removal support. It’s true that you can almost always do a decent job of using the operating system’s native program removal, but “decent” is about the best you can hope for. It will almost certainly miss many files and settings.
Developer and Packager Considerations
The programmer has mentally typed “The End” at the end of his lines of code. He is ready to release his little baby out into the world. In fact, after the work he’s put into it, that’s all he wants right now. That would be a mistake, because there are things that he needs to consider.
First, functionality for the developer doesn’t always equate to readiness for end users. The software may work perfectly in a development environment but break in the wild. The developer needs to be able to test his software with users who aren’t developers, and in a diverse set of systems.
Now he needs to select an installer framework. You may be familiar with InstallShield while you’re installing software, which is one of the packaging frameworks. These frameworks are programs for installing programs. The developer tells the framework what files it’s going to need and where to put them. It also lets him specify what changes require accommodation, like registry edits.
The developer still needs to figure out how to handle dependencies – will he bundle those other packages with his own, or will he require a separate download? He needs to know whether his program can use a library or code piece that is already installed, or will it need its own version? (When a different version of some existing code is called for, we call that a “side-by-side installation.”
He also needs to decide in advance what the installer should do if the installation fails. A good package will include a rollback mechanism so that users aren’t left with half a package of a broken program. It’s not pleasant to have to chase down all the stuff left behind from a failed install.
And then, there’s that End User License Agreement (EULA) and other legal documentation. The developer gets to decide how he wants to license his product, and different types of licensing let you do different stuff with the software. “Nobody reads those,” it’s true, but everyone should at least give them a cursory run-through. Somebody put a lot of work into them.
But What About Phones and Tablets?
It may surprise you to know that the mechanics of the installation process aren’t that different from the process for computers. There are some differences, though. Mobile apps are almost always distributed through an official app store. Side-loading (loading to the device from a different source) is possible, but it’s discouraged for several good reasons (security primarily), and it’s more restricted.
Installing applications on mobile devices is more streamlined, and it happens in a sandbox. The applications ask for the permissions they require after installation. The sandboxing of applications on mobile devices means that the apps don’t have as much access to other applications or system files. There’s also a vetting process at each store for additional protection.
Any dependencies that mobile applications handle are part of the application itself. Updates to the runtimes come in through the store, rather than the application itself. Removing an application from a mobile device is usually a clean operation, removing all the user data at the same time as the application goes away.
Your Turn
A smooth installation is often the first impression of the software, but is it always a good indicator of what to expect? I wonder if we’d even remember a good installation if the rest of the experience left us underwhelmed. Isn’t it unfortunate that we don’t sing the praises of a great installation experience more often? What do you think? Post your thoughts down below the “Related Posts” bar.
My photography shops are https://www.oakwoodfineartphotography.com/ and https://oakwoodfineart.etsy.com, my merch shops are https://www.zazzle.com/store/south_fried_shop and https://society6.com/southernfriedyanqui.
Check out my New and Featured page – the latest photos and merch I’ve added to my shops! https://oakwoodexperience.com/new-and-featured/
Curious about safeguarding your digital life without getting lost in the technical weeds? Check out ‘Your Data, Your Devices, and You’—a straightforward guide to understanding and protecting your online presence. Perfect for those who love tech but not the jargon. Available now on Amazon:
https://www.amazon.com/Your-Data-Devices-Easy-Follow-ebook/dp/B0D5287NR3