Warum 64-Bit-DLLs zu System32 gehen und 32-Bit-DLLs SysWoW64 auf 64-Bit-Windows?

https://stackoverflow.com/questions/949959

09-09-2019
|

Frage

Ich würde gerne wissen, wann brauchen wir unter

eine Datei platzieren

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

Ich hatte zwei DLL, einen für 32-Bit, ein für 64-Bit.

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

Zu meiner Überraschung, es ist andersrum ! Die 32 -Bit geht man in C: \ Windows \ SYSWOW 64 und die 64 -Bit DLL geht in C: \ Windows \ System 32 .

Sehr verwirrend Sachen. Was ist der Grund dahinter?

Lösung

Ich glaube, die Absicht war System32 umbenannt, aber so viele Anwendungen hartcodiert für diesen Pfad, dass es nicht möglich war, es zu entfernen.

SysWoW64 nicht für die DLLs von 64-Bit-Systeme gedacht war, dann ist es tatsächlich so etwas wie „Windows auf Windows64“, die Bits bedeutet, dass Sie 32-Bit-Anwendungen auf einem 64-Bit-Windows ausgeführt werden müssen.

Dieser Artikel ein wenig erklärt:

"Windows x64 ein Verzeichnis System32 hat, die 64-Bit-DLLs enthält So nativen Prozesse mit einem Bitness von 64 Fund (sic!).‚Ihrem‘DLLs, wo sie sie erwarten:. In dem Ordner System32 Ein zweites Verzeichnis, SysWOW64, enthält die 32-Bit-DLLs. Das Dateisystem Redirector die Magie des Versteckens die reale System32-Verzeichnis für 32-Bit-Prozesse und zeigt SysWOW64 unter dem Namen System32 der Fall ist. "

Edit: Wenn Sie sprechen über einen Installer, die Sie wirklich sollte nicht fest einprogrammieren der Pfad zum Systemordner. Stattdessen lassen Sie Windows für Sie darum kümmern, basierend auf, ob Ihr Installationsprogramm auf der Emulationsschicht ausgeführt wird.

Andere Tipps

sollte ich hinzufügen: Sie sollten nicht Ihre DLL in \ system32 \ sowieso setzen! Ändern Sie den Code, ändern Sie Ihren Installateur ... ein Haus für Ihre Bits finden, die nicht überall unter c: \ windows \

Zum Beispiel Ihres Installateur bringt Ihren DLLs in:

\program files\<your app dir>\

or

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

( Hinweis : Die Art und Weise Sie tatsächlich tun ist es, die Umgebung verwenden var:% Programfiles% oder % Programfiles (x86)% zu finden, wo Program Files ist .... Sie nicht davon ausgehen, es ist c: \ program files \ ....)

und setzt dann einen Registrierungs Tag:

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

Der Code, der verwendet Ihre DLLs der Registrierung liest, dann verbindet sich dynamisch an die DLLs in diesem Ort.

Das oben ist die intelligente Art und Weise zu gehen.

Sie nicht installieren immer Ihr DLLs oder Dritten dlls in \ system32 \ oder \ syswow64. Wenn Sie statisch geladen haben, setzen Sie Ihren DLLs in Ihrem exe dir (wo sie zu finden). Wenn Sie nicht die exe dir vorhersagen kann (zum Beispiel einige andere exe Ihre DLL rufen wird), können Sie Ihr dll dir in den Suchpfad setzen müssen (dies vermeiden, wenn bei allen mögl!)

system32 und syswow64 sind für Windows-Dateien zur Verfügung gestellt ... nicht für jedermann elses Dateien . Die einzige Grund, warum die Leute kamen in die schlechte Gewohnheit, dass Sachen gibt es, weil es immer im Suchpfad ist, und viele apps / Module verwenden statische Linken. (Also, wenn Sie wirklich, um es nach unten, die wirkliche Sünde ist das statische Linken - das ist eine Sünde in nativen Code und verwalteten Code - immer immer immer dynamisch verknüpfen)

lief in das gleiche Problem und erforscht diese für ein paar Minuten.

wurde ich gelehrt Windows 3.1 und DOS zu verwenden, jene Tage erinnern? Kurz nachdem ich mit Macintosh-Computern ausschließlich für einige Zeit gearbeitet, dann begann wieder zu Windows schwanken, nachdem eine 64-Bit-Maschine zu kaufen.

Es gibt tatsächlich Gründe für diese Änderungen (manche würden sagen historische Bedeutung), die notwendig sind für Programmierer ihre Arbeit fortzusetzen.

Die meisten Änderungen sind oben erwähnt:

Program Files vs Program Files (x86)

Am Anfang der 16 / 86bit-Dateien geschrieben wurden, '86' Intel-Prozessoren.
System32 wirklich bedeutet System64 (auf 64-Bit-Windows)

Wenn Entwickler zunächst mit Windows7 zu arbeiten begann, gab es mehrere Kompatibilitätsprobleme in denen andere Anwendungen, bei denen gespeichert.
SysWOW64 wirklich bedeutet SysWOW32

Im Wesentlichen in einfachem Englisch, es bedeutet "Windows on Windows in einer 64-Bit-Maschine . Jeder Ordner anzeigt, wo die DLLs für Anwendungen befinden sie sie wollen, sie nutzen.

Hier sind zwei Links mit allen grundlegenden Informationen, die Sie brauchen:

Hope this löscht Dinge!

System32 ist, wo historisch von Windows alle 32-Bit-DLLs platziert und System war für die 16-Bit-DLLs. Wenn Microsoft die 64-Bit-OS erstellt, jeder, den ich kenne, die Dateien erwartet unter System64 zu wohnen, aber Microsoft entschied es sinnvoller, 64-Bit-Dateien unter System32 setzen gemacht. Die einzige Begründung ich in der Lage gewesen zu finden, ist, dass sie alles wollte die 32-Bit war in einem 64-Bit-Windows-w / o ändern zu müssen etwas in den Programmen zu arbeiten - nur neu kompiliert werden, und es ist getan. Die Art, wie sie diese gelöst, so dass die 32-Bit-Anwendungen noch laufen können, war ein 32-Bit-Windows-Subsystem auf Windows64 genannt Windows32 zu erstellen. Als solches ist das Akronym SysWOW64 wurde für das Systemverzeichnis der 32-Bit-Subsystem erstellt. Das Sys ist die Abkürzung für System und WOW64 ist die Abkürzung für Windows32OnWindows64.
Seit 16 Fenstern bereits aus dem Windows getrennt 32, gab es keine Notwendigkeit für ein 16 Windows Auf Windows 64 Gleichwertigkeit. Innerhalb der 32-Bit-Subsystem, wenn ein Programm-Dateien aus dem Verzeichnis system32 verwenden geht, bekommen sie tatsächlich die Dateien aus dem SysWOW64-Verzeichnis. Aber der Prozess ist fehlerhaft.

Es ist ein schreckliches Design. Und nach meiner Erfahrung, ich hatte für das Schreiben von 64-Bit-Anwendungen viel mehr Veränderungen zu tun, das einfach das System32-Verzeichnis zu ändern System64 zu lesen eine sehr kleine Änderung gewesen wäre, und eine, die Pre-Compiler-Direktiven sollen handhaben.

Andere Leute haben bereits einen guten Job zu erklären, dieses ridiculus conundrum getan ... und ich denke, Chris Hoffman eine noch bessere Arbeit geleistet hat hier: https://www.howtogeek.com/326509/whats-the-difference-between-the- system32-and-syswow64-Ordner-in-Fenster /

Meine zwei Gedanken:

Wir alle dumm kurzsichtig Fehler im Leben machen. Wenn Microsoft nannte sie (zu der Zeit) Win32-DLL-Verzeichnis „System32“, machte es Sinn, zu der Zeit ... nehmen sie einfach nicht in Betracht, was passieren würde, wenn / wenn eine 64-Bit (oder 128-Bit) Version ihr O wurde später entwickelt - und das massive abwärts~~POS=TRUNC Thema wie ein Verzeichnisname verursachen würde. Hinterher ist immer 20-20, also kann ich sie nicht wirklich die Schuld (zu viel) für einen solchen Fehler. ... ABER ... Wenn Microsoft später wurde ihr 64-Bit-Betriebssystem entwickeln, auch mit im Nachhinein, warum oh warum sollen sie denselben kurzsichtig Fehler wieder nicht nur die genauen machen, aber es noch schlimmer durch gezielten machen geben es eine solche irreführende Name?!? Schande über sie!!! Warum nicht MINDESTENS nennt tatsächlich das Verzeichnis „SysWin32OnWin64“, um Verwirrung zu vermeiden?!? Und was passiert, wenn sie schließlich ein 128-Bit-OS produzieren ... wo dann werden sie setzen ihre 32-Bit, 64-Bit und 128-Bit-DLLs?!?
Alle diese Logik scheint noch völlig fehlerhaft zu mir. Auf 32-Bit-Versionen von Windows, System32 enthält 32-Bit-DLLs; auf 64-Bit-Versionen von Windows, System32 enthält 64-Bit-DLLs ... so dass Entwickler nicht Code-Änderungen würden machen, richtig? Das Problem mit dieser Logik ist, dass die Entwickler sind entweder jetzt machen 64-Bit-Anwendungen 64-Bit-DLLs benötigen oder sie machen 32-Bit-Anwendungen 32-Bit-DLLs benötigen ... oder so, sind sie nicht noch geschraubt? Ich meine, wenn sie immer noch eine 32-Bit-app zu machen, denn es ist nun auf einem 64-Bit-Windows ausgeführt werden, werden sie jetzt ein Code Änderung vornehmen müssen, um finden / verweisen auf die gleiche ol‘32-Bit-DLL sie vor (jetzt in SysWOW64 gelegen) verwendet. Oder, wenn sie auf einer 64-Bit-Anwendung arbeiten sind, werden sie brauchen, um ihre alte App für das neue Betriebssystem ohnehin neu zu schreiben ... so eine erneute Kompilierung / rebuild würde ohnehin benötigt werden !!!

Microsoft tut mir weh, nur manchmal.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow