2

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.

Improve this question
8
  • Be Afraid! Its because they are doing something they aren't supposed to be doing.
    – Aditya P
    Commented Mar 30, 2011 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
    Commented Mar 30, 2011 at 20:24
  • @stijn, mind listing that "all other platforms"?
    – SK-logic
    Commented Mar 31, 2011 at 14:23
  • @stjin: no, they don't. Ordinary Unix/Linux users can install applications with no problem,
    – kevin cline
    Commented Mar 31, 2011 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
    Commented Mar 31, 2011 at 16:43

6 Answers 6

Reset to default
9

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).

Improve this answer
8

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.

Improve this answer
3

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.

Improve this answer
2

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.

Improve this answer
18
  • 1
    Don't forget automatic rollbacks due to failures in the installation process and easy uninstall.
    – Vadim
    Commented Mar 30, 2011 at 17:04
  • 2
    @grey and @sk-logic... could also be becasue it works.
    – Matthew Whited
    Commented Mar 30, 2011 at 19:09
  • 3
    @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
    Commented Mar 30, 2011 at 19:46
  • 1
    @GrandmasterB, the tragedy of the registry is that Microsoft has provided a nuanced and sophisticated infrastructure, but far too many programers use it as a garbage can. Need a persistent setting? Bang, into HKLM it goes, far too much trouble to look in HKCU. It also creates a bizarre coupling between all your applications: the install of your Justin Bieber fan club app corrupts the registry, and the next thing you know, your SQL Server won't boot.
    – Charles E. Grant
    Commented Mar 30, 2011 at 20:30
  • 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
    Commented Mar 30, 2011 at 20:51
2

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.

Improve this answer
0

Installers have to be run with elevated privileges 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 don't 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.

Improve this answer
10
  • 2
    .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
    Commented Mar 30, 2011 at 20:39
  • 5
    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
    Commented Mar 30, 2011 at 20:40
  • 2
    Chrome for example pretends it's on a Mac and installs into AppData\Local
    – Martin Beckett
    Commented Mar 30, 2011 at 20:46
  • 2
    @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
    Commented Mar 30, 2011 at 21:04
  • 2
    @Charles, I clearly state in my answer that apps dont need to go there ("...and software can run just fine outside the program files directory"). MS recommends that practice because PF requires elevated rights to change files within it, making it more difficult for virii and trojans to infect applications. If a virus attempts to infect other executables, you will get a UAC prompt, alerting you to the change. This is in response, btw, to years of the programmer community screaming bloody murder about Windows security, and demanding it. But if you want to install somewhere else, go nuts.
    – GrandmasterB
    Commented Mar 30, 2011 at 21:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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