>
> Each compiler generates a differently named, but functionally equivalent
and
> interchangeable (vtable is identical). So if I compile with Watcom (and
> include a header file), and I get passed a pointer to an IFoo, i can use
> it just fine -- my copy of the vtable compile in Watcom is the same as the
> version in the library compiled with VC (since it's a COM object).
>
> But i *can't* just start calling random functions in the DLL -- they're
> mangled wrong for me. But if I generate an object by calling
CreateInstance
> of some global component manager, I don't have to call any DLL functions,
> since I can get around needing the constructor.
>
> I'm pretty darn certain that's what's going on :)
>
Yes! That's what I was meaning to say :)
> ...
>
> So for using mozilla from another compiler ... i *assume* that XPCOM on
> windows registers components in the system component registry (if i'm
wrong,
> forget it, this won't work :). Then everything should be fine, except that
> you'll have to build any utility objects completely within (say) Watcom.
> Assuming that all the utility objects use the right declaration magic (so
> that they have COM vtable layout), passing those objects back and forth
> should be fine.
>
Yes (I think.)
XPCOM uses it's own component.reg, not the Windows system registry, but that
shouldn't matter.
The problem that started all this is that some of the standard items in the
XPCOM library are exported as classes from the library itself. For instance
nsMemory is this way, as is the nsComponentManager. These can not be used by
different compilers because you will only be able to link up to them in the
library dll so if you happen to be using the same compiler the library dll
was built with (this is due to name mangling as we talked about before...)
So what would be nice would be a C API style interface to the core XPCOM
library items (like the component manager, the memory manager, etc.) This
can then just shunt it's calls to the C++ version which already exists, and
then you get compiler independence of the XPCOM library (and the API it
provides.)
Ken
