Vista - linking with different versions of MFC (for some WPF magic)

I have and MFC executable that is compiled with visual c++ 6 and statically
links the MFC dlls. This exe loads a dll at runtime using Loadlibrary. That
dll ist compiled using visual c++ 8.0 (2005) and links MFC as a shared dll.
The dll exports a function that creates a MFC control (a CWnd derived
object) and displays it.
While this SEEMS to work fine in release mode, I get a lot of debug
assertions (in afxwin.inl) un debug mode.
First of all I have not found a way to debug those assertions, since we are
dealing with two vc++ versions here. Is there a decent way to debug across
different versions of vc++ ?
But more imporantly is there a way I can work with different versions MFC
like in the above described scenario?

I have created a simple little example project that illsutrates this issue.
(be sure to read the readme.txt to understand the structure of the project).
It can be downlaoded form the below url and is also attached to this
message.

http://www.htw-dresden.de/~s9686/MFCTest.rar


The idea behind the whole thing is this:

I have a hughe vc++ 6.0 project that creates an excecuteable. Now I am
planning to exchange some of the controls in that application with WPF
(formerly known as avalon) controls. We want to achieve this without having
to import/compile that main appication project to/with vc++ 8 (since that
would require some major changes). Instead we just put all the stuff that
needs c++/CLI, WPF and vc++ 8 into an extra dll that only exports some
unmanaged functions for the creation of the WPF controls. Unfortuantely that
means I have to deal with different versions of MFC here.

Short answer is no, using multiple versions of MFC in different DLL's and
passing MFC data between them is not supported. int's, handles, and other
non-MFC stuff should work, but MFC 8 is not binary compatible with MFC 6 so
you can't pass objects between them. Sounds like what you're seeing is CWnd
is close enough to binary compatible that no one complaints in release mode,
but asserts in debug mode.

My guess is that in the long-term, moving the code to MFC 8 will be less
work than trying to manage two versions of MFC in the same process, but if
you need to go with the two MFC's you might want to check out the MFC
newsgroup/forum, they may have some further thoughts.

-Nick Kramer [MSFT]
http://blogs.msdn.com/nickkramer

---
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"bonk" <schwertfischtrombose@gmx.de> wrote in message
news:eu%236%23Fn$FHA.916@TK2MSFTNGP10.phx.gbl...
>I have and MFC executable that is compiled with visual c++ 6 and statically
>links the MFC dlls. This exe loads a dll at runtime using Loadlibrary. That
>dll ist compiled using visual c++ 8.0 (2005) and links MFC as a shared dll.
>The dll exports a function that creates a MFC control (a CWnd derived
>object) and displays it.
> While this SEEMS to work fine in release mode, I get a lot of debug
> assertions (in afxwin.inl) un debug mode.
> First of all I have not found a way to debug those assertions, since we
> are dealing with two vc++ versions here. Is there a decent way to debug
> across different versions of vc++ ?
> But more imporantly is there a way I can work with different versions MFC
> like in the above described scenario?
>
> I have created a simple little example project that illsutrates this
> issue. (be sure to read the readme.txt to understand the structure of the
> project). It can be downlaoded form the below url and is also attached to
> this message.
>
> http://www.htw-dresden.de/~s9686/MFCTest.rar
>
>
> The idea behind the whole thing is this:
>
> I have a hughe vc++ 6.0 project that creates an excecuteable. Now I am
> planning to exchange some of the controls in that application with WPF
> (formerly known as avalon) controls. We want to achieve this without
> having to import/compile that main appication project to/with vc++ 8
> (since that would require some major changes). Instead we just put all
> the stuff that needs c++/CLI, WPF and vc++ 8 into an extra dll that only
> exports some unmanaged functions for the creation of the WPF controls.
> Unfortuantely that means I have to deal with different versions of MFC
> here.
>
>
>
>
>
>
>

What if I do not pass MFC data between those dlls. Instead of a CWnd I
could just pass and HWND (that's what I do in that sample project). Or
is a HWND considered to be "MFC data"?).
By the way, I have managed to make those debug assertions go away by
applying the AFX_MANAGE_STATE(AfxGetStaticModuleState());
So are you saying, as long as I do not pass MFC class instances (or
pointers) from one dll to the other I should be fine ?

(It turned out that moving from MFC 6 to MFC 8 (vc++6 to vc++8
respectively) in a project of this scale is a pretty tedious task. )

Nick Kramer [MSFT] schrieb:
> Short answer is no, using multiple versions of MFC in different DLL's and
> passing MFC data between them is not supported. int's, handles, and other
> non-MFC stuff should work, but MFC 8 is not binary compatible with MFC 6 so
> you can't pass objects between them. Sounds like what you're seeing is CWnd
> is close enough to binary compatible that no one complaints in release mode,
> but asserts in debug mode.
>
> My guess is that in the long-term, moving the code to MFC 8 will be less
> work than trying to manage two versions of MFC in the same process, but if
> you need to go with the two MFC's you might want to check out the MFC
> newsgroup/forum, they may have some further thoughts.
>
> -Nick Kramer [MSFT]
> http://blogs.msdn.com/nickkramer
>
> ---
> This posting is provided "AS IS" with no warranties, and confers no rights.
> Use of included script samples are subject to the terms specified at
> http://www.microsoft.com/info/cpyright.htm
>
>
> "bonk" <schwertfischtrombose@gmx.de> wrote in message
> news:eu%236%23Fn$FHA.916@TK2MSFTNGP10.phx.gbl...
>
>>I have and MFC executable that is compiled with visual c++ 6 and statically
>>links the MFC dlls. This exe loads a dll at runtime using Loadlibrary. That
>>dll ist compiled using visual c++ 8.0 (2005) and links MFC as a shared dll.
>>The dll exports a function that creates a MFC control (a CWnd derived
>>object) and displays it.
>>While this SEEMS to work fine in release mode, I get a lot of debug
>>assertions (in afxwin.inl) un debug mode.
>>First of all I have not found a way to debug those assertions, since we
>>are dealing with two vc++ versions here. Is there a decent way to debug
>>across different versions of vc++ ?
>>But more imporantly is there a way I can work with different versions MFC
>>like in the above described scenario?
>>
>>I have created a simple little example project that illsutrates this
>>issue. (be sure to read the readme.txt to understand the structure of the
>>project). It can be downlaoded form the below url and is also attached to
>>this message.
>>
>>http://www.htw-dresden.de/~s9686/MFCTest.rar
>>
>>
>>The idea behind the whole thing is this:
>>
>>I have a hughe vc++ 6.0 project that creates an excecuteable. Now I am
>>planning to exchange some of the controls in that application with WPF
>>(formerly known as avalon) controls. We want to achieve this without
>>having to import/compile that main appication project to/with vc++ 8
>>(since that would require some major changes). Instead we just put all
>>the stuff that needs c++/CLI, WPF and vc++ 8 into an extra dll that only
>>exports some unmanaged functions for the creation of the WPF controls.
>>Unfortuantely that means I have to deal with different versions of MFC
>>here.
>>
>>
>>
>>
>>
>>
>>
>
>
>

bonk wrote:
> What if I do not pass MFC data between those dlls. Instead of a CWnd I
> could just pass and HWND (that's what I do in that sample project). Or
> is a HWND considered to be "MFC data"?).
> By the way, I have managed to make those debug assertions go away by
> applying the AFX_MANAGE_STATE(AfxGetStaticModuleState());
> So are you saying, as long as I do not pass MFC class instances (or
> pointers) from one dll to the other I should be fine ?

That's correct. The same applies to STL and ATL as well.

Any classes/structs that you control the layout of (and hence have the same
definition in VC6 and VC8) can be passed across. The compilers are ABI (app
binary interface) compatible (VC8 being a superset of VC6) as long as you
stay away from a few things (function template names are decorated
differently, wchar_t is encoded differently).

Of course, you have to use two runtime libraries, so you can't transfer
ownership of CRT objects (e.g. memory) across the VC6/VC8 boundary (i.e.
malloc from one CRT, free in the other won't work).

-cd