Sorry I'm coming late to the discussion Heinz.
The whole reason for COM was to create a standard binary footprint in memory so that various programming languages could interoperate at a binary level instead of a source code level. Therefore, given a C++ class (not a COM based class), that class will only, with 100% certainty of success, be able to be accessed by a client written with the exact same version of C++. In other words, there is no guarantee that an ordinary C++ class in a dll written in Microsoft C++ will be able to be accessed correctly by GNU C++. In fact, there is no absiolute guarantee that a Microsoft Version 6 C++ class will be accessable from a version 7 client. While it likely will, there is no guarantee. The reason for that is that the C++ standard specifies all kinds of things related to syntax and what must compile and what must not compile, and behaviors, but does not specify how any C++ language implementor must layout binary objects.
COM was designed to overcome that hurdle by specifying a particular binary layout. Any language can then create COM objects that can be used by any other language. For example, I freely interoperate between C, C++ and PowerBASIC in my work. But the objects I create in C or C++ or low level PowerBASIC adhere to the COM memory layout for objects. I hope this philosophical point of view helps clear it up for you. This is a point that confuses a lot of folks. They think that now that PowerBASIC supports objects, it should freely interoperate with C++. It will, if the C++ class one wishes to interoperate with was built according to the COM specification, which involves a particular memory setup involving the virtual function table and virtual function table pointers.
