Kommunikation zwischen zwei Programmen
-
An COM dachte ich auch schon. Bin auf dem Gebiet aber nicht sonderlich versiert und habe deswegen keine Ahnung, wo man da überhaupt COM einsetzen könnte
Kannst du etwas genauer werden?
Nur die Änderungen zu schicken ist vielleicht eine Möglichkeit. Dann würde eben Rechenzeit für das Herausfinden der Änderung draufgehen...
-
Wär es nicht geschickter die Analyse direkt in dem Plugin durchzuführen.
Die Kommunikation zwischen den 2 Prozessen (wenn ich richtig verstanden habe)
ist bestimmt deutlich langsamer als In-Prozess Kommunikation, da die
Kommunikation immerhin bei jedem Tastendruck stattfindet.
-
Die Darstellung der Ergebnisse muss auf jeden Fall in der externen Applikation erfolgen. D.h. ich muss die Ergebnisse zur externen Applikation schicken. Das würde das Datenaufkommen aber erhöhen, weil das Ergebnis meistens einen größeren Umfang als der zu analysierende Text hat.
Außerdem ist angedacht, nicht nur ein Word-PlugIn, sondern auch eines für Excel, PowerPoint, ApplikationXYZ zu erstellen. Und dann wäre es dumm, wenn der Analysepart im PlugIn wäre (-> Code-Redundanz)
-
Bei C# fällt mir sofort .Net Remoting ein, damit geht sowas recht elegant. Intern wird dort auch COM verwendet, aber es gibt auch die Möglichkeit seit 2.0 named pipes zu verwenden. Also im Endeffekt liegst du damit schon richtig, wenn du deine Anwendungen nicht in verschiedenen Domänen verwenden willst, weil glaube das können Named Pipes nicht.
-
Nein, das will ich nciht.
.NET-Remoting hört sich nach einer .NET-Technologie an (*g* dummer Satz, ich weiß). Was ich damit sagen will: Muss ich das Gegenstück dazu in meiner C++-Applikation von Hand implementieren?
-
Wenn es dir um Geschwindigkeit und das nicht übers Netzwerk funktionieren muß, gibts eingeltich nur eine Wahl: File Mapping / named shared memory und das ganze mit ner semaphore oder ein ppar named event synchronisieren.
Bei COM, .NET-Remoting, ... hast du immer irgendwo nen Proxy/Stub drinnen der deine daten von einem prozess in den schaufelt. Das kannst in dem Fall 'per Hand' viel effiezienter machen
-
Hm, daran habe ich noch garnicht gedacht. Mal google anschmeißen.
-
Wenn du schonmal hier bist: Muss ich den Inhalt dieses Speicherblocks pollen oder kann ich mich irgendwie benachrichtigen lassen, wenn er geändert wurde?
-
Kannst doch ganz einfach über events machen.
Event1: neue daten sind da - intial state aus
Event2: daten sind abgearbeitet - intial state an- Plugin wartet auf Event2 und mach ein Event2 reset sobald es signaled ist
- Plugin kopiert die neuen daten
- Plugin setzt Event1
- Zurück zu 1- App wartet auf Event1 und mach ein Event1 reset sobald es signaled ist
- App ändert daten
- App setzt Event2
- Zurück zu 1
-
stimmt: com bringt overhead. kannst allerdings in c++ machen und c#, ohne irgendwie selbst was zu implementieren. generell musst du deine objekte dazu in wrapper klatschen, die dann die methoden für den marshaler unterstützen. welche genau das sind weis ihc nicht mehr, als ich das damals benutzt hab, waren die schon implementiert. das prinzip geht so:
prog1 => [marshaler] => transfer (lokal/netzwerk) => [unmarshaler] => prog2
aber shared mem oder files sollten besser sein, wie matt das erkl#rt hat. man muss sich dazu glaub ich an einen prozess anhängen, dafür gibts winapi calls.
-
generell musst du deine objekte dazu in wrapper klatschen, die dann die methoden für den marshaler unterstützen.
Wenn du dein interface nicht als [local] kennzeichnest kümmert sich doch der MIDL um die generieung des proxy/stub code, oder hast du das alles per hand gemacht!?
(das sind die dlldata.c oder xxx_p.c files die plötzlich auftauchen )Der genaue interne ablauft ist für nen call in einen anderen Prozess ist:
Prozess A -> Proxy -> COM Runtime Channel -> RPC Runtime ==(Named Pipe/Socket/..)==> RPC Runtime -> COM Runtime Channel -> Stub -> Prozess BKlar, dass das unmgengen an Zeit braucht
-
So, habe mich jetzt mal ein bisschen in das Thema eingearbeitet.
Named shared memory (CreateFileMapping mit INVALID_HANDLE_VALUE als Dateihandle) geht ja trotzdem über die Festplatte:MSDN schrieb:
If hFile is INVALID_HANDLE_VALUE, the calling process must also specify a mapping object size in the dwMaximumSizeHigh and dwMaximumSizeLow parameters. In this scenario, CreateFileMapping creates a file mapping object of a specified size that the operating system paging file backs, instead of by a named file in the file system.
Oder habe ich "paging file" hier falsch verstanden?
Dann weiter:
Wenn ich in zwei verschiedenen Prozessen MapViewOfFile mache, dann dürften die beiden Zeiger ja nicht auf den selben Speicherbereich zeigen, oder? Zumindest lese ich das aus der Beschreibung von MapViewOfFileEx heraus:MSDN schrieb:
Typically, the suggested address is used to specify that a file should be mapped at the same address in multiple processes. This requires the region of address space to be available in all involved processes
D.h., wenn ich nur die normale Funktion MapViewOfFile verwende, wäre der Prozess ja folgender:
App schreibt Daten in seinen Speicherbereich -> Daten werden in Datei im paging file kopiert und von dort in den Speicherbereich von PlugIn.
Richtig? Oder habe ich jetzt was total falsch verstanden?
-
So, habe mich jetzt mal ein bisschen in das Thema eingearbeitet.
Named shared memory (CreateFileMapping mit INVALID_HANDLE_VALUE als Dateihandle) geht ja trotzdem über die Festplatte:Wenn du es so betrachest, geht alles früher oder später über die festplatte
Nur die Teile deines Programms die aktuell aktive sind werden im RAM gehalten, alles andere wandert ins page file. Wenn dein Programm nun einen Adresse anspricht, die nicht im RAM liegt wird ein page fault interrupt ausgelöst, der dafür sorg, dass die benötigte page ins RAM geladen wird.
Das passiert laufend, davon bekommt dein Programm gar nichts mit.
Und nur so am Rande: da kann man auch richtig gut optmieren mit diesem page zeug, wenn man seine speicher blocks so abarbeitet, dass man möglichst wenig page faults hat. Bsp: statt in einen 1MB block 5x mal von oben nach unten zu itterieren und damit im schlechtesten fall 1024 page faults zu erzeugen, kann man auch 5x durch die ersten 4KB, dann 5x durch die nächsten 4KB ... itterieren und damit nur 256 fage faults zu erzeugenApp schreibt Daten in seinen Speicherbereich -> Daten werden in Datei im paging file kopiert und von dort in den Speicherbereich von PlugIn.
Richtig? Oder habe ich jetzt was total falsch verstanden?Ja.
Der einzige unterschied zum normale verfahren von oben ist hier, dass sich 2 Prozesse einen page teilen.
-
Na ok
Dann versuch ich's einfach mal so. Danke!