Why does Windows 7 install 64 bit apps in the Program Files (x86) folder? Can I change the behaviour?

Question

I've been using the 64-bit version of Windows 7 since the CTP and have run into a few problems with applications that get installed in the C:\Program Files (x86) folder. What's the purpose of having 2 separate Program Files directories anyway?

Every program I've installed has gone into the C:\Program Files (x86) folder. It doesn't seem to matter if the app is 32 or 64 bit. Why don't 64-bit apps get placed in C:\Program Files?

Is there a way to change the default to be C:\Program Files instead? Would it mess anything up if I just put everything into C:\Program Files?

If indeed there is some benefit to having a separate folder for 64 bit apps, it seems like the more sensible default would have been to use C:\Program Files for x86 apps and create a new C:\Program Files (x64) folder for the new 64-bit apps. This would help maintain backwards compatibility. I work as a software developer and some of my projects contain path references to libraries under C:\Program Files. Now those references are broken on the Windows 7 machine that has placed them in C:\Program Files (x86). I even tried to change the target location in the installer to be C:\Program Files, but that was ignored and the app went into C:\Program Files (x86) anyway.

This is very frustrating because I need to share source code between 32 and 64 bit machines and I don't want to have to mess with some configuration file that sets the path to these libraries differently on different machines.

Edit regarding environment variables: (Using only default English values of variables for simplicity.) On a 64-bit machine %ProgramFiles% will be C:\Program Files while the brand new variable %ProgramFiles(x86)% will be C:\Program Files (x86). So, if you have a 32-bit program that needs to find the folder path that it would be installed under, it would need to check to see if it was running on a 32-bit or a 64-bit version of Windows in order to know which environment variable to use. Any 32-bit apps that were written without this consideration would need to be updated in order to work correctly on a 64-bit machine. So even using environment variables, the backwards compatibility is broken.

Also, %ProgramFiles(x86)% doesn't exist on 32-bit versions of Windows. If it did, then 32-bit apps could just always use that environment variable and wouldn't need any conditional logic based on which OS they're running on.

Answer 1

The reason for this is simply many older installers either do not understand the new file structure and plonk everything in the standard program files directory or you are looking at a smart program that has a few 32-bit components which are being copied there.

Your best bet is to download a new program - such as x64 Winrar and just see where it installs to just to rule out a problem with your machine.

As for messing stuff up - it can, but it really depends on the program, there is no one answer fits all... some smaller, compact programs with just a few files should have no problem, where as, if you talk about Office, Adobe or any other "suite" or large program, it will most likely fail as they have many shared components that are cross architecture.

Answer 2

If you use anything other than %ProgramFiles% (or CSIDL_PROGRAM_FILES, or under .NET Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles)) you're in trouble anyway, since custom installations can have programs installed under other volumes (D: for instance) and international installations often have other folders by default.

• Spanish Windows: C:\Archivos de Programa,
• French Windows: C:\Programmes,
• German Windows : C:\Programme,
• Swedish Windows: C:\Program

etc.

Answer 3

Please note that under 64-bit versions of Windows 7 (this may also apply to other newer OS versions as well, but I can only confirm this for Win 7 64-bit) there is a difference between the aparent location of your %ProgramFiles% in explorer and in DOS.

Under windows 7 the actual physical folder location of %ProgramFiles% (and the associated %ProgramFiles(x86)% environemnt variable) is fixed as per the English version; i.e. "C:\Program Files" and "C:\Program Files (x86)" respectivley, but is shown in exploer localised as appropriate.

To provide a specific example; on a Swedish Windows 7 64-bit install, if you open Explorer and look in the system drive (typically C:) you see "Program" and "Program (x86)" folders. Typing %ProgramFiles% into the address bar moves you into "C:\Program".

However if you open a DOS box and type SET you will see that the actual value of %ProgramFiles% is "C:\Program Files" not the "C:\Program" folder exploer shows you. Further exploring with CD and DIR you can see it physically is "C:\Program Files"

The moral is if you use the environment varaibles or program via the API's everything will still work, but be aware of this subtle change when exploring the file system!