I don't know if this message got out the first time - our mail system has
been on the blink all day. If this is a repeat then I apologise (but I
didn't see anything come back, including the cc to myself... - so if you
sent anything in response, please send it again).
> Which is good - the bad news is (AFAIK) that DLLs come hand in hand
> with the stdcall calling convention in Win32, meaning that you have to
use
> the C stack for argument passing; there's no guarantee of registers not
being
> clobbered while transferring control to a DLL entry point (I'd love to be
proven
> wrong on this one!) This is definitely not what you want in STG land. So
we
> need a way of sufficiently abusing DLLs such that we don't have to give
> up the use of registers completely, but still use them to chunk a program
> into a bunch of dynamically loadable bits...
> --Sigbjorn
Things are not as bad as you fear. You can treat a DLL as an array of raw
binary relocatable data with a set of (exported) symbols defining locations
within that data array. In particular there is (as far as I know) nothing
to prevent you from defining DLL entry points into an arbitrary block of
assembler and nothing to prevent code using the DLL from branching to that
entry point using any calling convention.
Another useful point - there are two ways of loading a DLL: statically at
load time or dynamically at run time. If a DLL is loaded statically then
it must be on the path when the .EXE is loaded, but the user of the DLL is
then able to use the DLL as if it was linked directly into the code - this
is done by linking the .EXE with a 'stub' library that just defines the DLL
entry points. In particular, if this method is used the caller sees no
difference between ordinary linkage and DLL linkage!
Run time dynamic linkage is rather harder to manage, as the entry points
in the DLL need to be explicitly queried at run time - but this isn't
really what we need, as this can all be done through the C api anyway once
we've managed to (statically) link to the Win32 DLLs.