SxS is a relatively new OS feature supported by Windows on XP,
Windows 2003, and Vista. SxS is a must-have feature in order to
deploy most modern software products such as Microsoft Office 2007,
Adobe Reader 8, and .NET 2.0/3.0. Thinstall is the only application
virtualization solution which supports SxS.
In the early days Microsoft recommend installing DLLs to
c:\windows\system32 if you wanted to share them with other
applications. This lead to "DLL Hell" since one applications
installer would install one version of a DLL and another installer
would install another version overwriting the existing DLL. If the
new version of the DLL wasn't compatible the older application
would suddenly break and stop working.
This is still how the majority of applications install their DLLs,
even Office 2007 installs approximately 7 DLLs to
c:\windows\system32. Slowly the industry is moving to deploy shared
DLLs using SxS as XP becomes mainstream and Visual Studio 2005
forces this on you if you want to use the Version 8 C Runtime
libraries.
With SxS technology, applications can install DLLs to version
specific directories tell Windows what version of the DLL should be
used when they load a DLL by that name. For example, Office 2007
installs MFC80 (8.0.50727.42) to the following path:
If you wonder about the weird path, it contains information about
the DLL version. The algorithm for producing this path is
purposefully unpublished by Microsoft so the only way to place
files here is by using the MSI installer technology. Because MSI is
responsible for putting SxS Dlls in the correctly location,
Microsoft was free to tinker with the path format in Windows Vista.
So a installed SxS dll will go to different locations on Windows XP
and Windows Vista. Because users might migrate their existing XP
installations to Vista, the upgrade process will automatically move
the DLLs to their new home on Vista.
Windows OSes which have SxS will look for an application's manifest
information to determine which version to load from SxS. A manifest
is a fairly simple XML description of all the SxS DLLs that might
be loaded by the application and which version to use. The manifest
can either be embedded in the application EXE/DLL file as a
resource or stored separately on the filesystem as a .manifest
file. In the second case, the manifest file for app.exe would be
called app.exe.manifest.
The manifest resolution algorithm is fairly complex and I won't get
into all the details here, but it can include among other things
searching based on the user's locale (i.e. Look for French/German
version first). As well, to eliminate security disasters like what
happened with gdiplus.dll, SxS DLLs have a "force upgrade"
mechanism implemented as separate security policy files (also XML
files). This mechanism allows Microsoft to override version number
request by applications in the case where some gaping security hole
is discovered in a shared library that effects thousands of
applications. For example, an application manifest may say "I want
version 1.0.0.0 of xyz.dll", but Microsoft can push a policy file
update that says "redirect all request of version 1.0.0.0 to
1.0.0.5".
Thinstall 3.0 has built-in support for SxS and manifest/policy file
handling, so if you capture the installation of an application that
installs SxS dlls it works perfectly on every platform with zero
installation.
If the application normally installs DLLs to c:\windows\winsxs\...
this will be reflected in the capture and show up in your project
under %systemroot%\winsxs\....
At runtime, Thinstall will examine the application's manifest file
(from the resource section or separate .manifest virtual file) and
determine which version of a DLL should be used. Thinstall then
loads the correct version of the DLL from the virtual path
(contained inside the package). Thinstall supports management of
runtime activation contexts as well, so it knows which version of
DLLs to load from dynamic dll loads.
Natively (without Thinstall) SXS is only supported on xp, w2k3, and
vista, but not 2k and NT. This means if you want to support 2k and
NT (without Thinstall) you need to install into 2 locations
(automatically done by MSI installer 3.0):
1. c:\winnt\system32 (or application directory)
2. SXS path location (c:\winnt\winsxs)
Location #1 is required to support nt/2k, and location #2 is
required in order to meet MS's "Designed for Windows" guidelines
which state the app must continue to work if the OS is upgraded
from 2k->xp
Because Thinstall has its own SxS processing, all SxS technology is
available for both nt/2k and xp/w2k3/vista in the Thinstalled
environment. That's right, we bring modern OS technology and make
it work on older platforms!
On Windows Vista, Microsoft has changed the path locations and file
path name-mangling algorithm for SxS DLLs. Thinstall automatically
moves SxS DLLs captured for XP/w2k3 and moves them to the correct
location in virtual space for Windows Vista at runtime when the app
starts – so the same EXE can run on all platforms with no changes.
This is why we advertise Thinstall as "instant migration".
In the case of emergency policy updates, Thinstall will
automatically switch from using the packaged version of DLL to
system DLLs if the system policy file dictates. This means if the
host PC is up to date with Windows update, you are protected from
Thinstalled packages that contain DLLs that fall into this "needs
emergency update" category. When we implemented this, we had a
discussion with the Microsoft SxS team, and they assured us that
policy files are only used in 2 cases:
1. In case of emergency (none have occurred yet)
2. For MS beta products, in this case beta DLLs will be redirected
to shipped versions
Thinstall is the only virtualization technologies which fully
supports SxS which allows you to virtualize most new applications
where virtualization products fail and must have SxS dlls
physically installed on the machine before they will work.