DLLHell

COM对象常常被编译为dll文件。COM组件模型虽然很不错&＃xff0c;但是它自身存在致命的缺陷。由于COM对象可以被重用&＃xff0c;这样多个程序可能使用一个COM对象 &＃xff0c;如果这个COM组件升级了&＃xff0c;就很有可能出现其中某个程序无法使用新组件&＃xff0c;导致程序不能运行的情况&＃xff0c;这种情况被称为“DLL HELL”。有时安装了新的软件后很多其他的软件都无法使用&＃xff0c;往往就是这个原因。

Windows系统是以Dynamic Link Library&＃xff08;动态链接库&＃xff09;的方式让系统和应用软件共用所有的系统文件的。

DLL Hell的意思就是因为系统文件被覆盖而让整个系统像是掉进了地狱&＃xff08;什么软件都不能运行了&＃xff09;。

可能的原因

很多windows的应用程序在发布的时候会将它们所有要用到的DLL都一起打包发布&＃xff0c;很多应用程序的安装程序都不是很成熟&＃xff0c;经常在安装的时候将一个旧版本的DLL覆盖掉一个更新版本的DLL&＃xff0c;从而导致其他的应用程序运行失败。有些安装程序比较友好&＃xff0c;如果碰到需要覆盖新版的DLL时&＃xff0c;它会弹出一个对话框提醒用户是否覆盖&＃xff0c;但是即使这样&＃xff0c;有些应用程序只能运行在旧版本的DLL下&＃xff0c;如果不覆盖&＃xff0c;那么它可能无法在新版的DLL中运行。总的来说&＃xff0c;有三种可能的原因导致了DLL Hell的发生&＃xff1a; 一是由使用旧版本的DLL替代原来一个新版本的DLL而引起的。这个原因最普遍&＃xff0c;是Windows 9X用户通常遇到的DLL错误之一。 二是由新版DLL中的函数无意发生改变而引起。尽管在设计DLL时候应该向下兼容&＃xff0c;然而要保证DLL完全向下兼容却是不能的。

三是由新版DLL的安装引入一个新的Bug。

1. 在DLL的导出类中增加一个新的虚函数将导致如下问题&＃xff1a; 

　　&＃xff08;1&＃xff09;如果这个类以前就有一个虚函数B&＃xff0c;此时在它之前增加一个新的虚函数A。这样&＃xff0c;我们改变了类的虚函数表。于是&＃xff0c;表中的第一个函数指向了函数A&＃xff08;而不是原来的B&＃xff09;。此时&＃xff0c;客户程序&＃xff08;假设没有在拿到新版本的DLL之后重新编译、连接&＃xff09;调用函数B就会产生异常。因为此时调用函数B实际上转向了调用函数A&＃xff0c;而如果函数A和函数B的参数类型、返回值类型迥异的话问题就出来了&＃xff01;

　　&＃xff08;2&＃xff09;如果这个类原本没有虚函数&＃xff08;它的父类也没有虚函数&＃xff09;&＃xff0c;那么给这个类增加一个新的虚函数&＃xff08;或者在它的父类增加一个虚函数&＃xff09;将导致新增加一个类成员&＃xff0c;这个成员是一个指针类型的&＃xff0c;指向虚函数表。于是&＃xff0c;这个类的尺寸将会被改变&＃xff08;因为增加了一个成员变量&＃xff09;。这种情况下&＃xff0c;客户程序如果创建了这个类的实例&＃xff0c;并且需要直接或间接修改类成员的值的时候就会有问题了。因为虚函数表的指针是作为类的第一个成员加入的&＃xff0c;也就是说&＃xff0c;原本这个类定义的成员因为虚函数表指针的加入而都产生了地址的偏移。客户程序对原成员的操作自然就出现异常了。 

　　&＃xff08;3&＃xff09;如果这个类原本就有虚函数&＃xff08;或者只要它的父类有虚函数&＃xff09;&＃xff0c;而且这个类被导出了&＃xff0c;被客户程序当作父类来用。那么&＃xff0c;我们不要给这个类增加虚函数&＃xff01;不仅在类声明的开头不能加&＃xff0c;即使在末尾处也不能加。因为加入虚函数会导致虚函数表内的函数映射产生偏移&＃xff1b;即使你将虚函数加在类声明的末尾&＃xff0c;这个类的派生类的虚函数表也会因此产生偏移。

　　2. 在DLL的导出类中增加一个新的成员变量将导致如下问题&＃xff1a;

　　&＃xff08;1&＃xff09;给一个类增加一个成员变量将导致类尺寸的改变&＃xff08;给原本有虚函数表的类增加一个虚函数将不会改变类的尺寸&＃xff09;。假设这个成员增加在类声明的最后。如果客户程序为创建这个类的实例少分配了内存&＃xff0c;那么可能在访问这个成员时导致内存越界。

　　&＃xff08;2&＃xff09;如果在原有的类成员中间增加一个新的成员&＃xff0c;情况会更糟糕。因为这样会导致原有类成员的地址产生偏移。客户程序操作的是一个错误的地址表&＃xff0c;对于新成员后面的成员尤其是这样&＃xff08;它们都因为新成员的加入而导致了自己在类中的偏移的变化&＃xff09;。

DLL编码约定简述

　　下面是我搜集到的所有的解决方案&＃xff0c;其中一些是从网上的文章中拿来的&＃xff0c;一些是跟不同的开发者交流后得到的。

　　下面的约定主要针对DLL开发&＃xff0c;而且是为解决DLL的向后兼容性问题&＃xff1a;

　　1. 编码约定&＃xff1a;

　　&＃xff08;1&＃xff09;DLL的每个导出类&＃xff08;或者它的父类&＃xff09;至少包含一个虚函数。这样&＃xff0c;这个类就会始终保存一个指向虚函数表的指针成员。这么做可以方便后来新的虚函数的加入。

　　&＃xff08;2&＃xff09;如果你要给一个类增加一个虚函数&＃xff0c;那么将它加在所有其它虚函数的后面。这样就不会改变虚函数表中原有函数的地址映射顺序。

　　&＃xff08;3&＃xff09;如果你打算以后给一个类扩充类成员&＃xff0c;那么现在预留一个指向一个数据结构的指针。这样的话&＃xff0c;增加一个成员直接在这个数据结构中修改&＃xff0c;而不是在类中修改。于是&＃xff0c;新成员的加入不会导致类尺寸的改变。当然&＃xff0c;为了访问新成员&＃xff0c;需要给这个类定义几个操作函数。这种情况下&＃xff0c;DLL必须是被客户程序隐式&＃xff08;implicitly&＃xff09;连接的。

　　&＃xff08;4&＃xff09;为了解决前一点的问题&＃xff0c;也可以给所有的导出类设计一个纯接口的类&＃xff0c;但此时&＃xff0c;客户程序将无法从这些导出类继续派生&＃xff0c;DLL导出类的层次机构也将无法维持。

　　&＃xff08;5&＃xff09;发布两个版本的DLL和LIB文件&＃xff08;Debug版本和Release版本&＃xff09;。因为如果只发布Release版本&＃xff0c;开发者将无法调试他们的程序&＃xff0c;因为Release版与Debug版使用了不同的堆&＃xff08;Heap&＃xff09;管理器&＃xff0c;因而当Debug版本的客户程序释放Release版本DLL申请的内存时&＃xff0c;会导致运行时错误&＃xff08;Runtime failure&＃xff09;。有一种办法可以解决这个问题&＃xff0c;就是DLL同时提供申请和释放内存的函数供客户程序调用&＃xff1b;DLL中也保证不释放客户程序申请的内容。通常遵守这个约定不是那么简单&＃xff01;

&＃xff08;6&＃xff09;在编译的时候&＃xff0c;不要改变DLL导出类函数的默认参数&＃xff0c;如果这些参数将被传递到客户程序的话。

　　&＃xff08;7&＃xff09;注意内联&＃xff08;inline&＃xff09;函数的更改。

　　&＃xff08;8&＃xff09;检查所有的枚举没有默认的元素值。因为当增加/删除一个新的枚举成员&＃xff0c;你可能移动旧枚举成员的值。这就是为什么每一个成员应该拥有一个唯一标识值。如果枚举可以被扩展&＃xff0c;也应该对其进行文档说明。这样&＃xff0c;客户程序开发者就会引起注意。

　　&＃xff08;9&＃xff09;不要改变DLL提供的头文件中定义的宏。

2. 对DLL进行版本控制&＃xff1a;如果主要的DLL发生了改变&＃xff0c;最好同时将DLL文件的名字也改掉&＃xff0c;就象微软的MFC DLL一样。例如&＃xff0c;DLL文件可以按照如下格式命名&＃xff1a;Dll_name_xx.dll&＃xff0c;其中xx就是DLL的版本号。有时候DLL中做了很大的改动&＃xff0c;使得向后兼容性问题无法解决。此时应该生成一个全新的DLL。将这个新DLL安装到系统时&＃xff0c;旧的DLL仍然保留。于是&＃xff0c;旧的客户程序仍然能够使用旧的DLL&＃xff0c;而新的客户程序&＃xff08;使用新DLL编译、连接&＃xff09;可以使用新的DLL&＃xff0c;两者互不干涉。

　　3. DLL的向后兼容性测试&＃xff1a;还有很多很多中可能会破坏DLL的向后兼容性&＃xff0c;因此实施DLL的向后兼容性测试是非常必要的&＃xff01;

　　接下去&＃xff0c;我将来讨论一个虚函数的问题&＃xff0c;以及对应的一个解决方案。

　　虚函数与继承

　　首先来看一下如下的虚函数和继承结构&＃xff1a;

/**********DLL导出的类 **********/ class EXPORT_DLL_PREFIX VirtFunctClass{ 　public: 　　VirtFunctClass(){} 　　~VirtFunctClass(){} 　　virtual void DoSmth(){ 　　　//this->DoAnything();  　　　// Uncomment of this line after the corresponding method  　　　//will be added to the class declaration 　　} 　　//virtual void DoAnything(){}  　　// Adding of this virtual method will make shift in  　　// table of virtual methods }; /**********客户程序&＃xff0c;从DLL导出类派生一个新的子类**********/ class VirtFunctClassChild : public VirtFunctClass { 　public: 　　VirtFunctClassChild() : VirtFunctClass (){} 　　~VirtFunctClassChild(){}; 　　virtual void DoSomething(){} };

　　假设上面的两个类&＃xff0c;VirtFunctClass在my.dll中实现&＃xff0c;而VirtFunctClassChild在客户程序中实现。接下去&＃xff0c;我们做一些改变&＃xff0c;将如下两个注释行放开&＃xff1a;

//virtual void DoAnything(){}

　　和

//this->DoAnything();

　　也就是说&＃xff0c;DLL导出的类作了改动&＃xff01;现在如果客户程序没有重新编译&＃xff0c;那么客户程序中的VirtFunctClassChild将不知道DLL中VirtFunctClass类已经改变了&＃xff1a;增加了一个虚函数void DoAnything()。因此&＃xff0c;VirtFunctClassChild类的虚函数表仍然包含两个函数的映射&＃xff1a;

　　1. void DoSmth() 
　　2. void DoSomething() 

　　而事实上这已经不对了&＃xff0c;正确的虚函数表应该是&＃xff1a;

　　1. void DoSmth() 
　　2. void DoAnything() 
　　3. void DoSomething() 

　　问题就在于&＃xff0c;当实例化VirtFunctClassChild之后&＃xff0c;如果调用它的void DoSmth()函数&＃xff0c;DoSmth()函数转而要调用void DoAnything()函数&＃xff0c;但此时基类VirtFunctClass只知道要调用虚函数表中的第二个函数&＃xff0c;而VirtFunctClassChild类的虚函数表中的第二个函数仍然是void DoSomething()&＃xff0c;于是问题就出来了&＃xff01;

　　另外&＃xff0c;禁止在DLL的导出类的派生类&＃xff08;上例中的VirtFunctClassChild&＃xff09;中增加虚函数也是于事无补的。因为&＃xff0c;如果VirtFunctClassChild类中没有virtual void DoSomething()函数&＃xff0c;基类中的void DoAnything()函数&＃xff08;虚函数表中的第二个函数&＃xff09;调用将会指向一个空的内存地址&＃xff08;因为VirtFunctClassChild类维持的虚函数表仅仅维持有一个函数地址&＃xff09;。

　　现在可以看出&＃xff0c;在DLL的导出类中增加虚函数是一个多么严重的问题&＃xff01;不过&＃xff0c;如果虚函数是用来处理回调事件的&＃xff0c;我们有办法来解决这个问题。

COM及其它

　　现在可以看出&＃xff0c;DLL的向后兼容性问题是一个很出名的问题。解决这些问题&＃xff0c;不仅可以借助于一些约定&＃xff0c;而且可以通过其它一些先进的技术&＃xff0c;比如COM技术。因此&＃xff0c;如果你想摆脱“DLL Hell”问题&＃xff0c;请使用COM技术或者其它一些合适的技术。

　　让我们回到我接受的那个任务&＃xff08;我在本文开头的地方讲到的那个任务&＃xff09;————解决一个使用DLL的产品的向后兼容性问题。

　　我对COM有些了解&＃xff0c;因此我的第一个建议是使用COM技术来克服那个项目中的所有问题。但这个建议因为如下原因最终被否决了&＃xff1a;

　　1. 那个产品已经在某个内部层中有一个COM服务器。

　　2. 将一大堆接口类重写到COM的形式&＃xff0c;投入比较大。

　　3. 因为那个产品是DLL库&＃xff0c;而且已经有很多应用程序在使用它了。因此&＃xff0c;他们不想强制他们的客户重写他们的应用程序。

　　换句话说&＃xff0c;我被要求完成的任务是&＃xff0c;以最小的代价来解决这个DLL向后兼容性问题。当然&＃xff0c;我应该指出&＃xff0c;这个项目最主要的问题在于增加新的成员和接口类上的虚回调函数。第一个问题可以简单地通过在类声明中增加一个指向一个数据结构的指针来解决&＃xff08;这样可以任意增加新的成员&＃xff09;。这种方法我在上面已经提到过。但是第二个问题&＃xff0c;虚回调函数的问题是新提出的。因此&＃xff0c;我提出了下面的最小代价、最有效的解决方法。

　　虚回调函数与继承

　　然我们想象一下&＃xff0c;我们有一个DLL&＃xff0c;它导出了几个类&＃xff1b;客户应用程序会从这些导出类派生新的类&＃xff0c;以实现虚函数来处理回调事件。我们想在DLL中做一个很小的改动。这个改动允许我们将来可以给导出类“无痛地”增加新的虚回调函数。同时&＃xff0c;我们也不想影响使用当前版本DLL的应用程序。我们期望的就是&＃xff0c;这些应用程序只有在不得已的时候才协同新版本的DLL进行一次重新编译。因此&＃xff0c;我给出了下面的解决方案&＃xff1a;

　　我们可以保留DLL导出类中的每个虚回调函数。我们只需记住&＃xff0c;在任何一个类定义中增加一个新的虚函数&＃xff0c;如果应用程序不协同新版本的DLL重新编译&＃xff0c;将导致严重的问题。我们所做的&＃xff0c;就是想要避免这个问题。这里我们可以一个“监听”机制。如果在DLL导出类中定义并导出的虚函数被用作处理回调&＃xff0c;我们可以将这些虚函数转移到独立的接口中去。

　　让我们来看下面的例子&＃xff1a;

// 如果想要测试改动过的DLL&＃xff0c;请将下面的定义放开 //#define DLL_EXAMPLE_MODIFIED #ifdef DLL_EXPORT #define DLL_PREFIX __declspec(dllexport) #else #define DLL_PREFIX __declspec(dllimport) #endif /********** DLL的导出类 **********/ #define CLASS_UIID_DEF static short GetClassUIID(){return 0;} #define OBJECT_UIID_DEF virtual short  GetObjectUIID(){return this->GetClassUIID();} // 所有回调处理的基本接口 struct DLL_PREFIX ICallBack { 　CLASS_UIID_DEF 　OBJECT_UIID_DEF }; #undef CLASS_UIID_DEF #define CLASS_UIID_DEF(X) public: static  short GetClassUIID(){return X::GetClassUIID()&＃43;1;} // 仅当DLL_EXAMPLE_MODIFIED宏已经定义的时候&＃xff0c;进行接口扩展 #if defined(DLL_EXAMPLE_MODIFIED) // 新增加的接口扩展 struct DLL_PREFIX ICallBack01 : public ICallBack { 　CLASS_UIID_DEF(ICallBack) 　OBJECT_UIID_DEF 　virtual void DoCallBack01(int event) &＃61; 0; // 新的回调函数 }; #endif // defined(DLL_EXAMPLE_MODIFIED) class DLL_PREFIX CExample{ 　public: 　　CExample(){mpHandler &＃61; 0;} 　　virtual ~CExample(){} 　　virtual void DoCallBack(int event) &＃61; 0; 　　ICallBack * SetCallBackHandler(ICallBack *handler); 　　void Run(); 　private:  　　ICallBack * mpHandler; };

很显然&＃xff0c;为了给扩展DLL的导出类&＃xff08;增加新的虚函数&＃xff09;提供方便&＃xff0c;我们必须做如下工作&＃xff1a;

　　1. 增加ICallBack * SetCallBackHandler(ICallBack *handler);函数&＃xff1b;

　　2. 在每个导出类的定义中增加相应的指针&＃xff1b;

　　3. 定义3个宏&＃xff1b;

　　4. 定义一个通用的ICallBack接口。 

　　为了演示给CExample类增加新的虚回调函数&＃xff0c;我在这里增加了一个ICallBack01接口的定义。很显然&＃xff0c;新的虚回调函数应该加在新的接口中。每次DLL更新都新增一个接口&＃xff08;当然&＃xff0c;每次DLL更新时&＃xff0c;我们也可以给一个类同时增加多个虚回调函数&＃xff09;。

　　注意&＃xff0c;每个新接口必须从上一个版本的接口继承。在我的例子中&＃xff0c;我只定义了一个扩展接口ICallBack01。如果DLL再下个版本还要增加新的虚回调函数&＃xff0c;我们可以在定义一个ICallBack02接口&＃xff0c;注意ICallBack02接口要从ICallBack01接口派生&＃xff0c;就跟当初ICallBack01接口是从ICallBack接口派生的一样。

　　上面代码中还定义了几个宏&＃xff0c;用于定义需要检查接口版本的函数。例如我们要为新接口ICallBack01增加新函数DoCallBack01&＃xff0c;如果我们要调用ICallBack * mpHandler; 成员的话&＃xff0c;就应该在CExample类进行一下检查。这个检查应该如下实现&＃xff1a;

if(mpHandler !&＃61; NULL && mpHandler->GetObjectUIID()>&＃61;ICallBack01::GetClassUIID()){ 　((ICallBack01 *) mpHandler)->DoCallBack01(2); }

　　我们看到&＃xff0c;新回调接口增加之后&＃xff0c;在CExample类的实现中只需简单地插入新的回调调用。

　　现在你可以看出&＃xff0c;我们上述对DLL的改动并不会影响客户应用程序。唯一需要做的&＃xff0c;只是在采用这种新设计后的第一个DLL版本&＃xff08;为DLL导出类增加了宏定义、回调基本接口ICallBack、设置回调处理的SetCallBackHandler函数&＃xff0c;以及ICallBack接口的指针&＃xff09;发布后&＃xff0c;应用程序进行一次重编译。&＃xff08;以后扩展新的回调接口&＃xff0c;应用程序的重新编译不是必需的&＃xff01;&＃xff09;

　　以后如果有人想要增加新的回调处理&＃xff0c;他就可以通过增加新接口的方式来实现&＃xff08;向上例中我们增加ICallBack01一样&＃xff09;。显然&＃xff0c;这种改动不会引起任何问题&＃xff0c;因为虚函数的顺序并没有改变。因此应用程序仍然以以前的方式运行。唯一你要注意的是&＃xff0c;除非你在应用程序中实现了新的接口&＃xff0c;否则你就接收不到新增加的回调调用。