Uso WM_COPYDATA per abilitare la comunicazione tra i miei due processi A e B. Non c'è alcun problema per lo scambio di dati con tipi di dati di base.Passaggio di un'interfaccia a un processo diverso
Ora ho un problema, in alcuni casi voglio passare un'interfaccia (IDispatch) dal mio processo A al mio processo B. È possibile?
Non è possibile passare direttamente un puntatore a un altro processo. Come qualsiasi altro puntatore, un'interfaccia è valida solo nello spazio di indirizzamento del processo che la istanzia in fase di esecuzione. COM ha il proprio meccanismo per il marshalling di interfacce e dati oltre i limiti del processo, anche in diversi appartamenti nello stesso processo. Nel caso di interfacce, ciò implica proxy e stub che vengono eseguiti in ogni processo/appartamento e comunicano tra loro utilizzando vari meccanismi IPC, come pipe, RPC o TCP/IP. Date un'occhiata a questi articoli per come utilizzare le interfacce tra processi/appartamenti è compiuto:
Understanding Custom Marshaling Part 1
a fare quello che stai chiedendo, senza ricorrere ad attuare marshalling personalizzato, si dovrà fare in modo che uno dei processi agisca come un server COM out-of-process e quindi l'altro processo può utilizzare CoCreateInstance() o GetActiveObject() per ottenere un puntatore all'interfaccia all'oggetto del server che funziona all'interno del suo spazio indirizzo locale e lasciare che COM gestisca i dettagli del marshalling per te.
Non può essere eseguito direttamente, ma è possibile utilizzare un framework di servizio Client-Server, che può essere basato su interfaccia.
Per esempio, vedere l'ultima caratteristica della nostra Open Source mORMot quadro: Interface based services sample code e this link.
È possibile eseguire un interface su un processo remoto. La funzione gestisce tutti i mezzi di comunicazione del framework, ovvero chiamate in-process, messaggi GDI, named pipe e TCP/HTTP. Internamente utilizzerà WM_COPYDATA per i messaggi GDI, quindi trasmetterà i parametri e i risultati come JSON. Utilizzare this link per scaricare il codice sorgente (utilizzare la versione http://synopse.info/fossil 1.16+) e la documentazione (esistono diverse pagine su come implementare tali servizi).
È un progetto Open-Source, che funziona con Delphi 6 fino a XE2.
È inoltre possibile esporre l'interfaccia con un SOAP o un server client DataSnap (se si dispone della versione corrispondente di Delphi) o pacchetti commerciali n-Tier (come http://www.remobjects.com/da). Questo è simile al metodo implementato in mORMot.
COM è anche un buon candidato, nativo di Windows, ma è più difficile da inizializzare: dovrai registrare la COM su ciascun PC (con i diritti di amministratore), e non sarai in grado di farlo lavorare su una rete (DCOM è deprecato, ricorda). COM è buono se vuoi che il tuo servizio sia condiviso con altri linguaggi, come .Net, ma solo localmente.
Nessuna esperienza diretta con WM_COPYDATA. Ma avete controllato questo: http://www.codeproject.com/Articles/5307/Use-WM_COPYDATA-to-send-data-to-from-C-and-C-Windo. Anche Joseph Newcomer sembra suggerire che sia possibile - http://www.flounder.com/wm_copydata.htm (e in genere ha ragione con tutte le cose su Win32) – Gangadhar
@Gangadhar Questo è un link molto carino. Il problema deriva dal fatto che tutti i dati devono essere serializzati nel buffer WM_COPYDATA - puoi farlo a mano (come suggerisce l'autore), o fare affidamento sul marshalling automatico, come COM o mORMot. –
Forse sono completamente fuori, ma per quanto riguarda [ObjectFromLresult] (http://msdn.microsoft.com/en-us/library/windows/desktop/dd373605%28v=vs.85%29.aspx) e [LresultFromObject ] (http://msdn.microsoft.com/en-us/library/windows/desktop/dd318557%28v=vs.85%29.aspx)? – kobik