2

The purpose of this is to have the default "program files" (32 and 64 bit) folders located under an arbitrary path, possibly on a drive separate from where windows lives.

Initially I thought that this may be done using a system environment variable through the dialog located under Control Panel -> System -> Advanced -> Environment Variables. These variables turned out to be set in the registry under the key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion. However, one particular entry is confusing. The ProgramFilesPath entry seems to point at an environment variable that is not defined under the same registry key.

I could assume that the difference between ProgramFilesDir and ProgramFilesPath is none and that one of them exists as a backwards compatibility, but having some legitimate resource from Microsoft to look at would be better than guessing.

After receiving some worrying feedback about having both 32 and 64bit applications in the same folder, I have decided not to ask about the feasibility of this to avoid discussion.

The real question is if the desired effect is possible to attain by "cutting into" the windows setup process and modifying those registry entries as early as possible. These settings should be system wide and not only for software installed by a particular user. If this is indeed something that can be done, I wonder if there are any subtle pitfalls.

Programs that expect libraries and other resources to be in default locations can probably be dealt with using the same technique as employed by Windows to re-map the "Documents and Settings" folders and the like (i.e. breaking legacy applications is not real concern).

Improve this question
9
  • 1
    That is not a good idea to put 32-bit and 64-bit program at the same folder. Look the thread Why does 64-bit Windows need a separate “Program Files (x86)” folder?.
    – avirk
    Commented Nov 25, 2012 at 17:37
  • Let's say I won't try (I'm willing to guess/hope that none of my applications look at hard coded paths for their libs). It would still be worthwhile for me to put applications in folders named "ProgramFiles" and "ProgramFiles64" instead of "Program Files" and "Program Files (x86)".
    – Ярослав Рахматуллин
    Commented Nov 25, 2012 at 18:14
  • Then you can install them manually using Custom option and browse the desired path. I'm still no in the favor of installing all apps forcefully in same folder.
    – avirk
    Commented Nov 25, 2012 at 18:16
  • And If one were to install applications without the GUI? Not all installers (if any) are "smart" enough to accept the destination path as an argument. Besides, this is my workstation. I don't have to worry about ruining someone's work day or anything more dramatic.
    – Ярослав Рахматуллин
    Commented Nov 25, 2012 at 18:22
  • 1
    Clarification - Control Panel -> System -> Advanced -> Environment Variables changes are stored under HKCU\Environment and HKLM\System\CurrentControlSet\Control\Sesssion Manager\Environment, respectively, not HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion. The registry values ProgramFilesDir and ProgramFilesPath that are in that key, as far as I have seen in my research thus far, are statically set values. This KB article may also be an interesting read for the participants of this Q&A.
    – user66001
    Commented Oct 20, 2013 at 19:58

1 Answer 1

Reset to default
0

Yes, changing the variable should cause new programs to default to the new folder, but it also causes Windows (and any—properly coded—program that uses the variable) to look in the new folder for programs in general. As a result, it will break the software that is already installed to at least some degree.

Depending on the software, paths to them may or may not be hard-coded during installation. If they are not hard-coded and use the variable, then the program(s) will not be found anymore. If they are hard-coded, then they will (or at least should) continue to run, but other side-effects may/will manifest such as Windows and other programs that perfom operations on installed programs (like cleaning up temp-files, scanning for updates, etc.) may or may not be able to see them depending on how they are coded.

The point is that it is best to change the variable before or during (or at most, immediately after) installing Windows. Doing so later on, especially after having already installed programs (particularly large programs that dig deep into the system like most Microsoft programs) is a bad idea and fraught with risk.

(Actually, while the very point to using variables is to make it easier to make changes, the fact is that it is always risky to make changes to paths like Program Files and Windows no matter when you change it, because some programs—Windows included—will inevitably have a piece of code that expects things to be in a specific place, and will thus get broken if you change it.)

Improve this answer
2
  • Where is the variable set? How does one go about embedding a binary or even a batch script into the installation process of windows? I was thinking it would be possible to avoid problems with programs that expect stuff to be in default location using similar techniques as windows does with "Documents and Settings" and the like.
    – Ярослав Рахматуллин
    Commented Nov 25, 2012 at 21:19
  • The variable is stored in the registry HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion. If you want to modify it as early as possible, you would need to mount the registry hive from the installation files, modify it, then install Windows. That way, when Windows is installed, it will use the modified path right from the beginning.
    – Synetech
    Commented Nov 25, 2012 at 21:24

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