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 32

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.
Free Trending Threat Insights Every Day

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

LVL 32

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 32

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

How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

Join & Write a Comment

Introduction: Dialogs (2) modeless dialog and a worker thread.  Handling data shared between threads.  Recursive functions. Continuing from the tenth article about sudoku.   Last article we worked with a modal dialog to help maintain informat…
Basic understanding on "OO- Object Orientation" is needed for designing a logical solution to solve a problem. Basic OOAD is a prerequisite for a coder to ensure that they follow the basic design of OO. This would help developers to understand the b…
The goal of the video will be to teach the user the difference and consequence of passing data by value vs passing data by reference in C++. An example of passing data by value as well as an example of passing data by reference will be be given. Bot…
The viewer will learn how to clear a vector as well as how to detect empty vectors in C++.

747 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

9 Experts available now in Live!

Get 1:1 Help Now