[Prev][Next][Index][Thread]

Re: com and gcc question


Christian Smith <csmith@micromuse.com> writes:
> Vtables are an abstract concept. You should not depend on their
> implemntation. 

He then goes on to explain how to use structs to generate COM interfaces:
> 	struct {
> 		// This table hopefully should be in a COM compatible
> 		// format. If were going to be pedantic, maybe we should
> 		// just have an array of pointers in here, and use casts
> 		// in the main code.
> 
> 		// Generic COM interface functions.
> 		HRESULT (*QueryInterface)(...);
> 		HRESULT (*AddRef)(...);
> 		HRESULT (*Release)(...);
> 
> 		// Interface specific functions
> 		HRESULT (*Foo)(...);
> 	} * table;

But (as his comment reveals), this still isn't guaranteed to produce a
valid COM interface because C/C++ doesn't guarantee any particular
layout for structs - it relies on assumptions which happen to be valid
on all 32 bit C compilers we know about.

We're making the same "mistake" both when using vtables and when using
structs of assuming something about the language that isn't
necessarily true but which may be true for particular compilers.  The
only difference in this case is that the vtable assumption is often
false whereas the struct assumption is (AFAIK) always true.

> If I've missed something, give me a shout. I've a feeling theres a
> problem with this else Microsoft would have implemented it this way
> in the first place:)

COM is a binary standard with no bias towards any particular language.
Therefore Microsoft had to specify a particular layout for interfaces
so that anyone using any implementation of any language would know
precisely what they had to do to use a COM object.  

[This aspect isn't always clear - the first few pages of this paper
give the clearest explanation I've ever seen of this.  The paper was
written by people who wanted to use COM from Haskell (a
research/teaching language which is trying to move into the real
world) - it was written before the authors worked for Microsoft.

  http://research.microsoft.com/Users/simonpj/Papers/com.ps.gz

]

Ok, so suppose there's a binary standard out there that you want to
use and suppose you're free to add extensions to your compiler or to
tweak its representations a little so that it's easy to generate
things that satisfy that binary standard.  What are you going to do?
You tweak it, of course - with the result that code that exploits your
tweak isn't as portable.  Here in planet OSKit, we certainly exploit
a few gcc-ish features.  In fact, our code isn't even portable between
recent versions of gcc.

[I'd like to jump on the conspiracy theory bandwagon and say that
Microsoft adding tweaks to their compiler was just them trying to lock
people into their compiler but, having written a bunch of compilers
myself, I know that it's a very hard job to keep the languages
accepted by just two compilers in step even when you have perfect
communication between the developers of both compilers.  An extensions
which is just an afternoon hack for one compiler might require a month
of work for the other one; priorities may be very different; etc.
Moving into a competitive environment makes compatibility harder to
achieve but the pressures are already hard to resist in a friendly
environment.]

--
Alastair Reid        reid@cs.utah.edu        http://www2.cs.utah.edu/~reid/
Follow-Ups: References: