Why is COM (Component Object Model) language-indep

Question

I know that COM provides reusability at the binary level across languages and applications. I read that all components built for COM must adhere to a standard memory layout in order to be language-independent.

I do not understand what "standard memory layout" means.

What makes COM language-independent?

Answer 1

As I remember COM it is language independent ind the way that it's structure is documented and open (?). The downside is that the structure is "binary" and is closely tied to C/C++, which makes it difficult to used from other languages. The good news is that a lot of languages (like Python) have a C/C++ interface, which makes it possible (Win32com Python module) to use from other languages.

JSON is language independent in a way that it does not map directly to any language, although Python, Perl and Ruby (?) are close, but it is almost impossible to use from C/C++

Hope this makes some kind of sense

Answer 2

Don Box wrote an excellent explanation in the first chapter of his book Essential COM. You can read it here for free. I recommend it.

Answer 3

First, some technical background: C++ compilers usually generate something called a "vtable" for any class with virtual functions. This is basically a table of function pointers. The vtable contains a function pointer to every virtual method implemented by a class.

In COM, interfaces are basically abstract base classes which a component implements, e.g.:

class CSomeComponent : IUnknown, ISomeOtherInterface  { ... };

The vtable for CSomeComponent will include function pointers for all methods defined in these two interfaces.

struct __imaginary_vtable_for_CSomeComponent
{
    // methods required by IUnknown
    HRESULT (*QueryInterface)( const IID& iid, void** ppv );
    ULONG (*AddRef)();
    ULONG (*Release)();
    // methods required by ISomeOtherInterface
    void (*foo)();
    ...
};

Any instantiated object has a reference to the vtable of its dynamic type. This is how the program knows how to call the proper method in cases where a base method is overridden in a derived class:

class Base
{
public:
    virtual void foo() { ... }
}

class Derived : public Base
{
public:
    virtual void foo() { ... }  // overrides Base::foo()
    virtual void bar() { ... }
}

...

Base* X = new Derived;
X->foo();

The last line should call Derived::foo. This works because object X has a reference to the vtable for class Derived. As said, the vtable is like a list of function pointers. Now, vtables have a fixed layout: If class Derived inherits from class Base, the function pointer for method foo will be at the same relative location in Derived's vtable than in Base's vtable:

struct __imaginary_vtable_for_Base
{
    void (*foo)();
};

// __imaginary_vtable_for_Base::foo = Base::foo

struct __imaginary_vtable_for_Derived
{
    void (*foo)();
    void (*bar)();
};

// __imaginary_vtable_for_Derived::foo = Derived::foo

Now, if the compiler sees something like X->foo(), it knows that all for all classes derived from Base, method foo corresponds to the first entry in the vtable. So it issues a call to the first function pointer, which in X's case is a call to Derived::foo.

Answer to your question: Compilers can only generate COM components if they generate the same layout for vtables that the COM specification demands. vtables can be implemented in various different ways, especially when it comes to multiple inheritance (which is required with COM components). Adhering to a certain vtable format is necessary so that when you call a component's method f, you will actually call method f and not some other method g which happens to sit at f's position in the component class's vtable. I suppose COM-compliant compilers essentially have to produce the same vtable layouts as Microsoft Visual C++, since the COM technology was defined by Microsoft.

P.S.: Sorry for being so technical, I hope the above information is of some use to you.

Answer 4

Standard memory layout means a memory layout that is defined (standardised) in the COM specification, rather than whatever default one the calling or defining language uses. And it is exactly this sort of thing that makes it language independent! Code in a particular language calling a COM object doesn't have to care what language that COM object was written in, in terms of knowing its structure in memory.