Inside Windows Server 1002003 [Electronic resources] نسخه متنی

Side-by-Side Assemblies

RAM has historically been an expensive commodity, so Microsoft has always designed Windows to be frugal with memory. (Well, if not frugal, at least to gobble it with something less than the conspicuous consumption of a Roman Caesar.)

One way of conserving memory is to share the image of a DLL loaded by one process with other processes. This DLL sharing can cause no end of headaches, as I'm sure you're aware. For instance, a DLL installed by an application might be a version that lacks a function used by another application. If the second application launches after the first, it links to the DLL image that's already in memory. When it makes the ill-fated call to the missing function, the result is generally not pretty. It could be a "Dr. Watson" error or a general protection fault or even a bugcheck (Blue Screen of Death).

Nowadays, memory is much less expensive and reliability is much more important, so Microsoft is trying to reverse course on DLL handling to permit loading multiple versions of the same DLL. This uses more memory and disk space but it reduces compatibility errors.

Microsoft uses the term

assembly to refer to common blocks of code such as DLLs. An assembly designed to run with multiple versions is called a

Side-by-Side (SxS)

assembly . Only two DLLs in Windows Server 2003 and XP are SxS assemblies:

• Shell Common Controls version 6.0 (Comctl32.dll)




• GDI Plus version 1.0 (Gdiplus.dll)

Two DLLs may not seem like much of a revolution, but these two are used by many applications and are potential sources of compatibility problems thanks to the use of

themes in the new interface. By permitting a previous version of these two DLLs to run at the same time, applications are much less likely to experience compatibility issues. Look for an expansion of the number of SxS assemblies in future versions of Windows.