Windows刚出现时，应用程序都是静态链接的，方式非常简单，应用程序运载着自己的链接，从没发生过混乱。然而，这种简单是有代价的。

　　很明显，每一个应用程序都要携带相同的库，是有存储成本的。当时人们认为500M的磁盘就很大了，所以存储成本非常昂贵。当然，也修复了一些故障。如果发现了安全故障，必须要重新构建每一个应用程序，确保故障在所有的地方都被解决了。如果想为已经安装的应用做一次更新，简单是一场噩梦，通常是不可能的。曾经有个问题，某些库文件必须从平台得到，例如，设备驱动程序和操作系统库文件。这些库文件不能静态链接。

　　微软提出的解决方案是动态链接库（DLL），这个概念，就是当时Unix用户非常熟悉的共享库。它是这样工作的：加载应用程序时，加载器会自己加载DLL到内存中，在DLL中链接应用程序的代码和数据。DLL还可以信赖其他的DLL，所以加载器可能会需要递归的链接DLL，结果常常是一个复杂的信赖关系图。开发者接受了它，认为它不错。也就是说，开始大量的使用这个功能。然后就乱套了，为什么呢？因为共享是很难的，就像我们第一次在幼儿园学习一样。

　　共享

　　软件共享问题是所有的参与者必须同意一直都要共享。应用程序开发者熟知捷径，侵入库文件，以获得额外的特性，或者修补一些另人讨厌的故障，这将永远流行。不幸的是，一个开发者的修复办法让另一开发者感到恐慌，尤其是，其他开发者修复的问题。所以，修改过的DLL文件总是不能和所有使用它的应用程序兼容。在C++中，在类中添加一个方法，总是使编译后的代码与DLL不兼容。应用开发者始终没有考虑共享的后果，践踏（覆盖）已经安装的DLL文件，引起其他应用程序崩溃，使很多系统管理员产生阴影。

　　最初，DLL甚至是没有版本。后来才添加上的，但是，一些开发人员不太关心这些，包括微软自己也没有正确的DLL版本，所以，版本不能解决这个烂摊子。然而，即使版本、所有组件的标记都正确，人们也会遇到无法解决的情况，在信赖中造成不一样性。

　　我来解释一下。如果你有信赖关系图，你可以通过不同路径依赖相同的DLL，但是，每一个系统规定的参数可以是不同的。例如，一个颇为流行的LOG DLL。WIDGET DLL以及COMM DLL都使用这个库。见相邻的图片。

　　如果COMM.DLL需要LOG.DLL V1，WIDGET.DLL需要V2，加载器必须做一个选择，LOG。DLL只能在V1或者V2中链接一次。这就是所谓的“原子”问题，图片看起来像个钻石。在大的依赖关系中，这些不一致的问题是不可避免的，除非有单一的代码，所有组件在同一时间变化。

　　原子问题的解决方案是要始终向后兼容。如果LOG.DLL V2向后兼容V1，那么聪明的加载器会选择最新的版本。然而，迫使后代总是保持向后兼容现在的特性不是最佳方案，对开发者来说是残酷的。

　　共享的一个解决方案是隔离开来：停止共享。在Windows中，解决DLL痛苦的情况，应用程序因此允许他们自己的DLL搜索路径，使他们能有一个私有的DLL复本。这又回到了原点，只是增加了一些额外的复杂性：浪费内存，没有单独的故障修复的地方等。

　　为什么共享呢？

　　共享的所有问题，它值得吗？在Java中，WAR概念非常流行，清楚的隔离开来：每一个WAR包含所有的依赖，除了Java环境和应用程序服务器提供的库文件。是的，部署时有很多严重的问题，因为大公司在许多不同的WAR中复制了相同的库文件，引起了上传延迟等问题。在一些网站，虚拟机试图处理数量庞大，往往又不必要的字节码时会爆裂。然而，这些问题都有解决方案，应该明确公平的共享等问题。

　　所以，共不共享是一个问题。

　　我相信共享是必然发生的，从八十年代我工作的时候就有了这个信念。软件应该通过明确的接口，从组件上建立一对一的合作。这是解决这个大泥球问题的唯一方式，代码的维护和修改变得越来越难。如果你的软件依赖关系图看起来像Jackson Pollock，你就会有这样一个大泥球。

　　在组件模型中，我们必须把开发者（开发组件）和汇编者（把组件组装到应用程序中）的角色分开。在我们行业中，许多工作都朝不同软件子系统的更多的自主权方向发展。开源项目确实接近组件，但是，不幸地是它不是一个稳定的模块系统，该系统使这些组件更容易地使用。

　　更高的自主性需要共享接口，并让所有的组件联系起来，尽可能的保持最大的灵活性。组件开发人员甚至不喜欢看到组合组件，以防止不必要的依赖关系。组件越少，出现的错误越少。在组件开发中，只有契约是可见的。在这个模型中，这些组件组合到一起，形成了一个应用程序。

　　在《OSGI：让共享变得快乐（下）》中，我们将继续介绍相关内容。