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

[EWeiss]

Zitat von Dalai:

Zitat von EWeiss:

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 von 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 ?

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

Zitat von EWeiss:

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 von EWeiss:

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 von Neutral General:

Sehr mutig Assarbad zu widersprechen
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 von himitsu:

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 von EWeiss:

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 von EWeiss:

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 von EWeiss:

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 von EWeiss:

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 von Assarbad:

Zitat von Neutral General:

Sehr mutig Assarbad zu widersprechen
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 von Neutral General:

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

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