I usually install games into the C:/Games folder, but recently I've noticed that some of them also create files in APPDATA/Roaming, and in Documents.
How can I install all program files into one folder, and force program to keep all of its files in this folder in the future? I'm using Windows 10 Pro.
You cannot force all Windows programs to put all files into a specific folder. Windows has some specific folders designs that many (but not all) software developers respect, such as:
%ProgramFiles%%APPDATA% folder%ProgramData%I use the environment variable names like %name%, because the actual folder locations and names may change, depending on your install settings or language for example.
Ultimately, each software developer decides where files get saved to, and whether you are allowed to change those paths is up to them.
You can sometimes approximate this but there is no completely reliable method, moreover, the methods available are more likely to fail as program complexity goes up (especially games tend to not behave well). At the end of the day, all available methods rely on some form of interception or wrapping of the original native program, and have varying overhead and likelihood of 'leaks', not to mention incompatibilities that may cause programs to just crash.
The following options are listed in vaguely decreasing order of reliability & overhead, with the most reliable and highest overhead at the top.
This generally has quite high overhead, and is generally not suitable for anything graphically intensive (e.g. games - additionally, anticheat tends to be unhappy about VMs). You're effectively running a whole separate OS that can then be contained within a single file (virtual disk).
So you'll have CPU, RAM and disk overheads, and GPU passthrough is typically fairly unreliable for gaming purposes (consumer drivers basically do not support it). Most other applications will run fine, though the user experience does suck a little (you have little to no integration with other applications on the host OS).
On the plus side, there's basically no chance of leaks unless it's malware dedicated to breaking out via a vuln in the hypervisor.
This is moderately portable, in that you can store the VM on portable media and run it on another machine with a compatible hypervisor installed.
In Windows probably the best hypervisor these days is probably Hyper-V. VMware Workstation has traditionally had the best GPU virt, but VMware is... not in a great place since the Broadcom acquisition. Virtualbox is another option but its GPU virt has traditionally been quite poor.
The classic tool for doing this in Windows is Sandboxie. This works by intercepting Windows API calls from a designated application, including filesystem calls, and redirecting them to a different location.
Some games work in this, some don't. Ones that have an anticheat are unlikely to work (anticheat does not like any kind of injection/interception... seeing a pattern here?).
Other applications largely work, though more complex ones (including web browsers) do break from time to time. It really depends on what the application tries to do, whether Sandboxie has implemented the necessary interception, and whether it's even possible to intercept that functionality.
This is the "middle ground", almost a VM-lite. You get some of the isolation typical of VMs, but without running a whole OS. Unfortunately, it's also lacking some of the completeness of VMs.
I was going to say this option is not very portable, but it looks like that's changed with recent versions.
This is where things get really iffy. It's sometimes, partially possible to redirect parts of application writes. This is the approach PortableApps uses: it sets up an environment (modifies env variables, restores registry entries) before launching an application, and after the application closes it then tries to clean up (backup registry entries). There's a library of pre-wrapped apps, and it's possible to make your own wrapper.
The downside is this only works if the application plays nice and actually uses those environment variables. This does nothing to stop the application from writing where it wants to. It also does not play nicely with applications that install complex components (some shared libraries, etc.).
Which brings us back to the original answer of there is no universal answer. The best approach depends on why you want this, and there may be other approaches more appropriate for specific use-cases.
How to install all program files into one folder?
This seems to imply that the files were created by the installation procedure in the first place, which is not necessarily true. While some may indeed be created by the installation process, many of those files are created on first run by the already installed program, and nothing you do with the installation can change that.
There seem to be conflating two issues here which are related but not necessarily the same:
Both could be consolidated into what is typically called the portable applications, which are applications that are "system independent" to a certain degree, and strive to not change the host system, nor leave any or minimal data behind. That often means, installation method doesn't write to system folders, the application running doesn't store data in the user profile folder, Windows Registry is not used, and often doesn't require elevated administrator permissions to run.
The good news is, there are whole communities dedicated to creating and maintaining Portable software, like Portable Apps or Portable Freeware. There are some even for Linux as well. These are also often supported natively by certain niche applications, more common in Open Source software.
The bad news is most commercial applications don't support these out of the box, and don't make it easy to. There is also no single universal method to force applications into "portability" that will work reliably for any software. Many are just stubborn and wont submit to any methods at all, others may be impaired or only be partially portable.
For the installation process itself, here are a few techniques to manipulate, alter or work around executable installers, and force them to install to your desired folder, or avoid running the installer altogether, from most preferred/reliable, to least desirable.
Native Portable Setups - Some software providers provide native portable versions of their software. Common for Open Source apps, and some smaller or simpler commercial software.
Installers with Portable option - Some developers do make a portable install available from within the regular installer. You still have to trust the installer to respect it and not leave garbage or registry keys elsewhere, but are expected to work better than third party.
Third party portable versions - If the developers provide no native version, some times third party communities make them. Make sure you trust the creators of custom portable versions, can pose security or privacy risks. See Portable Apps or Portable Freeware among others.
Find setups in archive format - If no portable versions are available, try to find non installer formats like archives in Zip, 7Zip, or other compressed folders. These aren't necessarily portable per-se when run, but ease the first part of the process of getting hold of the binaries.
Extractable Installers - Some .exe installers can be extracted with advanced archive managers like 7Zip, allowing access to the binaries inside, and manually extracting to a folder of your choice. Results may vary, applications may not run if they indeed need any components installed to system.
MSI Installers - Installers in Microsoft Installer format msiexec may be extracted to a folder of choice using the command line utility msiexec. Results may vary, applications may not run if they indeed need any components installed to system.
Install into Windows Sandbox - If no other previous method allows direct access to the program files, open a Windows Sandbox instance, copy the installer into it and install the program there to any location. Afterwards find the installation directory copy out the resulting content over to your computer. Results may vary, applications may not run if they indeed need any components installed to system.
Last resort, if nothing else works, install the application, copy the files elsewhere, and then uninstall. Results may vary, applications may not run if they indeed need any components installed to system. May leave leftover garbage, stray files, and registry entries.
All these may help install an application to a custom location, but will do nothing to ensure the application afterwards won't write to default locations like system user profile, user data or other custom predetermined locations.
As for application data, when the application runs it can write data to a very wide variety of places anywhere in the system, typically from the user profile, to Local Appdata, Roaming Appdata, Shared users, ProgramData, among others, and last but not least to the Windows Registry.
Catching them all is hard, and working around them even harder. There are some sandboxing applications meant to enforce where applications can write to, and other "system snapshot" applications to catch and compare differences in system made by an application, but there is no single universal method for "sandboxing" applications to prevent them from writing elsewhere that will work for all, especially windows registry.
Complex software and games, are notorious for being stubborn to portabilization techniques.
Here's a few common techniques with varying degrees of success from most preferable to least desirable.
Native Portable - In-house developers typically now best how to, and if they provide the feature natively it is expected to be more reliable.
Third party portable versions - If the developers provide no native version, some times third party communities make them. Make sure you trust the creators of custom portable versions, can pose security or privacy risks.
Portable Folder - Some applications become portable simply by creating a specific folder with a certain name at a location of their choosing, typically next to the executable. Check the documentation, like Blender Portable folder for custom data storage.
Use native command line options or environment variables - Some applications support launching with command line options that override certain settings, or support their own environment variables. One common one is overriding the folder where user data, settings or preferences are saved. Create a .bat Batch script that launches the application and overrides these. Check the application documentation for command line options or variables and see if any suit your needs. For example Inkscape provides environment variables for the profile directory you can override. Firefox has a -profile command line argument you can use.
Override Environment Variables through scripting - As Cpt.Whale points out in his answer, most Operating Systems have environment variables of their own that point to common folders, like user profile, or installation paths. Some but not all applications read these variables. If they do, you can some times override them through command line. Create a .batBatch script that launches the application and overrides these, like say set HOMEPATH=%~dp0PortableData start "" Application.exe %1. This may have varying degrees of success, some applications may ignore them, other stop working altogether, others may require overriding several variables. Registry is typically harder to avoid.
Advantages of having "portable" applications are:
Disadvantages
My recommendation is to use Symbolic Links. For Windows, this is the mklink command.
Here's an example I personally use: Minecraft Java edition installs its user files to %APPDATA%.minecraft, which is not picked up by my automatic backup software. To fix this, I move the .minecraft folder to be called MinecraftAppData in my documents folder, then I run mklink /d "%APPDATA%\.minecraft" "%USERPROFILE%\Documents\MinecraftAppData". This creates a symbolic directory link to the documents folder into appdata, so any file that is modified by the game in the .Minecraft folder is actually redirected by the system to my Documents\MinecraftAppData folder. You will need to run mklink from an elevated command prompt, and you can see that it succeeds if your %APPDATA% contains a .minecraft folder with the shortcut style icon, except it will still say Type: Folder instead of Type: Shortcut.
This is how applications are usually installed in your Windows:
%PROGRAMFILES%/%PROGRAMFILES(X86)% for static application files required for its funtionality.%PROGRAMDATA% for app data files that should be shared across all users.%LOCALAPPDATA% (and similarly LocalLow) for user-specific files that are supposed to be machine-specific. This includes: cache, history, login data and similar types of files that shouldn't be shared for compatibility or security reasons.%APPDATA% for user data that is roamed, so can be shared across devices. Mostly settings, other types of configurations, various kinds of databases, etc..lnk entry, desktop shortcut etc.Bunch of apps, mostly media-related ones, also might use various other Users\[user] folders, such as Documents mentioned by you or Music, Videos, etc.
Installations for only one user. This one is much more messy and standards are often not followed well. Usually static files are placed in %LOCALAPPDATA%, but I've seen also usage of just root %USERPROFILE% (Users\[user]) or incorrect %APPDATA%. Then the %LOCALAPPDATA% %APPDATA and media folder standards mentioned above are supposed to be also followed here. System-wide folders like %PROGRAMFILES% and %PROGRAMDATA% are skipped.
Not too standard system disk root approach. This is usually done by various dev tools, e.g. Python. They often might also use C:\tools kind of directory. It's not recommended due to e.g. security, yet some tool devs stick to it mainly for comfort or backwards-compatibility reasons.
The two first approaches are standarized by commonly utilized installer frameworks/helpers. Examples:
These kind of frameworks usually bundle all files into files such as .exe, .msi that you can't really easily globally modify to meet your standard of a single directory. And even if you could, apps will still refer to some of the mentioned or different kinds of folders outside of installation, just in their own runtime code.
Lastly, to cover portable apps, even though they don't really have anything to do with installations, it's worth mentioning that even they might leave some files outside of your specific directory. For various reasons - sometimes optimization (user dirs assumed to be on faster SSD), sometimes because devs miss stuff when adding portability. Usually cache and other temporary stuff like that that isn't necessary for functionality. Which shouldn't matter for most users, but it's worth noting if your goal is to completely enclose everything in one directory.
Plus you won't find too many portable games these days.
