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.

I learned the reason for this recently when I answered a question about determining the architecture from the command-prompt. I'll see if I can find the relevant links...
–
SynetechJun 27 '12 at 17:42

13

Rather than answer your question, I would ask - how would you handle \program files\common files ?
–
sgmooreJun 27 '12 at 19:10

7

One-liner answer (and hence a comment): since you can easily run any application from any folder without knowing its architecture, then there's clearly no compulsory reason for this separation. It is a matter of convenience to support double installs of applications with both architectures. In some cases it makes a difference as they are not necessarily simple recompiles. The main problem is that 32 bit apps can't load 64 bit dlls, so you can't typically install both versions in the same place. The other alternative is having two "bin" folders for each application.
–
Sklivvz♦Jun 27 '12 at 23:18

10 Answers
10

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.

They didn't have to jump through these hoops to allow for 32-bit and 16-bit programs on the same system. I don't recall ever seeing a ProgramFiles (16) or some such. Besides, how exactly would a 32-bit program "find a 64-bit DLL and try to load it"? What programs go around hunting for random DLLs in %programfiles%? If it is a shared DLL, then it goes in WinSxS; if it is not shared, then it is up to the programmer to manage their own DLLs. The part about it being done as a convenience for programmers reasonable though.
–
SynetechJun 27 '12 at 18:40

25

IIRC Win3.1 didn't have a program files directory (or most apps ignored it); as a result there wouldn't be any legacy win16 apps looking for stuff in program files to begin with. Instead IIRC shared libraries were often plonked somewhere in the windows folder itself. Win32 having windows\system and windows\system32 is an artifact of that.
–
Dan NeelyJun 27 '12 at 19:26

13

Windows 3.1 didn't support long file names, so it wouldn't have been able to have a 'program files' folder.
–
user973810Jun 27 '12 at 19:29

@Jarrod: Actually, as every developer knows, Microsoft values backwards compatibility too highly. Literally every API they have has legacy methods they refuse to remove, and often serious bugs they refuse to fix, because they are afraid of breaking older programs that were written for that API. The same is true of most API's, but not to anywhere near the extant of Microsoft's.
–
BlueRajaJun 28 '12 at 2:38

It's interesting that the answers here and across the internet vary quite a bit. Finding an accurate answer to this important question has been a challenge. There appears to be quite a bit of false information presented on the internet, leading to confusion.

I've performed a significant amount of research, and have drawn the following conclusion, which I believe is accurate:

It makes no difference where an application is stored. At runtime, Windows will determine if the application is 32-bit or 64-bit and automatically use the appropriate DLL's and registry section.

This happens automatically, and is independent of where the application is stored. There is no speed, reliability, or other functional benefit to having separate 32-bit and 64-bit folders.

The sole reason for the default separation into two folders ('Program Files' and 'Program Files (x86)') is that if you have two versions of the same program (a 32-bit and 64-bit version), it provides a simple way to keep overlapping files separate. Even in this case, as long as all the filenames are unique, they could actually exist in the same folder without any consequence.

There is a caveat to the above conclusion, and that is the one of poorly coded applications. If an application has any paths hardcoded into it, it will only use that path. As a rule, paths should never be hardcoded into an application, but occasionally a programmer will make this mistake. In this case, the program will use the hardcoded path; the directory in which the application is installed will not affect where it actually looks for files.

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.

Hehe. Nice article. The comments to that article sound exactly like the ones here. Worse, that article was from more than two years ago, which just shows that this question is not new and if it still cannot be answered authoritatively, then I guess it never will (unless someone from the Windows team chimes in). Oh well, I suppose we should all just stop worrying and learn to love the bomb, uh, I mean to live with it. +1 For pointing out the article and showing that this question had been around for so long.
–
SynetechJun 28 '12 at 16:37

1

@Synetech thanks! Yeah, idea behind putting the article link is the same as you got. This is a very old time question but IDK why people couldn't get it yet. However the MS should write a KB or Documentation for this problem :)
–
avirkJun 28 '12 at 16:43

Yes they should, especially because it is not just developers that ask, even normal users wonder about it. Unfortunately Microsoft's documentation is not often too good.
–
SynetechJun 28 '12 at 16:44

@Synetech yup! MS documentation sucks most of the time. But yes they have wrote some good articles too and I'm pretty sure they are countable ;)
–
avirkJun 28 '12 at 16:48

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".

How does ProgramFiles(x86)` avoid clutter? There are still both 32- and 64-bit versions of files, so avoiding clutter doesn't make sense. There is no difference between putting them in \32\blah` or \blah\32; either way, they are separated. If anything, the current way separates the app's components (and also duplicates them unnecessarily since few apps use CommonFiles for resources and such. Besides, you make it sound as though apps are dumping their DLLs in a common bucket. It's easy enough to keep an app's 32-bit DLLs with its 32-bit exes and it's 64-bit DLLs with it's 64-bit exes.
–
SynetechJun 28 '12 at 14:58

Oh, and as for 95/98, who said anything about that? Even XP had a 16-bit subsystem (the NTVDM).
–
SynetechJun 28 '12 at 14:58

I thought you wanted an explanation. Few apps use CommonFiles? I have 35 different applications that have entries there. It's a safer place to store shared components than the System32 directory. Your statement that few apps use this is debatable. Quoting you: "They didn't have to jump through these hoops to allow for 32-bit and 16-bit programs on the same system. I don't recall ever seeing a ProgramFiles (16) or some such [...] The part about it being done as a convenience for programmers reasonable though." Well, yeah.. programmers do. We write the applications after all.
–
Jason LockeJun 28 '12 at 15:20

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):

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?

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.

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.

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.

Is that the original reason, though? Couldn't I just install the app to C:\Program Files\App32 and C:\Program Files\App64?
–
Stephen JenningsJun 27 '12 at 17:32

4

@StephenJennings: But that would require you to manually make the decision. The way it now works is that the process is automatic, because Windows knows what folder to provide when an application calls SHGetSpecialFolderPath to determine the install location.
–
Oliver Salzburg♦Jun 27 '12 at 17:39

6

@Synetech: Why install into %PROGRAMFILES% in the first place? Why not put the 32bit version on the users desktop and the 64bit into the Recycle Bin? Just because it can be done, doesn't mean it's a good idea. Sorry, I don't follow your reasoning.
–
Oliver Salzburg♦Jun 27 '12 at 17:49

4

@Synetech: Yes, you did give a perfectly good example of how it could be done. Another perfectly good example of how it could be done is the way it is actually being done right now. Simply writing a file to %PROGRAMFILES% and being certain that it will end up in the right folder is one thing. Checking for yourself which folder is the correct one is another. If you actually don't see the benefit of the former approach, then I will not be able to convince you. The question was why there are 2 folders. I think my answer is perfectly reasonable in that regard.
–
Oliver Salzburg♦Jun 27 '12 at 18:03

2

@OliverSalzburg, No quite. The question is why two folders are required, not why there are. In fact, he even bolded it: why is this even necessary? You did not explain why it is necessary and the example I gave (and even your own sarcastic example) just show that it does not have to be done the way it is.
–
SynetechJun 27 '12 at 18:05

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).

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.

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

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion

which normally points to C:\Program Files.

However, if the installer is a 32-bit application, registry redirection will cause the regitry key

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.

But why does it have to put it in different folders? Windows is already fully capable of determining the architecture of an executable by looking at the PE header. Why can it not load the appropriate environment when it loads the executable?
–
SynetechJun 27 '12 at 17:40

1

I think it just a choice from Microsoft to easily show to users which architecture they want from two program version when opening a program. I mean, if there wasn't these two folders and if it was transparent to users(if it switch automatically), they wouldn't know if running a 32 or 64 bits app, even, they wouldn't know which program to open if running on 64 bits..
–
DiogoJun 27 '12 at 17:48

1

The 64-bit version of IE has a reputation for being terrible.
–
Samuel Edwin WardJun 27 '12 at 18:29

1

MS recommends using office32 unless you're working with datasets large enough to exceed memory constraints. I believe the need to recompile binary addons to work with office64; combined with not giving any benefits in normal use cases is behind the decision.
–
Dan NeelyJun 27 '12 at 18:36

1

I think you'll find that a 64-bit program explicitly installed into the Program Files(x86) folder will work perfectly normally (and, in most cases, vice versa). Windows does not use the folder location to determine how to treat the executable.
–
Harry JohnstonJun 29 '12 at 2:38

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.

That doesn't explain it. Who exactly is using the environment variable and why would it care whether a program is 32-bit or 64-bit?
–
SynetechJun 27 '12 at 17:42

3

@Synetech - The author of programs use the environment variable. As to the reason it would care is because of references to dlls. You cannot load a 32-bit dll within a 64-bit process and vice versa.
–
RamhoundJun 27 '12 at 18:27

1

And how do %programfiles%, %programfiles(x86)%, or %programw6432% make a difference there? Any shared DLLs go into the single WinSxS directory, and any non-shared DLLs are right there with the executable. This would only matter if for some reason you have both 32-bit and 64-bit versions of the same program installed, and even then, you would keep the 32-bit DLLs with the 32-bit executable and the 64-bit DLL with the 64-bit executable. You can do this like so: %programfiles%\CoolApp\bin\32 and %programfiles%\CoolApp\bin\64`, why the separate top-level folders?
–
SynetechJun 27 '12 at 18:33

@Synetech Sure it does; %programfiles% has been around a while. If you install a 32 bit program on a 64 bit computer, having one place would cause problems for that 32 bit app. WoW though can redirect %programfile% to the (x86) version for 32 bit apps, and the non-x86 version for 64.
–
AndyJun 27 '12 at 20:24

i think people wouldn't be so confused , if there was no implicit redirection
–
kommradHomerJun 28 '12 at 13:50