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


227

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?


2
Inoltre, questo: Windows appare nella directory di lavoro corrente e nel PERCORSO di sistema. Non è possibile specificare diversamente. Oh aspetta, c'è. È possibile incorporare il percorso di ricerca nella DLL. È un campo lungo 8 byte. Sì. 8 caratteri.
Jeroen Baert,

Questo sembra non essere vero su Windows 7. Esecuzione di file su una DLL nel file system32 C: \ Windows \ system32 \ user32.dll C: \ Windows \ system32 \ user32.dll; Eseguibile PE32 per MS Windows (DLL) (GUI) Intel 80386 a 32 bit Ma per una DLL a 64 bit stampa eseguibile PE32 + per l'assemblaggio Mono / .Net di MS Windows (DLL) (console) Notare che questa DLL non è un .Net montaggio. È una DLL nativa.
user877329


11
Intervista con un ex Microsoftie . (Per una spiegazione seria di come è potuto accadere, vedi questa risposta .)
Tgr

superuser.com/a/157301/241386 "Ragioni di compatibilità all'indietro. Molte applicazioni presumono cose che non dovrebbero assumere e percorsi con codice fisso"
phuclv,

Risposte:


225

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.


27
Uff, ho appena incontrato questa stranezza oggi. Che cosa fuorviante che hanno fatto.
Andy White,

16
Ho affrontato anche questo oggi ... così confuso - Glut DLL a 32 bit entra in / SysWOW64, Glut DLL a 64 bit entra in / System32. Qualcuno dovrebbe scriverlo. Su internet.
Jeroen Baert,

8
La buona notizia è che, come esempio del genio ingegneristico di Microsoft, si tratta praticamente di auto-documentazione.
Spike0xff,

8
Una cosa che non capisco è, se il file system è in grado di dire che è un'app a 32 bit e reindirizzarla alla SysWOW64cartella, perché non potrebbero invece rilevare un'app a 64 bit e reindirizzare a un System64?!
Cole Johnson,

6
System32 è la versione di Windows a 32 bit delle DLL di sistema. Il sistema è la versione a 16 bit. La stessa azienda che ci ha fornito Windows 8 ci ha fornito SysWow64 per le DLL a 32 bit e System32 per le DLL a 64 bit durante l'esecuzione su un sistema operativo a 64 bit. Nei sistemi a 64 bit, la cartella di sistema è ancora la vecchia posta indesiderata a 16 bit, solo il System32 non è a 32 bit come suggerito e le cose a 32 bit si trovano nella directory di sistema con 64 nel nome. Non riesco a vedere come questo aiuti chiunque. complica le cose e rompe tutto. Tutto per salvare le persone dall'adattare "System32" su "System64" durante la conversione a 64 bit. Idiocy
Armand,

26

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


9
+1 ... ma aggiungerei che dovresti usare variabili come% PROGRAMFILES% non \ Programmi \
Rod MacPherson

Ai tempi di XP, era una pratica comune (e suggerita) per gli sviluppatori usare il registro per tali cose. Con Windows 7, questo non è più vero! Per motivi di controllo dell'account utente, sessioni utente multiple, ecc. Il registro in Windows 7 deve essere usato con parsimonia e con discrezione dagli sviluppatori.
Rykerker,

@RodMacPherson La mia risposta è stata migliorata per tenere conto del tuo suggerimento. Hai ragione!
Jonesome ripristina Monica il

Dopo alcune considerazioni, penso che questo risponda meglio alla domanda: "Quando dobbiamo posizionare un file in% SYSTEMROOT%". Mai. Questa risposta non soddisfa la curiosità sulla cartella syswow64, ma è quella che gli sviluppatori devono davvero leggere.
Thomas,

7

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:

Mi auguro questo chiarisca tutto!


4
Se vuoi essere preso sul serio, dovresti probabilmente attenuare il gergo e migliorare la grammatica. Inoltre, potresti voler strutturare un po 'di più la tua risposta, usare i paragrafi.
Klas Mellbourn,

2
@Crispy ha ripulito la risposta. In futuro, dovresti considerare ciò che Klas suggerisce e formattare la tua risposta per aumentare le possibilità di voti positivi. :)
RekindledPhoenix il

L'OP deve essere completamente riscritto o addirittura rimosso. È fuorviante e non molto utile.
Jonesome ripristina Monica il

5
SysWOW64 in realtà significa: [Sys] tem [W] indows 32-bit [o] n [W] indows [64] -bit quindi la forma abbreviata SysWoW64 (che non ha davvero senso, e Microsoft ha appena lasciato System32 per roba a 32 bit e creato un System64, in realtà non ci sarebbero problemi di compatibilità. Ciò che Microsoft fa nella sandbox di WoW è creare un reindirizzamento in memoria dall'accesso a 32 bit a System32 come richiesta a SysWoW64 ... come non è più complicato del semplice esporre il file system nel raw senza doverlo rimappare magicamente per le diverse piattaforme? Come notato in un precedente commento - Idiocy.
Armand

1
risposta porta più incomprensioni che chiarezza sulla domanda, il commento di Armands è una buona spiegazione.
nahab,

5

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.


2

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.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.