If you’re currently using any 64-bit version of Windows you may have noticed there are two “Program Files” folders, one for 64-bit and one for 32-bit apps. Why does Windows need to sub-divide them? Read on to see why.
Today’s Question & Answer session comes to us courtesy of SuperUser—a subdivision of Stack Exchange, a community-drive grouping of Q&A web sites.
SuperUser reader Stephen Jennings noticed the “Program Files” division and wanted to get to the bottom of things:
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
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.
It’s true there are plenty of explainer articles focused on the difference between the two–such as our treatment of the subject here–but why exactly does Windows sport dual folders?
If you’re looking for the short and sweet answer, turn to SuperUser contributor David Schwartz:
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
bin64directory inside that application. But that would impose permanent ugliness on 64-bit systems just to support legacy applications.
Another contributor, Oliver Salzburg, delves into the programming side of things and why exactly Microsoft would go about structuring the folders as they did:
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 thatknows 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
- Installers aren’t magicToday, we often use small programs to install our larger programs. We call these small programsinstallers.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
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_ProgramFilesto retrieve the correct path).
Everything finds it’s place automatically and the pattern is identical with every application you install.
- Consistency makes senseWhen 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.dlland 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
Now we’re getting philosophical…
What would go wrong if I somehow avoided the redirection mechanism and forced everything to install to the real
Most likely nothing (as long as other applications don’t depend on a fixed location for that application).
The WOW64 mechanism hooks into
CreateProcessand 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.
For more responses and interesting insights into the programming decisions and logistics of structuring the folders, hit up the full discussion thread at SuperUser here.