How COM Simplifies Interprocess Communication

[Previous] [Next]

Shortly after the release of Visual Studio 6, I attended a technical conference and saw people at a booth handing out T-shirts and other trinkets emblazoned with fluorescent flowers and hearts and the slogan, "COM Is Love." The giveaways weren't only designed to appeal to psychedelic programmers; they were also promoting that company's COM books and training programs. While I can neither confirm nor deny that COM is in fact love, I can explain how COM simplifies interprocess communication between objects.

Passing Parameters

Let's take a small step back and discuss calling procedures and passing parameters. Most languages provide two ways to pass parameters to procedures: by value and by reference. Passing a parameter by value is somewhat self-explanatory—you pass a value, or a copy of the data, into the procedure. If you pass a parameter by reference, a pointer to the data is passed into the procedure. When you pass by reference, you generally pass less data (you pass only a pointer to an area in memory), and the changes you make to the data within the procedure are visible outside the procedure.

When communicating among different applications or processes, passing simple parameters by value is fairly easy, while passing parameters by reference is more complex. In Windows, an application can modify the contents of memory allocated to its process. However, an application is not allowed to modify data stored in memory that's been allocated to other processes. So how can you call a procedure in another process and pass parameters by reference? Let COM do the dirty work.

How COM Passes Parameters

When you call a method on a COM component that's running in a separate process, COM handles the interprocess communication by packaging your parameter data and passing it across the process boundary. Packaging data in this fashion is called marshaling. If you want to pass a parameter by reference, COM initially treats your parameter as though you wanted to pass it by value—COM marshals your data across the process boundary so that the procedure has a copy of your data. But once the procedure completes, COM marshals the data in your parameter back to you. The result is that the procedure that resides in a separate process has accessed and modified data contained in the calling process.

Passing standard data types such as integers and strings is fairly straightforward. COM can easily package these data types, pass that data across process boundaries, and unpackage it in another process. User-defined types (UDTs) are more difficult to marshal, but COM recently acquired the ability to pass UDTs that are made up of standard data types (such as strings and integers) across process boundaries.

COM Objects and Process Boundaries

COM objects are much more complex than UDTs, and you cannot easily pass a COM object to another process. There's much more to an instance of a class than the values of its properties. COM objects have methods, and COM objects generally encapsulate data in internal structures that aren't exposed to other applications. You can, however, pass pointers or references to a COM object to another process. Whether you specify in your application to pass object variables by reference or by value, in both cases you're essentially passing a pointer to the COM object. Thus, COM objects are always passed by reference.

This is what occurs when you try to pass DAO's Recordset object and RDO's rdoResultset object across process boundaries. You simply get a pointer to the original object that still resides in its initial process.

This behavior is the default because COM can't generically package all the contents of an object to re-create it in another process. Programmers using the COM object can't override this default behavior. However, the developer of the COM object can build custom libraries to handle the interprocess communication so that the other process receives a distinct, and (hopefully) nearly identical, copy of the original object. Servers that handle this interprocess communication on their own have custom marshaling routines.