Side-by-Side (SxS)
Previous  Top  Next

Overview of Windows Side by Side technology

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 of xyz.dll", but Microsoft can push a policy file update that says "redirect all request of version to".

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.