I was thinking of the case where an EXE and DLL load different minor
versions of the same C/C++ runtime, for example VC8 Gold vs. VC8 SP1. In
that case you don't get two different versions of the VC8 runtime loaded.
You only get one. Which one depends on the manifest in the EXE and the
redirection policies which may have been defined. As an example, Windows 7
SP1 ships with a newer version of the VC8 runtime than the one that shipped
with VC8 SP1. If you run an EXE that was built for VC8 SP1 on a Windows 7
SP1 box the newer version that ships with Windows 7 SP1 always get's loaded,
even if you include the VC8 SP1 runtime with your EXE as a private SxS
assembly. Works that way here. Try it.
In the case where the EXE and DLL were built for different major versions of
the VC runtime then you do in fact get two different versions of the VC
"lallous" <***@lgwm.org> wrote in message news:firstname.lastname@example.org...
Thanks for your reply.
But loading one DLL to address both prog.exe and dll1.dll is always
guaranteed to be the right thing?
What if a certain version of the runtime exported a function and
another version did not. dll1.dll needs that export and refers to
version x.y.a while prog.exe loads x.y.z that does not have that
export and the system only loaded the exe's version (x.y.z) thus
leading to a malfunctioning of dll1.dll ?
On Jan 31, 9:08 pm, "RossettoeCioccolato"
Post by RossettoeCioccolato
I believe that the manifest in the exe takes precedence over the manifest in
the DLL's. Also, there may be a mandatory redirection policy defined e.g.
to load a more recent version of the CRT if a service pack has been applied
or on more recent versions of Windows such as Windows 7.