2016-04-19 9 views
2

Ich konvertierte ein altes Visual Studio-Projekt mit vs2015 und fügte eine 64-Bit-Plattform-Konfiguration hinzu.64bit Eigenschaftenblätter verwenden 32bit winapi dlls

Ich frage mich, warum die Linker-Attribute 32bit-Bibliotheken enthalten (wie kernel32.lib; user32.lib; gdi32.lib; winspool.lib; comdlg32.lib; advapi32.lib; shell32.lib; ole32.lib; oleaut32. lib).

Zuerst dachte ich, das ist ein Fehler von mir, da ich ausgewählt habe, die Einstellungen von den Win32-Plattform-Einstellungen zu kopieren, aber dann sah ich, dass diese Einstellungen von einem Eigenschaftsfenster importiert wurden, das vom Studio eingefügt wurde: "Microsoft.Cpp .x64.user "

Ist das wirklich die Art und Weise, wie dies funktionieren sollte? Ich habe irgendwo gelesen (hier auf SO: Can a 64 bit EXE link against 32-bit DLLs?), dass eine 64-Bit-App keine Verbindung zu 32-Bit-DLLs herstellen kann.

Kann mich jemand aufklären?

Antwort

4

Diese DLL-Namen stammen vor 23 Jahren, als die erste 32-Bit-Version von Windows veröffentlicht wurde. Windows-Versionen 1 bis 3 waren 16-Bit und verwendeten kernel.dll, user.dll und so weiter. Sie haben "32" nach dem DLL-Namen geklebt, um sie von den 16-Bit-Versionen zu unterscheiden, und stellen sicher, dass ein 32-Bit-Prozess nicht versehentlich eine 16-Bit-DLL laden kann.

Sie haben das nicht erneut getan, als sie die 64-Bit-Version von Windows veröffentlichten. Zu viele Programme haben diese Namen bis zu diesem Zeitpunkt fest codiert, normalerweise in einem LoadLibrary() - Aufruf, und das Ändern der Namen hätte es zu schwierig gemacht, solche Programme auf 64-Bit zu portieren. Nicht einmal das Verzeichnis, in dem diese DLLs gespeichert sind, wurde umbenannt, es ist immer noch "system32".

So hat ein Computer jetzt zwei Kopien von kernel32.dll et al, die 64-Bit-Version befindet sich in c: \ windows \ system32 und die 32-Bit-Version in c: \ windows \ syswow64. Es ist immer noch sehr wichtig, dass ein 32-Bit-Prozess nie versucht, eine 64-Bit-DLL zu laden, und umgekehrt, genau wie es vor 23 Jahren wichtig war. Sie haben also einen weiteren Trick gefunden, der File System Redirector stellt sicher, dass ein 32-Bit-Prozess die Kopie nur in syswow64 sehen kann.

Beachten Sie die Kuriosität von 64-Bit-DLLs in einem Verzeichnis namens "System32" und 32-Bit-DLLs in "syswow64". Zuerst lernen viele Programmierer, jetzt wissen Sie, wie das passiert ist.

Ähnlich wie bei den .lib-Dateien enthält das SDK-Verzeichnis ein x86- und ein x64-Verzeichnis zum Speichern dieser Dateien. Auch ziemlich automatisch, wo der Linker nach der .lib-Datei sucht, wird unter Projekt> Eigenschaften> VC++ - Verzeichnisse> Bibliotheksverzeichnisse konfiguriert. Ein Win32/x86-Plattformziel verwendet $ (WindowsSDK_LibraryPath_x86) und ein x64-Ziel verwendet $ (WindowsSDK_LibraryPath_x64).

+0

ahh - ok - ich verstehe. Ich war auch irritiert von der Abhängigkeit walker (2.1.xx), die zeigte, dass die exe 64bit ist, aber die abhängigen dlls nicht. Bei einer aktualisierten Version (2.2.xxx) werden die Abhängigkeiten auch als 64bit markiert - im Gegensatz zu ihren Namen (wie Sie auch erklärt haben) –

Verwandte Themen