Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

On the Windows platform, most large applications come with their own installer which sets up folders under C:\Program Files, possibly some other places, and perhaps adding some registry keys, etc.

But there's still quite a few tools around that consist of just an .exe or maybe also a README and a .dll or two.

How should I install such tools? Directly in C:\Program Files? All in one subfolder under C:\Program Files? Somewhere under C:\Users\Me? Somewhere totally different?

Or maybe different approaches for the tools with just an .exe to those that also have other files, or maybe only the ones with .dlls need to be treated differenty ...

Is there any standard accepted way to do this? A "best practice"? If the answer depends on the Windows version, I'm using Windows 7.

EDIT

I forgot to mention when asking this question that I had just tried to manually create new subfolders under C:\Program Files like I thought I had done before, but Windows put up a dialog Destination Folder Access Denied. This caused me to think twice rather than just blindly click Continue.

Destination Folder Access Denied

share|improve this question

This question has an open bounty worth +100 reputation from Steven Penny ending in 3 days.

This question has not received enough attention.

Acceptable answer should address at least 4 folders, for example - C:\Program Files - C:\ProgramData - C:\Users\Steven - C:\Users\Steven\AppData With implications of using each, such as - availability to other users - permission concerns

1  
I have such a little project, 2 exe, 1 hlp and 2 ascii textfiles, registry is not written to. I give it away as zip and let them extract to the directory they want to. –  ott-- Jan 11 '13 at 9:33
3  
What point of view are you asking this question from? Specifically, is this an application that you're writing, or are you trying to install somebody else's application(s)? –  Harry Johnston Jan 14 '13 at 1:28
2  
@HarryJohnston: It's for installing other people's applications. I downloaded several programs designed to view or edit very large files the other day and a couple didn't have installers. But the same applies for most command-line tools on Windows too, of which I have several. –  hippietrail Jan 14 '13 at 6:22
    
Your EDIT does not match with your actual question. Do you want to install in C:\Program Files or not ? Make a choice ... –  UltraDEVV 2 hours ago

7 Answers 7

As far as I know there is no best practises. It is really up to you individually to decide how you want to handle it.

I tend to follow the same standard as any application with an installer. If it is an executable or library I would place in either in \Program Files\ if it is 64Bit and Program Files (x86)\ if it's 32Bit.

Data files I tend to store in my Users folders since they are normally specific to a user.

There are also applications like Google Chrome and Click-Once Applications that deploy to Users\AppData\, however these are not normally available to multiple profiles.

I prefer the first method because if I need to log in on another profile or as administrator I can still access the applications.

With regards to the permission warning. It is exactly that, a warning. It is simply to warn you from using the folder for the wrong reasons, however it doesn't prevent you from using it.

share|improve this answer
1  
I recommend not manually installing applications in the Program Files folder, because applications without installers are often either elderly or ports from other operating systems, so they don't always cope well with the space in the path. YMMV. –  Harry Johnston Jan 14 '13 at 1:31

I agree with already given answers to some point. But for really small programs (utils) I tend to put them to bin folder (in my case E:\bin). These programs are usually single exe file or my own python scripts. I add this folder to PATH variable so I can use these program from command line (which I tend to use quite a lot).

share|improve this answer
    
I did also consider making a generic C:\Program Files\bin for these types of tools and utilities. Thanks for the feedback. –  hippietrail Jan 11 '13 at 9:51

As far as I know there's no universal approach.

Placing your applications into Program Files is a rather standard way. And you'll get the access protection: regular (and non-elevated) users can't write to Program Files. So you can't accidentally delete, overwrite such files; and they're better protected from viruses.

That is why you get the warning — elevation request – when you try to create a folder in Program Files.

Hence, Program Files is the most secure place for executable files.

However, it is not suitable for (portable) apps which store their configuration near the .exe because they won't be able to save the configuration changes.


ProgramData is for storing application data shared among users. By default all users can create files and folders here but only the user that created them can modify the files.

This folder could be easily used for shared apps/tools. At the same time, I never saw an app in this folder.


If you place apps in your user profile, \Users\<username>, other users of the system will have no access to it. You have all the permissions to your profile, so you won't get any security warning. That's the reason why Chrome installs into user's profile: it can update itself easily without prompting for elevation.

In per-user mode, Windows Installer packages, .msi files, install to Users\<username>\AppData\Microsoft\Installer\<ProductId>. So it's quite standard to keep non-shared apps in user's profile.

I have utils folder in my user's profile with apps which are useful only to me. This folder is added to my users PATH environment variable for easy access.

For shared apps, I use C:\tools or similar directory, possibly on another drive. It's added to global PATH variable.

share|improve this answer

If you take cygwin's default install choices, it places all your files at c:\cygwin. I would take the same approach. I personally have a c:\apps folder. In the past, I have used c:\utils, and c:\cli (short for command line). It really depends on how you want to organize your files. I would suggest for single off utilities to place them in a catchall folder. For a suite of utilities (e.g. cygwin, sysinternals, rktools), might I suggest a subfolder of its own. For example, you might put all the sysinternals inside c:\apps\sysinternals. If you install cygwin, that will take most (if not all) of the Unix commands you have come to love.

Remember to change your environmental variables (Start > Control Panel > System > Advanced > Environmental Variables) and appendd any new app paths to your PATH system variable. This allows you to run them on demand from the command prompt or by using Windows+R (run command).

share|improve this answer

There's more than one approach, it depends on how your app reacts:

Considering that you'll install a small portable app, you should consider that the app's configuration xml/ini file may use the current \Program Files\MyApp\ folder, then, any standard user may not have the elevated rights to write to this folder. If you take this approach, you may save each user's config xml/ini to his \appdata\roaming\MyApp\ folder. To my knowledge, any user-specific portable app should be deployed to a user\appdata\roaming\MyApp\ folder, where the current user has elevated rights.

However, if your app uses the registry for its configuration settings, you could use \Program files\MyApp\ or \Program files (x86)\MyApp. Or better, if you deploy many small tools of your own, you could use a collective folder like \Program Files\HippieTrail Studios\My App1\ etc.

Personally i take the \Program files\MyApp\ approach with extra care to save any .xml/.ini/.sqlite/.txt to the app's \roaming\ folder.

share|improve this answer
1  
After some clarifications and comments, i'd say you should go with the classic C:\Toolbox\ approach (probably with elevated permissions). My answer above stands mainly for complete portable apps rather than command-line tools and standalone utilities. Also, if you want to bypass the nagging security window you may change permissions of specific folders to give more rights to standard users. However, this is not recommended neither by security guidelines nor for every tool in the bag, cause the system will eventually become "swiss cheese". –  liquidplace Jan 14 '13 at 8:42

There are no rules about this, you can install them where-ever you want to, but installing them to your OSP (Operating System Partition) in a non-user folder is generally a good idea, because you'll get the same access protections are you have on other applications; this makes it harder to accidentally delete, or have them modified by a third party (eg: virus).

Personally, I usually put the program in "C:\Program Files (x86)", because most such programs I've encountered are 32bit, but if it was a 64bit program then I'd place it in C:\Program Files". If it's a system related program (eg: Imagex.exe) then I will place it in "C:\Windows\system32" for 32bit programs, and "C:\Windows\system32" for 64bit programs to allow easier access from the command line when running elevated command prompts, because you start in C:\Windows\system32" by default; this means you can type "name.exe" instead of C:\location\name.exe" to run the program.

Some people prefer to seperate their portable (does not require installation or perform unsupervised alternations outside its folder), and non-installer-based (not portable, but doesn't require use of an installer) programs from regular programs by creating a new directory on their OSP (eg: C:\Portable Program Files (x86), or C:\Dumpable Program Files (x86). I would advise the 2nd of the 2 given it's greater level of accuracy, even if it doesn't sound as pretty.

To summarize, there are no rules, however if you install them to the OSP (in a non-user folder) you will be able to help protect the program from undesired un-installation/modifications (including malicious modifications), and under some circumstances organization can be beneficial (eg: the previously mentioned system32 folder for system CLI programs).

share|improve this answer
1  
I think you have fundamentally misunderstood the question. The first part of the original question is "Best practice", not "What are the rules". –  Steven Penny 2 days ago
    
@StevenPenny Not at all, just a different phrasing. The point of the question is reasons to do X or not do X. –  Robin Hood 2 days ago

If you're looking to standardize these applications then I'd suggest using the Chocolatey package standards. This is good for a lot of different reasons; mainly because a lot of the software has already been packaged for you and is ready to install from anywhere with just a few commands.

It is also easy to make your own packages for applications which you can't freely distribute. You probably do have the right to distribute anything you own on your own network; so for those applications you can setup a local repository. If you are managing many computers or have limited internet bandwidth this can be helpful even for the free stuff.

share|improve this answer

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.