> It's not just the vtables that we have to worry about, it is also the > member variables. Any change to the binary footprint of the object will > make it fail.
Actually, this is only true when we're talking about concrete classes - this is one of the great things about using interfaces (aka "pure virtual classes") - the way the functions pointers (i.e. vtable entries) are laid out in memory is defined by the interfaces that a class implements, independent of the construction of the object itself (i.e. member variables) - so you can change the object however you like as long as you are going through interfaces. If you combine this with the fact that you MUST link against a dll in order to use its concrete classes directly (i.e. bypassing interfaces) then you'll see that the only DLLs that are in such danger are those which are linked directly against mozilla.exe. This should at least allow us to focus our efforts. > Another example of this is a NS_NewXXX function that is inlined and then > does a 'new' internally instead of using XPCOM to create the object. > There are some of those in layout/content but I'm not sure if they are > being used from another DLL. Right, so in the context of what I just said above, we know that they are not used, because nobody links against the layout or content dlls; they are loaded dynamically by the component manager. So those dlls are safe. I'm looking at xpfe/bootstrap/makefile.win, and looking at the LLIBS line - it looks like these are the only dlls we need to examine: gkgfx.dll expat.dll util.dll png.dll mng.dll js3250.dll Alec
