Windows 64 Bit Verhau...



  • OK, ich verstehe es nicht, vielleicht kann mich hier einer aufklären: Wenn ich unter einem 64-Bit-Windows eine 32-Bit-Applikation installiere, hätte ich gedacht, dass die zugehörigen DLLs in SYSTEM32 landen (weil 32 -> 32 Bit -> logisch).

    Dem ist aber NICHT so, tatsächlich werden die 32-Bit-DLLs nach SYSWOW64 installiert. Was soll das denn? Und vor allem: wo würden echte 64-Bit-DLLs landen - etwa in SYSTEM32?

    Ich bin für jede Erhellung dankbar 🙂





  • Kirkenes schrieb:

    Und vor allem: wo würden echte 64-Bit-DLLs landen - etwa in SYSTEM32?

    Ja, genau. Der verlinkte Artikel erklärt das.

    Fand ich auch – gelinde gesagt – etwas unintuitiv.



  • nman schrieb:

    Fand ich auch – gelinde gesagt – etwas unintuitiv.

    Ich frage mich auch langsam, was die eingeschmissen haben, als die auf diese Idee gekommen sind. Der Irrsinn geht - wie ich inzwischen rausgefunden habe - nämlich noch weiter: eine 64-Bit-DLL verlinkt nach diesem Quatsch nach z.B. system32/kernel32.dll. Diese kernel32.dll ist dann tatsächlich aber die 64-Bit Version.



  • Das eigentliche Problem ist, daß man 1993, bei der Einführung von Win32, überhaupt dieses "32"-Suffix hinzugefügt hat. 16-Bit-Code konnte zwar halbwegs leicht nach Win32 portiert werden, aber ohne breaking changes im Windows-API ging es nicht. 64-Bit-Windows verwendet aber immer noch das Win32-API ohne großartige Änderungen.

    Heute ist der PE-Loader ja schlau genug, bei gleichnamigen 32- und 64-Bit-DLLs im Pfad die jeweils passende zu laden. Ich nehme an, daß einer der Gründe für den Suffix damals war, daß man unter Win9x 16- und 32-Bit-Code in einem Prozeß mischen konnte (anders als 32- und 64-Bit-Code), so daß man schon irgendeine Distinktion zwischen den alten und neuen DLLs einführen mußte. Aber "KernelEx.dll" wäre trotzdem besser gewesen.

    Was also tun, da es nun Unmengen von Code gibt, der an sich trival nach 64-Bit-Windows portierbar ist, in dem aber viele Aufrufe à la GetProcAddress("kernel32.dll", ...) versteckt sind? Oder P/Invokes? Desgleichen mit Installer-Skripten, in denen "System32" hartkodiert ist? Soll man die 64-Bit-DLLs und die Ordner ordentlich mit "64" suffizieren und die Programmierer alle zu #ifdef _M_AMD64 -Orgien zwingen? (Und was machen wir dann bei den P/Invokes in einer Anwendung, die mit "AnyCPU"-Target kompiliert wird? #ifdef jedenfalls nicht, das greift ja schon zur Übersetzungszeit) Oder einfach alle DLLs weiterhin "*32.dll" nennen und ein paar Tricks im PE-Loader (s.o.) und im WoW64-Layer einführen, damit sowohl 32- als auch 64-Bit-Programme denken, ihre System-DLLs würden in System32 liegen? Das irritiert halt solche Leute, die meinen, sie müßten in den Innereien des Systems rumstochern; und zugegeben schafft es zusätzliche Komplexität, wenn man einen 32-Bit-Installer für 64-Bit-Software verwendet. Aber abgesehen davon funktioniert es doch erstaunlich reibungslos.


Anmelden zum Antworten