Uso WM_COPYDATA para habilitar la comunicación entre mis dos procesos A y B. No hay problema para intercambiar datos con tipos de datos básicos.Pasar una interfaz a un proceso diferente
Ahora tengo un problema, en algún caso quiero pasar una interfaz (IDispatch) de mi proceso A a mi proceso B. ¿Es posible?
No se puede pasar directamente un puntero de interfaz a otro proceso. Al igual que cualquier otro puntero, una interfaz solo es válida en el espacio de direcciones del proceso que crea una instancia en el tiempo de ejecución. COM tiene su propio mecanismo para reunir las interfaces y los datos a través de los límites del proceso, incluso en diferentes apartamentos en el mismo proceso. En el caso de las interfaces, eso involucra proxies y stubs que se ejecutan en cada proceso/apartamento y se comunican entre sí utilizando varios mecanismos de IPC, como pipes, RPC o TCP/IP. Echar un vistazo a estos artículos de cómo el uso de las interfaces a través de procesos/apartamentos se lleva a cabo:
Understanding Custom Marshaling Part 1
para hacer lo que está pidiendo, sin recurrir a la aplicación de cálculo personalizado, que tendría que hacer que uno de los procesos actúe como un servidor COM fuera de proceso, y luego el otro proceso puede usar CoCreateInstance() o GetActiveObject() para obtener un puntero de interfaz al objeto del servidor que funcione dentro de su espacio de direcciones local, y dejar que COM maneje los detalles de la ordenación para ti.
No se puede hacer directamente, pero puede utilizar un marco de servicio Cliente-Servidor, que puede estar basado en la interfaz.
Por ejemplo, véase la última característica de nuestra Open Source marco Mormot: Interface based services sample code y this link.
Puede ejecutar un interface en un proceso remoto. La función maneja todos los medios de comunicación de la infraestructura, es decir, llamada en proceso, mensajes GDI, canalizaciones con nombre y TCP/HTTP. Internamente usará WM_COPYDATA para mensajes GDI, luego transmitirá los parámetros y resultados como JSON. Use this link para descargar el código fuente (use la versión http://synopse.info/fossil 1.16+) y la documentación (hay varias páginas sobre cómo implementar esos servicios).
Es un proyecto de código abierto que funciona con Delphi 6 hasta XE2.
También puede exponer su interfaz con SOAP o DataSnap Client-Server (si tiene la versión correspondiente de Delphi) o paquetes comerciales n-Tier (como http://www.remobjects.com/da). Esto es similar al método implementado en mORMot.
COM es también un buen candidato, nativo de Windows, pero es más difícil de inicializar: tendrá que registrar el COM en cada PC (con derechos de administrador), y no podrá hacerlo trabajar en una red (DCOM está en desuso, recuerde). COM es bueno si desea que su servicio se comparta con otros idiomas, como .Net, pero solo localmente.
Sin experiencia directa con WM_COPYDATA. Pero si ha comprobado esto, http://www.codeproject.com/Articles/5307/Use-WM_COPYDATA-to-send-data-to-from-C-and-C-Windo. También Joseph Newcomer parece sugerir que es posible - http://www.flounder.com/wm_copydata.htm (y generalmente tiene razón con todas las cosas Win32) – Gangadhar
@Gangadhar Este es un enlace muy bueno. El problema se debe al hecho de que todos los datos deben ser serializados en el búfer WM_COPYDATA; puede hacerlo a mano (como sugiere el autor) o recurrir a referencias automáticas, como COM o mORMot. –
Tal vez estoy totalmente fuera, pero ¿qué pasa con [ObjectFromLresult] (http://msdn.microsoft.com/en-us/library/windows/desktop/dd373605%28v=vs.85%29.aspx) y [LresultFromObject ] (http://msdn.microsoft.com/en-us/library/windows/desktop/dd318557%28v=vs.85%29.aspx)? – kobik