Briefly
Program Files
is where 64bit software is installed.
Program Files (x86)
is where 32bit software is installed.
Program Data
is where both sets of programs should write data (such as configuration data, for example) that they want to store for all users (so can't go in a single users AppData
or MyDocs
) and that does not belong in registry.
The difference between the two ProgFiles
folders allows you to have two different versions of software installed (for example Internet Explorer comes in both 32 and 64 bit flavors installed together) because Windows silently redirects requests from software in the (x86)
folders.
As for question 2, you can probably ignore Program Data
most of the time (nothing should be installed in there), but I often find myself jumping between the two ProgFiles
folders so I'll be looking for other answers here to help with that.
Is there any reason why 64-bit software and 32-bit software had to be split in this way? I mean, it's just files on the disk, isn't it? – Neil Barnwell – 2010-08-20T09:32:00.940
No idea! I've heard it's for compatability reasons. But all my 32bit and 64bit games (not many in the latter category) are installed in
C:\Games
and I have not problems with either. Plus I've loads of utilities I run straight off myD:
. – DMA57361 – 2010-08-20T09:34:41.470This question on ServerFault might be useful. I'll add some of the key points to my answer. – DMA57361 – 2010-08-20T09:41:05.423
3It's important for some programs! Some compilers, Integrated Development Environments and similar programs have need for both 32bit version and 64 bit version. It's not uncommon to find 64 bit in Program Files and 32 in Program Files (x86). Still, there is no need for directories o be called like that. They may as well be called a and b. It's just that x86 hints at its contents. – AndrejaKo – 2010-08-20T09:42:17.500
Note however that some programs can have "C:\Program Files" has their default path, directly written, without caring about the appropriate folder. That's how you end with 32-bit programs in the folder in theory dedicated to 64-bit. – Gnoupi – 2010-08-20T09:47:44.183
2Indeed, those that don't use the
%ProgramFiles%
environment variable cannot be automagically redirected by Windows. – DMA57361 – 2010-08-20T09:56:59.7831
This blog post gives quite good explanation of the various 16/32/64-bit folders: http://piers7.blogspot.com/2010/07/64-bit-explained.html
– petergil – 2010-08-20T11:50:26.797@DMA57361, @Gnoupi: It is theoretically possible, though, as Windows 64-bit already redirects 32-bit applications writing to
C:\Windows\System32
intoC:\Windows\SysWOW64
. – Hello71 – 2010-08-20T16:59:52.227@Hello, @Mario's answer has the link to here which indicates redirects are done assuming programs call a specific API function to get the relevant folder. If a program has it's path hard-coded in then it won't get redirected.
– DMA57361 – 2010-08-20T17:27:32.680@DMA57361: I opened a 32-bit Command Prompt,
cd
ed toC:\Windows\System32
, then wrote a file. Then, I used 64-bit Windows Explorer to navigate toC:\Windows\System32
. The file wasn't there. I then navigated toC:\Windows\SysWOW64
. The file was in there. Windows 7 Ultimate 64-bit. – Hello71 – 2010-08-27T15:41:55.900@Hello Same here. Very interesting, but we can't rely on the behaviour of elements provided as part of the OS to work the same as a "normal" program, there might be additional magic in them to ensure compatibility. What we really need to is to build a simple program that simply checks for a file in
system32
(that doesn't appear insyswow64
, possible created), compile to both 32 and 64 bits versions, and then see what happens. – DMA57361 – 2010-08-27T16:38:41.790@Hello, well it seems you are correct. I made a
txt
file insystem32
and built a quick C++ app to read out it to console (usingC:/windows/system32
hardcoded). Compiled as 32bit it did not find the file, compiled 64bit and it does. – DMA57361 – 2010-08-27T17:14:24.037