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

[jaenicke]

64 Bit geht erst ab XE2.

Mit dem Process Monitor solltest du aber wie gesagt schnell weiterkommen.

[SearchBot]

Ich hab mir jetzt das Trial von Delphi 10.1 installiert und das Tool mit 64bit compiliert.
:coder2:
Jetzt meint das Ding beim Laden der DLL: "%1 ist keine zulässige win32-Anwendung".:pale:
Häää?

:wall:-schnauze voll-:kotz:

Ich hab jetzt ein seriell-auf-USB-Adapter an das Messgerät gesteckt, Treiber für diesen COM-Port-Adapter installiert, mit TComPort-Komponente Verbindung gelegt... - läuft!

Danke für eurer Mitdenken :thumb:

[jaenicke]

Zitat:

Zitat von SearchBot (Beitrag 1339193)

Jetzt meint das Ding beim Laden der DLL: "%1 ist keine zulässige win32-Anwendung".:pale:
Häää?

Was erst Recht dazu passt, dass da falsche DLLs im Pfad gefunden werden, weshalb ich bei sowas eben auch immer mit dem Process Monitor schaue.

Aber wenn es jetzt läuft, ist ja gut. :)

[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:

Zitat von Dalai (Beitrag 1338937)

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:

Zitat von EWeiss (Beitrag 1338944)

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

Wetten daß doch?!

Zitat:

Zitat von EWeiss (Beitrag 1338944)

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:

Zitat von SearchBot (Beitrag 1339007)

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

[Neutral General]

Zitat:

Zitat von EWeiss (Beitrag 1347064)

Zitat:

Wetten daß doch?!

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

Sehr mutig Assarbad zu widersprechen :mrgreen:
Kann zum Thema selbst nicht wirklich was beitragen, aber mich würd interessieren was am Ende rauskommt :)

[himitsu]

Diese DLL wird beim Windows Explorer registriert und da der in Windows 64 auch 64 Bit ist, kann er auch nur Eplorer-Plugins laden, welche ebenfalls 64 Bit sind,
bzw. in Windows 32 nur 32 Bit-DLLs.


Das hat aber nichts mit Treibern oder Ressourcen-DLLs zu tun.


Das Einzige, wo sich solche DLLs in der Bittigkeit unterscheiden dürfen ist bei solchen Out-Of-Process COM Servern, wo die DLL nicht im eigenen Prozess geladen wird, sondern in einem externen DLLHost ... da nimmt die COM-Schnittstelle dann die Verbindung/Datenkonvertierung/-übertragung vor.

[EWeiss]

Zitat:

Zitat von Neutral General (Beitrag 1347071)

Zitat:

Zitat von EWeiss (Beitrag 1347064)

Zitat:

Wetten daß doch?!

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

Sehr mutig Assarbad zu widersprechen :mrgreen:
Kann zum Thema selbst nicht wirklich was beitragen, aber mich würd interessieren was am Ende rauskommt :)

Habe ich kein Problem mit ist auch NUR ein Mensch ;)

Mich auch aber es ist doch ersichtlich Oder?
Das laden einer Library von einer 32Bit Anwendung ist nicht gleichzusetzen mit der Funktion ob diese DLL dann mit 32Bit Anwendung kommunizieren kann.
Das habe ich wohl ausreichend dokumentiert das es NICHT geht.

gruss

[EWeiss]

Zitat:

Zitat von himitsu (Beitrag 1347074)

Falsch.

Diese DLL wird beim Windows Explorer registriert und da der in Windows 64 auch 64 Bit ist, kann er auch nur Plugins laden, welche ebenfalls 64 Bit sind,
bzw. in Windows 32 nur 32 Bit-DLLs.


Das hat aber nichts mit Treibern oder Ressourcen-DLLs zu tun.

Falsch!
Ich registriere sie selbst.. mit meiner 32Bit Anwendung.

Würde ich es nicht tun könntest du den Tab in den Eigenschaften Dialog gar nicht erst sehen.

Ich beziehe mich darauf.

Zitat:

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

Ob es nun ein Treiber oder eine normale 64Bit DLL ist spielt dabei jetzt keine rolle.
Noch deutlicher als mit Bildern kann man es nicht widergeben.
Wenn das jemand nicht sieht braucht er eine Brille.

gruss

[Dalai]

Zitat:

Zitat von EWeiss (Beitrag 1347064)

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 ?

Ganz einfach: Hier wird kein Interface verwendet sondern eine Shell Extension. Shell Extensions sind DLLs, die logischerweise immer nur von Prozessen der passenden Architektur geladen werden können. Deshalb liefern viele Anwendungen zwei Shell Extensions mit, eine für 32 bit und eine für 64 bit, oft unabhängig von der Architektur der Anwendung selbst.

Grüße
Dalai