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!
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.
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):
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?
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 FilesApp and the 64bit installer will write to C:Program FilesAppsixtyfour.
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.
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:Windowssystem32awesome.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 FilesMicrosoftOffice14.0wizards.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 Filesx86 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.
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.
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.)
The reason is to make upgrading a program to 64-bit easier for developers. They don’t have to write any custom code to check for the program in one directory when compiling in 32-bit mode and in another directory when compiling in 64-bit mode; they just check C:Program Files, and when running under 32-bit mode, this automatically gets changed to C:Program Files (x86) by 64-bit Windows. Similarly, the registry entries are isolated between 32-bit and 64-bit programs.
This prevents conflicts from unknowing developers who just change their compilation mode to 64-bit without putting much thought into it, and prevents an enormous amount of work for developers who want users to be able to install both 32- and 64-bit versions of their software simultaneously.
But why would any program want to allow both version to be installed simultaneously? One example: Photoshop and IE have extensions that are native .dll’s. You cannot have 32- and 64-bit code mixed in the same process, so an addon for the 32-bit version cannot be used with the 64-bit version, and vice-versa. Thus, Photoshop/IE have to allow both versions to be installed, or risk breaking their huge base of existing addons.
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.
“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.
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.
Programs that runs on “Program Files(x86)” use the WOW64 subsystem (Windows 32-bit on Windows 64-bit is a set of drivers and APIs intented to run x32 applications over a x64 architecture system):
The WoW64 subsystem comprises a lightweight compatibility layer that has similar interfaces on all 64-bit versions of Windows. It aims to create a 32-bit environment that provides the interfaces required to run unmodified 32-bit Windows applications on a 64-bit system. Technically, WoW64 is implemented using three dynamic-link libraries (DLLs):
- Wow64.dll, the core interface to the Windows NT kernel that translates between 32-bit and 64-bit calls, including pointer and call stack manipulations
- Wow64win.dll, which provides the appropriate entry-points for 32-bit applications
- Wow64cpu.dll, which takes care of switching the processor from 32-bit to 64-bit mode
64 bits system need to “emulate” 32 bits applications, that is the reason why Windows need to “segregate” two Program Files folders.
Having to separate folders makes it possible to keep the native 64-bit applications and thos that require the WoW64 apart.
This can be useful – as @OliverSalzburg already pointed out – if you wish to install both he 64-bit and 32-bit of a web browser (for example), since some plug-ins and add-ons might only available for one of the two.
Having to separate folders makes this separation automatic, using techniques such as registry redirection.
Suppose an installer tries to determine the program files folder by reading the registry by using, e.g., RegQueryValueEx.
In any case, it tries to read the registry key
which normally points to C:Program Files.
However, if the installer is a 32-bit application, registry redirection will cause the regitry key
to be read instead, which normally points to C:Program Files (x86).
Why these particular folder names have been used can only be answered by the people who made this choice. You could always change the default folders’ names if you want to.
Does Windows somehow present itself differently to a program running out of “Program Files (x86)”?
I doubt it. Most installers permit you to choose a custom installation folder, so it doesn’t really matter where a program gets installed.
I can’t believe the confusion here.. firstly I’m a full-time developer.
MS did this to solve the case where a DLL is used by both older 32-bit applications and newer 64-bit applications. The older method could not be changed (System32, Program Files, etc.) because that would break older programs that cannot be recompiled.
So MS created a folder to store 64-bit specific programs, assemblies and libraries so that new programs could link to the proper libraries, and older programs would continue working as normal.
As it stands, .Net DLLs can coexist with other versions on the same machine. For example, you can have Library.1.0.1, Library.1.0.2, Library 1.1.0, etc. And this is only for a specific bit size (32 or 64). If separate folders are not used, then every assembly needs to have a 32 and 64 bit version. This would severely clutter up a directory that already contains multiple versions of the same assembly.
This is all developer stuff. As a user I only have to deal with it when I’m working with a 32-bit program on Windows 7 64. And I prefer having the ability to run a 32-bit version and the same application in 64-bit as well. When I’m working on a 32-bit application that I need to compile in 64-bit, all I do is tell the compiler to do so. Dll names and everything else stays the same.
The reason this didn’t exist with Windows 95/98 is those systems simulated a 32-bit runtime; it wasn’t a genuine 32-bit operating system. It faked 32-bit execution with something named “thunking”.
Here’s a good definition: http://searchwinit.techtarget.com/definition/thunk
Just a relevant personal experience – I was running a 32-bit game (MW-1) on a 64-bit system. First time around, I did the installation in another directory, instead of Program Files (x86). The game worked, using its own drivers, but the graphics were blurred and pixelated during the in-game cut-scenes.
I tweaked all the settings I could think of – no luck. (My specs are awesome enough to run HQ definition graphics, btw.)
Then, I started thinking along this direction and re-installed the game in the Program Files (x86). And behold! the game was working perfectly with crystal clear graphics.
I hope this helps. I’m not much of a computer geek btw, so please excuse any technical gaffes I may have made. Cheerio.