The Off-Key Bard
Technology

What Actually Happens When You Install Software?

Or: why installing a program involves a lot more than copying an EXE. That progress bar is doing more than you think — and uninstalling often doesn't undo all of it.

Or: Why Installing a Program Involves a Lot More Than Copying an EXE

You download a program. Double-click the installer. Windows asks: Do you want to allow this app to make changes to your device? You click Yes. Then the familiar ritual: Next → I Agree → Next → Install. A progress bar. Thirty seconds later: Installation Complete.

It feels like the computer simply took the program and put it somewhere. Sometimes that's almost true. Other times, a single progress bar can be hiding the creation of hundreds of files, configuration database entries, shared library installations, background service registrations, scheduled tasks, firewall rules, device drivers, file type associations, and instructions for how the software should eventually be removed.

So what does it actually mean to install software?

An Installer Is a Program Running a Recipe

The most important thing to understand is that an installer isn't a compressed archive that unpacks itself. It's software — and like all software, it can make decisions.

Before placing a single file, an installer might examine your computer: Which version of Windows is running? Is this a 64-bit system? Is an older version of the application already present? Are required components installed? Is sufficient disk space available? It uses those answers to decide what to do.

That makes installation more like executing a recipe than unpacking a box. The installer chooses which files to place, where to put them, what to configure, and what to tell the operating system about itself.

Why Moving to Another Computer Sometimes Doesn't Work

Suppose you install an application called BardWriter. The installation directory might contain:

The main executable, supporting libraries, graphics assets, language files, configuration templates, plugins, and databases. The executable is the part that begins running. It may depend on every other file to do its job — which is why copying a random .exe from an installed application's directory and moving it to another computer often doesn't work. The rest of the application is missing.

Software also doesn't live in one directory. On Windows, parts of an installed application may be spread across:

Program Files for the main binaries (64-bit). Program Files (x86) for 32-bit legacy applications. AppData\Local for user-specific caches and data. AppData\Roaming for settings meant to sync between devices. ProgramData for data shared across all users on the machine.

This is why deleting a desktop shortcut doesn't uninstall the app — the shortcut is a pointer to the binary, not the binary itself. The application, settings, and services remain untouched.

Installer size and installed size can also differ dramatically. Compressed delivery and unpacked installation aren't the same thing. A 500 MB installer might require 2 GB after extraction. And some installers — called web installers or bootstrappers — are tiny themselves and download the application components they need during setup. If the download servers disappear, the installer may no longer have anything to install.

The Registry: Configuration the Computer Keeps Track Of

The Windows Registry is a hierarchical database that stores configuration information for Windows and the applications running on it. When software is installed, it typically writes Registry entries describing things like where it's installed, what version it is, how to start it, what file types it handles, and how the operating system should remove it later.

When you double-click a .docx file and Word opens, a Registry entry mapping that file extension to the Word application was set up during Word's installation. When you see an application in the Add or Remove Programs list, the information that makes that entry appear — including what the uninstaller is and where to find it — typically lives in the Registry.

The Registry isn't the only place applications store configuration. Modern software may use JSON or XML files, SQLite databases, AppData directories, or cloud synchronization. But the Registry remains a central part of how Windows and applications track installed software.

Dependencies: The Software Inside the Software

Applications are built in layers. Instead of writing image-decoding routines, network stack implementations, or audio processing from scratch, developers depend on shared libraries — code that can be used by multiple applications simultaneously.

On Windows, these are typically DLLs (Dynamic Link Libraries). Your application might depend on a graphics library, a C++ runtime provided by Microsoft, a framework like .NET, and several others. The installer may check whether required versions of those dependencies are already present, and install what's missing.

This created one of computing's more notorious historical problems: DLL Hell. If Application A installed an older version of a shared DLL over Application B's newer version, Application B could immediately break. Modern systems use side-by-side assembly manifests — allowing multiple versions of a library to coexist — and modern applications increasingly use package managers or bundled dependencies to avoid interfering with each other. But the fundamental challenge remains: shared dependencies are shared, and changing them can affect multiple applications at once.

Background Processes That Start Without You Asking

Many applications install components that run continuously in the background, without any window on screen.

Windows Services are programs that start with the operating system and run independently of any user session. Your antivirus runs as a service. OneDrive sync runs as a service. Game launchers install services. Printer software installs services.

Applications can also register startup entries that launch a process when you log in, and scheduled tasks that run on a timer. That "startup programs" list in Task Manager is a partial view of what installers have registered behind the scenes over the years. Every entry represents something a program asked Windows to run — potentially for as long as the software is installed.

UAC: The Permission Prompt Is Not a Formality

That Windows prompt asking whether you want to allow an application to make changes to your device comes from User Account Control (UAC). It appears because the installer is requesting elevated privileges — permission to modify parts of the system ordinary applications can't change freely: installing system services, writing to protected directories, modifying machine-wide Registry entries, installing device drivers.

The prompt isn't asking "would you like to continue?" It's asking something closer to: "Do you trust this software enough to let it make protected system changes?" Clicking Yes grants the installer significant authority. That's not a reason to be paranoid about every installer — most legitimate software uses that authority appropriately. But it's a reason not to let it become an unconscious reflex on a program you didn't intend to download.

Not every installation requires this level of access. Some applications install entirely within your user profile and don't require UAC elevation at all. Some software ships as a portable application — a self-contained directory that runs without any system-wide installation, makes minimal system changes, and can sometimes be moved between computers by copying the folder. Even portable apps may create temporary files or settings outside their directory when they run, but the installation footprint is much smaller.

Why Uninstalling Leaves Things Behind

Ideally, an uninstaller perfectly reverses everything the installer did: removes every file, every Registry entry, every service, every scheduled task. In practice, uninstallers routinely leave things behind — and not always for bad reasons.

User data is often deliberately preserved. If you uninstall a photo editor today and reinstall it next month, you'd probably rather keep your custom presets and settings than start over. The uninstaller leaves that data intact.

Shared dependencies present a harder problem. If an uninstaller isn't certain whether another installed application still depends on a shared library, it will likely leave the library in place rather than risk breaking something else.

Registry entries — particularly orphaned keys from applications that didn't clean up thoroughly — accumulate over years of software installations and removals. Most stale Registry entries don't measurably affect performance (the "registry cleaner" software market has historically overstated this), but they do accumulate.

Services and startup entries from long-removed software can also persist, which contributes to the slowdown discussed elsewhere in the series.

Stores and Package Managers: A Different Model

Traditional desktop installers represent one approach. Others exist.

The Microsoft Store (and similar stores on macOS, iOS, and Android) distribute applications in sandboxed packages that install and uninstall cleanly, can be updated centrally, and limit what the application can access on the system. The tradeoff is restrictions on what the application can do.

Package managers — common in Linux environments and increasingly available on Windows through winget — retrieve and install software from curated repositories, track installed packages and their dependencies, and handle updates cleanly. They apply a more systematic approach to the dependency management problem that traditional installers handle inconsistently.

Neither model has replaced traditional installers for most Windows desktop software, but both represent attempts to solve the cleanup and dependency problems the traditional approach doesn't fully address.

The Bard's Take

Installing software is fundamentally an act of trust. When you grant an installer elevated privileges, you're not just letting a program copy files — you're permitting it to modify operating system configuration, register services, adjust network rules, write to the Registry, and alter how the computer behaves going forward.

Most of the time, legitimate software uses that authority to create a working, integrated application. But remembering what's actually happening explains why:

Uninstalling an application doesn't always leave the computer exactly as it was before. Removing a shortcut doesn't remove the software. Background processes in Task Manager often trace back to installers from months or years ago. A fresh Windows installation feels faster than one that's accumulated years of software — because all of those registered services, startup entries, and accumulated components reset to zero.

The progress bar races across the screen. Installation complete. But the computer has been changed in ways the progress bar never mentioned — and many of those changes will persist long after you stop using the software.

Sources

← Back to the Desk — Technology