From: Mike Nordell (tamlin@algonet.se)
Date: Mon Apr 22 2002 - 00:52:49 EDT
Kenneth J.Davis wrote:
> Another option, that may or may not produce usable plugins is the linker's
> /FORCE option, this is just as bad though.
I'd say that's simply not an option - it's infinitely worse to create a
crashing (or otherwise non-functional) binary than to not produce a binary
at all.
> I don't believe any of these plugins are accessing these static variables
> directly.
They don't, but the functions (that use the functions that use...) access
them, and as such they obviously must be defined. Since they are static
variables they are initialized at module load-time and therefore have to be
defined within the binary that acess them.
I think the "correct" fix is to provide the interface from within AW using
virtual functions only (so that the plugin doesn't bind to a specific
function address, but to a specific vftable offset). Another idea to make it
less fragile (reducing the possibility of being bitten by a baseclass
change) could be to create an interface like:
class foo {
virtual <type1> GetApp<Type1>Attr(const char* szSomething);
virtual <type2> GetApp<Type2>Attr(const char* szSomething);
};
(replace "<typeN>" with suitable data types) and give a pointer to an
implementation of this interface to the plugin.
Just some ideas.
/Mike
This archive was generated by hypermail 2.1.4 : Mon Apr 22 2002 - 00:54:46 EDT