Por que DLLs de 64 bits vão para System32 e DLLs de 32 bits para SysWoW64 no Windows de 64 bits?

Gostaria de saber quando precisamos colocar um arquivo em

C: \ Windows \ System32 ou C: \ Windows \ SysWOW64, em um sistema Windows de 64 bits.

Eu tinha duas DLLs, uma para 32 bits e uma para 64 bits.

Logicamente, pensei em colocar a DLL de 32 bits em C: \ Windows \ System32 e a DLL de 64 bits em C: \ Windows \ SysWOW64.

Para minha surpresa, é o contrário ! O de 32 bits entra em C: \ Windows \ SysWOW 64 e a DLL de 64 bits entra em C: \ Windows \ System 32 .

Coisas muito confusas. Qual a razão por trás disso?

Acredito que a intenção era renomear o System32, mas tantos aplicativos codificados para esse caminho que não era possível removê-lo.

O SysWoW64 não foi projetado para as DLLs de sistemas de 64 bits, na verdade é algo como "Windows no Windows64", significando os bits necessários para executar aplicativos de 32 bits em janelas de 64 bits.

Este artigo explica um pouco:

"O Windows x64 possui um diretório System32 que contém DLLs de 64 bits (sic!). Portanto, processos nativos com um número de 64 encontram as DLLs" suas "onde esperam: na pasta System32. Um segundo diretório, SysWOW64, contém 32 DLLs de bits. O redirecionador do sistema de arquivos faz a mágica de ocultar o diretório System32 real para processos de 32 bits e mostrar o SysWOW64 sob o nome de System32. "

Editar: se você está falando de um instalador, não deve codificar o caminho para a pasta do sistema. Em vez disso, permita que o Windows cuide disso com base em sua instalação ou não na camada de emulação.

Devo acrescentar: você não deve colocar suas dll em \ system32 \ de qualquer maneira! Modifique seu código, modifique seu instalador ... encontre uma casa para seus bits que NÃO esteja em nenhum lugar em c: \ windows \

Por exemplo, seu instalador coloca suas DLLs em:

\program files\<your app dir>\

or

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

( Nota : A maneira como você realmente faz isso é usar o ambiente var:% ProgramFiles% ou% ProgramFiles (x86)% para descobrir onde está o arquivo de programas .... você não assume que seja c: \ arquivos de programas \ .. ..)

e depois define uma marca de registro:

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

O código que usa as dlls lê o registro e vincula dinamicamente às dlls nesse local.

O acima é o caminho inteligente a seguir.

Você nunca instala suas DLLs ou DLLs de terceiros em \ system32 \ ou \ syswow64. Se você precisar carregar estaticamente, coloque suas dlls no diretório exe (onde elas serão encontradas). Se você não conseguir prever o diretório exe (por exemplo, outro exe chamará sua dll), talvez seja necessário colocar seu diretório dll no caminho de pesquisa (evite-o, se possível!)

system32 e syswow64 são para arquivos fornecidos pelo Windows ... não para outros arquivos . A única razão pela qual as pessoas adquiriram o mau hábito de colocar coisas lá é porque elas estão sempre no caminho de pesquisa, e muitos aplicativos / módulos usam links estáticos. (Então, se você realmente entender, o pecado real é a vinculação estática - isso é pecado no código nativo e no código gerenciado - sempre sempre vincula dinamicamente!)

Deparou-se com o mesmo problema e pesquisou isso por alguns minutos.

Fui ensinado a usar o Windows 3.1 e o DOS, lembra-se daqueles dias? Logo depois que trabalhei estritamente com computadores Macintosh por algum tempo, comecei a voltar ao Windows depois de comprar uma máquina de x64 bits.

Existem razões reais por trás dessas mudanças (algumas diriam significado histórico), necessárias para que os programadores continuem seu trabalho.

A maioria das alterações é mencionada acima:

• Program Files vs Program Files (x86)

  No começo, os arquivos de 16/86 bits eram gravados em processadores Intel '86'.

• System32realmente significa System64(no Windows de 64 bits)

  Quando os desenvolvedores começaram a trabalhar com o Windows7, havia vários problemas de compatibilidade em que outros aplicativos eram armazenados.

• SysWOW64 realmente significa SysWOW32

  Basicamente, em inglês simples, significa 'Windows no Windows em uma máquina de 64 bits' . Cada pasta indica onde as DLLs estão localizadas para os aplicativos em que desejam usá-las.

Aqui estão dois links com todas as informações básicas necessárias:

• Redirecionador de sistema de arquivos MSDN

• SysWow64 Explained

Espero que isso esclareça as coisas!

O System32 é onde o Windows historicamente colocou todas as DLLs de 32 bits e o System foi para as DLLs de 16 bits. Quando a microsoft criou o sistema operacional de 64 bits, todos que eu conhecia esperavam que os arquivos residissem no System64, mas a Microsoft decidiu que fazia mais sentido colocar arquivos de 64 bits no System32. O único raciocínio que pude encontrar é que eles queriam que tudo que tivesse 32 bits funcionasse em um Windows de 64 bits sem ter que alterar nada nos programas - apenas recompile e pronto. A maneira como eles resolveram isso, para que os aplicativos de 32 bits ainda pudessem ser executados, foi criar um subsistema Windows de 32 bits chamado Windows32 On Windows64. Como tal, o acrônimo SysWOW64 foi criado para o diretório System do subsistema de 32 bits. O Sys é a abreviação de System e WOW64 é a abreviação de Windows32OnWindows64.
Como o Windows 16 já está segregado do Windows 32, não havia necessidade de uma equivalência do Windows 16 no Windows 64. No subsistema de 32 bits, quando um programa usa arquivos do diretório system32, eles obtêm os arquivos do diretório SysWOW64. Mas o processo é falho.

É um design horrível. E, na minha experiência, tive que fazer muito mais alterações para escrever aplicativos de 64 bits, que simplesmente alterar o diretório System32 para ler System64 teria sido uma mudança muito pequena e que as diretivas de pré-compilador devem tratar.

Outras pessoas já fizeram um bom trabalho ao explicar esse dilema do ridículo ... e acho que Chris Hoffman fez um trabalho ainda melhor aqui: https://www.howtogeek.com/326509/whats-the-difference-between-the- system32-and-syswow64-folders-in-windows /

Meus dois pensamentos:

1. Todos cometemos erros estúpidos de míope na vida. Quando a Microsoft nomeou o diretório (System32) de DLL do Win32 (na época) "System32", fazia sentido na época ... eles simplesmente não levaram em consideração o que aconteceria se / quando uma versão de 64 bits (ou 128 bits) do SO deles foi desenvolvido mais tarde - e o enorme problema de compatibilidade com versões anteriores que esse nome de diretório causaria. A retrospectiva é sempre de 20 a 20, então não posso culpá-los (demais) por esse erro. ... NO ENTANTO ... Quando a Microsoft mais tarde desenvolveu seu sistema operacional de 64 bits, mesmo com o benefício da retrospectiva, por que, oh, por que eles cometeriam não apenas exatamente o mesmo erro míope de novo, mas piorariam ainda mais, propondo é um nome tão enganador?!? Que vergonha para eles !!! Por que não, pelo menos, na verdade, nomeie o diretório "SysWin32OnWin64" para evitar confusão ?! ? E o que acontece quando eles finalmente produzem um sistema operacional de 128 bits ... então onde eles colocam suas DLLs de 32 bits, 64 bits e 128 bits?!?

2. Toda essa lógica ainda parece completamente falha para mim. Nas versões de 32 bits do Windows, o System32 contém DLLs de 32 bits; nas versões de 64 bits do Windows, o System32 contém DLLs de 64 bits ... para que os desenvolvedores não precisem fazer alterações no código, correto? O problema dessa lógica é que esses desenvolvedores agora estão criando aplicativos de 64 bits que precisam de DLLs de 64 bits ou estão criando aplicativos de 32 bits que precisam de DLLs de 32 bits ... de qualquer maneira, eles ainda não estão ferrados? Quero dizer, se eles ainda estão criando um aplicativo de 32 bits, para rodar agora em um Windows de 64 bits, agora precisam fazer uma alteração no código para encontrar / referenciar a mesma DLL de 32 bits que usado anteriormente (agora localizado no SysWOW64). Ou, se eles estiverem trabalhando em um aplicativo de 64 bits, precisarão reescrever o aplicativo antigo para o novo sistema operacional de qualquer maneira ... então uma recompilação / reconstrução seria necessária de qualquer maneira !!

A Microsoft às vezes me machuca.