¿Por qué las DLL de 64 bits van a System32 y las DLL de 32 bits a SysWoW64 en Windows de 64 bits?

Me gustaría saber cuándo necesitamos colocar un archivo debajo

C: \ Windows \ System32 o C: \ Windows \ SysWOW64, en un sistema de Windows de 64 bits.

Tenía dos DLL, una para 32 bits y otra para 64 bits.

Lógicamente, pensé en colocar la DLL de 32 bits en C: \ Windows \ System32 y la DLL de 64 bits en C: \ Windows \ SysWOW64.

Para mi sorpresa, ¡es al revés ! El de 32 bits entra en C: \ Windows \ SysWOW 64 , y el DLL de 64 bits entra en C: \ Windows \ System 32 .

Cosas muy confusas. ¿Cuál es la razón detrás de esto?

Creo que la intención era cambiar el nombre de System32, pero tantas aplicaciones codificadas para ese camino, que no era posible eliminarlo.

SysWoW64 no estaba destinado a los dlls de los sistemas de 64 bits, en realidad es algo así como "Windows en Windows64", lo que significa los bits que necesita para ejecutar aplicaciones de 32 bits en una ventana de 64 bits.

Este artículo explica un poco:

"Windows x64 tiene un directorio System32 que contiene archivos DLL de 64 bits (sic!). Por lo tanto, los procesos nativos con un bit de 64 encuentran" sus "archivos DLL donde los esperan: en la carpeta System32. Un segundo directorio, SysWOW64, contiene los 32 -bit DLLs. El redirector del sistema de archivos hace la magia de ocultar el directorio System32 real para procesos de 32 bits y muestra SysWOW64 bajo el nombre de System32 ".

Editar: si está hablando de un instalador, realmente no debe codificar la ruta a la carpeta del sistema. En su lugar, deje que Windows se encargue de usted en función de si su instalador se ejecuta o no en la capa de emulación.

Debo agregar: ¡No deberías poner tus dll en \ system32 \ de todos modos! Modifique su código, modifique su instalador ... encuentre un hogar para sus bits que NO esté en ninguna parte bajo c: \ windows \

Por ejemplo, su instalador pone sus dlls en:

\program files\<your app dir>\

or

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

( Nota : la forma en que realmente hace esto es usar el entorno var:% ProgramFiles% o% ProgramFiles (x86)% para encontrar dónde está Program Files ... no asume que es c: \ program files \ .. ..)

y luego establece una etiqueta de registro:

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

El código que usa sus dlls lee el registro, luego se vincula dinámicamente a los dlls en esa ubicación.

Lo anterior es el camino inteligente a seguir.

Nunca instales tus dlls, o dlls de terceros en \ system32 \ o \ syswow64. Si tiene que cargar estáticamente, coloque sus dlls en su directorio exe (donde se encontrarán). Si no puede predecir el directorio exe (por ejemplo, algún otro exe va a llamar a su dll), es posible que deba poner su directorio dll en la ruta de búsqueda (¡evite esto si es posible!)

system32 y syswow64 son para archivos provistos por Windows ... no para nadie más archivos . La única razón por la que la gente tuvo el mal hábito de poner cosas allí es porque siempre está en la ruta de búsqueda, y muchas aplicaciones / módulos usan enlaces estáticos. (Entonces, si realmente te pones a ello, el verdadero pecado es el enlace estático, esto es un pecado en el código nativo y el código administrado, ¡siempre siempre siempre se vincula dinámicamente!)

Me encontré con el mismo problema e investigé esto durante unos minutos.

Me enseñaron a usar Windows 3.1 y DOS, ¿recuerdas esos días? Poco después de que trabajé con computadoras Macintosh estrictamente por un tiempo, luego comencé a volver a Windows después de comprar una máquina de x64 bits.

Hay razones reales detrás de estos cambios (algunos dirían que tienen un significado histórico), que son necesarios para que los programadores continúen su trabajo.

La mayoría de los cambios se mencionan anteriormente:

• Program Files vs Program Files (x86)

  Al principio, los archivos de 16/86 bits estaban escritos en procesadores Intel '86'.

• System32realmente significa System64(en Windows de 64 bits)

  Cuando los desarrolladores comenzaron a trabajar con Windows 7, hubo varios problemas de compatibilidad donde se almacenaban otras aplicaciones.

• SysWOW64 realmente significa SysWOW32

  Esencialmente, en inglés simple, significa 'Windows en Windows dentro de una máquina de 64 bits' . Cada carpeta indica dónde están ubicadas las DLL para las aplicaciones que desean usar.

Aquí hay dos enlaces con toda la información básica que necesita:

• Redirector del sistema de archivos MSDN

• SysWow64 explicado

¡Espero que esto aclare las cosas!

System32 es donde Windows históricamente colocó todas las DLL de 32 bits, y System fue para las DLL de 16 bits. Cuando Microsoft creó el sistema operativo de 64 bits, todos los que conozco esperaban que los archivos residieran en System64, pero Microsoft decidió que tenía más sentido colocar archivos de 64 bits en System32. El único razonamiento que he podido encontrar es que querían que todo lo que tenía 32 bits funcionara en un Windows de 64 bits sin tener que cambiar nada en los programas: simplemente recompile y listo. La forma en que resolvieron esto, para que las aplicaciones de 32 bits aún pudieran ejecutarse, fue crear un subsistema de Windows de 32 bits llamado Windows32 en Windows64. Como tal, el acrónimo SysWOW64 se creó para el directorio del sistema del subsistema de 32 bits. El Sys es la abreviatura de Sistema, y ​​WOW64 es la abreviatura de Windows32OnWindows64.
Como Windows 16 ya está segregado de Windows 32, no había necesidad de una equivalencia de Windows 16 en Windows 64. Dentro del subsistema de 32 bits, cuando un programa usa archivos del directorio system32, en realidad obtienen los archivos del directorio SysWOW64. Pero el proceso es defectuoso.

Es un diseño horrible. Y en mi experiencia, tuve que hacer muchos más cambios para escribir aplicaciones de 64 bits, que simplemente cambiar el directorio System32 para leer System64 habría sido un cambio muy pequeño, y uno que las directivas del precompilador están destinadas a manejar.

Otras personas ya han hecho un buen trabajo al explicar este enigma del ridículo ... y creo que Chris Hoffman hizo un trabajo aún mejor aquí: https://www.howtogeek.com/326509/whats-the-difference-between-the- system32-and-syswow64-folder-in-windows /

Mis dos pensamientos:

1. Todos cometemos estúpidos errores miopes en la vida. Cuando Microsoft nombró su (en ese momento) directorio Win32 DLL "System32", tenía sentido en ese momento ... simplemente no tuvieron en cuenta lo que sucedería si / cuando una versión de 64 bits (o 128 bits) de su sistema operativo se desarrolló más tarde, y el gran problema de compatibilidad con versiones anteriores que tal nombre de directorio causaría. La retrospectiva siempre es 20-20, por lo que realmente no puedo culparlos (demasiado) por tal error. ... SIN EMBARGO ... Cuando Microsoft desarrolló más tarde su sistema operativo de 64 bits, incluso con el beneficio de la retrospectiva, ¿por qué? ¿Por qué? Es un nombre tan engañoso?!? ¡¡¡Me avergüenzo de ellos!!! ¿Por qué no AL MENOS realmente nombrar el directorio "SysWin32OnWin64" para evitar confusiones ?! ? ¿Y qué sucede cuando finalmente producen un sistema operativo de 128 bits ... entonces, ¿dónde van a colocar sus DLL de 32, 64 y 128 bits?!?

2. Toda esta lógica todavía me parece completamente defectuosa. En las versiones de 32 bits de Windows, System32 contiene archivos DLL de 32 bits; en las versiones de 64 bits de Windows, System32 contiene archivos DLL de 64 bits ... para que los desarrolladores no tengan que hacer cambios en el código, ¿correcto? El problema con esta lógica es que esos desarrolladores están creando aplicaciones de 64 bits que necesitan archivos DLL de 64 bits o están creando aplicaciones de 32 bits que necesitan archivos DLL de 32 bits ... de cualquier manera, ¿todavía no están atornillados? Quiero decir, si todavía están haciendo una aplicación de 32 bits, para que ahora se ejecute en un Windows de 64 bits, ahora tendrán que hacer un cambio de código para encontrar / hacer referencia a la misma DLL de 32 bits antigua que usado antes (ahora ubicado en SysWOW64). O, si están trabajando en una aplicación de 64 bits, de todos modos tendrán que volver a escribir su aplicación anterior para el nuevo sistema operativo ... ¡de todos modos, sería necesario recompilar / reconstruir de todos modos!

Microsoft me lastima a veces.