EXE with MFC statically linked loads DLL with MFC linked as shared

  • Thread starter Thread starter bonk
  • Start date Start date
B

bonk

Is it generally OK for an EXE that has MFC linked statically to load an use
another DLL wich has MFC linked as shared DLL ?

To be more specific:

I have an EXE that links a lib. Let's call it mylib.lib. That Lib as well as
the EXE have MFC linked statically.

Then in a completely different project I have a regular DLL, wich is
compiled with the /CLR switch and therefore needs the special CRT libs as
well as MFC linked as shared library. This DLL links mylib.lib too only that
this time mylib.lib links MFC as shared library too.

Both exe and dll need need to link against mylib.lib because the dll exports
a function that returns an interface whose methods contain types defined in
mylib.lib.

Now - is this scenario problematic in any way? If so why ?
 
Hi bonk!
Is it generally OK for an EXE that has MFC linked statically to load an use
another DLL wich has MFC linked as shared DLL ?
Click to expand...

As long as you do not pass *any* CRT/MFC types from your EXE to the DLL,
then there should be no problem...
For example: you must not pass "CString" as a parameter to a DLL-function...


Greetings
Jochen
 
Jochen Kalmbach said:
Hi bonk!

As long as you do not pass *any* CRT/MFC types from your EXE to the DLL,
then there should be no problem...
For example: you must not pass "CString" as a parameter to a
DLL-function...
Click to expand...

can you explain why ? Do CRT/MFC types differ between dynamically linked and
statically linked versions?

also, what about the rest of the above described scenario. The DLL exports a
function wich returns a pointer to an abstract class CMyInterface.
CMyInterface is defined in mylib.lib. Now CMyInterface is derived from CWnd
and also contains Methodes whose parameters are MFC types. I guess that fits
within "pass *any* CRT/MFC types from your EXE to the DLL" ... ?
 
Hi bonk!
can you explain why ? Do CRT/MFC types differ between dynamically linked and
statically linked versions?
Click to expand...

The reason is simple: The use different heaps for allocating memory...

If you pass a CString (or any other stuff from CRT/MFC/ATL/STL) and the
caller changes this string an freeing and allocation may occur and will
lead to freeing from the wrong heap and allocation from the wrong heap...
also, what about the rest of the above described scenario. The DLL exports a
function wich returns a pointer to an abstract class CMyInterface.
CMyInterface is defined in mylib.lib.
Click to expand...

If the DLL is using classes from a staticaly linked LIB, you will get a
warning that you are using different CRTs...
Now CMyInterface is derived from CWnd
and also contains Methodes whose parameters are MFC types. I guess that fits
within "pass *any* CRT/MFC types from your EXE to the DLL" ... ?
Click to expand...

Yes. This is also not allowed...

You must share the same CRT/MFC/ATL in *all* EXE/DLLs.

Greetings
Jochen
 
I there any source where I can get more details on what you just described ?
How come there are two different heaps ? Who is responsibe for those heaps?
Which mfc dll (mfc lib ?) and crt lib are used when linking MFC as shared
library an wich when liniking as static?
What crt lib is used when compliling with /CLR?
 
Thank you, Jochen for the detailed info.

So the reason, why I can't pass MFC Types across DLL boundaries if MFC is
linked differently has nothing to do with MFC itself but with the fact that
different copies of the CRT libraries are be used. Is that correct?

Are there different copies of the MFC libraries used as well ?

If linking MFC statically WOULDN'T require a special version of the CRT that
is different from the one used when lnking as shared library, I would be
fine. (yes, thats highly hypothetical).
 
Hi bonk!
So the reason, why I can't pass MFC Types across DLL boundaries if MFC is
linked differently has nothing to do with MFC itself but with the fact that
different copies of the CRT libraries are be used. Is that correct?
Yes.

Are there different copies of the MFC libraries used as well ?
Yes.

If linking MFC statically WOULDN'T require a special version of the CRT that
is different from the one used when lnking as shared library, I would be
fine. (yes, thats highly hypothetical).
Click to expand...

The MFC depends on the CRT. And you need to select the correct CRT
version (DLL or static) if you want to use the DLL/static MFC...

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/
 
Mh ..., this might cause some unexpected problems:

When I use the /CLR switch for my MFC-DLL, msvcmrt.lib (msvcm80.dll) is used
.. Now this lib is not used for all other DLLs and EXEs that have not been
compiled with /CLR (regardless of wether they are linked with MFC as shared
or static).

Now since in this case different versions (copies) of the CRT Library are
used as well, I will not be able to pass pointer to a CRT-Object between a
DLL, that is compiled with /CLR (and with MFC linked as shared) and a DLL
that is compiled without /CLR (and with MFC linked as shared).

This would kind of suck, since I would not be able to implement a wrapper
that wraps some .NET (i.e. WinForms) controls to be used in a plain
unmanaged MFC-EXE.
 
Back
Top