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

User · Accepted Answer

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

Edit: 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.

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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  lt your app dir gt    or   program files common files  lt your app name gt      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  lt your app name gt  -- 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

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

Examples related to dll

Examples related to 32bit-64bit

Examples related to system32

Examples related to syswow64