Discussion:
SxS question
(too old to reply)
lallous
2011-01-25 15:12:11 UTC
Permalink
Hello,

I have my application (prog.exe) with its manifest, dynamically
referring to some CRT libraries, in particular msvcrt90.dll version
x.y.z

Now suppose, another DLL (say dll1.dll, also with its manifest) that
will be loaded by prog.exe also refers to CRT libraries and also to
msvcrt90.dll but version x.y.a this time.

Will this work?

I mean, will the system load two different msvcrt90.dll versions and
properly resolve the import tables of dll1.dll to point to version
x.y.a and prog.exe to msvcrt90.dll version x.y.z?

Please advise.

--
Elias
rogero
2011-01-25 15:36:32 UTC
Permalink
Post by lallous
Hello,
I have my application (prog.exe) with its manifest, dynamically
referring to some CRT libraries, in particular msvcrt90.dll version
x.y.z
Now suppose, another DLL (say dll1.dll, also with its manifest) that
will be loaded by prog.exe also refers to CRT libraries and also to
msvcrt90.dll but version x.y.a this time.
Will this work?
I mean, will the system load two different msvcrt90.dll versions and
properly resolve the import tables of dll1.dll to point to version
x.y.a and prog.exe to msvcrt90.dll version x.y.z?
Perhaps :-)

In general yes, the exe will bind to x.y.z and the dll will bind to
x.y.a

But the 'policy' files for the CRT may direct multiple x.y.z versions
to the same assembly.
Eg on my machine with
EXE -> 9.0.21022.8
DLL -> 9.0.30201.0
the *single* CRT DLL loaded is version 9.0.30729.4148

(Whether that is what you *want* is a different question.)

HTH,
Roger.
lallous
2011-01-31 16:23:52 UTC
Permalink
Hello Roger,
Post by rogero
In general yes, the exe will bind to x.y.z and the dll will bind to
x.y.a
Good to know.
Post by rogero
But the 'policy' files for the CRT may direct multiple x.y.z versions
to the same assembly.
Eg on my machine with
EXE -> 9.0.21022.8
DLL -> 9.0.30201.0
the *single* CRT DLL loaded is version 9.0.30729.4148
(Whether that is what you *want* is a different question.)
Is that what I want? As long as dll1.dll works fine with the same
loaded DLL (though it asked for a different version) then fine.

OTOH, if dll1.dll works specifically w/ version x.y.a and the policy
files redirect to x.y.z then my dll1.dll could crash. So that's not
what I want.
What are policy files and where are they located?
RossettoeCioccolato
2011-01-31 20:08:05 UTC
Permalink
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.
lallous
2011-02-01 12:17:41 UTC
Permalink
Hello,

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.
RossettoeCioccolato
2011-02-01 18:15:10 UTC
Permalink
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
runtime loaded.

"lallous" <***@lgwm.org> wrote in message news:341f49a4-78a5-4f0b-bcde-***@d23g2000prj.googlegroups.com...
Hello,

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.
Continue reading on narkive:
Loading...