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

[SearchBot]

Hallo :wink:

Ich habe mit Delphi XE also eine 32bit-Anwendung auf meinem 32bit-System geschrieben.
Ich lese eine 32bit-DLL ein und alles ist gut.

Nun soll die Anwendung auf einem Windows7Pro 64bit-System ausgeführt werden.
Beim Laden meiner Anwendung (zu Beginn wird die DLL mit LoadLibrary geladen) sagt mir das System, daß es die DLL nicht findet.

Nun habe ich recherchiert und mit

Delphi-Quellcode:

extractfilepath(application.exename)+DLLname

den Pfad angegeben, damit es sie auch ganz sicher findet - sie ist ja sogar im gleichen Ordner wie die .exe !
Gleiche Meldung: DLL nicht gefunden! :pale:

Nun habe ich weiter geforscht, aber Google sucht mir da nicht richtig ("32bit dll in 64bit system loadlibrary delphi" - findet meist sowas wie '64bit-DLL in 32bit-App', oder für java...).

Wenn es über LoadLibrary nicht gehen würde, habe ich mir gedacht, die DLL "einfach" in die .exe als Resscource einzubinden und im Speicher zu starten, dann entfällt das LoadLibrary - so wie hier beschrieben. Das hätte ergänzend den Vorteil, daß die DLL nicht verloren geht :wink:

Aber bevor ich dieses KnowHow mühsehlig erlerne und dafür Stunden invenstiere... - bestehen hierzu überhaupt Aussichten auf Erfolg, daß das auch gelingt? Oder sollte ich in einer anderen Richtung weitersuchen, da ich die DLL nicht verändern kann?!

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

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:

Zitat von OlafSt (Beitrag 1338926)

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

[SearchBot]

Zitat:

Zitat von OlafSt (Beitrag 1338926)

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:

Zitat von EWeiss (Beitrag 1338929)

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

Delphi-Quellcode:

6f1ea56521e5ead1af5152081ea42a971ddbb85c78cbf3.WD1011_64_NL_Newport

im Vergleich zu

Delphi-Quellcode:

6f1ea7e7635967b1d4fec0f13548d3b1f10f6484144339.WD1011_32_NL_Newport

in der win32-Version, die ich bisher einwandfrei auf meinem 32bit-System genutzt habe.

Und soeben schrieb mir

Zitat:

Zitat von Dalai (Beitrag 1338937)

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

Zitat von SearchBot (Beitrag 1338938)

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

[Zacherl]

Zitat:

Zitat von OlafSt (Beitrag 1338926)

Eine 64Bit-Anwendung erfordert zwingend 64Bit-DLLs

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. Die System Dlls wie kernel32 sind in einer 64 Bit Anwendung sehr wohl geladen, nur kann die Anwendung diese nicht sehen, da sie in einem Speicherbereich > 32 Bit gemappt werden. Das 32 bittige kernel32 Äquivalent leitet die Aufrufe der Systemfunktionen dann nur noch auf den 64 Bit Code um, während gleichzeitig die CPU kurzzeitig in den 64 Bit Mode geschaltet wird.

Dieses kurzzeitige Umschalten kann man übrigens auch selbst machen:
http://rce.co/knockin-on-heavens-gat...ode-switching/

Ist allerdings nicht ganz trivial und sicherlich ziemlich hacky.

[bra]

Zitat:

Zitat von Zacherl (Beitrag 1338946)

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:

Zitat von bra (Beitrag 1338951)

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:

Zitat von EWeiss (Beitrag 1338952)

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:

Zitat von EWeiss (Beitrag 1338952)

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

[Dalai]

Zitat:

Zitat von SearchBot (Beitrag 1339007)

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:

Zitat von Zacherl (Beitrag 1338974)

Zitat:

Zitat von bra (Beitrag 1338951)

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

Zitat von bra (Beitrag 1338951)

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.

[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

[EWeiss]

Zitat:

Zitat von Dalai (Beitrag 1347079)

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

Darum geht es nicht wie, wo oder was diese DLL tut.
Fakt ist das sie mit einer 32Bit Anwendung wenn als 64Bit ausgelegt nicht geladen werden kann.
Darum geht es. Das ist nun mal Fakt.

Seine Behauptung war es geht!
Und das habe ich widerlegt.


gruss

[himitsu]

Deine DLL spicht aber nicht mit 'nem Treiber, sonder mit dem Windows-Explorer und dafür muß sie in dessen Prozessraum geladen werden, was im Windows 64 nur 64 Bit-DLLs können.

Deine DLL könnte aber dennoch mit einem 32 Bit-Treiber reden, auch vom 64 Bit-Windows-Explorer aus.

[EWeiss]

Zitat:

was im Windows 64 nur 64 Bit-DLLs können.

Richtig!

Das ist der Grund warum es auch nicht geht.
Aber er sagte doch es geht.
Dem habe ich widersprochen.

Treiber hin oder her..

gruss

[Assarbad]

Zitat:

Zitat von EWeiss (Beitrag 1347064)

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 ?

Vermutlich weil eine Shellerweiterung für einen 64-bittigen Windows Explorer auch 64-bittig sein sollte? Das ist nix neues.

Zitat:

Zitat von EWeiss (Beitrag 1347064)

Ich habe dir also einen Sichtbaren beweis erbracht das es nicht geht..

Irrtum. Du hast das Thema gewechselt und eine neue Behauptung aufgestellt, die ich nie angezweifelt habe. Darf ich dich nochmals auf deine ursprüngliche Aussage aufmerksam machen, ja?

Zitat:

Zitat von EWeiss (Beitrag 1338944)

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

Das ist und bleibt Unsinn. Aber die Details hat Zacherl ja ausgeführt (seine Beiträge, nicht der Link) ;)

Die üblichen Schnittstellen über die du aus dem Win32-Subsystem mit einem (KM-)Treiber kommunizierst sind DeviceIoControl, ReadFile, WriteFile (und natürlich CreateFile und CloseFile). Sind die in WOW64 verfügbar? Ja? Gut, dann kannste auch kommunizieren.

Ich schreib dir jetzt keinen extra (KM-)Treiber, keinen Bock drauf. Aber da ich selbst über lange Jahre genau diesen Anwendungsfall gewartet habe und dies bis heute tue (32-bittige Anwendung/DLL kommuniziert mit 64-bittigem Treiber auf 64-bittigem Windows), bin ich mir da auch sehr sicher ;)

Zitat:

Zitat von Neutral General (Beitrag 1347071)

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

Warum? Ist doch nix ehrenrühriges dran. Solange es der Wahrheitsfindung dient ...

Zitat:

Zitat von himitsu (Beitrag 1347074)

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.

Das unterschreibe ich voll und ganz.

Zitat:

Zitat von EWeiss (Beitrag 1347076)

Das laden einer Library von einer 32Bit Anwendung ist nicht gleichzusetzen mit der Funktion ob diese DLL dann mit 32Bit Anwendung kommunizieren kann.

Ich zitier' dich jetzt nicht noch ein zweites Mal ;) ... siehe deine ursprüngliche Behauptung weiter oben.

Zitat:

Zitat von EWeiss (Beitrag 1347078)

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.

Puh, jetzt lehnste dich aber weit aus dem Fenster.

Wir redeten doch von einem Treiber, ja? Die meisten Treiber, gerade für Hardware, existieren im Kernelmodus (KM), richtig? Wie kommunizierst du mit dem Kernelmodus? Üblicherweise paketbasiert. Die o.g. Funktionen sind ein gutes Beispiel. Übrigens sieht man hier die Verwandtschaft (im Geiste) zu Unix™. Dort benutzt man auch Funktionen um "Dateien" zu öffnen, lesen und schreiben um auf Geräte unter /dev zuzugreifen. Und auch DeviceIoControl findet seine Entsprechung in der Funktion ioctl.

Zitat:

Zitat von EWeiss (Beitrag 1347089)

Das ist der Grund warum es auch nicht geht.

Genau (bezogen auf dein Beispiel, welches in keinem Zusammenhang zu KM-Treibern steht). Mit der Ausnahme die Zacherl genannt hat. Aber diese würde ich mal unter "Hack" verbuchen und für unsere Diskussion ignorieren.

Zitat:

Zitat von EWeiss (Beitrag 1347089)

Aber er sagte doch es geht.
Dem habe ich widersprochen.

Treiber hin oder her..

Das ist der springende Punkt. Leider liegst du aber mit dem Vergleich falsch, insbesondere wenn wir von (KM-)Treibern reden.

Wenn du eine DLL lädst um Funktionen drin aufzurufen, befindest du dich im gleichen Adreßraum (wir ignorieren weiterhin den Artikel den Zacherl verlinkt hat). Wenn du eine 32-bit DLL (sei es kernel32.dll oder deine eigene) auf einem 64-bit Windows in eine 32-bit Anwendung lädst, dann kannst du die Funktionen und Daten in der DLL nur erreichen weil sie im gleichen Adreßraum sind. Das ist eine sehr direkte Geschichte und erfordert wenig Phantasie oder Wissen. Einfach Auf CPU-Ebene call und jmp usw. um zum Ziel zu gelangen.

Ich versuch mal zu erklären was abgeht ohne zu tief in die Materie einzudringen. Dafür muß ich etwas vereinfachen. Für eine grobe Erklärung kannste dir eine aktuelle Ausgabe von "Windows Internals" zur Hand nehmen. Für Details zusätzlich einen Debugger, die WDK-Dokumentation und einen Disassembler. Alternativ bietet sich auch an in die Quellen von ReactOS zu schauen, welches Windows nachzubilden versucht.

Wenn du eine Anforderung stellst, die in den Kernelmodus geht, bspw. eine Datei liest, oder eben ein Hardwaregerät anspricht, wird ein sogenannter IRP (I/O Request Packet) an das CDO (Control Device Object) oder PDO (Physical Device Object) eines Treibers geschickt [1]. Um eine Datei zu öffnen wäre das bspw. IRP_MJ_CREATE, weshalb man halt CreateFile als extra Funktion hat.

Wenn du dir WinObj von Sysinternals zur Hand nimmst und unter \GLOBAL?? guckst, siehste da bspw. symbolische Links zu einer Volume-Instanz. Der I/O Manager sieht nun bspw. einen Pfad wie \??\C:\boot.ini, welchen kernel32.dll bereits aus der Dos/Win32-Form in die native Form überführt hat. Für diese Erklärung nimm einfach an, daß \GLOBAL?? == \??. Der I/O Manager geht nun den Pfad ab und sieht daß \GLOBAL?? ein Gerät (Device) oder einen Symlink namens C: enthält ... und löst den Namen mithilfe des Object Managers auf und gelangt bspw. zu \Device\Harddisk\Volume2. Der Pfad wird also zu \Device\Harddisk\Volume2\boot.ini. Nun weiß der I/O Manager aber, daß \Device\Harddisk\Volume2 ein Gerät ist und weiß welcher Treiber (üblicherweise der Festplattentreiber und Dateisystemtreiber) dafür verantwortlich ist (es handelt sich um einen Gerätestapel ... so filtert übrigens auch ein AV-Treiber Dateizugriffe). Also wendet er sich vertrauensvoll an dieses Gerät (\Device\Harddisk\Volume2) und übergibt dem zuständigen Treiber den restlichen Pfad (\boot.ini). Wenn ein Festplattentreiber involviert ist, reicht er es an das Dateisystem weiter (wenn du aber bspw. den Bootsektor ausliest, erledigt das der Festplattentreiber normalerweise). Der Dateisystemtreiber weiß dann damit was anzufangen (oder auch nicht, wenn die Datei nicht existiert) und extrahiert die Informationen aus dem IRP und reagiert entsprechend. Nach diversen Sicherheitschecks (schließlich kam die Anforderung ja in einem Benutzer- und Prozeßkontext), mag das Öffnen erfolgreich sein. In diesem Fall bekommt der UM ein Handle zurück. Wenn nun ReadFile oder WriteFile mit diesem Handle benutzt wird, wird ein IRP mit IRP_MJ_READ oder IRP_MJ_WRITE in den Kernelmodus übertragen und dort entsprechend weiterverarbeitet. Wenn man DeviceIoControl benutzt, ist es IRP_MJ_DEVICE_CONTROL und ein vordefinierter IOCTL (I/O Control Code), den du bspw. WinIoctl.h entnehmen kannst für diverse in Windows eingebaute Treiber. Das Handle wiederum wird intern in einen Zeiger auf ein FILE_OBJECT umgewandelt, wenn der Dateisystemtreiber (oder Dateisystemfiltertreiber) damit zu tun haben. Diese Objekte sind in der Tat Objekte im OOP-Sinn, auch wenn sie das nicht im Delphi- oder C++-Sinn sind. Sie haben Funktionen (öffnen, schließen usw.) und Daten. Der Object Manager ist verantwortlich dafür. Einen Überblick über die Objekttypen erhält man in \ObjectTypes, denn dort existieren die "Klassen" als Instanzen des Objekttyps "Type".

So, durch diese paketbasierte Kommunikation kann nun ein 32-bit Prozeß (oder eine darin geladene 32-bittige DLL) auf einem 64-bittigen Windows mit einem 64-bittigen (KM-)Treiber kommunizieren. Q.E.D.

[1] Ein AV-Treiber hat bspw. ein CDO um eben gesteuert werden zu können (Scanner aktivieren, deaktivieren oder bspw. Ausnahmen für Pfade konfigurieren oder Einstellungen am Scanner vornehmen, bspw. Archive scannen ja/nein). Kann aber auch andere Device Objects erzeugen und damit anderes machen. Es gibt nicht nur CDOs und PDOs. Treiber die nur Software ansprechen nennt man Virtual Device Drivers (VDD), im Gegensatz zu jenen die eine Schnittstelle zu einem Hardwaregerät herstellen.

[Neutral General]

Zitat:

Zitat von Assarbad (Beitrag 1347103)

Zitat:

Zitat von Neutral General (Beitrag 1347071)

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

Warum? Ist doch nix ehrenrühriges dran. Solange es der Wahrheitsfindung dient ...

Es war auch mehr als Spaß gemeint, weil du hier denke ich mal als äußerst kompetent angesehen wirst und das was du schreibst auch eigentlich immer Hand und Fuß hat ;)

[Assarbad]

Zitat:

Zitat von Neutral General (Beitrag 1347106)

Es war auch mehr als Spaß gemeint, weil du hier denke ich mal als äußerst kompetent angesehen wirst und das was du schreibst auch eigentlich immer Hand und Fuß hat ;)

Danke für die Bauchpinselei. Da sprichst du etwas an was auch gut als Grund für dieses Thema herhalten könnte, wenn man sich den Unsinn vor Augen führt den man (bspw. ich) manchmal vor Jahren schrieb -- und jetzt ist man etwas "schlauer" aber kennt im Grunde nur seine (neuen) Grenzen genauer. Ich sollte Dichter werden :lol:

[EWeiss]

Zitat:

Ich sollte Dichter werden

Jup dem kann ich nichts hinzufügen..
Zumindest sind deine Beiträge inspirierend.

Zitat:

Irrtum. Du hast das Thema gewechselt und eine neue Behauptung aufgestellt, die ich nie angezweifelt habe. Darf ich dich nochmals auf deine ursprüngliche Aussage aufmerksam machen, ja?

Ich habe meine Aussage als allgemein aufgefasst nicht nur Treiber spezifisch.
Aber letztendlich kann man es so hinstellen wie man es gerne hätte ;)
Da kann ich dir leider nicht widersprechen. LOL

Es gibt für mich nur eins <> als funktioniert.

gruss

[TERWI]

Aus gegebenem Anlass einen "uralten" Fred mal wieder nach oben gepusht !

Ehrlich gesagt: Zu meinem Prob bin nach Studium des Fred's hier nicht schlauer geworden.
Problem hier:
- 64Bit Win Anwendung
- 32Bit DLL die ich verwenden möchte ... muss, weil es keine 64er Version zu geben scheint.

Bisher mit
DLLHandle := LoadLibrary(PChar(DateiName));
hat ja alles super funktioniert ...

Unter x64 funzt das laden ja auch mit
DLLHandle := LoadLibraryExA(PAnsiChar(DateiName), 0, $40);

Allerdings endet
GetProcAddress(DLLHandle, 'IrgendeineFunktion');
dann immer mit NIL - d.h. kein Zugriff.

Die für mich unbeantworte / ungeklärte Frage:
... geht das nun grundsätzlich nicht, oder
... welche "Klimmzüge/Special Hacks" muss man da machen, damit das (eventuell irgendwie) geht ?



Nachtrag:

Es geht hier speziell um den Fehler: 0x8007001F

NEIN ... nicht das was Google & Co. zum Theme "Windows-Update" anbieten.
Hier geht es um DirectShow - im speziellen zu IKsPropertySet.

Lesen der jeweiligen Props mit '.GET' funktioniertr ohne Probleme,
aber schreiben mit '.SET' macht Sorgen ...
-> ERROR: 0x8007001F
Ich finde da im WWW zahlreiche Links, aber nichts was zum Problem passt.

[TurboMagic]

Es gab Mal eine Lösung eines Schweizers mit der könnte man 64 bit DLLs in 32 bit Programmen nutzen. War ein kleiner in Loader mit dem man mittels Memory Mapped File kommuniziert hatte und der die DLL Aufrufe dann ausgeführt hat. Gab glaube ich auch eine andersherum Lösung. War damals in Code Central gewesen.

[himitsu]

In dem 64 Bit Prozess wurden sie bestimmt nicht genutzt,
aber man kann DLLs in einem 32 Bit-Prozess hosten und über eine Bridge damit reden.
Für sowas ist z.B. die dllhost.exe im Windows, jeweils als 32- und 64-Bit-Variante.
https://docs.microsoft.com/en-us/win...dll-surrogates

Dafür gab es auch was im CC
[add] http://cc.embarcadero.com/Item/27667

Es lässt sich die DLL zwar im anderem System laden, aber alle Zeiger und der Programmcode darin passen nicht, also kann natürlich auch keine Prozedur aufgeführt werden, selbst wenn GetProcAddress etwas geliefert hätte.
Also entweder man lässt den Code in 32 Bit laufen oder man braucht z.B. einen Emulator, welcher den Inhalt der Datei auf 64 Bit übersetzt.
https://stackoverflow.com/questions/...it-application


Bridges zwischen System nutzt Delphi an mehreren Stellen.
Delphi zu Java
Win32 zu UWP (z.B. vieles bezüglich BT oder rechts die Benachrichtigungen ist/waren nicht im Win32).
https://www.embarcadero.com/products...desktop-bridge
Und ja, Win64 nutzt die Win32-API (die Komponenten/Befehle/DLLs, welche genutzt werden, entsprechen der gleichen API)