Re: Using legacy DLLs
On Fri, 17 Aug 2007 13:03:07 GMT, "John A. Byerly"
<johnbREMOVE@flashcutcnc.REMOVEcom> wrote:
I have been routinely passing MFC
objects across DLL boundaries (not all of MFC is GUI. I use MFC strings,
lists, maps, etc.).
Thousands of programs are based on the MFC DLL, which by definition
requires "passing objects across DLL boundaries." That's not a problem.
I (very incorrectly) treated the MFC library similar to
libraries like Rogue Wave
I don't know what that means.
and treated DLLs like shared libraries in Unix.
That's a problem. Unix tries to making dynamic linking as much like static
linking as possible, while Windows treats DLLs as separate objects with a
formal import/export protocol.
Two huge mistakes that are going to cost me a significant amount of time.
The thing to realize is that using __declspec(dllexport|dllimport) on
classes is equivalent to static linking WRT compilation dependencies. (Is
using classes in Unix shared libraries really any different in this
respect?) Also, to compose a program out of EXE and DLLs such that it
behaves (almost) like a statically linked program, you need to link all the
modules to the same CRT DLL, MFC DLL, and so forth, because if a module
statically links to a library, it gets its own private copy of that
library, and the duplicated data tends to cause trouble. This also applies
to template static data, which is to be avoided unless you explicitly
instantiate and export from some DLL all specializations that have static
data. There are other, more obscure problems that are less commonly
encountered, such as each module having its own atexit stack, which can
cause what I call the "Destructor Inversion Problem", which can mess up the
relative order of destruction of local static variables in DLLs WRT other
static duration objects in the program.
--
Doug Harrison
Visual C++ MVP