Ich verwende WM_COPYDATA, um die Kommunikation zwischen meinen beiden Prozessen A und B zu ermöglichen. Es ist kein Problem, Daten mit grundlegenden Datentypen auszutauschen.Übergeben Sie eine Schnittstelle an einen anderen Prozess
Jetzt habe ich ein Problem, in einigen Fällen möchte ich eine Schnittstelle (IDispatch) von meinem Prozess A zu meinem Prozess B übergeben. Ist es möglich?
Es ist nicht möglich, einen Schnittstellenzeiger direkt an einen anderen Prozess zu übergeben. Wie jeder andere Zeiger ist eine Schnittstelle nur im Prozessadressraum gültig, der sie zur Laufzeit instanziiert. COM verfügt über einen eigenen Mechanismus zum Marshallen von Schnittstellen und Daten über Prozessgrenzen hinweg, sogar über verschiedene Wohnungen hinweg im selben Prozess. Im Falle von Schnittstellen sind dies Proxies und Stubs, die in jedem Prozess/Apartment laufen und über verschiedene IPC-Mechanismen wie Pipes, RPC oder TCP/IP miteinander kommunizieren. Werfen Sie einen Blick auf diese Artikel, wie mit Hilfe von Schnittstellen über Prozesse/Wohnungen erreicht wird:
Understanding Custom Marshaling Part 1
zu tun, was Sie fordern, ohne Rückgriff eigenes Marshalling umzusetzen, müssten Sie einen der Prozesse als einen prozessexternen COM-Server fungieren, und dann kann der andere Prozess CoCreateInstance() oder GetActiveObject() verwenden, um einen Schnittstellenzeiger auf das Serverobjekt zu erhalten, das innerhalb seines lokalen Adressraums arbeitet, und COM die Marshalling-Details behandeln lassen für dich.
Es kann nicht direkt durchgeführt werden, aber Sie können ein Client-Server-Service-Framework verwenden, das interface-basiert sein kann.
Zum Beispiel finden Sie in der letzten Merkmal unserer Open Source mORMot Rahmen: Interface based services sample code und this link.
Sie können einen interface auf einem Remote-Prozess ausführen. Das Merkmal behandelt alle Kommunikationsmittel des Rahmenwerks, d. H. In-Prozess-Anruf, GDI-Nachrichten, Named Pipes und TCP/HTTP. Intern wird es WM_COPYDATA für GDI-Nachrichten verwenden, dann die Parameter und Ergebnisse als JSON übertragen. Verwenden Sie this link, um den Quellcode herunterzuladen (verwenden Sie die http://synopse.info/fossil 1.16+ Version) und die Dokumentation (es gibt mehrere Seiten über die Implementierung dieser Dienste).
Es ist ein Open-Source-Projekt, das mit Delphi 6 bis XE2 arbeitet.
Sie können Ihre Schnittstelle auch mit einem SOAP- oder DataSnap-Client-Server (wenn Sie über die entsprechende Version von Delphi verfügen) oder n-tier-kommerziellen Paketen (wie http://www.remobjects.com/da) verfügbar machen. Dies ähnelt der in mORMot implementierten Methode.
COM ist auch ein guter Kandidat, nativ zu Windows, aber es ist schwieriger zu initialisieren: Sie müssen die COM auf jedem PC (mit Administratorrechten) registrieren, und Sie werden es nicht schaffen können arbeiten über ein Netzwerk (DCOM ist veraltet, erinnern). COM ist gut, wenn Sie möchten, dass Ihr Dienst mit anderen Sprachen wie .Net geteilt wird, aber nur lokal.
Keine direkte Erfahrung mit WM_COPYDATA. Aber ave Sie überprüft dies - http://www.codeproject.com/Articles/5307/Use-WM_COPYDATA-tosend-data-to-from-C-and-C-Windo. Auch Joseph Newcomer scheint zu suggerieren, dass es möglich ist - http://www.flounder.com/wm_copydata.htm (und er hat im Allgemeinen Recht mit allen Dingen Win32) – Gangadhar
@Gangadhar Dies ist ein sehr netter Link. Problem ergibt sich aus der Tatsache, dass alle Daten in den WM_COPYDATA-Puffer serialisiert werden müssen - Sie können es von Hand tun (wie der Autor vorschlägt), oder sich auf automatisiertes Marshalling verlassen, wie COM oder mORMot. –
Vielleicht bin ich völlig aus, aber was ist mit [ObjectFromLresult] (http://msdn.microsoft.com/en-us/library/windows/desktop/dd373605%28v=vs.85%29.aspx) und [LresultFromObject ] (http://msdn.microsoft.com/en-us/library/windows/desktop/dd318557%28v=vs.85%29.aspx)? – kobik