The fundamental difference between objects that live within the runtime and those that live outside the runtime is that they are managed objects. For more information on managed object see the Virtual Object System (VOS) Specification
Classic COM objects are allocated from a standard Windows heap. These objects are considered unmanaged objects. By convention, the object itself is responsible for freeing the memory it uses when no more references to the object exist. This is accomplished through COM reference counting.
In the NGWS runtime, managed objects are allocated from the runtime’s managed heap and are automatically garbage collected by the runtime. In order to do this, all references to managed objects are traced. When the last reference to the object is removed, the runtime garbage collector reclaims the memory occupied by the object This eliminates the need to reference count managed objects. The runtime essentially handles the reference counting internally.
Tracing is possible within managed code because the runtime is aware of the outstanding references that exist on an object. As each new object reference is declared within managed code, the runtime adds the reference to a list of live references. At any given time, the runtime is aware of all live references that exist on a given object. As the references fall out of scope or change their value, the list of live references is updated. As long as the reference is within managed code the runtime is able to trace it. References from unmanaged code are a different story.
There is no way for the runtime to trace references from unmanaged code to managed objects. Even if the runtime knew about the references, there would be no way to tell if a reference was live or dead. Because classic COM clients are written in unmanaged code, there’s no way of tracing the references they hold on managed objects living within the runtime.
Therefore, the runtime does not allow classic COM clients to reference managed objects directly, instead the runtime creates a wrapper called the COM Callable Wrapper (CCW) that acts as a proxy for the real managed object.
The CCW is not garbage collected and therefore it can be directly referenced by unmanaged clients. The object that it wraps though is garbage collected like any other managed object. The CCW is responsible for handling all aspects of the interaction between managed objects and COM clients. For example, the CCW handles data type marshaling and the translation of COM HResults into NGWS runtime exceptions. In general, the CCW does everything necessary to make the COM client think it is using a COM server and to make the NGWS runtime server appear as though a NGWS runtime client is using it. Section 4 of this document covers the CCW in detail. It addresses all aspects of the interaction between COM clients and NGWS objects. In other words, it addresses unmanaged to managed interoperability.
Making calls from NGWS to COM also presents a problem when it comes to managing object lifetime. COM objects expect to be reference counted, but in a managed environment reference counting is unnatural. It would be very confusing if developers writing managed code had to handle references to managed and unmanaged objects differently (not to mention the problems it introduces to the upgrade process). To abstract the differences between managed and unmanaged references the runtime uses another type of wrapper class called a Runtime Callable Wrapper (RCW). The RCW is a managed object that acts as a proxy for a reference counted COM object. The RCW is garbage collected in the usual way but also maintains an internal cache of interface pointers on a single COM identity. The internal interface pointers kept by the RCW are reference counted like any other COM interface but references to the RCW itself are traced. The RCW is responsible for handling all aspects of the interaction between managed clients and COM objects. This include maintain object identity, data marshaling and exception handling. In general, the RCW does everything necessary to make the NGWS runtime client think it is using a NGWS runtime server and to make the COM server appear as though a COM client is using it.
Section 5 of this document covers the RCW in detail. It addresses all aspects of the interaction between Runtime clients and COM objects. In other words, it addresses managed to unmanaged interoperability.