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

[bra]

Zitat von Zacherl:

Das ist nicht ganz korrekt. Zumindest kann eine 32 Bit Anwendung "ohne Probleme" eine 64 Bit DLL laden. So funktioniert übrigens auch die ganze WOW64 Emulation.

Das wäre mir neu. Nicht umsonst gibt es unter Windows 64 Bit zwei unterschiedliche Verzeichnisse c:\Windows\system32 (64 Bit) und c:\Windows\SysWOW64 (32 Bit), bei denen die jeweilige DLL drinliegt.

PS: Man beachte vor allem die äußerst sinnvolle Benennung der Verzeichnisse unter Windows 64 Bit. Was MS da geraucht hat, möchte ich mal wissen.

[EWeiss]

Irgendwie wird hier was missverstanden.

Es geht hier um ein USB Gerät die Treiber sind nun mal aufgrund des Treibermodels von Windows zwingend auf 64Bit ausgelegt.
Da kann man tricksen wie man will.

gruss

[Zacherl]

Zitat von bra:

Das wäre mir neu. Nicht umsonst gibt es unter Windows 64 Bit zwei unterschiedliche Verzeichnisse c:\Windows\system32 (64 Bit) und c:\Windows\SysWOW64 (32 Bit), bei denen die jeweilige DLL drinliegt.

Hast du den Artikel gelesen?

Zitat von EWeiss:

Irgendwie wird hier was missverstanden.

Es geht hier um ein USB Gerät die Treiber sind nun mal aufgrund des Treibermodels von Windows zwingend auf 64Bit ausgelegt.
Da kann man tricksen wie man will.

Der Treiber muss 64-bit sein, aber die dazugehörige DLL, die die Kommunikation mit dem Treiber übernimmt, kann ja trotzdem als 32-bit Kompilat vorliegen.

[SearchBot]

Zitat von EWeiss:

Irgendwie wird hier was missverstanden.

Es geht hier um ein USB Gerät die Treiber sind nun mal aufgrund des Treibermodels von Windows zwingend auf 64Bit ausgelegt.
Da kann man tricksen wie man will.

gruss

Äh.. nein.
Das System ist 64bit.
Den Treiber gibt es in 64Bit und in "x32onx64".
Die Schnittstellen-DLL hat 32bit.
Es gibt auch eine mit 64bit, wie ich jetzt analysiert habe.
Beide jedoch sagen, wenn sie von meinem 32bit-Programm geladen werden sollen, daß die DLL nicht gefunden wird.

Zacherl macht mir Hoffungen

[Dalai]

Zitat von SearchBot:

Die Schnittstellen-DLL hat 32bit.
Es gibt auch eine mit 64bit, wie ich jetzt analysiert habe.
Beide jedoch sagen, wenn sie von meinem 32bit-Programm geladen werden sollen, daß die DLL nicht gefunden wird.

Dann analysiere doch mal die Abhängigkeiten, wie von mir im EDIT oben vorgeschlagen. Sonst kann man nur raten und im Nebel stochern. Neben dem genannten FileAlyzer ist Dependency Walker eine weitere Möglichkeit. Es gibt auch diverse Plugins für Total Commander (FileInfo und PE Viewer), die für eine simple Analyse ausreichen.

MfG Dalai

[jaenicke]

Die einfachste Variante wurde noch nicht genannt:
Nimm einfach den Process Monitor und schau nach was da versucht wird zu laden. Den Filter kannst du auf "Process Name" "is" "Deine Exe ohne Pfad" setzen, das war es.

Wenn dort weitere DLLs versucht werden zu laden oder ähnliches, wirst du das dort sehen. Und wenn die DLL an der falschen Stelle gesucht wird, siehst du das auch.

Das ist viel einfacher als die DLLs zu analysieren und feste Abhängigkeiten zu suchen.

Eine Möglichkeit:
Irgendwo liegt eine 64-Bit Version der Datei im Pfad. Ich weiß nicht, ob LoadLibrary dann weiter nach passenden Varianten sucht.

[bra]

Zitat von Zacherl:

Zitat von bra:

Das wäre mir neu. Nicht umsonst gibt es unter Windows 64 Bit zwei unterschiedliche Verzeichnisse c:\Windows\system32 (64 Bit) und c:\Windows\SysWOW64 (32 Bit), bei denen die jeweilige DLL drinliegt.

Hast du den Artikel gelesen?

Ich habe ihn mal überflogen und für mich klingt das ganze ziemlich Voodoomäßig. Wer weiss, wann einem das mal um die Ohren fliegt, weil sich die Zugriffsadressen ändern oder ähnliches... ich würde solche Hacks jedenfalls nur im absoluten Notfall nutzen.

[Zacherl]

Mit Zugriffsadressen hat das ja nichts zu tun und dass sich das Pseudo-Segment ändert, ist auch höchst unwahrscheinlich. Dennoch hast du natürlich recht, dass es ein Hack ist und ab Win8.1 V3 funktioniert das Prinzip sowieso nicht mehr ohne Weiteres, da eine neue Anti-Exploit Technologie als Seiteneffekt auch das Heaven Gate unbrauchbar macht.

Für den Threadersteller ist das Ganze wohl sowieso unerheblich, da er ja eine 32-Bit DLL besitzt. Vermutlich benötigt diese DLL lediglich eine bestimmte Version der C-Runtimes, weshalb er den File-not-found Error bekommt.

[SearchBot]

Hm..

die Beispiele vom Hersteller funktionieren auf 64bit auch nicht richtig... möglicherweise ein allgemeines Problem.

Mit dem FileAnalyzer erkenne ich jetzt nichts, was mir weiterhilft, aber interessant ist er allemal
Mit den anderen Tools will ich mich noch beschäftigen.

Wahrscheinlich wäre es das Beste, wenn ich mein Tool auf 64bit compilieren würde, dann läut es ohne wow64-Emulation und hat zu den richtigen DLLs Zugriff, oder?
Mit Delphi XE scheine ich aber keine 64-Bit Apps generieren zu können, oder habe ich was übersehen?

[Aviator]

Zitat von bra:

Das wäre mir neu. Nicht umsonst gibt es unter Windows 64 Bit zwei unterschiedliche Verzeichnisse c:\Windows\system32 (64 Bit) und c:\Windows\SysWOW64 (32 Bit), bei denen die jeweilige DLL drinliegt.

PS: Man beachte vor allem die äußerst sinnvolle Benennung der Verzeichnisse unter Windows 64 Bit. Was MS da geraucht hat, möchte ich mal wissen.

WOW64 bedeutet ja Windows On Windows 64. Also das 32-bit System. Den eigentlichen System32 Ordner hätte sie natürlich besser benennen können, das stimmt.