This Is How Software Installers Work on Windows, macOS, and Linux - The first knowledge sharing application in Vietnam

Modern operating systems provide you with easy methods to set up new applications. These include automated installer packages as well as commands that install many bits of software at once. But what actually happens when you run that installer or issue that command?

Let’s take a look at how software gets installed on three major desktop platforms: Windows, macOS, and Linux.

MAKEUSEOF VIDEO OF THE DAY

SCROLL TO CONTINUE WITH CONTENT

Mục lục bài viết

Methods of Software Installation

There are a few different ways you can get new applications running on your computer. In order of increasing complexity, these include:

Software Compilation — Building the application from its source code. For the most technical users only.
Software Archives — Unpacking archives such as ZIP files and running the program from wherever you extracted it. This may require some extra tweaking.
Installer Packages — Finding an installer file and (double-)clicking to start the installation.
Software Managers/Stores — Selecting the app from a nice interface and clicking a big “Install” button. It’s magic!

In this article we’ll examine the Installer Packages, as most Software Managers/Stores ultimately deal with these types of packages behind the scenes anyway. For today’s main desktop platforms — Windows, macOS, and Linux — we’ll look at what makes up one of these packages, and what occurs when you install them.

Microsoft Windows

The Installer packages you’re likely to come across for Windows come in one of two main flavors. Executable files (EXE) can set up your program by doing the heavy lifting of placing files in the right location and performing Windows Registry updates. Windows Installer packages (MSI) add to this by providing standardized services such as uninstalls.

You can inspect the contents of EXEs or MSIs by opening the archive with 7-Zip. If you use it to look at 7-Zip’s own EXE installer, you’ll find a number of different files within:

While these files have no containing folder within the installer, the developer will have pointed each one at a target directory. Most of them end up in the “default install location” — the same suggestion you typically see for a folder like “C:\Program Files\[program name]” or “C:\Program Files (x86)\[your new app].”

When using a sophisticated tool like InstallShield to create installer packages, app developers can customize the installation. For example, they can designate which versions of Windows it it will install on, set up shortcuts to be created in the Start Menu and/or on the Desktop, or collect user info such as name, address, etc. The sample InstallShield project in the image below shows the screen for setting whether Windows Registry keys should be created or updated.

With InstallShield, the app files and other customizations get wrapped up in a setup.exe file. Opening it with 7-Zip will show that inside is an MSI package that, when run, looks just like the installation we’re all used to. Let’s review what happens during this process.

Windows Installation Process

An installer will take the following steps to set your app up for use (the precise order of which may vary depending on the developer’s customizations):

An installer can contain other archives, like the aforementioned MSI or formats like CAB. As a first step the installer will extract these to a temporary location.
Next, it will check to see that any dependencies that have been set are available. If anything’s missing it will download it if possible, or exit the installer with an error if not.
If any dependencies are required, they will be installed first using whatever installer they come with (ever had an install interrupted for .NET Framework?).
Next, the installer will begin copying the app’s files and placing them in their correct location.
If the developer configured any shortcuts, the installer will create and point them to the actual installation path (remember, you can change this when the installer is run).
Changes to the Windows Registry, if any, will be executed.
Lastly, the installer may prompt the user to enter information such as name or web site address.

This process may seem complex compared to the next operating system on the list. Let’s take a look at installing software on macOS.

Apple macOS

Windows installers have a lot going on under the hood. But if you’ve used a Mac you know that installing an application is often as easy as downloading a copy of the app, opening the disk image (DMG), and following some easy prompts. Sometimes the download even provides you with a “Drag here!” icon.

Let’s dive into the APP bundle as well as its counterpart the PKG installer.

macOS Package Structure

The APP file on the surface is in fact simpler than Windows for two main reasons. Firstly, it’s a standard folder. The only difference is that it ends with a “.APP” suffix. If you download one of these on Windows, you’ll see it displays just as any other file folder would in Explorer. Secondly, APP files demand that absolutely everything the program requires is included. There’s no worry about missing dependencies with these types of installers.

These bundles must contain three things in a folder called “Contents”: 1) an “Info.plist” file that contains application metadata such as name, language, version number, etc.; 2) a “MacOS” directory that holds the main executable; and 3) a “Resources” directory that holds assets the application needs to function (e.g. an application icon). There are other optional folders such as “Frameworks” (bundles of functionality that aren’t specific to the app), “Plug-Ins” (functionality for the app that is not required to run it) and “SharedSupport” (extraneous data like templates).

In contrast, the PKG format is a combination of a Windows-like installer with a Unix-like structure. The 7-Zip application will also open a PKG file, which is compressed in xar format. Within is one or more Payload files, which is also an archive. To extract its contents use the following chain of commands (cpio is an archive format as well as a program for manipulating them) in a Mac or Linux Terminal:

 cat Payload | gunzip -dc | cpio -i

Once done, you’ll see a familiar Unix-like directory tree.

In the example below, I’ve used document converter, Pandoc. It includes a binary in /usr/local/bin and some documentation in /usr/local/share/man. How do these things actually get in place? We’ll take a look at how each of these actually installs to your Mac.

I’ve used the Windows version of 7-Zip to illustrate this, rather than the command-line only Linux version.

macOS APP Installation Process

When you drop that APP file onto your Applications folder, it doesn’t really change all that much. Remember, everything needed to run the program is self-contained. The only difference from a standard drag-and-drop is that the “Info.plist” file gets registered with the system.

This will configure things such as which executable is called when you start the app, which icon is displayed, file types it supports, and more. But otherwise your app (such as the APP package for the Atom Editor shown below) is now ready to use.

macOS PKG Installation Process

Opening a PKG file, on the other hand, launches a “wizard-style” installer. For simple programs this is typically a component installer, which typically goes through the following steps:

Run the preinstall script.
Unpack the “Payload” contents to the machine.
Run the postinstall script.

Developers can then combine multiple components into a single product archive install. This adds options such as displaying a EULA for the user to accept, collecting info from the user, and selecting the components to install. Meanwhile, the Apple Installer takes care of all the details of installing the necessary components one-by-one in the background.

Speaking of Unix-based installers, we’ll move on to the two leading Linux package formats in the next section.

Ubuntu and Fedora Linux

Ah, DEB versus RPM. One of the great flame wars, bested only by the likes of vi versus emacs or KDE versus GNOME. Yet these formats are more similar than they are different. Let’s take a look.

Linux Package File Structure

To take a look at the inside of a DEB file, you can try a GUI archive manager. Otherwise, use the ar command. The following command entered in the terminal will extract the contents of a Debian package:

 ar -x name-of-your-package.deb

Three files will come out of this:

control.tar.gz — This in turn contains one primary file, Control, which contains metadata about the package, such as it’s official name, version, and dependencies. It may also contain other files such as scripts to be run during the install process or default config files.
data.tar.gz — The files that make up the application itself are in this TAR.GZ archive. Everything, including binaries, documentation, and default configs are in here. In the example package kde-service-menu-encfs_0.5.2_all.deb, it contains files and directories as shown in the below image.
debian-binary — This is a file that defines what version of the Debian package format the file is using. For modern distributions this will just contain “2.0” on a single line.

In Fedora, you can use the rpm2cpio and cpio commands to extract an RPM package and browse their files:

 rpm2cpio name-of-your-package.rpm | cpio -idvm

For the package kde-cli-tools-5.9.4-2.fc26.x86_64.rpm, you’ll see a file tree similar to the DEB package. But it does not provide the metadata, at least not in the binary package. You’ll need to download the source RPM (.SRC.RPM) corresponding to your binary version, then use the same command above on that file. Included in that will be a SPEC file that contains many of the same items as the Control file in a Debian package.

Now that we have an understanding of the structure of Linux packages, let’s explore what happens when you actually install them.

Linux Package Installation

When you install packages of either format, regardless of the front-end, a similar set of steps happens:

The package system examines the package’s contents to determine whether there are missing dependencies. Depending on the tool, it will either warn you, or set to downloading them.
If the packages contain pre-install scripts or commands they run next.
Then the package system actually extracts the package’s files.
With the files in place, post-install scripts run.
Finally, the package is registered with the internal database using its metadata, so it can be uninstalled later.

Knowing How Software Is Installed Is a Good Thing

Because developers of operating systems and the software that runs on them do a great job of making software installation easy, you don’t really need to pay attention to the details. But having some knowledge about that’s happening behind the scenes will give you some peace of mind about what is being installed on your system, as well as helping with troubleshooting.

How many of the above software install methods have you done? Do you prefer DEB or RPM? Or do Mac’s APP bundles represent the pinnacle of ease-of-use? Ever had a nightmare install happen? Let us know in the comments below!