On Thu, Jan 18, 2001 at 10:51:38AM -0600, Ken Kozman wrote:
>
> 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.)
>
I get it :)
Yes. that would be nice. And it wouldn't be a big change -- just the few
core system objects which appear to be all static functions anyhow (since
you have to be able to get hold of these objects to start instantiating
stuff). So clearly these things should have been extern "C" from the
beginning :) since they gain no benefit from being C++, and they end up
mangled.
But it should be a fairly simple patch to wrap them with C functions.
The only other thing you'd want is an easy way to grab the utility objects
(like nsString) so you can build them for yourself, so you can instantiate
them from outside the mozilla dll's if you need to ... (basically just a
list of files to grab, or perhaps even collected into one place).
This doesn't sound that hard to do. Not that I'm volunteering :)
ari
