Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

The current tendency to ship even the smallest applications (like simple games, tools, etc.) as a Windows Installer (.msi) or even with .exe that can do virtually anything is very annoying. After the application is installed it is run as standard user, but it is useless if during installation it can do what it wants.

For example, configuring a firewall, maybe I do not want my new shiny 15 KB calculator application to have full access to the Internet (for incoming connections :) )

Custom actions inside Windows Installer installer files are even worse, since it is possible to run a custom function inside the provided DLL file!

How do you manage to handle this, just ignore problem, or maybe have some unknown for me methods of running Windows Installer packages? And from the other side, why on Earth is everybody making installers? In many many cases, a simple ZIP file will be enough, at least as a opportunity to a standard installer.

share|improve this question
    
Be Afraid! Its because they are doing something they aren't supposed to be doing. –  Aditya P Mar 30 '11 at 18:43
3  
you do know that pretty much all installers on all other platforms also require elevated privileges? Apart from that, some installer files can be extracted with 7zip and the likes, I find myself trying that often: I'm all for portable versions. –  stijn Mar 30 '11 at 20:24
    
@stijn, mind listing that "all other platforms"? –  SK-logic Mar 31 '11 at 14:23
    
@stjin: no, they don't. Ordinary Unix/Linux users can install applications with no problem, –  kevin cline Mar 31 '11 at 15:57
1  
I'm not that epxerienced, but afaik on debian a normal user cant just run 'apt-get install' nor start/stop services, idem for gentoo but there the command is 'emerge' or so. And when running the typical Mac OSX installers ther's alwasy a box asking the user to grant the installer elevated permissions, no? –  stijn Mar 31 '11 at 16:43

6 Answers 6

up vote 3 down vote accepted

The reason you need elevated privileges has to do with a per-machine install. If you were doing a correct per-user install, you would not need elevated privileges. So this is an education/learning issue with the developers of the small applications and the end users, as they all expect to need to run installs at elevated privileges. Only installations that need to be used by all users should install as per machine on Windows Vista and above.

Some more per-user information is in Per-user Installations (MSDN).

share|improve this answer

It's the result of many system paradigms and conventions being a result of Windows' origin as a single-user environment.

People make installers because that's the way it's been done for years and people expect it. Programs go into C:\Program Files because that's the way it's been done for years and people expect it. And so on.

Only now with a new focus and dozens of security workarounds has that convention begun to get obnoxious.

share|improve this answer

Elevated privileges may be required to, for example, access the registry, write to the Program Files directory, or register COM objects and services.

The requirement of those privileges depends on the system's group policies, user ownership and permissions for various directories, and the access level of the user (e.g., Administrator vs. Limited User).

Installers make it convenient to install programs for inexperienced users, or to simplify the complex tasks of setting up needed DLLs, COM objects, and registry entries.

MSI files can also be invoked automatically with a script in unattended installations, again simplifying the process of installation of software.

share|improve this answer
1  
Don't forget automatic rollbacks due to failures in the installation process and easy uninstall. –  Vadim Mar 30 '11 at 17:04
2  
@grey and @sk-logic... could also be becasue it works. –  Matthew Whited Mar 30 '11 at 19:09
2  
@SK-logic, because the registry is the proper place to register the location of apps (get it, 'regist-ry'?), and where you integrate with the shell (file associations and such), and where you register components that provide functionality to other applications. –  GrandmasterB Mar 30 '11 at 19:46
1  
@SK-logic, good or bad architecture is irrelevant. Unless you happen to be the Windows product manager for Microsoft, the registry exists whether you like it or not, and its the place to do the things I mentioned. –  GrandmasterB Mar 30 '11 at 20:51
1  
@Charles, Windows uses the registry for the things I mentioned. Its not MY doing. Its just the way they designed it. You can point at other OS's all day long, but the registry is still going to be here, and still going to be the place for the tasks I described. If you want to 'register' a COM component, its done in the registry - whether you like it or not. Its where Windows looks. I dont know what you think you are trying to persuade me into believing here - I wasnt offering subjective opinion on what the registry was used for, I was saying what it is actually used for. –  GrandmasterB Mar 30 '11 at 20:57

Windows Installer has historically been very bad at handling packages intended to be optionally per-machine or per-user. Until Vista it was largely possible, so long as you ran with the required permissions for the option you selected, but was prone to certain problems. Anything using the so-called COM tables would register per-machine, ignoring the setting of the ALLUSERS Property.

Then on Vista UAC made it impossible for the common case, as either a package could be told to elevate (for the per-machine case), or not to elevate (for the per-user case), but you had to declare which it was ahead of time. Unless you disable UAC, however, a package marked not to need elevation only rarely had the permissions necessary for a per-machine install.

Finally Windows 7 has introduced a new per-user paradigm built off of per-user locations and the new MSIINSTALLPERUSER Property. This corrects both the COM table per-machine registration to a per-user registration, and the UAC elevation problem. It will be interesting to see what the up-take of this property is, as it can be more difficult to write an application correctly to handle both installation scenarios.

share|improve this answer

When I create an installer for an application, I can't know how the user intends to use it. I don't know if they want to install it for every user to use, or only the installing user. If an application is to be used by all users, then it must be installed in a location that is accessible by all users, and you need to install program shortcuts in locations that all users can access. This requires elevated privileges.

Click-once deployment allows single-user non-elevated installation, so not all installs require priviledged access, but in general, you have to design your installers to appeal to the lowest common denominator, which will be access by all users.

share|improve this answer

Installers have to be run with elevated priviledges because the /Program Files and /Windows directories require administrator rights for changes to be made to them. This is so that when you open an email attachment called 'I love you' and it turns out to be a trojan, you'll get warned if it tries to wipe out your operating system (or open a port, or do other dangerous things).

You dont need an installer obviously, and software can run just fine outside the program files directory. But consider that while you, a person posting on programmers, may have no problem manipulating files and directories to manually install an application with multiple files, 90% of the world does have a problem doing such tasks. So installers are created.

share|improve this answer
1  
Or, perhaps they think it is boring and something they really don't want to spend their time on, and with all those smart technologies and stuff the things should be smart enough to figure things out on their own. –  Inca Mar 30 '11 at 19:09
1  
.msi files are not executables the way self-contained installers (ie, setup.exe) are. They are packages of files that are opened by a 'trusted' service, Windows Installer. There is no need to prompt for elevation because Windows Installer isnt going to email a virus to 10 million people when it loads a .msi file. –  GrandmasterB Mar 30 '11 at 20:39
3  
The trouble is that far too many Windows programmers use elevated privileges entirely gratuitously. The put icons on the shared desktop when they could just put them on the user's desktop. They write settings in HKLM when there is no reason they couldn't go in HKCU. They could put the executables in the user's directory tree, but they insist on putting them in the system directories. Even worse they hard code stuff to "C:\Program Files" even though there has been an API to find where programs should be installed since Winodws 3.1. As far as I can tell it's all just laziness. –  Charles E. Grant Mar 30 '11 at 20:40
2  
Chrome for example pretends it's on a Mac and installs into AppData\Local –  Martin Beckett Mar 30 '11 at 20:46
1  
@Martin, Chrome can be wiped out then by any application with normal user rights. Chrome also, btw, writes to the registry. Open reg-edit and search for 'Chrome'. –  GrandmasterB Mar 30 '11 at 21:04

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.