Re: C++ Version 6 app using c++ version 8 dll
"Norman Diamond" <ndiamond@community.nospam> wrote in message
news:ObOuF6XfHHA.5044@TK2MSFTNGP05.phx.gbl...
Exactly the opposite happens. As far as I can tell, a program compiled
by non-SP1 can probably load the SP1 MFC and CRT, but that's all. A
program partly compiled by non-SP1 and partly compiled by SP1 tries to
load both, and then the loader never proceeds far enough to see if just
the SP1 version would be adequate, it just detects the conflicting
compiled dependencies.
It detects the conflict and then does what exactly?
Aborts.
I read Nikola's blog again:
http://blogs.msdn.com/nikolad/archive/2007/02/09/q-a-on-adapting-vs2005-sp1-to-build-your-applications.aspx
He says if you have the right applocal deployment, you could conceivably
have both RTM and SP1 DLL's in your process. If you don't do applocal, then
you should have supplied the SP1 vc_redist.exe or use the MSM so that the
customer's machine has SP1 DLL's on it, and then all your modules, whether
built with SP1 or not, will use SP1. At least that's how I read it.
Coming back to the situation when both RTM and SP1 runtimes are loaded into
the process. Well, this sets up the same kinds of problems Joe likes to
harp on why static linking is a bad idea. Because in both cases, multiple
runtimes are loaded into the process. But this is even worse than static
linking. If we are static linking, we take active precautions to avoid the
possible conflicts (see links in Nikola's blog). But if you're like Joe who
assumes he can allocate memory in one module and free it in another, because
it is all using the same runtime, he will be in for a rude shock in the case
where having both the RTM and SP1 RTL's in his process will cause this to
fail miserably.
Fun, huh? Norman, you are right about the new DLL hell being worse than the
DLL Classic. But don't call the new one ".NET" it is confusing since it has
nothing to do with .NET.
Static linking is looking better and better. ;)
-- David