Why does 64-bit Windows need a separate "Program Files (x86)" folder?

I know that on a 64-bit version of Windows the "Program Files" folder is for 64-bit programs and the "Program Files (x86)" folder is for 32-bit programs, but why is this even necessary?

By "necessary", I don't mean "why could Microsoft not have made any other design decisions?" because of course they could have. Rather, I mean, "why, given the current design of 64-bit Windows, must 32-bit programs have a separate top-level folder from 64-bit programs?" Put another way, "what would go wrong if I somehow avoided the redirection mechanism and forced everything to install to the real C:\Program Files\?"

There are plenty of questions on Super User and elsewhere that assert "one is for 32-bit programs, one is for 64-bit programs", but none that I can find give the reason. From my experience, it doesn't seem to matter whether a 32-bit program is installed in the correct place or not.

Does Windows somehow present itself differently to a program running out of "Program Files (x86)"? Is there a description that shows exactly what's different for a program installed in "Program Files (x86)" instead of "Program Files"? I think it's unlikely that Microsoft would introduce a new folder without a legitimate technical reason.

Short answer: To ensure legacy 32-bit applications continue to work the same way they used to without imposing ugly rules on 64-bit applications that would create a permanent mess.

It is not necessary. It's just more convenient than other possible solutions such as requiring every application to create its own way to separate 32-bit DLLs and executables from 64-bit DLLs and executables.

The main reason is to make 32-bit applications that don't even know 64-bit systems exist "just work", even if 64-bit DLLs are installed in places the applications might look. A 32-bit application won't be able to load a 64-bit DLL, so a method was needed to ensure that a 32-bit application (that might pre-date 64-bit systems and thus have no idea 64-bit files even exist) wouldn't find a 64-bit DLL, try to load it, fail, and then generate an error message.

The simplest solution to this is consistently separate directories. Really the only alternative is to require every 64-bit application to "hide" its executable files somewhere a 32-bit application wouldn't look, such as a bin64 directory inside that application. But that would impose permanent ugliness on 64-bit systems just to support legacy applications.

It allows you to install both the 32bit and the 64bit version of an application without it overwriting itself.

After looking at this answer and comment thread the next day, I realize a possible major oversight in my answer. I falsely assumed a programming background and when I was talking about you in my comments, I didn't mean the user, but the programmer.

I don't work for Microsoft and I have no clue what the real reasoning behind these folders is, but I think the reason to have these folders is so obvious that I have no problem arguing it.

So let's break it down!

1. Folders are awesome!

   Let's agree on something. Folders are great! We don't need them, we have enough possible file names to put every single file on the root of your hard drive, so why have folders at all?

   Well, they help us order our stuff. And ordering stuff is great. It helps us to process things more easily. This is especially useful when working with a machine that requires structure.

2. Separating data and logic is great!

   A paradigm often found in programming, is to separate data from logic. You want one part that knows how to do something and you want another part you can do something with.

   This is also found in the file system.

   We have folders for application (logic) and folders for our valuables (data):

   Logic

   • %WINDIR%
   • %PROGRAMFILES%
   • %PROGRAMFILES(x86)%

   Data

   • %PROGRAMDATA%
   • %HOMEDRIVE%%HOMEPATH%

   So, it seems like folders are awesome and it makes sense to put programs in their own little folder. But why have 2? Why not let the installer handle that and put everything into one Programs folder?

3. Installers aren't magic

   Today, we often use small programs to install our larger programs. We call these small programs installers.

   Installers aren't magic. They have to be written by programmers and are applications (with possible bugs) like any other application out there. So let's look at the situation an imaginary programmer would have to face with and without the current system:

   1 Program Files folder

   The developer maintains 2 installers. One for the 32bit and one for the 64bit version of his application. The 32bit installer will write to C:\Program Files\App\ and the 64bit installer will write to C:\Program Files\App\sixtyfour\.

   2 Program Files folders

   The developer maintains 1 installer. The installer will always write to %PROGRAMFILES% and depend on the operating system to expand the path accordingly (you actually don't use environment variables for these cases, you'd use SHGetKnownFolderPath with FOLDERID_ProgramFiles to retrieve the correct path).
   Everything finds it's place automatically and the pattern is identical with every application you install.

4. Consistency makes sense

   When you learn something, that usually implies that an observed behavior was consistent. Otherwise there is really nothing to observe and learn.

   The same is true for our little file system. It makes sense to always put the same stuff into the same folders. That way, we'll know where to look when we're looking for something.

   The system for 32/64 application distinction furthers this goal. Applications are separated into 2 locations to avoid conflicts in names, binary loading behavior and security (to some extent).

I still don't get it. This seems useless

You should never forget one thing. People are incredibly stupid. This includes users, super users and especially programmers.

This is why we need stuff like file system redirection to even make our systems usable.

Programmers will just go in there and try to load C:\Windows\system32\awesome.dll and not care about if they're running on a 32 or 64 bit system. They would try to load the 64bit DLL and simply crash. Some programmers want to use some Office DLL, no problem, they know where to find it! C:\Program Files\Microsoft\Office\14.0\wizards.dll... and another crash!

All these requests by 32bit application are redirected into the 32bit counterparts to avoid application crashes.

We need some fixed folder names to build such a system. If there is no folder structure to support this redirection, then how are you going to make it work?

Okay, now I get it. But why not use C:\Program Files\x86\ then?

Now we're getting philosophical...

What would go wrong if I somehow avoided the redirection mechanism and forced everything to install to the real C:\Program Files\?

Most likely nothing (as long as other applications don't depend on a fixed location for that application).

The WOW64 mechanism hooks into CreateProcess and will perform more sophisticated (more sophisticated than checking the folder name of the executable) checks on the executable image to determine if it is 32 or 64 bit.

Yeah, but I mean, like, ALL applications!

• What would happen if I put both diesel and gas into my car?
• What would happen if I try to use both alternating and direct current on the same line?
• What would happen if I keep both my cat and my fish in the same aquarium?

Some questions don't require answers. It is not intended to be done, don't do it. There is nothing to be gained here. The amount of problems such a change could cause will always outweigh any possible benefits someone could see in this.

TL;DR:

To summarize, no, it's not necessary; they could have used a single folder, and no, Windows does not present itself differently to a program being run from one location or another.

Well, everybody seems to be throwing in their opinions on this, so I'll toss in my 2¢. Others have already conjectured on the reasons as to why Microsoft chose to create separate top-level folders for 32-bit and 64-bit versions of programs, so I'll leave that part (the best reason was David's explanation that it is as a convenience to programmers). Of course even then, it doesn't quite address the direct question why is this even necessary?, to which the answer is presumably: it's not.

Instead, I'll address the main body of the question

Does Windows somehow present itself differently to a program running out of "Program Files (x86)"?

Not really, but the location of the program can affect the behavior, but not in the way you would think.

When you run a program, Windows sets up an environment in which to run it (I mean in terms of memory, addressing, etc., not just environment variables). This environment depends on the contents of the executable (32-bit and 64-bit programs differ internally). When you run a 32-bit program on a 64-bit system, it runs in the 32-bit subsystem which emulates a 32-bit environment. It is called WoW64 (WoW64 stands for Windows on Windows 64-bit) and is similar to how 16-bit apps would be run in XP using the NTVDM.

When you run a program with or without admin privileges, it affects how it runs, but the location should not affect it (though there are some examples of location dependency like some drivers for example).

(I am using a different computer, so I cannot rely on my browser history to backtrack my steps, but the other day while answering this SU question I ended up at this SO question which caused me to Google PROCESSOR_ARCHITEW6432 which lead to this SO question and this Microsoft blog posting.)

Somewhere along the way, I read a StackOverflow post about how the envirnoment variable %processor_architecutre% gives different results depending on where you run the command-prompt from (I'll try to find the exact quote).

The answer turned out to be due whether the 32-bit or 64-bit version of the command prompt was run (i.e., from System32\ or SysWoW64\). In other words, while the location seems to affect the program's behavior, it is only because there are different versions of the program, not because Windows treats the folder in a special way.

This makes sense because the executable file's contents dictate whether it is 32-bit or 64-bit, so you could put both a 32-bit and 64-bit copy of the same program (e.g., foobar32.exe and foobar64.exe) in the same folder and when you execute them, they will be loaded correctly (the 64-bit version will be run natively and the 32-bit one will be run in the WoW64 emulation layer).

FreePascal allows you to install both DOS and Windows versions and they go in the same folder: %programfiles%\FreePascal. It manages the different architectures by keeping executable files (.exe, .sys, .dll, .ovr, etc.) in separate folders and sharing resource files like pictures, source-files, etc.) There is no technical reason that this could not also be done for 32- and 64-bit versions of a program. Like David said, it is just easier for the programmer if they are kept separate (i.e., using variables to make it look like there is only one set of files, etc.)

Another reason is that most programs used to use environmental variables such as %PROGRAMFILES% to point to where their program was installed. For 64 bit programs, it goes to the normal place. For 32 bit programs, it will redirect that to the new Program Files (x86) folder.

Although, at least with the new .Net stuff in Visual Studio, they now have the App.Local variable that eliminates the entire need for this.

Microsoft’s solution to this transition from 32-bit to 64-bit has been to add legacy support for most 32-bit applications. In other words, most 32-bit applications will function in the 64-bit operating environment. Keep in mind that other operating systems operating on a 64-bit architecture cannot load or run 32-bit applications at all.

To help make the transition easier, Microsoft has designated that all 32-bit application should, by default, be loaded into the Program Files (x86) folder rather than getting mixed in with true 64-bit applications in the regular Program Files folder.

Source

"what would go wrong if I somehow avoided the redirection mechanism and forced everything to install to the real C:\Program Files\?"

Nothing. The two program directories are only for organization, or to keep programs that have two version a 32-bit and 64-bit version separate, like Internet Explorer. But you can install a 32-bit program in "Program Files" and a 64-bit program in "Program Files x86" and nothing will happen the program will run the same.

Wiki says:

Some application installers reject spaces within the install path location. For 32-bit systems, the short name for the Program Files folder is Progra~1. For 64-bit systems, the short name for the 64-bit Program Files folder is Progra~1 (same as on 32-bit systems); while the short name for the 32-bit Program Files (x86) folder is now Progra~2.