There are several reasons why programs come as installers rather than standalone executables:
File Size Concerns
Programs with many, large dependencies can bundle Web-based installers that download the dependencies and place them in a common location, so that they can be shared by multiple programs. For example, DirectX is a very large library. If every single program on your system that depends on DirectX just bundled the entire DirectX runtime with it, it would consume a good bit of space. This may not seem to matter in the age of 4 TB hard disks, but consider that SSDs are quite a lot smaller in capacity, and they're coming into common use on ultrabooks, some with as little as 64 GB of storage. And of course there are many other shared libraries aside from DirectX.
Programs that are both very large and continuously updated are best distributed as a collection of many small files, along with a launcher or updater program that checks the Internet for an update, and if any update exists, only download the required changes. If all large programs were shipped as a single monolithic executable, it is very likely that the patch process would require re-downloading the entire executable, as patching the running executable file on disk is near impossible due to file locks. Also, because the updater needs to know where its files are, it often stores that directory path in a well-known location in the registry.
User Convenience Concerns
Installers for very large programs, such as Visual Studio and Microsoft Office, allow the user to de-select the installation of certain features, if the user knows they will never need them. This has 3 potential benefits: it reduces disk space consumption; it can reduce download time and bandwidth consumption if the installer is a web downloader; and it can reduce "clutter" and "bloat" on the user's machine, fewer start menu / desktop shortcuts, fewer startup programs, etc.
Installers for complicated programs often come with configuration options that the user can set up using a user-friendly graphical interface as part of the installer. See for example the MySQL or SQL Server installers, which can take you through the entire process of getting your database server up and running before you even click "Finish" on the installer.
Installers can prompt the user for required information, such as license keys, which only need to be entered once. This can simplify the design of the program itself, and reduce the number of things it has to do and check for when it starts up. This also results in the user having confidence that, once the program is successfully installed, it should "just work" -- there are no more "gotchas" within the program that may hold them up from using it.
Compatibility Concerns
Some programs conflict with other programs. This is a simple and unfortunate fact of software engineering. Before installing a program that has known conflicts with other programs, it is often helpful to first check the system to see whether an incompatible program is installed. The user can then be alerted if so. For example, there is a very dangerous incompatibility potential in older versions of VMware and VirtualBox, that resulted in a Blue Screen of Death, because one program would try to use a special virtualization processor instruction after it was already reserved for user by the other product. If you were to simply provide the end product to the user without an installer, you would have to check for the presence of incompatible products at every start of your program, which could slow down the startup of the program.
Programs may have dependencies on other system components that can only be installed at a system-wide level, not at a per-user level. In order to install these special system components, administrative privileges are usually required, and an installer usually has to be run.
Elevated privileges and special services
- Some programs depend on changes to the operating system for their functionality, and these changes can't easily be implemented without some kind of installer to take care of them with administrative privileges. For instance, programs that install drivers or kernel modules, such as Wireshark, can't simply be run, because you absolutely have to ship the kernel-mode components in separate files. In the absolute best case, you would still have to have the user manually unzip an archive, and then run some kind of installer for the device driver. Services are another example of something that requires administrative privileges to install. Installer software is particularly good at obtaining admin rights in an elegant way, without requiring that the main program itself request admin rights every time it runs (this would be an unnecessary security exposure in many cases).
Having given all these reasons for why installers are useful, here are a few observations from the other side:
Many programs, even those that are only available for download as an installer that requires admin privileges, can be forcibly "unpacked" from their installers and run directly without installing them. Other programs, especially open source ones, are repackaged into self-contained executables by PortableApps. It is noteworthy that some programs, when unpacked from their installer, will have reduced functionality, exhibit errors, or other problems.
On operating systems other than Windows, it is almost always possible to simply download (or compile) programs and run them as a regular user, without obtaining root. There are a few exceptions with respect to packages that are a core part of the operating system, but for most user applications, you can run it in your home directory without installing it system-wide using the package manager. Windows is a bit of a special case in that most desktop programs on Windows have an installer, and can usually not be installed any other way.
Even on non-Windows platforms, programs that need the ability to load a kernel module come with some sort of installer, which compiles the kernel module and installs it in the right directory. You can also expect to see an installer in the event that the program is a daemon that will be started using a system service script, e.g. in /etc/init.d
. This type of "shrinkwrapped binary" is a less common distribution method on GNU/Linux, but most Linux distributions still provide most software in the form of installable packages, each of which requires root access (admin access) to install.
Conclusions
You asked why we need installers. The short answer is that we don't -- not strictly speaking, anyway. There are vanishingly few examples of applications that cannot, in principle, be bundled into a single self-contained executable with no resources, no installer, etc. Even something as complicated as VMware Workstation could automatically obtain admin privileges, write the hypervisor kernel module out to a file on disk, and install it dynamically on program startup, and ship all of its resources (images, sounds, etc.) bundled inside the data section of the executable.
Using an installer or not is a choice that software producers have to make. There are advantages and disadvantages to using an installer. Many vendors choose to distribute their software both as an installer, and as a standalone binary, or at least as a ZIP file that can simply be unpacked and run. For software that does not absolutely require an installer, this is a very pragmatic way to go, and makes everyone happy. Usually, software that does not ship in any other form than with an installer is software that requires administrative privileges to install some component of itself, since the installer is the most elegant way to obtain the needed privileges.
Personally, I find installers very annoying in my day to day work, because sometimes I want to run a program when I don't have administrative rights on the computer I'm using. I have quite a bit of experience manually unpacking installers to extract the program files within, and then getting those files to run correctly. However, on my personal PC at home where I always have administrative access, I find installers beneficial and convenient, because most installers give me useful options, like whether to create a desktop shortcut, that I would have had to do manually instead without it.
I was stuck in similar situation like you. Here is my current solution: Overwrite the profile everytime shutdown using robocopy.
- create an account with all default settings you want to use.
- make a copy of that profile folder by robocopy.
eg, robocopy c:\users\xxx c:\users\xxx_bak /mir /xj
- create a bat. "echo d | robocopy c:\users\xxx_bak c:\users\xxx /mir /xj"
- set shutdown script to run the bat
for my 10-year-old PC (Core2Duo + new SSD), it takes maybe 10-20 seconds to shutdown for profile with around 300MB.
it can't restore (until next shutdown) if power off suddenly / log out. I thought about using robocopy in start script, just not sure if windows will wait the bat to finish before login. you could try.
Best Answer
If you right-click inside the WSCC window, you can enable Show Hidden Items:
Alternatively, you can control the behavior through the Options: