> Um, COM *does* provide a spec for this, because you have to be able to use
> COM objects across compiler boundaries. AFAIK this is done as part of the
> declaration specification magic. And again AFAIK (get me if i'm wrong)
XPCOM
> does this as well -- I assume it's folded into NSI_EXPORT or whatever the
> declaration magic is for methods that are exported from a DLL ...
>
> But by all means, don't believe me. Go look at the symbol table yourself.
MS
> used to ship a utility called QuickView (or maybe it came with VC++) that
> could look at the symbols a dll provides ...
>

It is my belief that COM does NOT provide this sort of mapping when you are
exporting a class from a DLL, just when you are passing pointers to classes.
The reason is the pointers only refer to the methods by an offset number
(the virtual table) whereas the DLL exportation is done via a name (in this
case a mangled name.) I'm about 99% sure of this, but I've never really been
100% sure of anything.

Here is a place to get the "souped" up version of quickview (also called
depends.exe) It is really nice in that you can right click on a DLL and show
it's dependencies (after you run the depends program once.)

http://www.dependencywalker.com/

Ken



Reply via email to