A bit of history
Since the very beginning Windows used dynamic link libraries. In the days of 12MHz 80286 processors or 25 MHz i386 when 16MB of RAM was considered lavish, every byte counted. DLLs saved the precious RAM by using the same image for multiple tasks loaded at the same time. In the beginning only the operating system came with DLLs but very soon developers started using this mechanism to not only share code between tasks but also to load pieces of functionality as they were needed and unload them when the task no longer required them. We use DLLs today, but not necessarily because of memory constraints. We use them for common code, code libraries, optional functionality, COM components, internationalization and many other reasons.
The Problem
As new DLLs came out of Microsoft and a myriad of software vendors, older versions were replaced by new versions. Installation routines were expected to check if any of the installed DLLs already existed on the target machine and only replace it, if the DLL to be installed is newer then the already in the system. Alas, many install processes checked incorrectly or did not check at all and wrote their respective files regardless of what was already in place. The day the first DLL was replaced by an older version was the first day of DLL hell - programs began to break because of wrong DLL versions. After that it only got worse. Software vendors released new versions of their DLLs which were incompatible with old versions but replaced the old versions anyway. Setup programs replaced new DLLs with old DLLs. Product installations replaced system components with versions that did not match the rest of the OS and took the whole system down. The situation required a major remedy.
The Solution
To stabilize the operating system Microsoft added protective measures to the OS. System files could no longer be replaced, an if they were, the OS restored them to the known good version. The library search path was modified to include the application own directory first. This allowed every application to include private versions of DLLs independently of other applications. Unfortunately none of these measures could address a whole major class of libraries - COM components. COM components are registered in the system registry and by design there could only be one version of any COM components registered at a time.
Enter Side-by-Side
With Windows XP Microsoft introduced new technology: Win32 Side-by-Side. DLLs, including COM components, TLBs and other files can now be grouped in assemblies described by accompanying manifests. No COM registration is required and files do not reside in System or System32 directories. Applications can use their own manifests to specify which assemblies they want to use. There can be multiple, possibly incompatible, versions of the same COM component or the same non-COM DLL and multiple applications running at the same time can use any versions they choose. Finally there is a way of battling DLL hell. This technology is available in all 32-bit and 64-bit versions of Windows starting with Windows XP and including Windows 10 as well Windows Server. Please note that because Microsoft ended support of Windows XP and Vista Manifest Maker no longer supports these platforms.
Technical details
It is important to understand that the same or very similar terminology is used by both win32 side-by-side and .Net technology. Win32 side-by-side assemblies and manifests are not the same as .Net assemblies and manifests - do not confuse them.
A win32 side-by-side assembly is a collection of any files described by a common manifest. The manifest is an XML file matching a predefined schema. http://msdn2.microsoft.com/en-us/library/aa375632.aspx.
The Windows system loader and COM implementation have been modified to implement this new technology. As a new process is created, the operating system creates an activation context for the process. This is a list of all files, COM attributes and window classes included in the application manifest and all manifests recursively referenced by that manifest. Any request for a COM component first checks if this component is included in the activation context. Any request to load a module using LoadLibraryExW (all other forms of LoadLibrary* eventually call this function) first checks if the module should be loaded from a location described by the activation context.
Why do you need side-by-side
From the above discussion it is pretty obvious that side-by-side is the only way for win32 applications to gain independence of the central registration of COM components and a very convenient way to make explicit choices as to which DLLs it should be using.
Developers:
make your applications stable and avoid being broken by other installations
that might replace the components you use.
ISVs:
package your libraries intro cohesive packages that work regardless of everybody
else breaking the system and other applications. Stop having to worry about
binary compatibility between versions.
Corporate deployments:
package applications with specific sets of DLLs and COM information; once tested
and deployed they will not break as other applications are installed.
Power users:
take control of your systems, corral conflicting programs, make the system stable
and applications worry-free.
Why do you need our help
We know win32 side-by-side (both 32-bit and 64-bit) inside out. We know how it works, where it works and, most importantly, where it does not work. We offer consulting, mentoring and development services. Whether you need guidance for your developers or help in corporate deployment planning contact us at sxs@manifestmaker.com. We are here to help you.
Why you need Side-by-Side Manifest Maker
Typing XML by hand is tedious and error prone. Creating XML using general XML editing tools helps you make the XML well-formed and valid, but you still have to identify and type in all appropriate GUIDs, ProgIDs and other attributes. Look in your own %systemroot%\WinSxS\Manifests directory. Open any manifest file with notepad or an XML editing tool. In our experience it takes between 2 and 8 hours to create a manifest comparable to x86_Microsoft.MSXML2_6bd6b9abf345378f_4.1.0.0_x-ww_b319d8da.Manifest (if you do not have Microsoft XML 4 installed, download it from Microsoft: http://www.microsoft.com/downloads/details.aspx?familyid=3144b72b-b4f2-46da-b4b6-c5d7485f2b42&displaylang=en). It takes 5 to 10 minutes to create it with Side-by-Side Manifest Maker. And, in almost all cases, our manifest is right the first time.