32bit-DLL mit LoadLibrary auf einem 64bit-System laden?

[EWeiss]

Zitat:

ich habe eine DLL, mit der ich über USB Befehle an ein Messgerät sende.

Ich denke mal das es um diese DLL geht.

Wenn das der Fall ist dann wird unter einem 64Bit System eine 64Bit.dll (Treiber für das USB Gerät) geladen und nicht eine 32Bit.
Das ist der Grund warum die DLL nicht gefunden wird.

gruss

[SearchBot]

Gut aufgepasst

Der Hersteller hat auch Treiber mitgeliefert "win32at64bit", diese hab ich dann auch installiert; die DLL, die ich nutze, ist aus den Beispielen und gibt es in keiner anderen Version. Interessanterweise hat das Meldungsfenster jetzt keinen Inhalt mehr

Mit welchen Problemen hätte ich zu rechnen, wenn ich den kompletten Quelltext auf einem 64bit-Delphi kompilieren wollte?
Die 32bit-DLL könnte ich dann wohl trotzdem nicht laden, oder!?

Edit:
Warum greift das WOW64-System nicht bzw. wie kann man es motivieren?

[OlafSt]

Eine 64Bit-Anwendung erfordert zwingend 64Bit-DLLs.

Kannst also aufhören, es zu versuchen.

[EWeiss]

Zitat von OlafSt:

Eine 64Bit-Anwendung erfordert zwingend 64Bit-DLLs.

Kannst also aufhören, es zu versuchen.

Nicht unbedingt...
Es gäbe die Möglichkeit mit einer zwischengeschalteten 32Bit Anwendung auch eine 64Bit Anwendung über IPC WM_COPYDATA 32Bit Dll's anzusprechen.

Ob das mit Treiber Dll's möglich ist habe ich noch nicht probiert.
Hingegen bei normalen DLL's (keine Treiber) ist das sehr wohl machbar.

gruss

[Dalai]

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).

Sofern aber weitere DLLs zum Zugriff mitgeliefert wurden bzw. vorhanden sind, wie es z.B. bei der Windows API (z.B. shell32.dll) der Fall ist, sehe ich kein Problem. Daher mein Tip: untersuche die DLL, um die es geht, genauer mit einem PE Analysetool, z.B. FileAlyzer o.ä.

MfG Dalai

[Assarbad]

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.

Zitat von Dalai:

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.

Zitat von EWeiss:

Du kannst über eine 32Bit Schnittstelle nicht mit einen 64Bit Treiber kommunizieren.

Wetten daß doch?!

Zitat von EWeiss:

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.

Zitat von SearchBot:

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.

[EWeiss]

Zitat:

Wetten daß doch?!

JO? Möchte ich schwer bezweifeln und den Beweis dafür antreten.

Ich habe eine 64Bit DLL geschrieben bzw. für ein 64Bit Betriebssystem verfügbar gemacht (Die gab es vorher nur in 32Bit)
Diese integriert sich in den Eigenschaften Dialog von *.mp3 Dateien im System 64Bit.

Wenn das so klappt wie du sagst warum werden dann diese Eigenschaften nicht mehr erkannt wenn ich
versuche eine Datei mit einer 32Bit Anwendung zu öffnen bzw. davon die Eigenschaften anzeigen zu lassen ?

Weder werden die Icons noch die Eigenschaften der Datei im *.mp3 (Eigenschaften Dialog) angezeigt.
Der Grund ist einfach eine Kommunikation findet nicht statt weil ich versuche mit einer 32Bit Anwendung eine 64Bit DLL zu laden.

Siehe Anhang.. Das sagt alles.
Ich habe dir also einen Sichtbaren beweis erbracht das es nicht geht..

Nebenbei! Und ja ich registriere diese Datei selbst mit meiner 32Bit Anwendung so das diese DLL dem System zur verfügung steht.
Sie funktioniert aber nicht mit einer 32Bit Anwendung. Unabhängig davon ob ich sie ansprechen\registrieren kann oder nicht!

Zitat:

Aber dann sah ich so seltsame Behauptungen, denen ich noch entgegentreten will, da sie unwahr und falsch sind.

Nun was ist unwahr und falsch?
Beweise mir das Gegenteil dann reden wir weiter.

Ja ich kann sie laden/registrieren usw.. das ist aber nicht gleichzusetzen das sie auch funktioniert mit einer 32Bit Anwendung.

gruss

[SearchBot]

Zitat von OlafSt:

Eine 64Bit-Anwendung erfordert zwingend 64Bit-DLLs.

Kannst also aufhören, es zu versuchen.

Ja, das weiß ich. Es ist ja auch eine 32bit-Anwendung auf einem 64bit-System. Folglich würde im Hintergrund das WoW64-System aktiv sein, wie ich jetzt gegoogelt habe. Und ich weiß auch, daß 64bit-DLLs nicht mit 32bit-Anwendungen zusammenarbeiten. Daher habe ich ja auch eine 32bit-DLL mit meiner 32bit-Anwendung im Einsatz, allerdings auf einem 64bit-System...

Zitat von EWeiss:

Nicht unbedingt...
Es gäbe die Möglichkeit mit einer zwischengeschalteten 32Bit Anwendung auch eine 64Bit Anwendung über IPC
und WM_COPYDATA 32Bit Dll's anzusprechen.

Ob das mit Treiber Dll's möglich ist habe ich noch nicht probiert.
Hingegen bei normalen DLL's (keine Treiber) ist das sehr wohl machbar.

gruss

Ich habe nochmal die DLL angesehen - es ist eigentlich kein Treiber, sondern eine Schnittstelle zum Treiber (den ich in der x86at64bit-Version (weiß nicht, ob ich den richtigen Begriff dazu verwende) installiert hab). Wenn ich die DLL austausche, geht es trotzdem nicht.

In der x86at64bit-Version, die das Hersteller-Treibersetup im "C:\Program Files (x86)" installiert hat, steht der String
6f1ea56521e5ead1af5152081ea42a971ddbb85c78cbf3.WD1011_64_NL_Newport im Vergleich zu
6f1ea7e7635967b1d4fec0f13548d3b1f10f6484144339.WD1011_32_NL_Newport in der win32-Version, die ich bisher einwandfrei auf meinem 32bit-System genutzt habe.

Und soeben schrieb mir

Zitat von Dalai:

... Daher mein Tip: untersuche die DLL, um die es geht, genauer mit einem PE Analysetool, z.B. FileAlyzer o.ä.

Worauf müsste ich da speziell achten?

[Dalai]

Zitat von SearchBot:

Worauf müsste ich da speziell achten?

Lad die DLL im Tool und wirf einen Blick auf die Architektur bzw. Machine. Das ist je nach benutztem Tool unterschiedlich benannt. Bei FileAlyzer ist es auf der Registerkarte "PE Header" zu finden; entweder steht dort "Machine: 64-bit Windows (AMD)" oder "Machine: Intel 386".

[EDIT]
Achso, eine Sache noch: DLLs haben genau wie Programme (EXE) Abhängigkeiten. Die sollte man sich ebenfalls anschauen, ob die allesamt erfüllt sind. Sonst schlägt das Laden einer DLL ebenfalls fehl. Bei FileAlyzer findet man das auf der Registerkarte "PE Imports".
[/EDIT]

MfG Dalai

[EWeiss]

Also Nochmal!

Zitat:

Alle Hardwaregeräte benötigen 64-Bit-Treiber, um mit einer 64-Bit-Version von Windows funktionsfähig zu sein.

Selbst dann wenn deine Anwendung 32Bit und die Schnittstelle (API) in 32Bit ausgelegt ist.
Du kannst über eine 32Bit Schnittstelle nicht mit einen 64Bit Treiber kommunizieren.
Da hilft auch ein Austauschen nichts.

Das Hardwaregerät wird ohne 64Bit Treiber nicht funktionieren.

gruss