Can I use an mfc extension dll (compiled in vc6) in an mfc app compiled with vc9 ?

Posted on 2011-03-14
Last Modified: 2013-11-20
I have a "mfc extension dll" that has a dialog resource, and want to display a dialog.

So I go this way:



... in my client app

This works very fine.

Now I want  a VC9 COMPILED project to use this  dll, display the dialog using DoModal() etc.

How can I achieve this ?

The problem starts with assertion:
afxwin1.inl, line 22 ASSERT(afxCurrentResourceHandle != NULL);

please note:
- AfxSetResourceHandle(..)

won't fix this problem

AfxSetResourceHandle(..) - is already used, works fine with vc6 app
AFX_MANAGE_STATE - no need for this, it's already a mfc extension dll

Seems tough - Can you help ?
Question by:stev75
LVL 86

Accepted Solution

jkr earned 125 total points
ID: 35130916
Are you sure that your DLL is being loaded in the 1st place? The MFC runtime DLLs are not compatible, so you'd need the ones that are required for VC6's MFC to be installed as well.

I'd rather go for recompiling the DLL with the newer VS version.
LVL 33

Assisted Solution

sarabande earned 250 total points
ID: 35136123
the AFX_MANAGE_STATE cannot ommitted cause by default the resources were used from application and not from dll.

MSDN says:

By default, MFC uses the resource handle of the main application to load the resource template. If you have an exported function in a DLL, such as one that launches a dialog box in the DLL, this template is actually stored in the DLL module. You need to switch the module state for the correct handle to be used. You can do this by adding the following code to the beginning of the function:

AFX_MANAGE_STATE(AfxGetStaticModuleState( ));

note, that is MSDN of VC6.


Author Comment

ID: 35136392
Hi, 2 questions:

@jkr Fact: The dll is compiled to use "mfc as static"library.
To me, this is required, since it is compiled under vc6 and should work with vc9-compiled app. So it won't need any vc6 runtime dlls.
But how can I achieve that on a "DoModal()", the old vc6 dlls are used ? I think you and me agree, that's not possible.
I have this idea:
- NOT call CDialog::DoModal() / CDialog::Create() just a ShowWindow() (and have something like a static dialog)
- use a CWinApp in my dll? I saw that there are some threads here like "Use 2 CWinapp's in one app".
In any case, I would need to switch back from "mfc extension dll"

This msdn help doesn't cover the problem of 2 modules compiled in different visual studio versions.

Btw, It is already working in my vc6 client app, that uses the vc6 compiled dll.
The "mfc extension"-mode won't need  a line of code with AFX_MANAGE_STATE(AfxGetStaticModuleState( ));
I use AfxSetResourceHandle(..) and everything is working fine in my vc6 client app! DoModal() etc works fine.

You can make the fun and do following: run a vc9 app using a vc6 debug-dll in vc9 debugger. When stepping through dll code, the mfc sources from version9 are displayed in visual studio (something like "dlgcore.cpp"). But without any understandable relation to the visual studio debug windows  and their variables.
I guess it's the vc9 mfc sources, but internally, the vc6 dll is working with vc6 mfc sources (because it's linked statically) Am I right ?
LVL 44

Assisted Solution

AndyAinscow earned 125 total points
ID: 35136546
For me an extension dll is to provide classes (those exported that is) which are used as the base of further classes in the main application.  What you are trying to do I think is impossible.

If all you need to do is show a modal dialog then I would suggest you compile it as a 'normal' dll rather than an extension dll.  The you could use LoadLibrary, call and exported function to display the dialog then FreeLibrary.  That ought to get around any problems with different libraries.

The (simple) alternative is do what jkr suggested originally - just recompile the dll.  After all you need to distribute the latest MFC runtimes with the main application.
Is Your Active Directory as Secure as You Think?

More than 75% of all records are compromised because of the loss or theft of a privileged credential. Experts have been exploring Active Directory infrastructure to identify key threats and establish best practices for keeping data safe. Attend this month’s webinar to learn more.

LVL 33

Assisted Solution

sarabande earned 250 total points
ID: 35136816
i strongly support the advice of jkr to port the dll to the same version as the app.

the application and the dll were exchanging pointers to structures which might have changed in size or members and therefore calls most likely would not work. because of that i could think that ms has made checks which prevent from the usage you intend to do. many structures for example have a size-of-structure as first member which could be checked by the called function before going on.

the it-is-working-all-fine-in-vc6 is a weak argument cause it could have run by accident or the errors might have been ignored or auto-corrected. it also could work when the functions of the dll were not called directly from app but indirectly from other dll functions.

i posted the vc6 MSDN snippet cause it says the contrary to that you said regarding the usage of AFX_MANAGE_STATE. it wasn't meant as a solution but as something where you might check a possible wrong assumption on your old code.


Author Comment

ID: 35140596
now after reading your good and helpful comments I think building the dll in vc9 is a good advice(-;

Speaking of the problem of conflicting old and new mfc link libraries: if you encounter the problem of differing struct sizes (such as time_t), why "linking statically to mfc" is no option to avoid it ? also, I use only standard c types in export functions.

Anyway, I looked up that "CWinApp" is part of regular mfc dlls. So if I switch the dll project to "regular", that might fix the problem of the assertion. Does it ?

LVL 33

Expert Comment

ID: 35145947
linking statically to mfc is a solution for one mfc application which doesn't use other dlls. for your case it would mean you do all resources in your application project and have statically linking for all of your code. but even in that case you would need to make sure that all sources have used the same header files, so in any case the mfc version you link against staically must be the same than using for your application.


Author Comment

ID: 35205376
if you use "static mfc" linking along with shared resources (such as a dialog), you will always get afx assertions in the most different places.

Now I use "mfc shared dlls" and use same visual studio version for all components, and it works fine.

Featured Post

Is Your Active Directory as Secure as You Think?

More than 75% of all records are compromised because of the loss or theft of a privileged credential. Experts have been exploring Active Directory infrastructure to identify key threats and establish best practices for keeping data safe. Attend this month’s webinar to learn more.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Title # Comments Views Activity
sum28 challenge 31 106
Modbus - whats the maximum I can store in one register? 4 78
Fibonacci challenge 11 110
Exception thrown at 0x00007FFD5BC81F28 7 38
Templates For Beginners Or How To Encourage The Compiler To Work For You Introduction This tutorial is targeted at the reader who is, perhaps, familiar with the basics of C++ but would prefer a little slower introduction to the more ad…
Introduction: Ownerdraw of the grid button.  A singleton class implentation and usage. Continuing from the fifth article about sudoku.   Open the project in visual studio. Go to the class view – CGridButton should be visible as a class.  R…
The viewer will learn how to user default arguments when defining functions. This method of defining functions will be contrasted with the non-default-argument of defining functions.
The viewer will learn how to clear a vector as well as how to detect empty vectors in C++.

895 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

16 Experts available now in Live!

Get 1:1 Help Now