feature article
Subscribe Now

Why Do We Install Software?

Exploring the Technical Reasons Behind an Old Procedure

“I can install toilets. I’m learning how to do basic wiring.” – Sandra Bullock

Why do we “install” software on our PCs, phones, and sometimes even embedded systems? Why don’t new programs just run right out of the box without going through the whole installation process? 

The procedure for installing (and later uninstalling) seems to go through phases over the years. With big room-sized machines attended by lab-coated technicians, you literally did install new software, in the sense of plugging in different boards, wires, and circuitry. Even though those early computers were programmable, the programs themselves were hard-wired. 

Videogame consoles didn’t always make you install games. You just plugged in the newest Nintendo cartridge and it ran. Uninstalling meant yanking the cartridge out. Same deal for early PCs with programs on cassette tape or floppy disk. 

Embedded systems mostly avoid the installation processes, but that’s by default, not by design. One good definition of “embedded system” is “any machine that ships with all the software it’s ever going to have.” No aftermarket software? No need to install it. The operating system and its applications are one and the same, now and forever, amen. 

But Windows, MacOS, Linux, and other modern operating systems make us go through an install process for each new program. What’s up with that? Same goes for smartphones, although the installation is largely hidden as part of the vendor-mediated download. 

We take it for granted, but why is installation even necessary? Why can’t we simply load and run new programs like those old video game cartridges? Skipping the installation step would improve the “out of box experience” for new applications. It would also eliminate the painful and often unsuccessful uninstall process, which invariably leaves unwanted cruft behind. Most of all, skipping the install/uninstall procedure would leave the operating system untouched and comparatively reliable. There’s no downside. 

Granted, there are some cases where an install process seems warranted, as when the program insinuates itself into the operating system’s GUI. Sometimes we want to right-click a Windows file and have the new app’s options appear in the pop-up context menu alongside the standard OS options. That’s slick, and it clearly needs integration with the Windows GUI or it wouldn’t work. 

Cloud storage options (OneDrive, iCloud, Dropbox, et al.) fall into this category, too. They need deep OS integration in order to appear seamless, and that requires an install process and a reboot. Sometimes you need to hook an interrupt, change a driver, or fiddle with file associations. Okay, I get that. 

But what about the other 95% of apps we install? Why do spreadsheets, word processors, email programs, games, web browsers, weather monitors, and other familiar miscellany need to spend the first 20 minutes of their lives going through an extensive install process? Why does anything from Adobe take so long? What deep OS integration do they need that wouldn’t be better accomplished by just… running? 

I’m convinced that eliminating software installation completely would make operating systems faster and more reliable. That goes for desktops, laptops, phones, embedded systems – all of it. Without third-party tinkering, the OS and its drivers would remain just as the developer intended. API calls can (or should) provide all the interface that third-party apps need. All application-related files stay in their own directory/folder, and “uninstalling” consists of deleting that directory tree. No muss, no fuss, no leftover detritus. Is your system slowing down over time as you install more programs? Can’t blame the installer. 

Debugging gets a lot easier, too, because you’re not left wondering how much of the code is really the OS vendor’s work and how much has been tampered with by a succession of installed/uninstalled applications and drivers over time. Better yet, digitally sign each executable file so you always know exactly whose code you’re looking at. 

Or, we could just rethink this whole reprogrammable computer thing and treat everything as a closed embedded system with all the code in OTPROM. The factory gets one shot at shipping code before it’s set forever. Better yet, replace all the software with hard-wired circuits. Then replace the circuits with real hardware, circa 1890. That’ll fix them ornery bugs.

Leave a Reply

featured blogs
Nov 24, 2020
The ICADVM20.1 and IC6.1.8 ISR15 production releases are now available for download at Cadence Downloads . For information on supported platforms and other release compatibility information, see the... [[ Click on the title to access the full blog on the Cadence Community si...
Nov 23, 2020
It'€™s been a long time since I performed Karnaugh map minimizations by hand. As a result, on my first pass, I missed a couple of obvious optimizations....
Nov 23, 2020
Readers of the Samtec blog know we are always talking about next-gen speed. Current channels rates are running at 56 Gbps PAM4. However, system designers are starting to look at 112 Gbps PAM4 data rates. Intuition would say that bleeding edge data rates like 112 Gbps PAM4 onl...
Nov 20, 2020
[From the last episode: We looked at neuromorphic machine learning, which is intended to act more like the brain does.] Our last topic to cover on learning (ML) is about training. We talked about supervised learning, which means we'€™re training a model based on a bunch of ...

featured video

AI SoC Chats: Scaling AI Systems with Die-to-Die Interfaces

Sponsored by Synopsys

Join Synopsys Interface IP expert Manmeet Walia to understand the trends around scaling AI SoCs and systems while minimizing latency and power by using die-to-die interfaces.

Click here for more information about DesignWare IP for Amazing AI

featured paper

Simplify your isolated current & voltage sensing designs

Sponsored by Texas Instruments

Learn how the latest isolated amplifiers and isolated ADCs can operate with a single supply on the low side, and why this offers substantial benefits over traditional solutions.

Click here to download the whitepaper

Featured Chalk Talk

Mindi Analog Simulator

Sponsored by Mouser Electronics and Microchip

It’s easy to go wrong in the analog portion of your design, particularly if you’re not an analog “expert.” Electrical simulation can help reduce risk and design re-spins. In this episode of Chalk Talk, Amelia Dalton chats with Rico Brooks of Microchip about the MPLAB Mindi tool, and how it can help reduce your design risk.

Click here for more information about MINDI Analog Simulator.