VC C++ 2005 sp1 "vcredist_x86.exe"

[Ira Baxter]

We have building a 32-bit application using VC6 for, well, a long time,
and redistributing it with MSVCRT.DLL, MSVCP60.DLL on various versions
of windows without any trouble, including XP 64.

We recently switched to VC C++ 2005, and rebuilt our application.
It still worked fine with our current distribution procedures.

Then I installed VC 2005 SP1, and suddenly, newly compiled images
no longer run on distributed-to machines.
It appears I now have to execute a package
called "vcredist_x86.exe", and our tool binary seems to
*require* MSVCP80.DLL.

What changed?

What does the redist package do,
and how do I find out more about it, so that we
can consider replicating what it does in our
distribution? Finally, why can't I continue
to use MSVCP60.DLL?

Thanks in advance,

Ira Baxter
www.semanticdesigns.com

[David Lowndes]

Post by Ira Baxter
We have building a 32-bit application using VC6 for, well, a long time,
and redistributing it with MSVCRT.DLL, MSVCP60.DLL on various versions
of windows without any trouble, including XP 64.
We recently switched to VC C++ 2005, and rebuilt our application.
It still worked fine with our current distribution procedures.
Then I installed VC 2005 SP1, and suddenly, newly compiled images
no longer run on distributed-to machines.
It appears I now have to execute a package
called "vcredist_x86.exe", and our tool binary seems to
*require* MSVCP80.DLL.
What changed?

Ira,

I'm very surprised that you say it worked with VS2005 - it shouldn't
have - unless you were previously building with the 'C' run-time
statically linked.

Are you sure you've not changed your project settings from static
linking the run-time to the (default) DLL linking? That would explain
the situation.

Dave

[Ira Baxter]

Post by David Lowndes

Post by Ira Baxter
We have building a 32-bit application using VC6 for, well, a long time,
and redistributing it with MSVCRT.DLL, MSVCP60.DLL on various versions
of windows without any trouble, including XP 64.
We recently switched to VC C++ 2005, and rebuilt our application.
It still worked fine with our current distribution procedures.
Then I installed VC 2005 SP1, and suddenly, newly compiled images
no longer run on distributed-to machines.
It appears I now have to execute a package
called "vcredist_x86.exe", and our tool binary seems to
*require* MSVCP80.DLL.
What changed?

Ira,
I'm very surprised that you say it worked with VS2005 - it shouldn't
have - unless you were previously building with the 'C' run-time
statically linked.
Are you sure you've not changed your project settings from static
linking the run-time to the (default) DLL linking? That would explain
the situation.

I don't believe we were doing static linking with the MSVC6 version,
as I can recall shipping instances without the VC6 DLL and getting
complaints at execution time ("Can't execute ...") which were resolved by
providing that DLL. Perhaps I don't understand what static linking
is in the face of DLLs; I'm under the impression that static linking
binds the object code to the DLL content to provide a monolithic
result.

In upgrading to the VS2005, I did not do anything special, other than
take the defaults, since it built on the first try module about 1500
changes in declaration syntax :-{ . In particular,
I did not go to look for static vs. dynamic linking changes The only thing
that
seems different is this new-fangled notion of "embedded manifest".
The manifest itself appears to contain direction mention of the VC8 DLL
(appended); unfortunately, I don't have any manifest files from
the pre-SP1 step since we were doing development then.
And we have not been sending out the manifest file in our distribution.

I have also appended the present linker command, if that gives any hints.
I can't see any specific evidence of a requirement for the
MSVCP80.DLL, so if its here, I assume its a hidden rule
I don't know about. How does the Linker know that
a VC*8* DLL is *required*? I assume all the compiler
is emitting is calls on on a DLL API.

Your "surprise" suggests you know something I don't. Care
to comment on the knowledge that suprised you in some detail?
Is the explicit manifest a new "feature" turned on by SP1?
Thanks.

-- IDB

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC80.CRT"
version="8.0.50727.762" processorArchitecture="x86"
publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
</dependentAssembly>
</dependency>
</assembly>


/OUT:"Release/run.exe" /INCREMENTAL:NO /NOLOGO /LIBPATH:"C:\Program
Files\Microsoft Platform SDK\Lib" /MANIFEST
/MANIFESTFILE:".\Release\run.exe.intermediate.manifest" /DEBUG
/PDB:".\Release/run.pdb" /MAP:".\Release/run.map" /SUBSYSTEM:CONSOLE
/LARGEADDRESSAWARE /MACHINE:X86 /ERRORREPORT:PROMPT odbc32.lib odbccp32.lib
netapi32.lib iphlpapi.lib kernel32.lib user32.lib gdi32.lib winspool.lib
comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib
odbc32.lib odbccp32.lib

[Carl Daniel [VC++ MVP]]

Post by Ira Baxter

Post by David Lowndes

Post by Ira Baxter
We have building a 32-bit application using VC6 for, well, a long
time, and redistributing it with MSVCRT.DLL, MSVCP60.DLL on various
versions of windows without any trouble, including XP 64.
We recently switched to VC C++ 2005, and rebuilt our application.
It still worked fine with our current distribution procedures.
Then I installed VC 2005 SP1, and suddenly, newly compiled images
no longer run on distributed-to machines.
It appears I now have to execute a package
called "vcredist_x86.exe", and our tool binary seems to
*require* MSVCP80.DLL.
What changed?

Ira,
I'm very surprised that you say it worked with VS2005 - it shouldn't
have - unless you were previously building with the 'C' run-time
statically linked.
Are you sure you've not changed your project settings from static
linking the run-time to the (default) DLL linking? That would explain
the situation.

I don't believe we were doing static linking with the MSVC6 version,
as I can recall shipping instances without the VC6 DLL and getting
complaints at execution time ("Can't execute ...") which were
resolved by providing that DLL. Perhaps I don't understand what
static linking
is in the face of DLLs; I'm under the impression that static linking
binds the object code to the DLL content to provide a monolithic
result.

You got lucky, I suspect. Installing .NET 2.0 also installs the VC++ CRT
and C++RT (but not MFC or ATL), since the 2.0 CLR itself it built with VC++
2005. As soon as you moved to SP1, however, you became dependent on a DLL
that isn't already on the machine.

Are you saying that your 2005 pre-SP1 image DIDN'T depend on MSVCP80.DLL, or
did you just not notice it because the required version was already present
on your target machines?

-cd

[Ira Baxter]

Post by Carl Daniel [VC++ MVP]

Post by Ira Baxter

Post by David Lowndes

Post by Ira Baxter
We have building a 32-bit application using VC6 for, well, a long
time, and redistributing it with MSVCRT.DLL, MSVCP60.DLL on various
versions of windows without any trouble, including XP 64.
We recently switched to VC C++ 2005, and rebuilt our application.
It still worked fine with our current distribution procedures.
Then I installed VC 2005 SP1, and suddenly, newly compiled images
no longer run on distributed-to machines.
It appears I now have to execute a package
called "vcredist_x86.exe", and our tool binary seems to
*require* MSVCP80.DLL.
What changed?

Ira,
I'm very surprised that you say it worked with VS2005 - it shouldn't
have - unless you were previously building with the 'C' run-time
statically linked.
Are you sure you've not changed your project settings from static
linking the run-time to the (default) DLL linking? That would explain
the situation.

I don't believe we were doing static linking with the MSVC6 version,
as I can recall shipping instances without the VC6 DLL and getting
complaints at execution time ("Can't execute ...") which were
resolved by providing that DLL. Perhaps I don't understand what
static linking
is in the face of DLLs; I'm under the impression that static linking
binds the object code to the DLL content to provide a monolithic
result.

You got lucky, I suspect. Installing .NET 2.0 also installs the VC++ CRT
and C++RT (but not MFC or ATL), since the 2.0 CLR itself it built with VC++
2005. As soon as you moved to SP1, however, you became dependent on a DLL
that isn't already on the machine.

And why would an service pack (set of fixes) add a dependency that wasn't
there previously?

Post by Carl Daniel [VC++ MVP]
Are you saying that your 2005 pre-SP1 image DIDN'T depend on MSVCP80.DLL, or
did you just not notice it because the required version was already present
on your target machines?

Most of the trial targets are X64 machines, so I can see that they
might the DLL already. In checking just now, one of the 32 bit targets
*does* have
the MSVCP80.DLL on it from an SDK install, which might explain why
it wasn't a distribution problem. So I suppose it is possible that
I was lucky when I switched to VS2005 that my targets effectively all had
this DLL.
OTOH, in an earlier investigation of the problem, on one of the 64
bit systems, there seemed to some issue with so called
"side by side" (SXS) directories on the X64 systems that "vcredist_x86.exe"
resolved. Where can I get a clear picture of what vcredist_x86.exe
actually does?

-- IDB

[Arnaud Debaene]

Post by Ira Baxter
And why would an service pack (set of fixes) add a dependency that wasn't
there previously?

The service pack introduces a new CRT Dll (with bug fixes). The whole
manifest idea is taht applciation check the exact version and signature
(CRC) of their dependencies.
Before you upgraded to SP1, your target machines had the VC2005 gold (no SP)
Dlls already installed (maybe by the .NET framework 2, maybe by a
distribution of the SDK, or by another program). However, those target
machines do not have the VC2005 SP1 Dll's installed.
If there wasn't a manifest in your app, the error will go unnoticed and your
program will happily use the VS2005 gold version of the Dll, potentially
bringing incompatibilities, or breaking things in subtle ways at runtime.

Post by Ira Baxter

Post by Carl Daniel [VC++ MVP]
Are you saying that your 2005 pre-SP1 image DIDN'T depend on MSVCP80.DLL,

or

Post by Carl Daniel [VC++ MVP]
did you just not notice it because the required version was already

present

Post by Carl Daniel [VC++ MVP]
on your target machines?

Most of the trial targets are X64 machines, so I can see that they
might the DLL already. In checking just now, one of the 32 bit targets
*does* have
the MSVCP80.DLL on it from an SDK install, which might explain why
it wasn't a distribution problem. So I suppose it is possible that
I was lucky when I switched to VS2005 that my targets effectively all had
this DLL.
OTOH, in an earlier investigation of the problem, on one of the 64
bit systems, there seemed to some issue with so called
"side by side" (SXS) directories on the X64 systems that
"vcredist_x86.exe"
resolved.

As it name implies, vcredist_x86 is supposed to be used on 32 bits systems;
there are other redistribuables packages for 64 bits targets.

Post by Ira Baxter
Where can I get a clear picture of what vcredist_x86.exe
actually does?

It installs the VC2005 Dlls (msvcr80.dll and msvcp80.dll) on the SxS folder
for systems that supports side-by-side assemblies (XP and up), and in
system32 folder for older targets. See
http://msdn2.microsoft.com/en-us/library/ms235291(VS.80).aspx.

Also, see http://msdn2.microsoft.com/en-us/library/aa983349(VS.80).aspx for
more details on VS2005 SP1.

Arnaud
MVP - VC

[Ira Baxter]

That's great information, thanks very much!

-- IDB

Post by Arnaud Debaene

Post by Ira Baxter
And why would an service pack (set of fixes) add a dependency that wasn't
there previously?

The service pack introduces a new CRT Dll (with bug fixes). The whole
manifest idea is taht applciation check the exact version and signature
(CRC) of their dependencies.
Before you upgraded to SP1, your target machines had the VC2005 gold (no SP)
Dlls already installed (maybe by the .NET framework 2, maybe by a
distribution of the SDK, or by another program). However, those target
machines do not have the VC2005 SP1 Dll's installed.
If there wasn't a manifest in your app, the error will go unnoticed and your
program will happily use the VS2005 gold version of the Dll, potentially
bringing incompatibilities, or breaking things in subtle ways at runtime.

Post by Ira Baxter

Post by Carl Daniel [VC++ MVP]
Are you saying that your 2005 pre-SP1 image DIDN'T depend on MSVCP80.DLL,

or

Post by Carl Daniel [VC++ MVP]
did you just not notice it because the required version was already

present

Post by Carl Daniel [VC++ MVP]
on your target machines?

Most of the trial targets are X64 machines, so I can see that they
might the DLL already. In checking just now, one of the 32 bit targets
*does* have
the MSVCP80.DLL on it from an SDK install, which might explain why
it wasn't a distribution problem. So I suppose it is possible that
I was lucky when I switched to VS2005 that my targets effectively all had
this DLL.
OTOH, in an earlier investigation of the problem, on one of the 64
bit systems, there seemed to some issue with so called
"side by side" (SXS) directories on the X64 systems that
"vcredist_x86.exe"
resolved.

As it name implies, vcredist_x86 is supposed to be used on 32 bits systems;
there are other redistribuables packages for 64 bits targets.

Post by Ira Baxter
Where can I get a clear picture of what vcredist_x86.exe
actually does?

It installs the VC2005 Dlls (msvcr80.dll and msvcp80.dll) on the SxS folder
for systems that supports side-by-side assemblies (XP and up), and in
system32 folder for older targets. See
http://msdn2.microsoft.com/en-us/library/ms235291(VS.80).aspx.
Also, see http://msdn2.microsoft.com/en-us/library/aa983349(VS.80).aspx for
more details on VS2005 SP1.
Arnaud
MVP - VC