Using MFC90 Class exported from DLL with DLL built with MFC100

Question

Please forgive me if this question has been asked before, but I promise I looked extensively and could not find anything (maybe I just couldn't come up with the right search terms).

Here's the situation, I have a DLL built on MFC90 that exports a class (and uses MFC objects in the header file like CString, POSITION, etc.), we'll call this DLL ONE. Since I only have access to VS2010, I'm limited to building MFC based DLLs and Apps on MFC100, and I have another DLL, we'll call it TWO, that uses the objects exported from DLL ONE. So far it seems to work okay, but I want to know if I should really expect some bugs or weird quirks when linking a DLL built with MFC100 to a DLL built with MFC90, or if it's a trivial concern.

**NOTES**

• I do not have the option of rebuilding DLL ONE.
• I have looked for free options to build applications on MFC90 using VS2010, but I have not successfully found a solution. I read that I could simply download the Windows SDK 6.01, but when I downloaded it from Microsoft there was no trace of MFC in it.
• I do not have the option to use VS2008 (except for VS2008 Express, which does not come with MFC).
• This is all company proprietary code, so I cannot post any of the source code.

**EDIT**

• I should probably mention that DLL TWO exports functions that take a pointer to the class exported by DLL ONE as their arguments.
• None of the exported classes are derived from MFC objects. The exported classes only use MFC objects as member variables, member function arguments, or internally inside member functions. I can't say this one 100% certainty, but I don't believe the classes make use of anything more than CString, or POD structures like POINT & POSITION.

Answer 1

Without the source assuming the DLL's are proprietary themselves (the code + the MFC used with, or just one or the other) I would imagine that they'd be just as quirky as utilizing any kind of DLL that Microsoft provides themselves. So I'm sure it's trivial, in my experience which someone wrote a wrapper for WMPLib.DLL in it's own DLL, the file API for it didn't cause any underlying issues but the error handling was terrible, the portability from XP to vista and 7 wasn't an issue but passing the wrong value at the wrong time was. All in all, I think it just matters how well the internal functions are written to interface with the MFC.

Answer 2

To pass MFC-derived objects, or pointers to MFC objects and memory allocated by MFC, you must build an extension DLL. I assume you are having an MFC extension DLL project. If you have a complex MFC object like CView embedded in a structure, then you probably are embedding a pointer to MFC object. MFC objects with a known, version-independent layout like CRect is OK to pass.

MFC extension dlls are not portable across multiple versions. From the documentation of Extension DLLs :

Both the client application and the extension DLL must use the same version of MFCx0.dll.

Thus you can't link an MFC 9 extension DLL with MFC 10 libs. You need to ask the author to rebuild with MFC10, or obtain VC9 to have the MFC 9 libs.

The reason being, if you have memory layout mismatch between the V9 class definition and the V10 one, you would have at best memory leak and at worst random crash if you try mix both, as offset of members in MFC objects can be different in different versions. When you write to an address thinking it is Foo::memberA could be overwriting Foo::memberB because the memory layout are different. Also static variables are stored in different places. Probably the first mismatch you would notice if you try mix MFC versions is a debug assert in the runtime class checking which is called pretty frequently in MFC.

Answer 3

Should work out of the box. I have seen projects with mixed versions of MFC. The only problem is deployment. MFC 8.0 and 9.0 need a manifest (and are preferably deployed in WinSxs) whereas 7.x and 10.x can simply be placed in the same folder as your executables.

As long as you have the merge modules for MFC/CRT 9.0, no worries.