Używam WM_COPYDATA, aby umożliwić komunikację między moimi dwoma procesami A i B. Nie ma problemu z wymianą danych z podstawowymi typami danych.Przekaż interfejs do innego procesu
Teraz mam problem, w niektórych przypadkach chcę przekazać interfejs (IDispatch) z mojego procesu A do mojego procesu B. Czy to możliwe?
Nie można bezpośrednio przekazać wskaźnika interfejsu do innego procesu. Jak każdy inny wskaźnik, interfejs jest ważny tylko w przestrzeni adresowej procesu, który tworzy instancję w środowisku wykonawczym. COM ma swój własny mechanizm gromadzenia interfejsów i danych pomiędzy granicami procesu, nawet w różnych mieszkaniach w tym samym procesie. W przypadku interfejsów, które obejmuje proxy i kody pośredniczące, które działają w każdym procesie/apartamencie i komunikują się ze sobą za pomocą różnych mechanizmów IPC, takich jak rury, RPC lub TCP/IP. Wystarczy popatrzeć na tych artykułów na jak przy użyciu interfejsów między procesami/apartamentów odbywa się:
Understanding Custom Marshaling Part 1
Aby zrobić to, co prosicie, bez uciekania się do wdrażania niestandardowych Organizowanie, trzeba by sprawiają, że jeden z procesów działa jako serwer COM, który jest poza procesem, a następnie inny proces może użyć CoCreateInstance() lub GetActiveObject(), aby uzyskać wskaźnik interfejsu do obiektu serwera, który działa w jego lokalnej przestrzeni adresowej, i pozwolić COM obsługiwać szczegółowe informacje dla Ciebie.
Nie można tego zrobić bezpośrednio, ale można użyć frameworku usług klient-serwer, który może być oparty na interfejsie.
Na przykład, zobacz ostatnia cechę naszego Open Source struktury mORMot: Interface based services sample code i this link.
Można wykonać interface na zdalnym procesie. Ta funkcja obsługuje wszystkie środki komunikacji w ramach, tj. Wywołanie w toku, komunikaty GDI, nazwane potoki i TCP/HTTP. Wewnętrznie będzie używał WM_COPYDATA dla wiadomości GDI, a następnie przesyłał parametry i wyniki jako JSON. Użyj kodu this link, aby pobrać kod źródłowy (skorzystaj z wersji http://synopse.info/fossil 1.16+) i dokumentacji (jest kilka stron o tym, jak wdrożyć te usługi).
Jest to projekt typu Open Source, współpracujący z Delphi 6 do XE2.
Możesz także narazić swój interfejs na serwer SOAP lub DataSnap-Client (jeśli posiadasz odpowiednią wersję Delphi) lub komercyjne pakiety n-Tier (takie jak http://www.remobjects.com/da). Jest to podobne do metody zaimplementowanej w mORMot.
COM jest także dobrym kandydatem, natywnym dla systemu Windows, ale trudniej go zainicjować: będziesz musiał zarejestrować COM na każdym komputerze (z uprawnieniami administratora), a nie będziesz mógł go wykonać praca w sieci (model DCOM jest przestarzały, pamiętaj). COM jest dobry, jeśli chcesz, aby twoja usługa była współdzielona z innymi językami, takimi jak .Net, ale tylko lokalnie.
Brak bezpośredniego doświadczenia z WM_COPYDATA. Ale sprawdziłeś to - http://www.codeproject.com/Articles/5307/Use-WM_COPYDATA-to-send-data-to-from-C-and-C-Windo. Również Joseph Newcomer wydaje się sugerować, że jest to możliwe - http://www.flounder.com/wm_copydata.htm (i generalnie ma rację ze wszystkimi rzeczami Win32) – Gangadhar
@Gangadhar To bardzo ładny link. Problem wynika z faktu, że wszystkie dane muszą być serializowane do bufora WM_COPYDATA - możesz to zrobić ręcznie (zgodnie z sugestią autora) lub polegać na automatycznym ładowaniu, takim jak COM lub mORMot. –
Może jestem całkowicie wyłączony, ale co z [ObjectFromLresult] (http://msdn.microsoft.com/en-us/library/windows/desktop/dd373605%28v=vs.85%29.aspx) i [LresultFromObject ] (http://msdn.microsoft.com/en-us/library/windows/desktop/dd318557%28v=vs.85%29.aspx)? – kobik