Eigentlich wollte ich nur antworten um zu erklären, daß man mit
LoadLibraryEx sehr wohl auch eine 32-bittige
DLL per Flag
LOAD_LIBRARY_AS_DATAFILE laden kann. Dann hat man allerdings keine
(triviale) Möglichkeit Code darin auszuführen, kann aber die exakt gleiche Ressourcen-
DLL sowohl für die 32-bit und 64-bit Variante seiner Anwendung benutzen.
Aber dann sah ich so seltsame Behauptungen, denen ich noch entgegentreten will, da sie unwahr und falsch sind. Aber ich sehe auch, daß Zacherl das auch schon vollkommen richtig angesprochen hat. Danke übrigens für den interessanten Link, Zacherl.
Man sollte hier DLLs von Treiber und Interface auseinanderhalten. Die DLLs vom Treiber entsprechen natürlich immer der Architektur des Systems, sind also 32 bittig auf einem x86 und 64 bittig auf einem x64 (bis auf Ausnahmen wie Co-Installer).
Das stimmt
so pauschal nicht. Das ist
üblich, aber keinesfalls erforderlich. Während der (KM-)Treiber immer der Architektur des Betriebssystemkernels entsprechen muß, kann eine 32-bittige
DLL (oder Anwendung oder anderer Code) durchaus auf einen 64-bit (KM-)Treiber zugreifen, wenn WOW64 existiert. Kurzum wenn ein Windows ein 32-bittiges Programm ausführen kann, kann dieses 32-bittige Programm auch mit Treibern schnacken.
Du kannst über eine 32Bit Schnittstelle nicht mit einen 64Bit Treiber kommunizieren.
Wetten daß doch?!
Das Hardwaregerät wird ohne 64Bit Treiber nicht funktionieren.
Genau. Mit der
DLL im Usermode hat das aber herzlich wenig zu tun. Wenn du nicht gerade sehr exotische Kommunikationsprotokolle zwischen dem Treiber und dem UM-Code benutzt [1], ist es unproblematisch für WOW64-Code mit einem 64-bittigen Treiber zu schnacken.
Das kann man sich auch ganz einfach veranschaulichen. Aufgrund der Architektur von Windows sind geladene Treiber gleichberechtigt mit dem Kernel. Kann ein 32-bittiges UM-Programm mit dem Kernel kommunizieren? Klar. Also gibt es keinen Grund warum das nicht auch für einen (KM-)Treiber gelten sollte.
Den Treiber gibt es in 64Bit und in "x32onx64".
Das würde dann auf einen UM-Treiber hinweisen. Für bestimmte Geräteklassen sind Treiber auch im Usermode (UM) möglich.
[1] Der Austausch von
Zeigern verbietet sich natürlich, ist aber ohne
MDL und das Sperren des Speichers ohnehin nicht sinnvoll machbar. Aber selbst auf die UM-Puffer auf welche die
IRPs bei DeviceIoControl, ReadFile und WriteFile verweisen können, sind von einem 64-bittigen Treiber zugreifbar. Wird aber
im Puffer ein Zeiger übertragen wird man sich Probleme einhandeln.