Learning DCOM

Memory

Recall that COM must know the exact size of all data that is sent back and forth between a client and its objects. For simple data types (e.g., short, long, or our Zone structure), COM knows their sizes. However, you can modify these data types with pointers (e.g., Zone *, and so forth). When you’re calling a function on a different system (or even a different address space on the same system), COM can’t get away passing the four-byte address in the pointer; COM has to pass all the data being pointed to.

We know the importance of dynamic memory management in C and C++. Good programming requires allocated memory to be correctly destroyed. If your code lies in one single process, you know when to deallocate heap-based memory, which you have previously allocated. However, in a distributed architecture, which likely contains multiple execution contexts, you have a client and an object, including the object’s associated proxy and stub. Remember that after you’ve deployed your components, ten thousand clients may use your objects. How should the clients, objects, and proxies/stubs deal with dynamic memory management?

COM, which relies on RPC, provides a number of rules that you must follow to correctly manage dynamic memory. When you specify a COM interface, you designate memory management assumptions by using the [in], [out], and [in, out] MIDL attributes. These attributes are hints that allow COM to correctly manage memory at the proxies and stubs level in standard marshaling. ...