By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,192 Members | 1,253 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,192 IT Pros & Developers. It's quick & easy.

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

P: n/a
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 ?

Mar 17 '06 #1
Share this Question
Share on Google+
8 Replies


P: n/a
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 ?


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
Mar 17 '06 #2

P: n/a
"Jochen Kalmbach [MVP]" <no********************@holzma.de> schrieb im
Newsbeitrag news:%2****************@TK2MSFTNGP12.phx.gbl...
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 ?


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...


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" ... ?
Mar 17 '06 #3

P: n/a
Hi bonk!
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 ? 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...


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


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.
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" ... ?


Yes. This is also not allowed...

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

Greetings
Jochen
Mar 17 '06 #4

P: n/a
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?

"Jochen Kalmbach [MVP]" <no********************@holzma.de> schrieb im
Newsbeitrag news:Os*************@TK2MSFTNGP12.phx.gbl...
Hi bonk!
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 ?
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...


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


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.


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" ... ?


Yes. This is also not allowed...

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

Greetings
Jochen

Mar 17 '06 #5

P: n/a
Hi bonk!
I there any source where I can get more details on what you just described ?


See: Potential Errors Passing CRT Objects Across DLL Boundaries
http://msdn2.microsoft.com/ms235460

And because MFC/STL uses new/malloc the same article applies to these as
well.

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/
Mar 17 '06 #6

P: n/a
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).

"Jochen Kalmbach [MVP]" <no********************@holzma.de> schrieb im
Newsbeitrag news:%2****************@TK2MSFTNGP12.phx.gbl...
Hi bonk!
I there any source where I can get more details on what you just
described ?


See: Potential Errors Passing CRT Objects Across DLL Boundaries
http://msdn2.microsoft.com/ms235460

And because MFC/STL uses new/malloc the same article applies to these as
well.

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

Mar 17 '06 #7

P: n/a
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).


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/
Mar 18 '06 #8

P: n/a
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.

"Jochen Kalmbach [MVP]" <no********************@holzma.de> schrieb im
Newsbeitrag news:%2****************@TK2MSFTNGP11.phx.gbl...
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).


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/

Mar 18 '06 #9

This discussion thread is closed

Replies have been disabled for this discussion.