实现应用程序中的并行组件共享（一）

实现应用程序中的并行组件共享（一）2010-05-16摘要：探讨 Microsoft（R） Windows（R） 2000 和 Windows 98 第二版本中并行共享组件的实现（如 Windows 认证规范中讨论的）。包括新的并行组件的创建以及使用 DLL/COM 重定向处理相同组件的不同版本之间的不兼容性。包括编写和安装并行组件以及重新打包和测试应用程序的指南。

介绍

一点背景知识

新组件共享策略

比较两种策略

创建新的并行组件

并行组件编写指南

安装并行组件

DLL/COM 重定向

使用 DLL/COM 重定向

介绍

现代操作系统和应用程序由许多组件构成。组件是自包含的软件实体，该软件实体提供了一组可被各种应用程序广泛使用的函数。因为单独的组件被多个应用程序使用，所以组件的共享是很有必要的。

成功的全局组件共享要求任何共享的组件功能和该组件的先前版本完全一样。但是如果不能实现的话，要达到百分之百的向后兼容实际上是很难的，因为测试所有使用共享组件的配置是非常困难的。新旧应用程序最终都使用相同的组件，因此，随着时间的推移，修正并改进这些组件变得愈加困难。

同时，组件的实际功能也不太容易定义。应用程序可能成为依附在组件上的意外副作用，而不被认为是该组件核心功能一部分。例如，组件中的一个错误可能影响到应用程序，以及当组件开发者选择修正此错误时应用程序失败，这种情况就是人们常说的“DLL Hell（该死的 DLL）”。这使得那些使用组件的应用程序会更加深该问题的严重性。

这种缺乏向后兼容性的情况使得在部署新的应用程序时，必须中断已部署的应用程序，或是牺牲某些新应用程序的功能。所有新的应用程序都要求共享组件的版本与已配置的版本不同。要在增强应用程序稳定性的同时提供成功的共享，Microsoft 已在 Windows 2000 和 Windows 98 第二版本中引入了并行共享，开创了通过选择性隔离来共享组件的新方式。

一点背景知识

在了解并行共享的详细信息之前，让我们看一些背景资料以及“DLL Hell”的问题。

组件共享

Windows 最初就采纳了共享的概念。所有操作系统都在提供稳定性、完整的服务集的需求与操作系统所要求的硬件的资源限制的之间寻求平衡。到目前为止， CPU 用量和磁盘空间仍然是 PC 平台中非常紧张的资源。很显然，要将操作系统和应用程序代码装入到一个很小空间，必须尽可能地共享代码。与许多其他好处相比，代码共享加强了硬件资源的均衡运用，并且最大程度地减少在前期质量保证检测中暴露的问题。代码共享是使 Windows 成功的要素之一。

Windows 的共享并不限于代码。应用程序和组件的状态，可以用注册表状态的形式、文件系统中的应用程序专用数据存储的形式和公开全局命名空间的 Windows API 的形式，在整个操作系统中找到。这类共享，在多个软件供应商生产的应用程序之间提供了高级别的互操作性，降低了成本，提高了软件的效率。

但是，共享也必须付出一些代价。共享意味着应用程序彼此依赖，引入了脆弱性因素。更改某一组件会对其他组件产生无法预料的影响。典型的情况，一个应用程序可能依赖于共享组件的一个特定版本。而另一个应用程序可能是用该共享组件的升级（或降级）版本安装的，因此第一个应用程序可能受此更改的影响。在极端的情况下，曾经工作正常的应用程序会突然功能紊乱，甚至失败。这种情况通常称为“DLL Hell”。

隔离

在系统中，共享的反面是隔离。通过将所有资源和代码静态地绑定到应用程序，可以隔离应用程序。但是如今对于依赖于 COM 或其他全局存储的系统资源的应用程序来说，完全的隔离是不可行的。

减少应用程序脆弱性的一种解决办法是，有选择地隔离应用程序和组件。在这种方案中，所有应用程序可能都具有对相同组件的访问权，但该组件目前有多个版本可用。组件开发者有权编制旧组件的新版本、作一些改进或修正错误。而客户可以选择适合于特定应用程序的版本。就像走进一个汽车配件商店为您的 1984 Chevy 挑选一个燃油泵一样。您会发现货架上的这个泵和一些比它晚来的适用于其他车型的泵并行放在一起。在使用组件的情况下，关键是提供适合于每个应用程序的版本并且隔离其他不同的版本。而且，在重定向的情况下，应用程序可以进行配置，以使用适合于该特定应用程序的组件版本，而不管最近开发的或以后将要开发那些版本。