Hello
> Yes. I know what's going on now :) (i'm dumb).
>
> 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.
Well, you almost close. The problem is that this component manager should
reside somewhere and this "somewhere" is some DLL. COM do this by provide
global system functions, like CoCreateInstance, which on the other hand
expexts that implementantion DLL export some specific functions, with specific
names. What I've tryed to say, is that XPCOM should have some wrapper
(perhaps) that would work same way.
> 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
Nope, XPCOM has nothing to do with the registry. But that doesn't matter - you
call your XPCOM class creation function, and you shouldn't bother about
implementation details. What I *do not* like about XPCOM, is that it is not
designed to be used as "system global". If you install several programs based
on XPCOM, you will get several instances of XPCOM, which isn't very wise. What
I think is, that guys @netscape should design (and follow) some guidelines
(and API) for XPCOM and XPCOM based components installation. This would be
very nice, since we all will get a cross platform (XP)COM toolkit. Also I
think that Mozilla itself should be bit more separated. I mean, for example,
that things like windowing should be a separated package, wich onse installed
could be used by other applications. For example if there is nsIWidget are
perfect candidate for implementation like that. So whenever someone need a
user interface, it could use nsIWidget based things and forget all other
things (I mean browser stuffs). Last, but the least, in that case, the
applications itself will use separate standart components, that only have to
be put together.
> That doesn't mean this *will* work :). The windows platform is seriously
> moving towards compiler unity ...
Nope... windows itself specifies rules about how to export functions from DLL,
but says none about their name. THe matter that all compiler uses same layout
to represent vtbl is a pure coinsidence - it has nothing to do with any
standarts and so. THere is no many ways how to implement vtbl, so no wonder
things are close enough
--
--
Regards,
Waleri
