[Prev][Next][Index][Thread]
Re: com and gcc question
BTW, is COM used in oskit in it's binary form, or is it just a model to
base code on? I ask because binary COM will come crashing down if oskit is
ported to 64-bit architectures.
On Wed, 22 Sep 1999, Alastair Reid wrote:
>
>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: