Is it possible to communicate through a COM object?

Question

Is it possible for 2 exes to communicate through a COM (ActiveX?) interface? Can a COM DLL coordinate data-sharing between 2 seperate processes?

Answer 1

If you want to communicate between two processes, use a named pipe.

(It is possible to call a remote COM object and share data that way, but it's unnecessarily complex.)

Answer 2

You might look at Sharing the CoffeeMonitor for a simple example written in VB6. This is probably most useful for n-way communication though, rather than simple one-on-one scenarios.

Yet another approach might be to use Mailslots which unlike Named Pipes can use broadcasts in a manner analogous to UDP broadcasts.

Answer 3

Can a com dll coordinate data-sharing between 2 seperate processes?

Caution: there will be two instances of that DLL, one in each process. If the DLL has/manages data, each instance of the DLL will have its own data: that data won't be shared between processes.

It is possible for 2 exes to communicate through a com interface, where the COM interface supports methods like, I don't know, putData and getData, however I think you may want to build/package/install this COM object as an out-of-process (*.exe) COM object, and not as an in-process (*.dll) COM object.

Or if you do use DLLs, you'll have to implement them to cope with there being two separate instance of them: e.g. it should use cross-process mutexes instead of in-process critical section, and cross-process shared memory instead of in-process private heap memory.

This may not be the best way to coordinate data-sharing, but it could be a way.

Answer 4

Yes, it is possible for 2 exes to communicate through a COM interface.

A COM client and a COM server can be in the same process, in two separate processes on the same computer or on two different computers.

Answer 5

The answer to your question, obviously, is yes.

The follow-up is:

1. Why do you want to share data? What are you trying to accomplish? What does the data look like? Do you need to marshal complex structures and make complex RPC calls, or do you just have a big chunk of data in memory and you want to have two people party on it?
2. Why do you think COM is the best way to do it? Have you considered just sending Window Messages, or using a Named Pipe (as suggested by @avakar), or using shared memory with named mutexes?

The answers to #1 will inform #2.

But lets say COM is the best solution for you. If you have some code in process A that wants to do something in process B, you register a COM object in b.exe and then have process A CoCreateInstance() the object. COM will start b.exe, create the object specified by the CLSID you pass to CoCreateInstance() and then give you a poitner to the specified interface you requested in the IID parameter to CoCreateInstance(). Now you can call methods on the object in process B from process A.

If you have further questions or clarifications, feel free to follow-up.

COM will marshal basic data types (basically everything a VARIANT supports) for you.

Answer 6

DCOM (Distributed COM) is the technology for communicating with a COM object running in a seperate process (or even machine). Though it would be helpful if you elaborated on your scenario, there might be a better option for what you're trying to do.