Dummy-Prozess[ERLEDIGT)
-
Ich suche eine Möglichkeit zur Einrichtung eines "Dummy-Prozesses", der bei Multi-Prozesss-Anwendungen die Fenster-Handles HWNDs der beteiligten Prozesse verwaltet und zur weiteren Kommunikation den Prozessen sein eigenes Fenster-Handle HWND mitteilen kann. Dieser "Dummy-Prozess" wäre beim ersten Prozess mit CreateProcess zu starten und mit dem letzten Prozess zu schliessen. Ich möchte damit Filemapping überflüssig machen. Der "Dummy-Prozess" soll quasi als Dienst verborgen im Hintergrund laufen. Den Einsatz von EnumWindows möchte ich möglichst vermeiden. Geht das oder gibt es für diesen Zweck bessere Möglichkeiten?
-
verstehen wir nicht. kannst du ein bisschen genauer sagen was du vorhast? so ergibt das für uns noch keinen sinn!
-
Zur weiteren Erläuterung: Der "Dummy-Prozess" soll ohne Filemapping in einer einzigen Dateninstanz die Fenster-Handles mehrerer eigener Prozesse (und vielleicht einiges mehr) verwalten. Jede Kommunikation zwischen den Prozessen geht dann allein über einfache Aufrufe von SendMessage. Das geht, aber ohne EnumWindows kommt man offensichtlich nicht zurecht! War nur eine Frage, ich komme auch so klar und suche alternative vielleicht bessere Lösungen.
-
Gelöscht, war unwichtig.
-
Bau Dir ein COM Singelton, dass die zentrale Veraltung übernimmt.
Mit Sicherheit kannst Du so sehr zentriert und einfach ein eigenes Interface für solche Funktionen aufbauen...
Die Frage ist nur: Warum wilst Du dass, wenn DU das Ganze evtl. über feste Klassennamen und FindWindow wirklich einfach hinbekommst...
-
Danke Martin Richter! Ich habe die Sache mit meinem Ansatz im Griff. Will bei Gelegenheit auch Deinen Vorschlag probieren.
-
BTW: kennt jmd. ne Seite mit Performance-Vergleich von IPC Mechanismen unter Windows? Also SendMessage vs. RPC vs. COM vs. raw-sockets etc. Würde mich interessieren (bloss aus Neugier).
-
Ich glaube nicht, dass man real diese Technken vergleichen kann. Oft genug kommt es nicht auf den Datendurchsatz an.
Mit COM ist es natürlich extrem einfach ganze Klassen abzubilden und deren komplexe Funnktionsweise. Für den Overhead bezahlt man.
Genauso wenn man Named-Pipes mit raw-Sockets vergleicht.
Für letzteres habe ich mal einen Test geschrieben (Jahre her). Ich habe keinen Geschwindigkeitsunterschied gesehen. Sowohl für IPC auf der gleichen Maschine wie auch hin zu einem Server. Für mich immer wieder ein Grund mehr gewesen einfach named Pipes zu verwenden, zudem ich hier auch sofort auf das Windows eigene Sicherheitssystem einfach zurückgreifen kann un dmir keine großen Gedanken um ein Protokoll machen muss...
