Go Premium for a chance to win a PS4. Enter to Win


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

Posted on 2011-03-14
Medium Priority
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 500 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 35

Assisted Solution

sarabande earned 1000 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 ?
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

LVL 45

Assisted Solution

AndyAinscow earned 500 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.
LVL 35

Assisted Solution

sarabande earned 1000 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 35

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

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

Question has a verified solution.

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

Introduction: The undo support, implementing a stack. Continuing from the eigth article about sudoku.   We need a mechanism to keep track of the digits entered so as to implement an undo mechanism.  This should be a ‘Last In First Out’ collec…
Go is an acronym of golang, is a programming language developed Google in 2007. Go is a new language that is mostly in the C family, with significant input from Pascal/Modula/Oberon family. Hence Go arisen as low-level language with fast compilation…
The viewer will learn how to use the return statement in functions in C++. The video will also teach the user how to pass data to a function and have the function return data back for further processing.
The viewer will learn additional member functions of the vector class. Specifically, the capacity and swap member functions will be introduced.

926 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