Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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.

share|improve this question
    
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... –  Synetech Jun 27 '12 at 17:42
13  
Rather than answer your question, I would ask - how would you handle \program files\common files ? –  sgmoore Jun 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
7  
I've always wondered why Microsoft didn't put 64-bit programs in a "Program Files (x64)" instead of *moving" the "legacy" Program Files directory to Program Files (x86) –  ultrasawblade Jun 28 '12 at 11:05
19  
The real mess about the 64/32bit differentiation is that /Windows/System32 contains 64bit content, while /Windows/SysWOW64 contains the 32bit stuff… –  poke Jun 28 '12 at 11:17

9 Answers 9

up vote 69 down vote accepted

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.

share|improve this answer
40  
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. –  Synetech Jun 27 '12 at 18:40
24  
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 Neely Jun 27 '12 at 19:26
12  
Windows 3.1 didn't support long file names, so it wouldn't have been able to have a 'program files' folder. –  user973810 Jun 27 '12 at 19:29
13  
@JarrodRoberson: Quite the reverse, it's because Microsoft values backwards compatibility extremely highly. –  David Schwartz Jun 27 '12 at 20:08
21  
@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. –  BlueRaja Jun 28 '12 at 2:38

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.

share|improve this answer
3  
Is that the original reason, though? Couldn't I just install the app to C:\Program Files\App32 and C:\Program Files\App64? –  Stephen Jennings Jun 27 '12 at 17:32
3  
@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
5  
@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
3  
@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. –  Synetech Jun 27 '12 at 18:05

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.

share|improve this answer
4  
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? –  Synetech Jun 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. –  Ramhound Jun 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? –  Synetech Jun 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. –  Andy Jun 27 '12 at 20:24
    
i think people wouldn't be so confused , if there was no implicit redirection –  kommradHomer Jun 28 '12 at 13:50

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

share|improve this answer
    
Revenge down-voting! Muahahaha! sigh –  Synetech Jun 28 '12 at 5:50
    
Down-vote strange :\. BTW good explain +1. –  avirk Jun 28 '12 at 16:31

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.

share|improve this answer
2  
+1 At least you addressed the underlying question of why average users would have both versions. –  Synetech Jun 28 '12 at 14:50

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.

share|improve this answer
    
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. –  Synetech Jun 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 :) –  avirk Jun 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. –  Synetech Jun 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 ;) –  avirk Jun 28 '12 at 16:48

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.

share|improve this answer
6  
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? –  Synetech Jun 27 '12 at 17:40
    
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.. –  Diogo Jun 27 '12 at 17:48
    
If the user is a novice, then I highly doubt they would be running both versions. In fact, even advanced users will rarely ever run both 32-bit and 64-bit versions of a program. If there is a 64-bit version available and the system is 64-bit, then (sane) people are expected to use the 64-bit version; there is no reasonable excuse to install or run the 32-bit version unless you are a developer and doing testing. Of course if the 64-bit version is experimental, then one would expect non-devs/testers to use only the 32-bit version and uninstall it when the 64-bit version is ready. –  Synetech Jun 27 '12 at 17:51
1  
The 64-bit version of IE has a reputation for being terrible. –  Samuel Edwin Ward Jun 27 '12 at 18:29
    
@SamuelEdwinWard, then you can call it "experimental". Even so, lets say you have both 32-bit and 64-bit versions of IE; what makes it mandatory to keep them in separate top-level folders? –  Synetech Jun 27 '12 at 18:35

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

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion

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.

share|improve this answer

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

share|improve this answer
    
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. –  Synetech Jun 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). –  Synetech Jun 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 Locke Jun 28 '12 at 15:20
    
Huh?​​​​​​​​​​​ –  Synetech Jun 28 '12 at 15:25
    
Just re-read this.. he said it better in his replies - superuser.com/a/442253/142951. If you're not a developer you might not see the purpose. –  Jason Locke Jun 28 '12 at 15:29

protected by Mokubai Jul 8 at 14:37

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.