55

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.

In particular, what might strike people as the obvious answer seems to have a catch:

I had tried to manually create new subfolders under C:\Program Files. In fact I thought I had done so before, but Windows puts up a dialog Destination Folder Access Denied. This caused me to think twice rather than just blindly click Continue.

Destination Folder Access Denied

On the assumption that greater minds than mine have come up against this many times over the years I'd like to ask the community if some kind of "best practice" has come to be accepted.

10
  • 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)? Jan 14, 2013 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. Jan 14, 2013 at 6:22
  • 1
    @UltraDEVV: I want to know if others have considered this problem and decided upon a "best practice". I want to know what solutions are out there before deciding whether to install in C:\Program Files or elsewhere and I provide info on a potential barrier to C:\Program Files being an obvious solution. Sep 24, 2014 at 5:50
  • So read mine! superuser.com/a/815831/354352
    – UltraDEVV
    Sep 24, 2014 at 5:53
  • @UltraDEVV: I already read yours and I already voted for it. It's cool to see this sleeper question come back to life after a three-and-a-half year rest! Sep 24, 2014 at 6:09

12 Answers 12

37

Use C:\Tools

or C:\Users\<user>\Tools
 

I'm using many small programs without installer and I'm recommending the following:

  • Save them all into C:\Tools
  • If a program consists of single file, put it directly under C:\Tools
  • If a program consists of multiple files, put it under C:\Tools\ProgramName
  • SysInternals tools have a special category C:\Tools\_SysInternals because there is many of them

I'm simply moving C:\Tools from machine to machine when migrating, works like a charm.

Practical sample (shortened listing):

C:\Tools\autoexec-elevated.bat
C:\Tools\cleanup.bat
C:\Tools\BabelMap.exe
C:\Tools\netmon.exe
C:\Tools\notifu.exe
C:\Tools\putty.exe
C:\Tools\UDPixel.exe
C:\Tools\battery.vbs

C:\Tools\3dclip-1.5.1\
C:\Tools\alternatestreamview\
C:\Tools\blender-2.71-windows64\
C:\Tools\Notepad++\
C:\Tools\QueryExpress\
C:\Tools\winscp555\
C:\Tools\Xinorbis\

C:\Tools\_Sysinternals\accesschk\
C:\Tools\_Sysinternals\Autoruns\
C:\Tools\_Sysinternals\depends22_x64\
C:\Tools\_Sysinternals\depends22_x86\
C:\Tools\_Sysinternals\LogonSessions\

I hope this gives an idea.

EDIT: Extended info

I suppose that under install in your question How should I install such tools? you actually mean manual setup, something like copying the files.

Rule of thumb: Use manually created folders for manually maintained files. Let system folders to be used by (installation) processes you don't directly control. You will immediately get benefit of recognition which content is 'yours' (and you can freely copy it) and which application is managed by the installer.

So when installing manually (by copying), stay away from

  • C:\Program Files - programs found here cannot be simply migrated, must be reinstalled (gives a great hint for migration)
  • C:\Program Files (x86) - as the above, but on 64-bit systems, 32-bit programs go here (can give a hint to determine whether particular app is 32-bit or 64-bit)
  • C:\ProgramData - application storages found here show that these programs maintain some of their data in their own way. But you asked about putting your programs under Data? Not a good idea.
  • C:\Users\Steven\AppData - again, putting programs under Data is not a good idea. If you asked about data, then several interesting things can be written about this path. But for programs simply 'no'. :)

Possible path

  • C:\Users\Steven - can be your alternative root if this is a shared computer and you want to keep it tidy, so you decide not to create any global directories. You can consider C:\Users\Steven\Tools for your programs or even C:\Users\Steven\Desktop\Tools if you want to use comfortable Desktop folder access available via shortcut from many places in Windows. But better can be the former one and you can still place the shortcut to this folder to desktop or whenever needed.

Edit: Additional useful hint:

If you want to make some of your small programs recognized in Windows 10 Start menu (for incremental searching of their names or instant elevated start using Ctrl+Shift+Enter), add their shortcuts there and launch them once. (Then you can remove them.)

6
  • 1
    This sounds good, but is it supported by best practices documentation or something like that? If so, it would really improve the answer.
    – user394804
    Feb 18, 2017 at 15:06
  • 1
    @DoritoStyle – you might need to check current best practices documentation in your corporation. If you know about some more general best practices documentation, please let me know and I'll check it.
    – miroxlav
    Feb 18, 2017 at 16:28
  • 2
    I use "C:\Utility" but otherwise use this same approach! Aug 25, 2017 at 15:38
  • 1
    Will something else, rather than 'Tools' work just as well: If I were to use something like C:\Other or C:\Users\<user>\Other, would that be considered just as "legit" as 'Tools'?
    – Henrik
    Jun 7, 2018 at 20:42
  • 1
    @Henrik - since there is no standard, use whatever fits your feelings and is clear enough. For example, I tried C:\Progs (name evokes small programs without installer), but at the end of the day it felt unintuitive so I reverted the name back to Tools.
    – miroxlav
    Jun 7, 2018 at 22:36
19

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

Placing your applications into C:\Program Files is a rather standard way. And you'll get the access protection: regular (and non-elevated) users can't write to C:\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 C:\Program Files.

Hence, C:\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.


C:\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, C:\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 C: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.

2
  • 1
    Do you keep only exe files in utils folder or all the files/folders coming along with exe file? May 13, 2021 at 12:33
  • 1
    @ShashwatKumar In most cases, only exe and dll files unless the exe requires additional files. If a tool/utility consists of many files, I create a separate folder for it to keep things neatly organised. May 14, 2021 at 17:12
9

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

1
  • I did also consider making a generic C:\Program Files\bin for these types of tools and utilities. Thanks for the feedback. Jan 11, 2013 at 9:51
7

As far as I know there are no best practices. 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.

3
  • 4
    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. Jan 14, 2013 at 1:31
  • 3
    I recommend not to manually install anything to %ProgramFiles% too, but for another reason: applications without installers are often portable, and you do not have write permission there
    – kinokijuf
    Sep 28, 2014 at 7:23
  • I also recommend not to install manually to %ProgramFiles% as it will only work if you have admin rights on that machine. Many people might work in corporate environments.
    – TJJ
    Sep 6, 2022 at 9:14
4
+100

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.

0
2

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

3
  • 6
    I think Cygwin developers don't care about Windows standards and it's wrong to copy their bad habit (creating folders in root directory). I feel its like creating \Program Files directory in linux.
    – Kamil
    Sep 24, 2014 at 12:05
  • I don't know why that would be a bad thing. Cygwin is for a Unix environment. Why would Cygwin cater to Windows standards, when they are for people that want to use Unix tools?
    – Sun
    Sep 25, 2014 at 15:24
  • 1
    @Sun exactly! OP asked for Windows best practices.
    – user394804
    Feb 18, 2017 at 15:07
2

I think creating a shortcut to C:\Tools in the Send To menu in windows is the best option as it is always accessible from anywhere. This way you could quickly "install" your small programs by right-clicking them and choosing Tools out of the Send To menu from anywhere in Windows.

I got this Tutorial about How to add to Send To menu from HowToGeek
I paste the summary:

To get to the SendTo folder, you’ll need to open up an Explorer window, and then paste in the following to the address bar.

%APPDATA%\Microsoft\Windows\SendTo

Then Paste the shortcut of the folder you want your programs to be copied there.

Then every time you download a new portable app just extract it and send it to that place.
The only problem is creation of shortcuts which I think worth to do it manually.
Regards.

6
  • The Send To folder isn't really suitable for use as a location to install a program. It has a specific purpose, namely, to enable sending files/documents for further handling by a program (e.g. Opening a file in Notepad). Further, all files placed in the Send To folder will appear on the Windows Context menu, including supporting .DLLs. That's clearly not desirable in the majority of cases. Sep 25, 2014 at 1:48
  • 2
    No. Looks like you and all downvoters did not get what I meant. I mean Add a shortcut of for example C:\Tools\ to Send To folder and access it from any where then you will not have the hassle of coping each of your programs manually. My answer is likely to make faster the process of coping for other stuff read others. It works for me great.
    – UltraDEVV
    Sep 25, 2014 at 10:34
  • I made a possible edit to include this additional clarification in your answer. Answers are up/down voted based on the answer, not necessarily on details included in comments, so hopefully this will help. Sep 25, 2014 at 13:52
  • No, starting with Windows Vista, the %APPDATA% variable is rooted in the %USERPROFILE%\AppData\Roaming folder, so for Windows 7 the path above is correct. In Windows XP you would need to add the Roaming folder as you indicated, however. Sep 25, 2014 at 14:31
  • If you believe your question is not clear you should clarify it. Why did you submit two answers?
    – Ramhound
    Sep 25, 2014 at 14:55
1

C:\Users\Me\toolName (a.k.a %homepath%\toolName) is the correct place of putting the tools assuming you want it for the Me user since some of this tools writing (temp) files and will require user's permission in-order to write toProgram files folder. another plus is that you won't forget to back it up because it's already in the user space.

2
  • 2
    I would use %homepath%' rather than c:\users\me`. This points to the right location even if the default location was moved, and is thus more portable. +1 for the writing/temp part.
    – Hennes
    Sep 26, 2014 at 13:03
  • i stand corrected and edited in the reason it was added and not replaced is to answer with the same terms as the question, thanks Hennes :)
    – Elazaron
    Sep 28, 2014 at 7:21
0

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.

1
  • 2
    (explaining myself) Many years ago i've deleted this reply because i got downvoted. Now i see almost all newer recommendations follow the same path of thought and action. Maybe i was ahead of my time, who knows...
    – cg_dev
    Oct 25, 2020 at 5:55
0

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

3
  • 1
    I think you have fundamentally misunderstood the question. The first part of the original question is "Best practice", not "What are the rules".
    – Zombo
    Sep 21, 2014 at 0:31
  • @StevenPenny Not at all, just a different phrasing. The point of the question is reasons to do X or not do X.
    – Robin Hood
    Sep 21, 2014 at 0:37
  • I just came up with something I like: Etc or Etcetera if you prefer real fancy pansy latin. On a close second place, I also considered Misc. But Etc sealed the deal for me. :)
    – Henrik
    Jun 7, 2018 at 21:05
0

On top of existing answers, I'd suggest you do this:

First put them in [dropbox_folder]\portable-tools\

Then if you re-install windows, or buy a new computer, you could try if they still work. If something no longer works, it means they're not portable, then you move them to the place suggested in other answers.

If you have multiple computers, and you don't want the settings or state of a tool to sync between computers (e.g. foobar2000 playlist), you can create [dropbox_folder]\portable-tools\ [computer_name], then put duplicate versions of the app under different [computer_name]s.

Btw if you're a programmer, I'd recommend putting the [dorpbox_folder] inside c:\users\me, this gives you lots of benefits as you'll soon find out.

-1

The default system Path environment variable in windows is something like (Depending on the version of windows installed):

%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\

Out of those options, %SystemRoot% (which is usually C:/) seems like the best choice for you read/write and it will be easy to reference later.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .