.exe zu .exe Kommunikation

[CCRDude]

WM_COPYDATA kommt spätestens an seine Grenzen, wenn ein Prozess elevated ist und der andere nicht (was logischerweise auch der Fall ist bei Kommunikation mit einem Systemdienst). Auch mit mehreren Prozessen auf verschiedenen Sessions (RDP, Fast User Switching, Terminal Services) kommt man da nicht weiter.

Ob WM_COPYDATA, Pipes, MMF, oder TCP - das kommt sicher auf den Verwendungsfall an.

In Prozessen, von denen es nur eine Instanz geben soll, übergebe ich ich Parameter an den bereits laufenden Prozess per Pipe, da fällt WM_COPYDATA auch schon aus, weil der laufende Prozess ja elevated sein kann.

MMF verwende ich beispielsweise, um in einem Systemdienst einen Status zu schreiben, auf den mehrere andere Prozesse dann nur lesend zugreifen. Ist einfach zu greifen weil kaum anders als Dateihandling.

Mit TCP kann man ziemlich viel, ich würde da aber auf bewährte Kontrollstrukturen zurückgreifen, mindestens https, warum nicht gleich webservices, da muss man mit entsprechenden Helfern keine einzelne Zeile selberschreiben?

[KodeZwerg]

Ich bin bereits daran alle Möglichkeiten einzubinden, siehe Bild Server.jpg

edit
Erster Test mit WMCOPYDATA ergab übrigens genau was Du sagst, wenn Server Admin ist und Client nicht dann klappt es nicht.

[günni0]

Wenn dein Beispiel gut funktioniert, sollte man es in die CodeLib aufnehmen wie ich finde.
Dann gäbe es eine zentrale Anlaufstelle für alle Fragesuchenden dieses Themas.

[KodeZwerg]

Da hätte ich Grundsätzlich nichts gegen einzuwänden aber das überlasse ich wichtigeren Menschen
Momentan tüftel ich daran wie ich jede Methode in eine einzelne Unit quetsche damit man dann nur noch die entsprechende Unit sich rausfischen brauch, falls Bedarf an so etwas besteht.
Mein Sorgenkind ist gerade eher der Client, dem bringe ich gerade bei auf die verschiedenen Methoden auch korrekt zu reagieren, auch da wieder einzelne Units.
Bis auf das WMCOPYDATA was zwangsläufig in der Hauptunit verankert sein muss denke ich das alles ein Gutes Ende nehmen wird, aber vielleicht finde ich ja noch einen Weg das WMCOPYDATA da auch rauszuhalten, mal sehen.
Wenn es fertig ist stelle ich es unter Benutzerprojekte bereit.
Einen Thread-Titel der Aussagekräftiger als ".exe zu .exe Komminukation" muss ich mir auch noch einfallen lassen ^_^

[Neutral General]

WM_COPYDATA muss nicht in der Hauptunit (Formular-Unit) verankert sein.
Du kannst Nachrichten auch empfangen mit einem eigenen unsichtbaren Fenster, was du leicht durch AllocateHWnd erstellen kannst.

[KodeZwerg]

Ich werde heute noch zum Piraten so oft wie ich schon "ahhhhrg" schrie )
PERFEKTER TIPP *KUSSI BUSSI*
Den werde ich exakt wie beschrieben umsetzen, dann sind seperate Units Null Problemo.

Vielen Dank @NG!

[Sherlock]

TCP hat einen entscheidenden Nachteil: Es ist nicht unmittelbar Terminalserver tauglich. Da die Applikationen einen definierten Serverport aufmachen müssen, geht das pro Maschine nur ein Mal. Man kann das im Terminalserver wohl konfigurieren, daß der gleiche Port mehrfach vergeben werden kann, aber daran muß man denken. Hab ich vor 15 Jahren alles mal durchmachen müssen, und bin am Ende für IPC bei COM gelandet...was richtig Geil lief, aber "because of popular demand" dann doch einen Schritt zurück zu WMCOPYDATA gegangen.

Sherlock

[Assarbad]

Zitat von CCRDude:

WM_COPYDATA kommt spätestens an seine Grenzen, wenn ein Prozess elevated ist und der andere nicht (was logischerweise auch der Fall ist bei Kommunikation mit einem Systemdienst).

Hier kann ChangeWindowMessageFilterEx Abhilfe schaffen, sofern sich die Fenster auf dem gleichen Desktop (oder war's die gleiche WindowStation?) aufhalten.