Software Installers

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

Installer Type

Description

Windows

.exe (executable)

Custom-built installer using frameworks like NSIS, Inno Setup, or InstallShield. May include wizard-style UI.

Windows

.msi (Microsoft Installer)

Standard Windows Installer package. Often used for enterprise deployments; integrates with Group Policy.

Windows

Microsoft Store App

Apps distributed via the Microsoft Store. Installed in a sandboxed, user-space environment.

Windows

Portable Apps

No installer required—just unzip and run. Doesn’t modify system files or registry. Useful for USB use.

macOS

.dmg (disk image)

Most common; user mounts the image and drags the app to the Applications folder.

macOS

.pkg (installer package)

Used for system-wide installs or apps requiring elevated permissions. May install background services.

macOS

Mac App Store App

Installed and updated via the App Store, sandboxed and vetted by Apple.

Linux

.deb (Debian-based)

Used by Debian, Ubuntu, and related distributions. Managed with apt.

Linux

.rpm (Red Hat-based)

Used by Fedora, CentOS, and RHEL. Managed with yum or dnf.

Linux

AppImage/Flatpack/Snap

Universal, self-contained installers with better cross-distro compatibility.

Linux

Source Code/Scripts

Compile-and-install via terminal using make or custom shell scripts. Often used by developers.

Android (Phones & Tablets)

.apk (Android Package)

The actual install file; used internally by the Play Store or sideloaded directly.

Android (Phones & Tablets)

Google Play Store App

User-friendly interface for discovering, installing, and updating apps.

Android (Phones & Tablets)

.aab (Android App Bundle)

Used by developers; Play Store builds .apks from this format for devices.

iOS

App Store App

All apps must be installed through the App Store unless using developer tools.

iOS

TestFlight Build

Used by developers for beta testing before public release.

iOS

Enterprise/MDM Installers

Used in corporate environments to deploy in-house apps outside the App Store.

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

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *