Stand-alone program has no external dependencies.
It doesn't have to be .exe file only, it can have accompanying libraries and data files: Unpack the archive to a folder and run the executable. If you just unpack an archive, no shortcut is added to Start menu, hence you'll have to navigate to the folder where the unpacked application is located and start it from there, or manually create a shortcut for it in Start menu. Many computer users find it difficult.
Easier to Use
An installer guides users through the installation process. You download the installer, .exe or .msi (the former is preferable for non-advanced users), and run it. It picks up the installation folder, usually in Program Files
, copies the files, creates shortcut in Start menu. You're done: in the majority of cases you simply click Next several time.
Then go to Start menu and run the application. Some installers provide an option to start the application when installation is complete.
If the application opens files or documents of certain type, the installer registers it with the shell. So that you can click the file to open it.
License Agreement
Many applications, both commercial and free ones, require you to accept the license agreement before you can use their application. Installation doesn't proceed until you acknowledge you agree to the license terms. Even if you didn't read the license, you have agreed to it.
Dependencies
Sometimes it's not enough to simply copy the executable files. Applications often use shared components or special runtime libraries. For example, .Net framework runtime has to installed to run the application written for .Net; even Visual C++ runtime, if it's not statically linked, has to be installed. The installer takes care of ensuring all the dependencies are satisfied.
If an application consists of several .exe and/or .dll files, dynamic linking to Visual C++ runtime reduces disk space. If .exe and .dll are statically linked, then the runtime is duplicated in each and every file.
License terms of a library may not allow statical linking.
Security
If a vulnerability is found in the runtime, it can updated separately from the application. Updates to .Net and Visual C++ runtime are installed automatically via Windows Update.
If executables and libraries are statically linked, then application vendor has to recompile the application and release the updated version. So using shared runtime reduces cost of application maintenance for developers and vendors.
Installing to Program Files
also provides more secure environment: the files there can't be modified or deleted without administrator privileges.
Registry
Many Windows applications rely on entries in the registry. If application uses COM, all the objects have to be registered otherwise the application will fail to create the needed object and will not start.
Great answer, but your opening with DirectX and runtime doesn't make sense. First off, DirectX's only runtime is within the language it is written in itself, which is C. – None – 2013-12-06T22:10:31.603
@TomTurkey Um... what? Why does it matter what language it's written in? Sure, you could statically link any DirectX components that you need straight into your executable, but like I said, that presents a file size problem if many programs start doing this with large libraries (Qt 4.x, for instance, runs about 40 MB). The code has to be somewhere, and you can't just assume that the DirectX version you need is already installed on the system, or you'll get an error when someone opens your program on Windows XP SP2 that hasn't been patched in ages. – allquixotic – 2013-12-06T22:20:47.050
4Oh, I think you misunderstood me -- in my answer, I wasn't talking about installing DirectX itself; I was talking about installing a program that depends on DirectX. To satisfy that dependency, you can either compile DirectX directly into your application, thus increasing wasted disk space consumption, or you can bundle a little app in your installer that checks whether you have the appropriate DirectX runtimes installed, and if not, downloads them and puts them in a centralized system location. The latter is much more efficient in terms of disk space and download size. – allquixotic – 2013-12-06T22:24:48.163
3@allquixotic Also, licensing. Sometimes, a library may not be licensed for reditribution independent of its installer. DirectX may fall into the category, I'm not sure. The .NET framework does, I think. It's not a technical restriction, but a legal one. (The .NET framework has additional technical restrictions, though. It's pretty tightly integrated into the OS.) – Bob – 2013-12-07T06:58:04.580
1boop. The sound of an upvoted comment. In my head. – allquixotic – 2013-12-07T08:33:03.870
@allquixotic I'm pretty sure you can't statically link to DirectX runtime because it's a set of COM interfaces. And the runtime itself is deeply integrated with the OS. So using an incompatible version of DirectX linked right into the executable can lead to app/system crash. DirectX falls into .NET framework category where your only option is to redistribute the original installer of DirectX. – Alexey Ivanov – 2013-12-07T12:41:17.957
@AlexeyIvanov True, COM is a special case; in order to avoid installing DirectX using the proper installer, you would have to embed the DLLs in your EXE, then extract them to disk at runtime into a temp folder, and use registrationless COM to interface with them. Or register them into HKCU and use them that way. – allquixotic – 2013-12-07T22:25:27.267