Why do 64-bit DLLs go to System32 and 32-bit DLLs to SysWoW64 on 64-bit Windows?

Question

I would like to know when do we need to place a file under

C:\Windows\System32 or C:\Windows\SysWOW64, on a 64-bits windows system.

I had two DLL's, one for 32-bit, one for 64-bit.

Logically, I thought I'd place the 32-bit DLL under C:\Windows\System32, and the 64-bit DLL under C:\Windows\SysWOW64.

To my surprise, it's the other way around! The 32-bit one goes into C:\Windows\SysWOW64, and the 64-bit DLL goes into C:\Windows\System32.

Very confusing stuff. What's the reason behind this?

Chinkapin

Also, this: Windows looks in the current working directory as well as in the system PATH. There is no way to specify otherwise. Oh wait, there is. You can embed the search path in your DLL. It is a field that is 8 bytes long. Yes. 8 characters. – Nydia

This seems not to be true on Windows 7. Running file on a DLL in the system32 file C:\Windows\system32\user32.dll C:\Windows\system32\user32.dll; PE32 executable for MS Windows (DLL) (GUI) Intel 80386 32-bit But for a 64-bit DLL it prints PE32+ executable for MS Windows (DLL) (console) Mono/.Net assembly Note that this DLL is not a .Net assembly. It is a native DLL. – Latonialatoniah

Linking similar question on superuser. – Chromatograph

Interview with an ex-Microsoftie. (For a serious explanation of how this came to be, see this answer.) – Traprock

superuser.com/a/157301/241386 "Backwards compatibility reasons. A whole lot of applications assume things they shouldn't assume and hard-code paths" – Numbersnumbfish

Answer 1

I believe the intent was to rename System32, but so many applications hard-coded for that path, that it wasn't feasible to remove it.

SysWoW64 wasn't intended for the dlls of 64-bit systems, it's actually something like "Windows on Windows64", meaning the bits you need to run 32bit apps on a 64bit windows.

This article explains a bit:

Windows x64 has a directory System32 that contains 64-bit DLLs (sic!). Thus native processes with a bitness of 64 find “their” DLLs where they expect them: in the System32 folder. A second directory, SysWOW64, contains the 32-bit DLLs. The file system redirector does the magic of hiding the real System32 directory for 32-bit processes and showing SysWOW64 under the name of System32.

If you're talking about an installer, you really should not hard-code the path to the system folder. Instead, let Windows take care of it for you based on whether or not your installer is running on the emulation layer.

Listen

Ugh, I just ran into this weirdness today. What a misleading thing that they have done. – Parcenary

Ran into this today too ... so confusing - Glut 32-bit dll goes into /SysWOW64, Glut 64-bit dll goes into /System32. Someone should write that down. On the internet. – Nydia

Ironically, you just did, and this thread is now the top link on google for "SysWOW64 32bits", so... – Disrelish

The good news is, as an example of Microsoft engineering genius, this is pretty much self-documenting. – Garbers

One thing I don't get is, if the file system can tell that it's a 32 bit app and redirect it to the SysWOW64 folder, why couldn't they instead have it detect a 64 bit app and redirect to a System64?! – Nadenenader

I don't know, but it might be something as simple as performance -- given that the system is natively 64-bit, the system components are 64-bit and most of the applications should be 64-bit as well. Having the redirection in place for 64-bit apps would then incur a performance hit in the most common scenario instead of the exception. – Listen

System32 is the Windows 32 bit version of the System DLLs. System is the 16 bit version. The same company that gave us Windows 8 gave us SysWow64 for 32 bit DLLs and System32 for the 64bit DLLs when running on a 64bit OS. In 64 bit systems, the System folder is still the old 16 bit junk, only the System32 is not 32bit as suggested, and the 32 bit stuff is in the System directory with 64 in the name. I fail to see how this helps anyone. it over complicates things, and breaks everything. All to save people from adapting hard-coded "System32" to "System64" when converting to 64bit. Idiocy – Summersummerhouse

Interestingly, I've yet to see a single instance of this affecting my life in any way. Yet even I, with no experience of OS development, was able to form a conjecture wherein the current way of doing things made some kind of sense. I guess you can't win if you're Microsoft. Change the folder name -> apps break -> Windows sucks! Don't change it -> naming is somewhat inconsistent -> Microsoft are idiots! – Listen

samlogic.net/articles/32-64-bit-windows-folder-x86-syswow64.htm "This may seem a bit illogical if you look at the folder names, but there is an explanation to this. It has to do with compatibility. Many developers have hard coded the path to the system folder in their applications source code. They have included "System32" in the folder path. And to preserve compatibility, if the application is converted to 64-bit code, the 64-bit system folder is still named System32." – Numbersnumbfish

It gets better! The 64 bit version of the winsock library, found in system32, named ws2_32.dll, still has the File Description "Windows Socket 2.0 32-bit DLL"... – Polygnotus

Call it a professional deformation or whatever, but this makes perfect sense to me. I'd probably do the same. – Autumn

Of course, the only problem there is that those 32-bit apps will look in the hard-coded System32 path, not SysWoW64, indicating that Windows knows and does the replace silently. In a perfect world, System32 would continue to be used for 32-bit objects, and old apps would continue to use that path, while a new System64 would introduce the new 64-bit objects, and new apps being created for the 64-bit platform would use System64 to access said objects. Or they could remain 32-bit and use System32. This kind of backwards hand-holding seems to have the opposite effect from the intent. – Betthezel

The problem with this backward compatibility talk is that Microsoft clearly doesn't have it as the highest priority. They had no qualms with ditching the 16-bit DOS libraries for the move to NT and 32-bit machines. And AFAIK the third-party devs took no issue with that. Why are they suddenly retarding the system for the move to 64-bit? – Betthezel

It's almost as bad as skipping Windows 9 because people were checking for Windows 9* off the version string for Windows versions like Windows 95, 98, etc. Honestly, they should be redirecting system calls for old applications so this isn't a problem rather than doing confusing directory names and skipping versions (and even changing the paths to their correct ones, etc). Don't become a slave of your own work. System32 should be for 32-bit stuff only. – Snocat

Answer 2

I should add: You should not be putting your dll's into \system32\ anyway! Modify your code, modify your installer... find a home for your bits that is NOT anywhere under c:\windows\

For example, your installer puts your dlls into:

\program files\<your app dir>\

or

\program files\common files\<your app name>\

(Note: The way you actually do this is to use the environment var: %ProgramFiles% or %ProgramFiles(x86)% to find where Program Files is.... you do not assume it is c:\program files\ ....)

and then sets a registry tag :

HKLM\software\<your app name>
-- dllLocation

The code that uses your dlls reads the registry, then dynamically links to the dlls in that location.

The above is the smart way to go.

You do not ever install your dlls, or third party dlls into \system32\ or \syswow64. If you have to statically load, you put your dlls in your exe dir (where they will be found). If you cannot predict the exe dir (e.g. some other exe is going to call your dll), you may have to put your dll dir into the search path (avoid this if at all poss!)

system32 and syswow64 are for Windows provided files... not for anyone elses files. The only reason folks got into the bad habit of putting stuff there is because it is always in the search path, and many apps/modules use static linking. (So, if you really get down to it, the real sin is static linking -- this is a sin in native code and managed code -- always always always dynamically link!)

Silma

+1 ...but I'd add that you should use variables like %PROGRAMFILES% not \Program Files\ – Asti

In the days of XP, it was a common (and suggested) practice for developers to use the registry for such things. With Windows 7, this is no longer true! For reasons of UAC, multiple user sessions, etc. The registry in Windows 7 should be use sparingly and with discretion by developers. – Dwan

@RodMacPherson My response has been enhanced to take your suggestion into account. You are right on! – Silma

After some consideration, I think this answers the question better - "When do we need to place a file under %SYSTEMROOT%". Never. This answer doesn't satisfy curiosity about the syswow64 folder, but it's the one developers really need to read. – Yasmineyasu

Answer 3

Ran into the same issue and researched this for a few minutes.

I was taught to use Windows 3.1 and DOS, remember those days? Shortly after I worked with Macintosh computers strictly for some time, then began to sway back to Windows after buying a x64-bit machine.

There are actual reasons behind these changes (some would say historical significance), that are necessary for programmers to continue their work.

Most of the changes are mentioned above:

• Program Files vs Program Files (x86)

  In the beginning the 16/86bit files were written on, '86' Intel processors.

• System32 really means System64 (on 64-bit Windows)

  When developers first started working with Windows7, there were several compatibility issues where other applications where stored.

• SysWOW64 really means SysWOW32

  Essentially, in plain english, it means 'Windows on Windows within a 64-bit machine'. Each folder is indicating where the DLLs are located for applications it they wish to use them.

Here are two links with all the basic info you need:

• MSDN File System Redirector

• SysWow64 Explained

Hope this clears things up!

Sailboat

If you want to be taken seriously, you should probably tone down the slang and improve the grammar. Also, you might want to structure your answer a bit more, use paragraphs. – Spermine

@Sailboat cleaned up the answer. In the future, you should consider what Klas suggests and format your response to increase the chances of upvotes. :) – Redman

The OP needs to be completely rewritten, or even removed. It is misleading and not really useful. – Silma

I am completely baffled by the decision to rename and relocate 32-bit stuff; why not just use extension DLL64 for 64-bit DLLs, and keep using DLL for 32-bit stuff? Even if 64-bit applications couldn't use 32-bit DLLs, I don't see why registry keys, directories, etc. have to be segregated--that just seems to add needless confusion. – Tella

SysWOW64 actually stands for: [Sys]tem [W]indows 32-bit [o]n [W]indows [64]-bit thus the abbreviated form SysWoW64 (which really makes no sense, and had Microsoft just left System32 for 32bit stuff, and created a System64, there really would not be compatibility issues. What Microsoft does in the WoW sandbox is to create an in memory redirect from 32bit access to System32 as a request to SysWoW64... how is this not more complicated than just exposing the file-system in the raw w/o having to magically remap it for the different platforms? As noted in a prior comment -- Idiocy. – Summersummerhouse

@Summersummerhouse Because there are a lot of developers out there who aren't smart enough to know whether their application requires 64 bit or 32 bit DLLs. Had MS done it your way, a lot of applications would crash because an inexperienced developer didn't hook the right libraries and Microsoft would be blamed for it. It's just an overly complex way to work-around ID10T errors and avoid a PR nightmare. – Yasmineyasu

answer bring more misunderstanding than clarity on the question, Armands comment is good explanation. – Ruthenious

Answer 4

System32 is where Windows historically placed all 32bit DLLs, and System was for the 16bit DLLs. When microsoft created the 64 bit OS, everyone I know of expected the files to reside under System64, but Microsoft decided it made more sense to put 64bit files under System32. The only reasoning I have been able to find, is that they wanted everything that was 32bit to work in a 64bit Windows w/o having to change anything in the programs -- just recompile, and it's done. The way they solved this, so that 32bit applications could still run, was to create a 32bit windows subsystem called Windows32 On Windows64. As such, the acronym SysWOW64 was created for the System directory of the 32bit subsystem. The Sys is short for System, and WOW64 is short for Windows32OnWindows64.
Since windows 16 is already segregated from Windows 32, there was no need for a Windows 16 On Windows 64 equivalence. Within the 32bit subsystem, when a program goes to use files from the system32 directory, they actually get the files from the SysWOW64 directory. But the process is flawed.

It's a horrible design. And in my experience, I had to do a lot more changes for writing 64bit applications, that simply changing the System32 directory to read System64 would have been a very small change, and one that pre-compiler directives are intended to handle.

Summersummerhouse

Answer 5

Other folks have already done a good job of explaining this ridiculus conundrum ... and I think Chris Hoffman did an even better job here: https://www.howtogeek.com/326509/whats-the-difference-between-the-system32-and-syswow64-folders-in-windows/

My two thoughts:

1. We all make stupid short-sighted mistakes in life. When Microsoft named their (at the time) Win32 DLL directory "System32", it made sense at the time ... they just didn't take into consideration what would happen if/when a 64-bit (or 128-bit) version of their OS got developed later - and the massive backward compatibility issue such a directory name would cause. Hindsight is always 20-20, so I can't really blame them (too much) for such a mistake. ...HOWEVER... When Microsoft did later develop their 64-bit operating system, even with the benefit of hindsight, why oh why would they make not only the exact same short-sighted mistake AGAIN but make it even worse by PURPOSEFULLY giving it such a misleading name?!? Shame on them!!! Why not AT LEAST actually name the directory "SysWin32OnWin64" to avoid confusion?!? And what happens when they eventually produce a 128-bit OS ... then where are they going to put their 32-bit, 64-bit, and 128-bit DLLs?!?

2. All of this logic still seems completely flawed to me. On 32-bit versions of Windows, System32 contains 32-bit DLLs; on 64-bit versions of Windows, System32 contains 64-bit DLLs ... so that developers wouldn't have to make code changes, correct? The problem with this logic is that those developers are either now making 64-bit apps needing 64-bit DLLs or they're making 32-bit apps needing 32-bit DLLs ... either way, aren't they still screwed? I mean, if they're still making a 32-bit app, for it to now run on a 64-bit Windows, they'll now need to make a code change to find/reference the same ol' 32-bit DLL they used before (now located in SysWOW64). Or, if they're working on a 64-bit app, they're going to need to re-write their old app for the new OS anyway ... so a recompile/rebuild was going to be needed anyway!!!

Microsoft just hurts me sometimes.

Hamiltonian