Pergunta

Eu gostaria de saber quando é que precisamos colocar um arquivo em

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

Eu tive dois DLL, uma para 32 bits, um para 64-bit.

Logicamente, eu pensei que eu iria 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 32 um bit entra em C: \ Windows \ SYSWOW 64 , e 64 bit DLL vai para C: \ Windows \ System 32 .

Muito confuso coisas. Qual é a razão por trás disso?

Foi útil?

Solução

Eu acredito que a intenção era mudar o nome System32, mas muitas aplicações hard-coded para esse caminho, que não era viável para removê-lo.

SysWoW64 não foi destinado para as DLLs de sistemas de 64 bits, é realmente algo como "Windows on Windows64", ou seja, os bits que você precisa para executar 32 bits aplicativos em um Windows de 64 bits.

Este artigo explica um pouco:

"Windows x64 tem um diretório System32 que contém DLLs de 64 bits processos Assim nativos com um número de bits de 64 find (sic!).‘Seus’DLLs, onde eles esperam-los:. Na pasta System32 Um segundo diretório, SysWOW64, contém as DLLs de 32 bits. o redirecionador sistema de arquivos faz a mágica de esconder o diretório System32 reais para processos de 32 bits e mostrando SysWOW64 sob o nome de System32. "

Edit: Se você está falando de um instalador, você realmente não deve codificar o caminho para a pasta do sistema. Em vez disso, deixar o Windows cuidar dele para você com base em se ou não o seu instalador está sendo executado na camada de emulação.

Outras dicas

Gostaria de acrescentar: Você não deve estar colocando sua DLL em \ system32 \ qualquer maneira! Modificar o código, modificar o seu instalador ... encontrar um lar para seus bits que não é em qualquer lugar sob c: \ windows \

Por exemplo, o instalador coloca suas DLLs em:

\program files\<your app dir>\

or

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

( Nota : A maneira como você realmente fazer isso é usar o ambiente Var:% ProgramFiles% ou % ProgramFiles (x86)% para descobrir onde Program Files é .... você não assumir que é c: \ Program Files \ ....)

e em seguida, define uma tag de registro:

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

O código que usa suas DLLs lê o registro, em seguida, vincula dinamicamente para as DLLs no local.

A descrição acima é a forma inteligente de ir.

Você nunca instalar as suas DLLs, ou DLLs de terceiros no \ system32 \ ou \ syswow64. Se você tiver que carregar estaticamente, você coloca suas DLLs na sua exe dir (onde serão encontrados). Se você não pode prever o exe dir (por exemplo, algum outro exe vai chamar sua DLL), você pode ter que colocar o seu dir dll no caminho de pesquisa (evitar isso, se em tudo poss!)

system32 e syswow64 são para Windows fornecido arquivos ... não para arquivos ninguém tinha o . As únicas pessoas razão adquiriram o mau hábito de colocar coisas lá é porque ele está sempre no caminho de pesquisa, e muitos apps / módulos usam vinculação estática. (Então, se você realmente começar a ele, o verdadeiro pecado é vinculação estática - este é um pecado em código nativo e código gerenciado - sempre sempre sempre dinamicamente link)

correu para o mesmo problema e pesquisado isso por alguns minutos.

me ensinaram a usar o Windows 3.1 e DOS, lembro daqueles dias? Pouco depois de ter trabalhado com computadores Macintosh estritamente por algum tempo, em seguida, começou a balançar de volta para o Windows depois de comprar uma máquina x64-bit.

Há razões reais por trás dessas mudanças (alguns diriam significado histórico), que são necessários para programadores para continuar seu trabalho.

A maioria das mudanças são mencionados acima:

  • Program Files vs Program Files (x86)

    No começo os arquivos 16 / 86bit foram escritos sobre, '86' processadores Intel.

  • System32 realmente significa System64 (em 64-bit Windows)

    Quando os desenvolvedores começou a trabalhar com Windows7, houve vários problemas de compatibilidade onde outras aplicações onde armazenado.

  • SysWOW64 realmente significa SysWOW32

    Essencialmente, na planície Inglês, isso significa 'Windows on Windows dentro de uma máquina de 64 bits' . Cada pasta está indicando onde as DLLs estão localizados para aplicações que eles desejam usá-los.

Aqui estão dois links com todas as informações básicas que você precisa:

Esperamos que este apura as coisas!

System32 é onde o Windows historicamente colocado todas as DLLs de 32 bits e sistema era para as DLLs de 16 bits. Quando a Microsoft criou o sistema operacional de 64 bit, todos que eu sei de esperar que os arquivos residam sob System64, mas a Microsoft decidiu que fazia mais sentido para colocar 64bit arquivos sob System32. A única raciocínio eu tenho sido capaz de encontrar, é que eles queriam tudo o que era de 32 bits para trabalhar em um de 64 bits do Windows w / o ter que mudar alguma coisa nos programas - apenas recompilação, e ele é feito. A maneira como eles resolveram este, de modo que os aplicativos de 32 bits ainda podia correr, era criar um Windows de 32 bits subsistema chamado Windows32 No Windows64. Como tal, a sigla SysWOW64 foi criado para o diretório de sistema do subsistema de 32 bits. Os Sys é curto para o sistema, e WOW64 é curto para Windows32OnWindows64.
Desde janelas 16 já é segregado a partir do Windows 32, não havia necessidade de um Windows 16 No Windows 64 equivalência. Dentro do subsistema de 32 bits, quando um programa vai usar arquivos do diretório system32, eles realmente obter os arquivos do diretório SysWOW64. Mas o processo é falho.

É um design horrível. E na minha experiência, eu tive que fazer muito mais muda para escrever aplicações de 64 bits, que simplesmente mudando o diretório System32 para ler System64 teria sido uma mudança muito pequena, e que directivas pré-compilador são destinados a alça.

Outras pessoas já fizeram um bom trabalho de explicar esse enigma ridiculus ... e eu acho que Chris Hoffman fez um trabalho ainda melhor aqui: https://www.howtogeek.com/326509/whats-the-difference-between-the- system32-e-SysWow64-pastas-in-windows /

Os meus dois pensamentos:

  1. Todos nós cometemos erros míopes estúpidas na vida. Quando a Microsoft nomeou seu (na época) anuário Win32 DLL "System32", fazia sentido no momento ... eles simplesmente não levar em consideração o que aconteceria se / quando um 64-bit (ou 128 bits) versão de seu sistema operacional foi desenvolvido mais tarde - eo enorme problema de compatibilidade como um nome de diretório para trás causaria. Retrospectiva é sempre 20-20, então eu realmente não posso culpá-los (muito) para tal erro a. ... No entanto ... Quando a Microsoft fez mais tarde desenvolver o seu sistema operacional de 64 bits, mesmo com o benefício da retrospectiva, por que oh por que eles fazem não só exatamente o mesmo míope erro novamente, mas torná-lo ainda pior, propositadamente dando -lo como um nome enganoso?!? Que vergonha !!! Por que não PELO MENOS realmente nomear o diretório "SysWin32OnWin64" a confusão evitar?!? E o que acontece quando eles eventualmente produzir um sistema operacional de 128 bits ... então onde eles estão indo para colocar seu 32 bits, 64 bits e 128 bits DLLs?!?

  2. Tudo isso lógica ainda parece completamente falho para mim. Em versões de 32 bits do Windows, System32 contém DLLs de 32 bits; em versões de 64 bits do Windows, System32 contém DLLs de 64 bits ... para que os desenvolvedores não teria que fazer alterações no código, correto? O problema com esta lógica é que os desenvolvedores são ou fazendo agora aplicativos de 64 bits que precisam de DLLs de 64 bits ou eles estão fazendo aplicativos de 32 bits que precisam de DLLs de 32 bits ... de qualquer forma, não são ainda parafusado? Quer dizer, se eles ainda estão fazendo um aplicativo de 32 bits, para que possa agora ser executado em um Windows de 64 bits, que agora vai precisar fazer uma alteração de código para encontrar / referência o mesmo ol' DLL de 32 bits que usado antes (agora localizado em SysWOW64). Ou, se eles estão trabalhando em um aplicativo de 64 bits, eles vão necessidade de re-escrever seu aplicativo velho para o novo sistema operacional de qualquer maneira ... então uma recompilação / reconstrução iria ser necessária qualquer maneira !!!

Microsoft só me dói, às vezes.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top