Why aren't all applications 'portable'?

"Installers are a result of years of evolution and a little bit of (simplified) history helps understand why they do what they do..

The windows 3.1 model suggested config.ini style configuration files per application with supporting shared libaries going into system folders to prevent duplication and wasted disk space.

Windows 95 introduced the registry allowing a central store for application configuration replacing many configuration files. More importantly, windows configuration was stored in the same place.

The registry became bloated due to applications not cleaning up after themselves. DLL hell happened as a result of multiple versions of the same shared libraries overwriting each other.

.NET introduced the concept of app.config (almost ini files mark 2, this time with a little more structure saving developers wasting time writing manual parsers). The GAC was introduced to version shared assemblies in an attempt to prevent DLL Hell.

In Windows XP and moreso in Vista, Microsoft attempted to define the userspace as a place to store user data and configuration files in a single standard location to allow for roamning profiles and easy migration (just copy your profile) with the applications installed in Program Files.

So I guess, the reason is that ""applications in windows are designed to live in one place, their shared dependencies in another, and the user specific data in another"", which pretty much works against the concept of xcopying a single location.

.. and that's before you have to configure user accounts, and setup and ensure security permissions, and download updates, and install windows services...

xcopy is the ""simple case"" and certainly isn't a best fit for everything."

"Great question, I asked a related question on Stack Overflow a while ago.

The answer often seems to be ""because that's how we've done it in the past"". Sorry but that doesn't wash with me.

A few others have said the main reason is due to the registry. If you are talking about a device driver or some other COM component etc, then yes this may be necessary, but not for GUI applications such as Word processors or spreadsheets.

It's quite possible to write an application that either checks on start-up for required registry settings, and prompts the user for them / uses defaults. Or, as many protable apps currently do, jst let the user know that OS integration is currently limited because you are running in portable mode.

Installers often also have a lot of ""knowledge"" about how the application works. Then when the application changes, you often have to update the installer too. This is a classic cause of bugs/problems I've seen in my time programming.

It's the one size fit's all approach."

"Mostly because of the windows registry - even though your programs are in a certain directory, settings are often stored in the registry.

It can also be because the program puts files in other directories on your computer other than the install directory (system32 for example)"

"One big advantage to installers over the Xcopy/portable installation type is self-repair.

An app that uses the Windows Installer system properly will have all sorts of info about it saved in the Windows Installer database on your machine, as well as quite often a cache of important parts of the setup files.

If the app breaks for some reason (something else deletes/replaces a file, registry gets corrupted, disk problems, user deletes shortcut etc) then if its an ""advertised shortcut"" the Installer actually checks key files and keys every time it starts up and replaces if they're not present, or you can go into Add/Remove Programs and click Repair on the app."

"I think it's partly to do with the large amounts of cruft windows apps need. For example, Registry keys, User data (/Users//AppData). Perhaps OSX just handles this better/differently.

Then again it's not impossible to create apps that you can just extract from an archive - I'm always happy when this is the case."