Warum werden 64-Bit-DLLs unter 64-Bit-Windows an System32 und 32-Bit-DLLs an SysWoW64 gesendet?

Ich würde gerne wissen, wann wir eine Datei unter platzieren müssen

C: \ Windows \ System32 oder C: \ Windows \ SysWOW64 auf einem 64-Bit-Windows-System.

Ich hatte zwei DLLs, eine für 32-Bit, eine für 64-Bit.

Logischerweise dachte ich, ich würde die 32-Bit-DLL unter C: \ Windows \ System32 und die 64-Bit-DLL unter C: \ Windows \ SysWOW64 platzieren.

Zu meiner Überraschung ist es umgekehrt ! Die 32- Bit-DLL geht in C: \ Windows \ SysWOW 64 und die 64- Bit-DLL in C: \ Windows \ System 32 .

Sehr verwirrendes Zeug. Was ist der Grund dafür?

Ich glaube, die Absicht war, System32 umzubenennen, aber so viele Anwendungen, die für diesen Pfad fest codiert sind, dass es nicht möglich war, ihn zu entfernen.

SysWoW64 war nicht für die DLLs von 64-Bit-Systemen gedacht, es ist eigentlich so etwas wie "Windows unter Windows64", dh die Bits, die Sie benötigen, um 32-Bit-Apps unter 64-Bit-Fenstern auszuführen.

Dieser Artikel erklärt ein bisschen:

"Windows x64 hat ein Verzeichnis System32, das 64-Bit-DLLs enthält (sic!). Daher finden native Prozesse mit einer Bitness von 64" ihre "DLLs dort, wo sie sie erwarten: im System32-Ordner. Ein zweites Verzeichnis, SysWOW64, enthält die 32 -bit DLLs. Der Dateisystem-Redirector macht die Magie, das echte System32-Verzeichnis für 32-Bit-Prozesse auszublenden und SysWOW64 unter dem Namen System32 anzuzeigen. "

Bearbeiten: Wenn Sie über ein Installationsprogramm sprechen, sollten Sie den Pfad zum Systemordner nicht fest codieren. Lassen Sie stattdessen Windows für Sie erledigen, je nachdem, ob Ihr Installationsprogramm auf der Emulationsebene ausgeführt wird oder nicht.

Ich sollte hinzufügen: Sie sollten Ihre DLLs sowieso nicht in \ system32 \ ablegen! Ändern Sie Ihren Code, ändern Sie Ihr Installationsprogramm ... finden Sie unter c: \ windows \ ein Zuhause für Ihre Bits, das sich NICHT irgendwo befindet

Zum Beispiel legt Ihr Installationsprogramm Ihre DLLs ab in:

\program files\<your app dir>\

or

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

( Hinweis : Die Art und Weise, wie Sie dies tatsächlich tun, besteht darin, die Umgebung var:% ProgramFiles% oder% ProgramFiles (x86)% zu verwenden, um herauszufinden, wo sich die Programmdateien befinden. Sie gehen nicht davon aus, dass es sich um c: \ Programme \ handelt. ..)

und setzt dann ein Registrierungs-Tag:

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

Der Code, der Ihre DLLs verwendet, liest die Registrierung und verknüpft sie dann dynamisch mit den DLLs an diesem Speicherort.

Das Obige ist der kluge Weg.

Sie installieren niemals Ihre DLLs oder DLLs von Drittanbietern in \ system32 \ oder \ syswow64. Wenn Sie statisch laden müssen, legen Sie Ihre DLLs in Ihrem exe-Verzeichnis ab (wo sie gefunden werden). Wenn Sie das exe-Verzeichnis nicht vorhersagen können (z. B. wird eine andere exe Ihre DLL aufrufen), müssen Sie möglicherweise Ihr DLL-Verzeichnis in den Suchpfad einfügen (vermeiden Sie dies, wenn überhaupt möglich!).

system32 und syswow64 sind für Windows bereitgestellte Dateien ... nicht für andere Dateien . Der einzige Grund, warum die Leute die schlechte Angewohnheit hatten, Dinge dort abzulegen, ist, dass sie sich immer im Suchpfad befinden und viele Apps / Module statische Verknüpfungen verwenden. (Wenn Sie sich also wirklich darauf einlassen, ist die wahre Sünde die statische Verknüpfung - dies ist eine Sünde in nativem Code und verwaltetem Code - immer immer immer dynamisch verknüpfen!)

Bin auf dasselbe Problem gestoßen und habe dies einige Minuten lang untersucht.

Mir wurde beigebracht, Windows 3.1 und DOS zu verwenden. Erinnern Sie sich an diese Tage? Kurz nachdem ich einige Zeit ausschließlich mit Macintosh-Computern gearbeitet hatte, begann ich nach dem Kauf eines x64-Bit-Computers wieder zu Windows zurückzukehren.

Es gibt tatsächliche Gründe für diese Änderungen (einige würden sagen, historische Bedeutung), die notwendig sind, damit Programmierer ihre Arbeit fortsetzen können.

Die meisten Änderungen sind oben erwähnt:

• Program Files vs. Program Files (x86)

  Zu Beginn wurden die 16/86-Bit-Dateien auf '86'-Intel-Prozessoren geschrieben.

• System32bedeutet wirklich System64(unter 64-Bit-Windows)

  Als Entwickler zum ersten Mal mit Windows 7 arbeiteten, gab es verschiedene Kompatibilitätsprobleme, bei denen andere Anwendungen gespeichert wurden.

• SysWOW64 bedeutet wirklich SysWOW32

  Im Klartext bedeutet dies im Wesentlichen "Windows unter Windows auf einem 64-Bit-Computer" . Jeder Ordner gibt an, wo sich die DLLs für Anwendungen befinden, die sie verwenden möchten.

Hier sind zwei Links mit allen grundlegenden Informationen, die Sie benötigen:

• MSDN File System Redirector

• SysWow64 erklärt

Hoffe das klärt die Dinge auf!

In System32 hat Windows in der Vergangenheit alle 32-Bit-DLLs platziert, und System war für die 16-Bit-DLLs vorgesehen. Als Microsoft das 64-Bit-Betriebssystem erstellte, erwartete jeder, den ich kenne, dass sich die Dateien unter System64 befinden würden, aber Microsoft entschied, dass es sinnvoller war, 64-Bit-Dateien unter System32 abzulegen. Der einzige Grund, den ich finden konnte, ist, dass sie wollten, dass alles, was 32-Bit war, in einem 64-Bit-Windows funktioniert, ohne dass irgendetwas in den Programmen geändert werden muss - einfach neu kompilieren und fertig. Die Art und Weise, wie sie dies lösten, damit 32-Bit-Anwendungen weiterhin ausgeführt werden konnten, bestand darin, ein 32-Bit-Windows-Subsystem namens Windows32 unter Windows64 zu erstellen. Daher wurde das Akronym SysWOW64 für das Systemverzeichnis des 32-Bit-Subsystems erstellt. Das Sys steht für System und WOW64 für Windows32OnWindows64.
Da Windows 16 bereits von Windows 32 getrennt ist, war keine Windows 16-Äquivalenz unter Windows 64 erforderlich. Wenn ein Programm innerhalb des 32-Bit-Subsystems Dateien aus dem System32-Verzeichnis verwendet, erhält es die Dateien tatsächlich aus dem SysWOW64-Verzeichnis. Aber der Prozess ist fehlerhaft.

Es ist ein schreckliches Design. Und meiner Erfahrung nach musste ich viel mehr Änderungen vornehmen, um 64-Bit-Anwendungen zu schreiben. Das einfache Ändern des System32-Verzeichnisses zum Lesen von System64 wäre eine sehr kleine Änderung gewesen, die von Pre-Compiler-Anweisungen verarbeitet werden soll.

Andere Leute haben dieses lächerliche Rätsel bereits gut erklärt ... und ich denke, Chris Hoffman hat hier noch bessere Arbeit geleistet: https://www.howtogeek.com/326509/whats-the-difference-between-the- system32-and-syswow64-Ordner-in-Windows /

Meine zwei Gedanken:

1. Wir alle machen dumme kurzsichtige Fehler im Leben. Als Microsoft sein (zu der Zeit) Win32-DLL-Verzeichnis "System32" nannte, war es zu der Zeit sinnvoll ... sie haben einfach nicht berücksichtigt, was passieren würde, wenn / wenn eine 64-Bit- (oder 128-Bit-) Version von ihrem Betriebssystem wurde später entwickelt - und das massive Abwärtskompatibilitätsproblem, das ein solcher Verzeichnisname verursachen würde. Rückblick ist immer 20-20, also kann ich sie nicht wirklich (zu viel) für einen solchen Fehler verantwortlich machen. ... JEDOCH ... Als Microsoft später sein 64-Bit-Betriebssystem entwickelte, auch im Nachhinein, warum sollten sie nicht nur genau den gleichen kurzsichtigen Fehler WIEDER machen, sondern ihn durch gezieltes Geben noch schlimmer machen ist es so ein irreführender Name?!? Schande über sie!!! Warum nicht MINDESTENS das Verzeichnis "SysWin32OnWin64" nennen, um Verwirrung zu vermeiden?! ? Und was passiert, wenn sie irgendwann ein 128-Bit-Betriebssystem produzieren ... wo werden sie dann ihre 32-Bit-, 64-Bit- und 128-Bit-DLLs ablegen?!?

2. All diese Logik scheint mir immer noch völlig fehlerhaft zu sein. In 32-Bit-Versionen von Windows enthält System32 32-Bit-DLLs. Unter 64-Bit-Versionen von Windows enthält System32 64-Bit-DLLs ... damit Entwickler keine Codeänderungen vornehmen müssen, richtig? Das Problem mit dieser Logik ist, dass diese Entwickler jetzt entweder 64-Bit-Apps erstellen, die 64-Bit-DLLs benötigen, oder 32-Bit-Apps, die 32-Bit-DLLs benötigen ... Wie auch immer, sind sie nicht immer noch durcheinander? Ich meine, wenn sie noch eine 32-Bit-App erstellen, damit sie jetzt unter 64-Bit-Windows ausgeführt werden kann, müssen sie jetzt eine Codeänderung vornehmen, um dieselbe alte 32-Bit-DLL zu finden / zu referenzieren zuvor verwendet (jetzt in SysWOW64). Oder wenn sie an einer 64-Bit-App arbeiten, müssen sie ihre alte App für das neue Betriebssystem trotzdem neu schreiben ... also wäre sowieso eine Neukompilierung / Neuerstellung erforderlich !!

Microsoft tut mir nur manchmal weh.