雷诺进气出强差别大吗:VC 实现应用程序对插件的支持

　　引言

　　目前，不少流行软件都提供有对外挂插件的支持功能，如Winamp、Realplay等等。这些软件通过对插件技术的使用为日后的软件升级和功能扩展提供了相当的便利条件。 尤为重要的是，通过使用插件技术，使得对软件的功能扩展将不再完全受限于软件厂商，任何第三方开发商或是程序员个人只要遵循了软件提供的插件接口标准去开发插件就完全可以同主体软件有很好的兼容，从而使用户对应用程序进行个性化功能扩展成为了可能。基于插件技术的以上诸多优势，本文下面将围绕插件的制作、应用程序对插件的支持等具体问题对其展开讨论。

　　设计思路及插件接口标准

　　通常支持插件的应用程序多将外挂扩展插件集中放置于某个指定的目录下，程序执行时首先在此目录下搜寻是否有插件存在，如有则为插件将其插入到应用程序，应用程序在终止运行时负责将插件释放。

　　至于插件以何种形式提供则没有固定的规定，可以是独立的应用程序，也可以是动态链接库或是其他一些文件格式，不管插件具体以何种形式提供，都是以方便使用为目的。本文即以使用较为灵活的动态链接库作为插件的提供形式，动态链接库通过外部导出函数为应用程序提供对插件功能的调用，应用程序在对动态链接库进行动态装载时也比较容易实现。这里与以往对动态链接库的使用有所不同，通常的应用程序事先已经明确知道需要使用哪些动态链接库，动态链接库又提供有哪些函数等信息，而允许使用插件的应用程序在发布时则无法预知在软件发布后第三方开发商将会开发出多少插件、插件都提供有什么功能函数等。因此这就需要在容许插件的应用程序和插件之间建立一种统一的接口标准并通过此接口标准完成对所有后期插件的管理。在此，主程序和插件之间是通过一个标准的DLL导出函数来实现的，主要用于在主体程序内插件对象的创建：
　　BOOL Plug_CreateObject(void ** pobj)
　　{
　　*pobj = new CPlugA;
　　return *pobj != NULL;
　　}
　　

　　
　　 其中类CPlugA是在动态链接库中由基类CPlugBase派生出来的，提供有插件的大部分主要功能，如插件图标的获取、插件提供的功能接口函数以及插件的释放等。基类CPlugBase的结构如下：
　　class CPlugBase
　　{
　　public:
　　CPlugBase(){};
　　virtual HICON GetIcon() = 0;
　　virtual void Interface(int k) = 0;
　　virtual void Release() = 0;
　　};
　　
　　 考虑到主体程序无法预知待插入的插件数目，为管理插件对象方便， 通过模板类CArray完成对各个插件对象的存储与管理，此模板类所管理的数组为PLUG_ST结构对象。PLUG_ST结构记录了插件类提供的的CPlugBase型指针和作为插件载体的动态链接库的实例句柄，其具体定义如下：
　　typedef struct{
　　CPlugBase * pObj;
　　HINSTANCE hIns;
　　}PLUG_ST, * LPPLUG_ST;
　　

　　另外，在程序界面上，每向应用程序添加一个新的插件，都应当在主程序的界面上增添与之相关联的按钮或菜单等，以便用户可以通过位于主程序界面上的按钮或菜单实现对插件内部功能函数的调用。本文在此是通过向工具条增添按钮的方式来达到此目的的，按钮上的图标由插件提供，应用程序通过插件类的GetIcon（）函数获取到图标句柄，并将其绘制在工具条按钮上。

　　为普通应用程序扩展插件支持功能

　　插件支持功能并非Winamp、RealPlay等大牌软件所独有，任何普通应用程序经过程序编码均可将其扩展为支持插件的应用程序。通常将这部分扩展代码在主框架类中完成，根据前面所述思路，首先从应用程序所在目录下搜寻子目录PLUGINS下是否存在以动态链接库形式提供的插件，如果在此目录下没有找到动态链接库那么就说明当前还没有插件，因此程序也就不需要做进一步处理，如果找到插件，就一一将其插入到应用程序。搜寻插件的部分代码如下：

　　其中，CreatePlug（）函数负责将插件装载到应用程序，其参数指定了待装载的插件的绝对路径。在实现时，首先通过LoadLibrary（）函数将插件模块装载到内存，并将获取到的实例句柄保存到PLUG_ST结构的hIns中，最后将此结构对象添加到CArray模板类对象m_arrPlugObj中，主要实现代码如下：
　　

　　同用户交互部分，则采取这样的处理：将所有插件的图标从插件动态链接库中提取出来，并放置于图象列表，最后在浮动工具条上创建对应的按钮并将插件图标绘制其上。同样也是出于对后期插件的不可预知性，在工具条上创建按钮的资源ID从ID_PLUG_POINTER开始，依次累加。具体实现可参考如下代码：
　　

　　对于各个插件按钮的命令响应也不能以通常的ON_COMMAND宏执行命令映射，而要以ON_COMMAND_RANGE宏实现对一个ID范围的命令映射：
　　

　　为保证系统资源的有效释放，在程序终止之前必须确保将加载过的所有插件资源予以释放：
　　

　　至此，只要应用程序在PLUGINS子目录下发现了插件动态链接库的存在，就会将其装载到程序并通过工具条按钮完成用户同新添加插件的交互。如要从程序去掉某个插件只需在插件目录下将对应的插件模块删除即可。

　　 插件的制作

　　 插件的制作其实就是对动态链接库的创建，因此总的来说比较简单，但是作为插件载体的动态链接库与普通的动态链接库还是有一些区别的。例如，插件需要为主体应用程序提供图标，因此不仅在资源中要引入插件图标，而且在编译时还要将其设置为"Use MFC in a Static Library"以便在编译时能将所有的资源打包到插件模块，否则在应用程序插入插件时将无法在工具条按钮上绘制图标。插件在创建时同样也必须遵循其同主体程序的接口标准，这主要通过导出函数来体现的：

　　在前面已经提到过，CPlugA是基类CPlugBase的一个派生类，可以根据需要对CPlugBase的几个虚函数进行重载，以实现本插件所独有的一些功能。另外，由于主体程序是通过GetIcon（）来获取插件图标的，因此必须在动态链接库被加载时首先通过LoadIcon（）函数将图标装载到内存并保存其句柄于m_hIcon，等待主程序通过GetIcon（）函数来获取，该句柄的释放在当动态链接库被释放时由函数DeleteObject（）来执行。

　　 小结

　　 通过前述方法可以为普通应用程序添加插件支持功能，并可以在软件发布后以插件的形式对软件进行功能上的扩展，操作过程也比较灵活方便。由于经过这种扩展，使软件的各大功能模块分布于不同的插件，在软件升级或维护时只需对相应的插件进行替换即可，这对软件的升级维护可以起到积极的作用。本文所述程序在Windows 98下由Microsoft Visual C++ 6.0编译通过。

　　引言

　　目前，不少流行软件都提供有对外挂插件的支持功能，如Winamp、Realplay等等。这些软件通过对插件技术的使用为日后的软件升级和功能扩展提供了相当的便利条件。 尤为重要的是，通过使用插件技术，使得对软件的功能扩展将不再完全受限于软件厂商，任何第三方开发商或是程序员个人只要遵循了软件提供的插件接口标准去开发插件就完全可以同主体软件有很好的兼容，从而使用户对应用程序进行个性化功能扩展成为了可能。基于插件技术的以上诸多优势，本文下面将围绕插件的制作、应用程序对插件的支持等具体问题对其展开讨论。

　　设计思路及插件接口标准

　　通常支持插件的应用程序多将外挂扩展插件集中放置于某个指定的目录下，程序执行时首先在此目录下搜寻是否有插件存在，如有则为插件将其插入到应用程序，应用程序在终止运行时负责将插件释放。

　　至于插件以何种形式提供则没有固定的规定，可以是独立的应用程序，也可以是动态链接库或是其他一些文件格式，不管插件具体以何种形式提供，都是以方便使用为目的。本文即以使用较为灵活的动态链接库作为插件的提供形式，动态链接库通过外部导出函数为应用程序提供对插件功能的调用，应用程序在对动态链接库进行动态装载时也比较容易实现。这里与以往对动态链接库的使用有所不同，通常的应用程序事先已经明确知道需要使用哪些动态链接库，动态链接库又提供有哪些函数等信息，而允许使用插件的应用程序在发布时则无法预知在软件发布后第三方开发商将会开发出多少插件、插件都提供有什么功能函数等。因此这就需要在容许插件的应用程序和插件之间建立一种统一的接口标准并通过此接口标准完成对所有后期插件的管理。在此，主程序和插件之间是通过一个标准的DLL导出函数来实现的，主要用于在主体程序内插件对象的创建：
　　BOOL Plug_CreateObject(void ** pobj)
　　{
　　*pobj = new CPlugA;
　　return *pobj != NULL;
　　}
　　

　　
　　 其中类CPlugA是在动态链接库中由基类CPlugBase派生出来的，提供有插件的大部分主要功能，如插件图标的获取、插件提供的功能接口函数以及插件的释放等。基类CPlugBase的结构如下：
　　class CPlugBase
　　{
　　public:
　　CPlugBase(){};
　　virtual HICON GetIcon() = 0;
　　virtual void Interface(int k) = 0;
　　virtual void Release() = 0;
　　};
　　
　　 考虑到主体程序无法预知待插入的插件数目，为管理插件对象方便， 通过模板类CArray完成对各个插件对象的存储与管理，此模板类所管理的数组为PLUG_ST结构对象。PLUG_ST结构记录了插件类提供的的CPlugBase型指针和作为插件载体的动态链接库的实例句柄，其具体定义如下：
　　typedef struct{
　　CPlugBase * pObj;
　　HINSTANCE hIns;
　　}PLUG_ST, * LPPLUG_ST;
　　

　　另外，在程序界面上，每向应用程序添加一个新的插件，都应当在主程序的界面上增添与之相关联的按钮或菜单等，以便用户可以通过位于主程序界面上的按钮或菜单实现对插件内部功能函数的调用。本文在此是通过向工具条增添按钮的方式来达到此目的的，按钮上的图标由插件提供，应用程序通过插件类的GetIcon（）函数获取到图标句柄，并将其绘制在工具条按钮上。

　　为普通应用程序扩展插件支持功能

　　插件支持功能并非Winamp、RealPlay等大牌软件所独有，任何普通应用程序经过程序编码均可将其扩展为支持插件的应用程序。通常将这部分扩展代码在主框架类中完成，根据前面所述思路，首先从应用程序所在目录下搜寻子目录PLUGINS下是否存在以动态链接库形式提供的插件，如果在此目录下没有找到动态链接库那么就说明当前还没有插件，因此程序也就不需要做进一步处理，如果找到插件，就一一将其插入到应用程序。搜寻插件的部分代码如下：

　　其中，CreatePlug（）函数负责将插件装载到应用程序，其参数指定了待装载的插件的绝对路径。在实现时，首先通过LoadLibrary（）函数将插件模块装载到内存，并将获取到的实例句柄保存到PLUG_ST结构的hIns中，最后将此结构对象添加到CArray模板类对象m_arrPlugObj中，主要实现代码如下：
　　

　　同用户交互部分，则采取这样的处理：将所有插件的图标从插件动态链接库中提取出来，并放置于图象列表，最后在浮动工具条上创建对应的按钮并将插件图标绘制其上。同样也是出于对后期插件的不可预知性，在工具条上创建按钮的资源ID从ID_PLUG_POINTER开始，依次累加。具体实现可参考如下代码：
　　

　　对于各个插件按钮的命令响应也不能以通常的ON_COMMAND宏执行命令映射，而要以ON_COMMAND_RANGE宏实现对一个ID范围的命令映射：

　　为保证系统资源的有效释放，在程序终止之前必须确保将加载过的所有插件资源予以释放：
　　

　　至此，只要应用程序在PLUGINS子目录下发现了插件动态链接库的存在，就会将其装载到程序并通过工具条按钮完成用户同新添加插件的交互。如要从程序去掉某个插件只需在插件目录下将对应的插件模块删除即可。

　　 插件的制作

　　 插件的制作其实就是对动态链接库的创建，因此总的来说比较简单，但是作为插件载体的动态链接库与普通的动态链接库还是有一些区别的。例如，插件需要为主体应用程序提供图标，因此不仅在资源中要引入插件图标，而且在编译时还要将其设置为"Use MFC in a Static Library"以便在编译时能将所有的资源打包到插件模块，否则在应用程序插入插件时将无法在工具条按钮上绘制图标。插件在创建时同样也必须遵循其同主体程序的接口标准，这主要通过导出函数来体现的：

　　在前面已经提到过，CPlugA是基类CPlugBase的一个派生类，可以根据需要对CPlugBase的几个虚函数进行重载，以实现本插件所独有的一些功能。另外，由于主体程序是通过GetIcon（）来获取插件图标的，因此必须在动态链接库被加载时首先通过LoadIcon（）函数将图标装载到内存并保存其句柄于m_hIcon，等待主程序通过GetIcon（）函数来获取，该句柄的释放在当动态链接库被释放时由函数DeleteObject（）来执行。

　　 小结

　　 通过前述方法可以为普通应用程序添加插件支持功能，并可以在软件发布后以插件的形式对软件进行功能上的扩展，操作过程也比较灵活方便。由于经过这种扩展，使软件的各大功能模块分布于不同的插件，在软件升级或维护时只需对相应的插件进行替换即可，这对软件的升级维护可以起到积极的作用。本文所述程序在Windows 98下由Microsoft Visual C++ 6.0编译通过。