Perché le DLL a 64 bit vanno a System32 e le DLL a 32 bit a SysWoW64 su Windows a 64 bit?

Vorrei sapere quando è necessario posizionare un file in

C: \ Windows \ System32 o C: \ Windows \ SysWOW64, su un sistema Windows a 64 bit.

Avevo due DLL, una per 32 bit, una per 64 bit.

Logicamente, ho pensato di posizionare la DLL a 32 bit in C: \ Windows \ System32 e la DLL a 64 bit in C: \ Windows \ SysWOW64.

Con mia sorpresa, è il contrario ! Quello a 32 bit entra in C: \ Windows \ SysWOW 64 e la DLL a 64 bit entra in C: \ Windows \ System 32 .

Roba molto confusa. Qual è la ragione dietro questo?

Credo che l'intenzione fosse quella di rinominare System32, ma così tante applicazioni codificate per quel percorso, che non era possibile rimuoverlo.

SysWoW64 non era destinato alle dll di sistemi a 64 bit, in realtà è qualcosa come "Windows su Windows64", che significa i bit necessari per eseguire app a 32 bit su Windows a 64 bit.

Questo articolo spiega un po ':

"Windows x64 ha una directory System32 che contiene DLL a 64 bit (sic!). Pertanto i processi nativi con un testimone di 64 trovano le" loro "DLL dove le si aspettano: nella cartella System32. Una seconda directory, SysWOW64, contiene i 32 -bit DLL. Il redirector del file system fa la magia di nascondere la directory System32 reale per i processi a 32 bit e mostrare SysWOW64 con il nome di System32. "

Modifica: se stai parlando di un programma di installazione, non dovresti davvero codificare il percorso della cartella di sistema. Invece, lascia che Windows se ne occupi per te in base al fatto che il tuo programma di installazione sia in esecuzione sul livello di emulazione.

Dovrei aggiungere: non dovresti mettere comunque le tue DLL in \ system32 \! Modifica il tuo codice, modifica il tuo programma di installazione ... trova una casa per i tuoi bit che NON è da nessuna parte in c: \ windows \

Ad esempio, il tuo programma di installazione inserisce le tue dll in:

\program files\<your app dir>\

or

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

( Nota : il modo in cui lo si fa effettivamente è utilizzare l'ambiente var:% ProgramFiles% o% ProgramFiles (x86)% per trovare dove si trova Program Files .... non si assume che sia c: \ program files \ .. ..)

e quindi imposta un tag di registro:

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

Il codice che utilizza le DLL legge il registro, quindi si collega dinamicamente alle DLL in quella posizione.

Quanto sopra è il modo intelligente di andare.

Non installi mai le tue dll o dll di terze parti in \ system32 \ o \ syswow64. Se devi caricare staticamente, metti le tue dll nella tua directory exe (dove saranno trovate). Se non riesci a prevedere la directory exe (es. Qualche altra exe chiamerà la tua dll), potresti dover inserire la tua dir dll nel percorso di ricerca (evitalo se possibile!)

system32 e syswow64 sono per i file forniti da Windows ... non per i file di qualcun altro . L'unica ragione per cui la gente ha preso la cattiva abitudine di mettere cose lì è perché è sempre nel percorso di ricerca e molte app / moduli usano collegamenti statici. (Quindi, se ci si arriva davvero, il vero peccato è il collegamento statico - questo è un peccato nel codice nativo e nel codice gestito - sempre sempre sempre link dinamico!)

Ho affrontato lo stesso problema e ho studiato questo per alcuni minuti.

Mi hanno insegnato a usare Windows 3.1 e DOS, ricordi quei giorni? Poco dopo ho lavorato rigorosamente con i computer Macintosh per qualche tempo, poi ho iniziato a tornare su Windows dopo aver acquistato una macchina a 64 bit.

Ci sono ragioni reali dietro questi cambiamenti (alcuni direbbero un significato storico), che sono necessari per i programmatori per continuare il loro lavoro.

La maggior parte delle modifiche sono menzionate sopra:

• Program Files vs Program Files (x86)

  All'inizio sono stati scritti i file a 16/86 bit, processori Intel '86'.

• System32significa davvero System64(su Windows a 64 bit)

  Quando gli sviluppatori hanno iniziato a lavorare con Windows 7, c'erano diversi problemi di compatibilità in cui erano archiviate altre applicazioni.

• SysWOW64 significa davvero SysWOW32

  In sostanza, in parole povere, significa "Windows su Windows all'interno di una macchina a 64 bit" . Ogni cartella indica dove si trovano le DLL per le applicazioni che desiderano utilizzarle.

Ecco due link con tutte le informazioni di base necessarie:

• Reindirizzamento del file system MSDN

• Spiegato SysWow64

Mi auguro questo chiarisca tutto!

System32 è dove Windows posizionava storicamente tutte le DLL a 32 bit e il sistema era per le DLL a 16 bit. Quando Microsoft ha creato il sistema operativo a 64 bit, tutti quelli che conosco si aspettavano che i file risiedessero in System64, ma Microsoft ha deciso che era più logico inserire file a 64 bit in System32. L'unico ragionamento che sono stato in grado di trovare è che volevano che tutto ciò che era a 32 bit funzionasse in un Windows a 64 bit senza dover cambiare nulla nei programmi - solo ricompilare, ed è fatto. Il modo in cui hanno risolto questo problema, in modo che le applicazioni a 32 bit potessero ancora essere eseguite, è stato quello di creare un sottosistema Windows a 32 bit chiamato Windows32 su Windows64. Pertanto, l'acronimo SysWOW64 è stato creato per la directory di sistema del sottosistema a 32 bit. Sys è l'abbreviazione di System e WOW64 è l'abbreviazione di Windows32OnWindows64.
Poiché Windows 16 è già separato da Windows 32, non è stata necessaria un'equivalenza di Windows 16 su Windows 64. All'interno del sottosistema a 32 bit, quando un programma utilizza i file dalla directory system32, in realtà ottengono i file dalla directory SysWOW64. Ma il processo è imperfetto.

È un design orribile. E nella mia esperienza, ho dovuto apportare molte più modifiche per la scrittura di applicazioni a 64 bit, che semplicemente cambiare la directory System32 per leggere System64 sarebbe stato un cambiamento molto piccolo, e quello che le direttive pre-compilatore sono destinate a gestire.

Altre persone hanno già fatto un buon lavoro nel spiegare questo enigma del ridicolo ... e penso che Chris Hoffman abbia fatto un lavoro ancora migliore qui: https://www.howtogeek.com/326509/whats-the-difference-b Between-the- system32-e-syswow64-cartelle-in-windows /

I miei due pensieri:

1. Tutti commettiamo stupidi errori miopi nella vita. Quando Microsoft ha chiamato la sua directory (allora) DLL Win32 "System32", allora aveva senso ... semplicemente non hanno preso in considerazione cosa accadrebbe se / quando una versione a 64 bit (o 128 bit) del loro sistema operativo è stato sviluppato in seguito - e il grave problema di compatibilità con le versioni precedenti causerebbe un tale nome di directory. Il senno di poi è sempre 20-20, quindi non posso davvero biasimarli (troppo) per un simile errore. ... TUTTAVIA ... Quando Microsoft ha successivamente sviluppato il proprio sistema operativo a 64 bit, anche con il senno di poi, perché oh perché non avrebbero commesso ANCORA lo stesso identico errore miope ma lo avrebbero persino peggiorato dando è un nome così fuorviante?!? Che si vergognino!!! Perché non ALMENO in realtà nominare la directory "SysWin32OnWin64" per evitare confusione ?! ? E cosa succede quando alla fine producono un sistema operativo a 128 bit ... allora dove inseriranno le loro DLL a 32 bit, 64 bit e 128 bit?!?

2. Tutta questa logica mi sembra ancora completamente imperfetta. Nelle versioni a 32 bit di Windows, System32 contiene DLL a 32 bit; sulle versioni a 64 bit di Windows, System32 contiene DLL a 64 bit ... in modo che gli sviluppatori non debbano apportare modifiche al codice, giusto? Il problema con questa logica è che quegli sviluppatori ora stanno realizzando app a 64 bit che necessitano di DLL a 64 bit o stanno realizzando app a 32 bit che necessitano di DLL a 32 bit ... in entrambi i casi, non sono ancora fregati? Voglio dire, se stanno ancora realizzando un'app a 32 bit, affinché ora venga eseguita su una Windows a 64 bit, dovranno ora apportare una modifica del codice per trovare / fare riferimento alla stessa vecchia DLL a 32 bit che usato prima (ora si trova in SysWOW64). Oppure, se stanno lavorando su un'app a 64 bit, dovranno comunque riscrivere la loro vecchia app per il nuovo sistema operativo ... quindi sarebbe comunque necessaria una ricompilazione / ricostruzione !!

Microsoft mi fa solo male a volte.