使用COM在Windows上的本地计算机上进行进程间通信

Question

I was investigating the option of doing interprocess communication on Windows using COM and C++ .

I found this article on MSDN , offering a list of interprocess communication options for Windows, and COM is one of them.
But, unfortunately, the COM option is just listed without much details.

Does someone have any pointers about doc or other resources on how to use COM for interprocess communication on Windows?

I'm not interested in communicating with remote machines (so: no DCOM ); I'm just interested in interprocess communication on the same local machine.

The idea would be to define some custom COM interfaces implementing some custom communication protocol, and then have a server program and a client program (each one in its own process, running on the same local machine), and use COM to communicate between the two (eg the client makes requests to the server, and the server returns proper answers, everything using COM interfaces).

So, for example: are there predefined COM interfaces to implement an interprocess communication? If so, what are them?

It would be helpful to have some tutorial or a more detailed guide about this subject.

Answer 1

If you have a COM interface that both sides know about then one process can register some object implementing that with the Running Object Table using a moniker. The other process can then retrieve the object from this interprocess table using the moniker identifier and query it for the known interface. Now the client process has a reference to something existing in the other process and calls will be marshalled by COM.

There are lots of things to go wrong though, particularly with ensuring your interfaces are being marshalled correctly. Marshalling is often not well tested until you start using multiple processes or you have been using .Net with your COM interfaces. Using oleautomation compatible types and marking the interface in IDL with the [oleautomation] attribute can help to ensure typelibrary marshalling will work but also attention to the other attributes used with arrays is important. We found this with the IPropertyBag2 interface some years ago. The Visual Studio 6 IDL description looks like this in ocidl.idl:

HRESULT Read(
            [in] ULONG cProperties,
            [in] PROPBAG2 * pPropBag,
            [in] IErrorLog * pErrLog,
            [out] VARIANT * pvarValue,
            [out] HRESULT * phrError
        );

and does not marshall more than a single VARIANT from the array provided. The newer version looks like this:

HRESULT Read(
           [in] ULONG cProperties,
           [in, size_is(cProperties)] PROPBAG2 * pPropBag,
           [in, unique] IErrorLog * pErrLog,
           [out, size_is(cProperties)] VARIANT * pvarValue,
           [in, out, unique, size_is(cProperties)] HRESULT * phrError
       );

which correctly associates the size of the pvarValue array with the size specified by the cProperties parameter. Assuming a typelibrary with the second definition has been registered then this interface should marshal properly now but a few years ago those missing parameters cost us a few brain cells working out why persistence was failing.