Where to install small programs without installers on Windows?

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.

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.

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

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.