Why does VC8 install libraries to WinSxS?
One of the changes introduced by Visual C++ 2005 is a
change in how we deploy the Visual C++ Runtime Libraries (CRT, MFC, ATL). Deployment
of the runtimes has been a complex and controversial question across many
versions. What we’ve attempted to do in this version of the product is both
simplify our plan and make it more robust in the face of potential security
situations. Explaining this is going to take a while, so I’m going to try
to spend a few blog posts on this theme.
Let me start with a little history. This
story explains some of the earliest, and most powerful motivation for changing
our deployment model.
Static Linking
Microsoft C and later Visual C++ has
included libraries since the very first version of the product, as does every C
and C++ product. These libraries were typically static-link binaries,
consisting of compiled .objs (bound into .libs) that you link to your own
application. The libraries do everything from the mundane (such as running initialization
code) to the fundamental (implementing printf so that you can say “hello
world”). Because the libraries were static-linked into your program by
the linker, they became inescapably part of your program.
This static linking had very clear
implications for what Microsoft call servicing
– the process of shipping updates to existing products. A product like
Microsoft Office has a clear Servicing model. Customers buy Microsoft Office
from their local software store, and if they later need an update to Office,
they contact Microsoft to get that update.
Servicing a development tool is more
complex. A customer goes and buys LovellSoft
Construction Toy Organizer
1.0 from my local store. They find a bug in the software, and contact
LovellSoft. LovellSoft, in turn,
determines that the bug was caused by a problem with a piece of Visual C++.
They contact Microsoft. Microsoft ships LovellSoft
an updated version of the Visual C++ Libraries with a fix for their problem.
They then use this update to build an updated copy of Construction Toy Organizer, which they
ship back to their customer.
You can see how Microsoft has no direct
relationship with LovellSoft’s
customer. If the Construction Toy Organizer
1.0 user contacted Microsoft directly, there is no way we could have
helped, even if we had wanted to, because our code has been linked in with code
supplied by LovellSoft.
As you can see, static linking can present
a real servicing problem if a security problem is found in static linked code. This
leads to a recommendation
Avoid static-linking library code into your
application wherever possible.
When security problems have been
found in static linked code in the past (such as this one), the community
has had to wait until many vendors who used the library rebuilt versions of
their product. This can take a long time.
Dynamic Linking
For some time, we have also shipped
our runtime libraries as a dynamic-link library (DLL). DLLs bring with them
several benefits (small binaries, less disk space, reduced code duplication), but
also creates some new problems (installation location, versioning) –
collectively known as “DLL Hell” in some circles.
DLLs make our servicing obligations
more ambiguous. When you ship a DLL that you got from Microsoft, it’s technically possible for LovellSoft’s customer to come
directly to Microsoft and get a new version of the DLL with the fix they need.
Note that I say “technically”, because in practice, we’ve
kept the servicing relationship for our library DLLs the same as the relationship
for our static linked code. We provide updated DLLs to software developers, who
then deploy those DLLs to their customers.
Windows
Servicing of one version of our libraries
(msvcrt.dll and mfc42.dll) is even more complex because the operating system
took a hard dependency on the library, meaning that they ship and service the
DLL. This means that if LovellSoft
are using VC6 to build their application, and they find a bug that they need a
fix for, they’d need to get a fix from Visual Studio (so that they could
redistribute msvcrt.dll to Windows 95 and Windows NT4), and get operating
system patches for whichever of Windows 2000, Windows XP and Windows Server 2003
that their application targets. Complicated.
Of course, this problem is now
purely hypothetical, because Visual C++ 6 (from Visual Studio 98) has been unsupported
since the end of last month.
Installation
Location Policy
The nub of DLL hell problems is a
versioning one. Does everyone on the system get the same version of a DLL? Can
a rogue application installer ‘roll back’ to an older, broken DLL?
If a new application installs a broken version of a DLL, can other applications
opt-out?
Our traditional motivation around
DLLs had been “sharing” disk and memory pages, so we focused on
installing DLLs like msvcr40.dll and msvcr20.dll to System32. But this strategy
created the DLL hell problem, as installation of these DLLs frequently broke
other programs.
Up to VC6, our advice was –
install your CRT DLL in system32 at setup time, assuming it is newer, and
reference count the installation. A side effect of this policy is that, in an
emergency, we do have a way to update msvcrt.dll. Since it’s required to
be installed in a central location, and since the Windows loader prefers loading
from that location over most others, we have the ability to deploy fixes
directly into system32. This isn’t as robust a plan as you might think,
but it was an avenue available to us.
During the time of VC6, Microsoft
started to get serious about addressing DLL Hell, and as a result for VC7, our
advice was the opposite – install your CRT DLL to your application’s
EXE directory and NOT to system32.
This has the advantage that one
installation won’t interfere with another. It also helps create software
that can be installed by non-administrators, run from networks or ‘xcopy-deployed’
– three things that we were getting much more interested in.
However, it also has the disadvantage
that with the VC7 libraries, we have no way of servicing these DLLs centrally.
The Need for Central
Servicing
As described above, we normally
leave servicing of library DLLs to software vendors. They have the best
knowledge of their customers needs, and so have best judgment on when and how
to deploy updates to their software.
But, some events transcend this kind
of policy. When a time-critical security problem is found in a redistributable
component [such as an active worm on the Internet], Microsoft can’t
just inform software developers of the problem and wait for them to update their
products. Customers and partners will expect us to provide central updates to
resolve these kinds of critical issues via https://windowsupdate.com.
The event linked above happened just
after I took over leadership of the C++ Libraries team, and made me fundamentally
rethink my assumptions about how we should ship our binaries.
A Solution
Luckily, in 1999 a team in Windows started
work on creating solutions for exactly these kinds of problems. Their efforts
resulted in the addition of manifest support to Microsoft Windows XP, and
provided the foundation for us to solve the servicing problem described above,
as well as several others that faced us. The solution means that most Visual
C++-build DLLs and EXEs have a manifest, but also means that, if an emergency
happens, we’ll be much better prepared than we were in previous versions.
In a future entry I’ll describe
how this solution works, and other benefits it has, and provide some tips and
tricks for problems you might hit.
In the mean time, write and tell me
what you think.
Martyn
Comments
Anonymous
October 18, 2005
Are there plans to deploy the WinSxS Visual Studio 8.0 libraries as an optional Windows Update?Anonymous
October 21, 2005
Nope, we don't have plans to do that. Application authors should redistribute the VC8 libraries their application needs as part of their application. [This is the same policy we've had for several versions -- only the VC6 msvcrt.dll was part of Windows].
MartynAnonymous
October 22, 2005
The comment has been removedAnonymous
October 25, 2005
The comment has been removedAnonymous
October 31, 2005
The problem is, not everybody wants to use MSI. Merge modules don't help if you use InnoSetup, NSIS, or simple XCOPY. There is no documented API for adding an assembly to WinSxS.Anonymous
November 02, 2005
I have to agree with the Anonymous Coward - I'm looking at moving our products to being built in VC8, and we use NSIS for our installations. Currently I can't see any way of getting the CRT libraries redistributed short of reverse engineering the MSI way of installing - if I place the CRT DLLs in the app path various exceptions about 'you must use the new way' are thrown!Anonymous
November 02, 2005
The comment has been removedAnonymous
November 02, 2005
There is no need to use MSI to use this solution. We provide two non-MSI solutions.
First, the product includes an EXE installer that installs everything to WinSxS. So you can use that if you prefer. You can find that here on your install:
X:Program FilesMicrosoft Visual Studio 8SDKv2.0BootStrapperPackagesvcredist_x86
However, if you want to install-applocal, you should make sure that your application has a manifest, and then copy the whole of this folder into your EXE directory:
X:Program FilesMicrosoft Visual Studio 8VCredistx86Microsoft.VC80.CRT
and other folders if you use more than the CRT. Make sure you include the manifest.
Martyn Lovell
Development Lead
Visual C++ Libraries
http://blogs.msdn.com/martynlAnonymous
November 02, 2005
Martyn,
Thanks for that - I guess I should read the help. There is a great help topic here:
[URL]ms-help://MS.VSCC.v80/MS.MSDN.v80/MS.VisualStudio.v80.en/dv_vccore/html/8d1a994b-9986-4171-9c0b-56d24808fd1f.htm[/URL]
andAnonymous
November 08, 2005
Martyn,
We've encountered a difference in the RTM msm's from the Beta2 in that an extra custom action SxsInstallCA has appeared but is not in the binary table. This causes msi's built with the release vc80_crt to fail on the missing custom action on Windows 2000 installs.
Did I miss something? Installing the Dot Net framework fixes it but this can't be a pre-requisite can it?
GrahamAnonymous
November 08, 2005
re. SxsInstallCA above:
I think I might have answered my question. The custom action is provided in MSI Version 3.1.
Maybe someone can point me to where this change/requirement was documented as I didn't see it.
/GrahamAnonymous
November 24, 2005
Why you kept the servicing relationship for DLLs the same as static libraries?Anonymous
November 24, 2005
The comment has been removedAnonymous
December 11, 2005
We ran into two problems here:
1) Windows Installer 3.x is needed (it seems like XP SP2 is enough and that is Windows Installer 3.0 and not 3.1?) Did anyone find where this new requirement is documented.
2) This is a major problem: The new merge modules for CRT, ATL80 etc. prevents Per User installations. They require Per Machine installations. This is a major problem for us.Anonymous
December 21, 2005
You mentioned SQL Slammer.
Microsoft Update didn't exist at this time, but if it existed and supported MSDE then, the security update could have been published thru that.Anonymous
October 23, 2006
The Visual C++ 8 libraries (CRT, MFC, ATL, etc.) now support the Shared Side-by-Side Assemblies...Anonymous
February 09, 2007
When VS2005 SP1 has been released because of manifests it become more visible what version of VC++ DLLsAnonymous
March 06, 2007
PingBack from http://www.cchsu.com/art-en/2007/03/07/56/Anonymous
March 06, 2007
PingBack from http://www.cchsu.com/arthur/2007/03/07/127/Anonymous
February 18, 2008
PingBack from http://ossmall.info/2008/02/18/c-application-failed-to-start-after-visual-studio-upgrade/Anonymous
July 22, 2008
PingBack from http://antonioblogroll.freemysqlphphosting.com/winsxspolicies.htmlAnonymous
October 29, 2008
PingBack from http://computinglife.wordpress.com/2008/10/30/porting-to-visual-c-2005-aka-whidbey/Anonymous
May 30, 2009
PingBack from http://outdoorceilingfansite.info/story.php?id=2957Anonymous
May 31, 2009
PingBack from http://outdoorceilingfansite.info/story.php?id=20593Anonymous
June 16, 2009
PingBack from http://topalternativedating.info/story.php?id=5595