• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1139
  • Last Modified:

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

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 ?
4 Solutions
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.
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.

stev75Author Commented:
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 ?
Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

AndyAinscowFreelance programmer / ConsultantCommented:
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.
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.

stev75Author Commented:
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 ?

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.

stev75Author Commented:
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.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

Tackle projects and never again get stuck behind a technical roadblock.
Join Now