WM_COPYDATA 64Bit -> 32Bit

[Gruber_Hans_12345]

Ich bin am verzweiflen ;)

Hat irgendwer ein Beispiel wie ich aus einer 64Bit Anwenung (FPC) per WM_COPYDATA zu meiner 32Bit Anwendung Daten schicken kann?
Irgendwei will das nicht und bekomme AV in meiner 32Bit Anwendung wenn ich auf die DAten zugreifen will.

Bin mir auch nicht so sicher, wo ich nun 64Bit Pointer habe und wo nicht, und ob ich in meiner 32Bit Anwenundg was ändern muß oder nicht.

Den es sieht ja so aus als ob die TCopyDataStruct Pointer hat, und diese ja dann 64 bit haben ...

[himitsu]

Bei WM_COPYDATA brauchst du dir erstmal, wegen den Bits bei den Daten, keine Geganken machen.

Denn hier kümmert sich windows um die Speicherverwaltung.

man schickt die Message ab, Windows ließt die übergebenen Daten aus, erstellt in der Zielanwendung eine neue Struktur, kopiert die Daten dort rein und übergibt erst dann alles an die andere Anwendung.

Also sollte es so erstmal egal sein, ob man von 32 Bit auf 64 Bit oder andersrum Daten sendet.
(OK, abgesehn davon, daß in der Zielanwendung nicht genügend Speicher für die zu versendeten Daten zur Verfügung stehen).

[Gruber_Hans_12345]

tja, das problem ist, das es leider nicht so funktioniert.

den das hätte ich auch schon gemacht, ich schau mir mal dann den aufruf von FPC an, vielleicht läuft da unter 64 bit noch was schief ...

[Gruber_Hans_12345]

ahhh .nocvh nicht ganz fix, aber sieht so aus als ob im FPC/Lazarus die Struktur falsch definiert ist ... da wird beim dwData ein DWORD verwendet muß aber ein ULONG_PTR verwendet werden

[himitsu]

Wo tritt denn die AV auf?

Du könntest dir ja auch erstmal an deine 32-Bit-Anwendung von einer anderen 32-Bit-Anwendung die Daten senden und shcauen ob es da läuft,
sowie die Daten von deiner 64-Bit-Anwendung an eine andere 64-Bit-Testanwendung senden.

Ansonsten bliebe auch noch MMF oder eine Pipe als Alternative.

[Assarbad]

64bit. Hmm? Zufällig Vista oder höher? Wenn ja, könnte es auch sein, daß dir ohnehin die Integrity Levels (Windows Integrity Mechanism) dazwischenfunken. Schon das Drag&Drop von Dateien auf ein Fenster mit höherem Integrity Level funktioniert meines Wissens nach nicht mehr.

[himitsu]

Wenn er von 64 auf die 32 Bit die Message sendet und die AV in 32 auftritt, also dem Ziel, dann muß es ja erfolgreich versendet worden sein? :gruebel:

Dieses Integrity Levels-Dingens sollte doch nur auftreten, wenn man Messages zwischen Anwendungen unterschiedlicher Rechte verwenden will?
Also z.B. von einem billigen User-Prozess zu einem mit höheren Adminrechten.
(wie z.B. Drag&Drop-Messages von einem normalen Explorer zu einer Anwendung mit Adminrechten)

[Assarbad]

Zitat:

Zitat von himitsu (Beitrag 1059631)

Wenn er von 64 auf die 32 Bit die Message sendet und die AV in 32 auftritt, also dem Ziel, dann muß es ja erfolgreich versendet worden sein? :gruebel:

:snowball: ... ups

Zitat:

Zitat von himitsu (Beitrag 1059631)

Dieses Integrity Levels-Dingens sollte doch nur auftreten, wenn man Messages zwischen Anwendungen unterschiedlicher Rechte verwenden will?

Die klassischen Rechte haben damit nur bedingt zu tun, wie ich das verstanden habe. Müßte man mal Dezi fragen.

Zitat:

Zitat von himitsu (Beitrag 1059631)

billigen User-Prozess

:lol:

[Dezipaitor]

Die Ausrichtung (Alignment) der Strukturen ist eine andere. Schau mal, wie groß deine Strukturen in 64 und 32bit sind mit sizeof(). Bei 64bit brauchen solche Strukturen oftmals mehr Speicher als im 32bit Zielprozess allokiert wurde. WM_COPYDATA ist doch DDE?! Die Daten sind doch für den Zielprozess als Readonly zu betrachten, ich glaube daher nicht, dass Windows die Daten irgendwie konvertiert (außer in den Prozess zu kopieren).

[Gruber_Hans_12345]

Also mittlerweile funkt es, das problem war im FPC bzw Lazarus, wo die TCopyDataStruct falsch definiert war, der Pointer Parameter war als DWORD definiert, und so kam nur müll in der 32Bit Anwendung an.