经典编程:DLL地狱及其解决方案

原作者：Ivan S Zapreev 
　　 
译者：陆其明 
　　 
　　概要 
　　 
　　本文将要介绍DLL的向后兼容性问题，也就是著名的“DLL Hell”问题。首先我会列出自己的研究结果，其中包括其它一些研究者的成果。在本文的最后，我还将给出“DLL Hell”问题的一个解决方案。 
　　 
　　介绍 
　　 
　　我曾经接受过一个任务，去解决一个DLL版本更新的问题————某个公司给用户提供了一套SDK，这个SDK是由一系列DLL组成的；DLL中导出了很多类，用户使用这些类（直接使用或派生新的子类）来继续他们的C++程序开发。用户在使用这些DLL时没有得到很详细的使用说明（比如使用这些DLL中导出的类有什么限制等）。当这些DLL更新为新的版本之后，他们发现他们开发的基于这些DLL的应用程序会经常崩溃（他们的应用程序从SDK的导出类派生了新的子类）。为了解决这个问题，用户必须重新编译他们的应用程序，重新连接新版本的SDK DLL。 
　　 
　　我将对这个问题给出我的研究结果，同时还有我从其它地方搜集过来的相关信息。最后，我将来解决这个“DLL Hell”问题。 
　　 
　　研究结果 
　　 
就我个人的理解，这个问题是由SDK DLL中导出的基类改动之后引起的。我查看了一些文章后发现，DLL的向后兼容性问题其实早有人提出。但作为一个实在的研究者，我决定自己做一些试验。结果，我发现如下的问题： 
　　 
　　1. 在DLL的导出类中增加一个新的虚函数将导致如下问题： 
　　 （1）如果这个类以前就有一个虚函数B，此时在它之前增加一个新的虚函数A。这样，我们改变了类的虚函数表。于是，表中的第一个函数指向了函数A（而不是原来的B）。此时，客户程序（假设没有在拿到新版本的DLL之后重新编译、连接）调用函数B就会产生异常。因为此时调用函数B实际上转向了调用函数A，而如果函数A和函数B的参数类型、返回值类型迥异的话问题就出来了！ 
　　 （2）如果这个类原本没有虚函数（它的父类也没有虚函数），那么给这个类增加一个新的虚函数（或者在它的父类增加一个虚函数）将导致新增加一个类成员，这个成员是一个指针类型的，指向虚函数表。于是，这个类的尺寸将会被改变（因为增加了一个成员变量）。这种情况下，客户程序如果创建了这个类的实例，并且需要直接或间接修改类成员的值的时候就会有问题了。因为虚函数表的指针是作为类的第一个成员加入的，也就是说，原本这个类定义的成员因为虚函数表指针的加入而都产生了地址的偏移。客户程序对原成员的操作自然就出现异常了。 
　　 （3）如果这个类原本就有虚函数（或者只要它的父类有虚函数），而且这个类被导出了，被客户程序当作父类来用。那么，我们不要给这个类增加虚函数！不仅在类声明的开头不能加，即使在末尾处也不能加。因为加入虚函数会导致虚函数表内的函数映射产生偏移；即使你将虚函数加在类声明的末尾，这个类的派生类的虚函数表也会因此产生偏移。 
　　 
　　2. 在DLL的导出类中增加一个新的成员变量将导致如下问题： 
　　 （1）给一个类增加一个成员变量将导致类尺寸的改变（给原本有虚函数表的类增加一个虚函数将不会改变类的尺寸）。假设这个成员增加在类声明的最后。如果客户程序为创建这个类的实例少分配了内存，那么可能在访问这个成员时导致内存越界。 
　　 （2）如果在原有的类成员中间增加一个新的成员，情况会更糟糕。因为这样会导致原有类成员的地址产生偏移。客户程序操作的是一个错误的地址表，对于新成员后面的成员尤其是这样（它们都因为新成员的加入而导致了自己在类中的偏移的变化）。 
　　 
　　（注：上述的客户程序就是指使用SDK DLL的应用程序。） 
　　 
　　除了上面这些原因外，还有其它操作会导致DLL的向后兼容性问题。下面列出了解决（大部分）这些问题的方法。 
　　 
　　DLL编码约定简述 
　　 
　　下面是我搜集到的所有的解决方案，其中一些是从网上的文章中拿来的，一些是跟不同的开发者交流后得到的。 
　　 
　　下面的约定主要针对DLL开发，而且是为解决DLL的向后兼容性问题： 
　　 
　　1. 编码约定： 
　　 （1）DLL的每个导出类（或者它的父类）至少包含一个虚函数。这样，这个类就会始终保存一个指向虚函数表的指针成员。这么做可以方便后来新的虚函数的加入。 
　　 （2）如果你要给一个类增加一个虚函数，那么将它加在所有其它虚函数的后面。这样就不会改变虚函数表中原有函数的地址映射顺序。 
　　 （3）如果你打算以后给一个类扩充类成员，那么现在预留一个指向一个数据结构的指针。这样的话，增加