分享
 
 
 

动态链结函式库(DLL-Dynamic Linked Library)

王朝other·作者佚名  2008-06-01
窄屏简体版  字體: |||超大  

前言

本章要介绍的是动态链结函式库(Dynamic Linked Library,简称DLL)的撰写、使用及相关主题。动态链结函式库是Windows程式设计的一门重要领域,不信的话,你可以看看在Windows系统目录下那些数量庞大的 .DLL档案,它的重要性及使用频率由此可见一般。

基本上,假如略去VCL软体元件不谈的话,在C++Builder中撰写及使用DLL的方法是和传统Windows SDK是一致的,然而如此一来C++Builder也就失去了它傲人的优势了。因此在本章中我会为你介绍如何撰写使用VCL元件的 DLL,同时也针对各种不同程式发展平台如Visual C++, VB之间的DLL使用上应注重的事项,做一个全面的探讨。

以C++Builder撰写动态链结函式库 (DLL)

图一 以C++Builder撰写的About Dialog

图一所展示的就是我所要撰写的一个以VCL元件组合而成的About Dialog,如何?看起来是不是颇具商业软体架势呢?

C++Builder由於其先天上的优势,因此在视觉化的程式设计领域游刃有馀。然而在现实的工作环境中,也许在你手中的专案并非使用C++Builder来撰写,而是以其他程式工具如Visual C++,VB或是Borland C++完成的,假如要全部改写原来的程式,不仅旷日废时,而且可能老板也不答应,那麽该怎麽办呢?对了,就是利用撰写DLL的途径来达到程式共享的目的,为了要让传统的Windows SDK程式设计人员也可以享受此一优势,因此你可以将部份视觉程式设计部份以DLL完成,然後提供外部函式供他人呼叫,如此你就可以兼顾两者,『执其两端,用於其中』,而顺利地解决问题了。

好了!废话不多说了,现在开始进入正题吧!

建立DLL专案

建立DLL专案的方式和一般应用程式大致相同。同样地你可以由 【File/New】来建立一个新的专案,然後选择DLL类型的专案。

如图二所示:

图二 选择DLL专案类型

建选择完专案类型之後,它就自动为你产生了相关档案。和应用程式不同的是,它只产生了一个PRoject档,而不包含表格档,而该档案只是一个包含DLL进入点程式的空壳子,程式大致如下:

int WINAPI DllEntryPoint(HINSTANCE hinst, unsigned long reason, void*)

{

return 1;

}

DllEntryPoint是DLL内定的程式进入点,因为本程式中并不做任何处理,所以就直接return 1了。

加入TForm表格

为了要撰写如图一的About Dialog,毫无疑问地,我们必须加入一个TForm表格,因为建立DLL专案时,并未自动产生相关的TForm表格,所以你必须以手动方式加入。此时你可以【File/New Form】来加入一个表格。再来我们就可以用和一般应用程式设计相同的方式,加入必要的软体元件,如图叁所示。

图叁 在设计时期(Design Time)的 TForm。

你可以看到,我在程式中使用了叁个TPanel元件(除了标出来的之外,另外还有一个用来作为放置所有元件的平台)。以及一个TImage元件,图叁个的叁个Panel元件的样子都不同,那是利用修改其 BevelInner,BevelOuter,BevelWidth来达成的,你可以试着去修改它,看看能否做出更好的效果。至於TImage是用来做为显示那张雅典娜图形的元件。

在安排好了所有元件的位置之後,我们再设定所有元件的OnClick事件处理函式,让它可以在使用者按下滑鼠时,关掉该交谈窗。这个事件处理函式很简单,只有短短的一行。

void __fastcall TForm1::Image1Click(TObject *Sender)

{

Close();

}

好了,至此我们已完成加入表格的程序。

撰写输出函式(EXPort Function)

在完成的表格的设计後,再来我们就要撰写输出函式,该外部程式可以利用呼叫该函式的方式显示这个表格。我们的输出函式定义如下:

extern "C" void _stdcall ShowImage(void);

其中 extern "C" 是用来告诉编译器,以C的方式来命名,而不要以C++ 的命名法,因为C++ 的命名法会在函式名称後加上参数型态等装饰字,如此会造成其他程式如VC++,VB等无法使用的困扰。另外 __stdcall是用来表示它使用的参数传入方法。我们在後续单元会针对以上两者做更为深入的介绍。

再来我们来看函式本身,这个函式很简单,只是利用new动态产生一个表格,然後利用ShowModal来显示该表格,ShowModal会一直等到使用者按Click之後才关掉表格,此时我们再以delete指令来释放占用的记忆体。

void _export _stdcall ShowImage(void)

{

Form1 = new TForm1(NULL);

Form1->ShowModal();

delete Form1;

}

在完成以上程式之後,你就可以编译程式。此时C++Builder会产生一个DLL档,以本程式而言,它会产生一个DLLSAMP.DLL档案,而这个就是供外部呼叫的动态链结函式库。

在C++Builder中使用DLL

再来我要告诉你如何使用动态链结函式库。我们以前面所产生的DLL为例。使用DLL有两种方式,分别为明确呼叫及不明确呼叫。

我先说明不明确呼叫的使用方式。不明确呼叫指的是,在程式中并没有一行程式是用来载入DLL,而是利用链结一个记载输入函式的函式库档案(LIB),来进行链结,如此系统会自动将该DLL载入,同时在使用完毕後将其释放,不必由使用者(也就是呼叫它的函式)来进行载入及释放的动作。

首先必须产生一个LIB档,你可以利用C++Builder程式目录内的IMPLIB.EXE来产生该档案,切忌勿使用Visual C++ 的IMPLIB.EXE,因为Microsoft所使用的格式是COFF格式的LIB档,而Borland所使用的格式是OMF格式的LIB档。(同样地,若是你的LIB档是要给Visual C++ 链结用的,那就要使用它所附的IMPLIB.EXE,在使用时不可不察)。因此我们可用以下指令产生DLLSAMP.LIB档。

IMPLIB DLLSAMP.LIB DLLSAMP.DLL

如此你就可以得到供程式链结用DLLSAMP.LIB档了。

接着我们来撰写使用该DLL的范例程式。这个程式相当简单,我只在表格中放置一个Button,然後撰写该Button的OnClick事件处理函式,使其呼叫ShowImage函式即可。

有一点要注重的是,你必须将先前产生的DLLSAMP.LIB加入此专案中,利用 【Project/Add to Project】选择LIB型态档案,即可将其加入。

最後我们就可以链结程式,以下为其执行结果。

图四 执行结果。

动态链结函式库彻底研究

在前面的范例中,我们已经示范了一个基础dll的撰写方式,然而那只能说是少部份的Know-How而已,接下来我想针对DLL做一个彻底的探讨,企图使您对它有一个全面的认知,同时也希望在Know-How之外,可以告诉你一些关於DLL的Know-Why。

DLL的生与死

DLL顾名思义,是一个可以动态链结的函式库。这其中包含两个意义。第一,它是动态链结的,也就是说它必须具有『招之即来,挥之即去』的基本特性,它只有在被需要的时候才会被载入系统中,而在不被需要时,即自系统中释放。第二,它是一个函式库,因此它的行为模式和一般的函式库没什麽不同,当它载入时,它就视同其他一般的函式般。

『招之即来,挥之即去』的DLL

前面我们提到,DLL必须具备『招之即来,挥之即去』的基本特性。那麽要如何载入及释放DLL呢?关於此点,我们必须分为两方面来探讨;即所谓的明确呼叫及不明确呼叫。

明确呼叫(explicited linked):所谓明确呼叫(explicited linked)是使用LoadLibrary函式来载入 DLL。使用FreeLibrary函式来释放 DLL。这种方式是由使用者主动透过LoadLibrary 载入该 DLL,然後以GetProcAddress来取得函式位址,再呼叫该函式。最後在不使用该DLL之後,再将其释放。使用明确呼叫的优点在於,你可以完全控制该DLL的载入及释放,最有效地利用系统资源:缺点则是,必须自行利用GetProcAddress来取得叫使用的函式位址,但也由於使用了GetProcAddress来取得函式位址,因此在使用上增加许多弹性。由於此种使用方式载入函式程式是主动且可见的,因此名之为明确呼叫。

不明确呼叫 ( implicited linked):所谓不明确呼叫则是利用链结DLL函式库所相对应的输出函式库 ( export library),来达成呼叫函式的目的。因此载入DLL以及释放DLL的程序是不可见的,当使用该输出函式库的程式载入後,系统即将该DLL载入,当使用该输出函式的程式结束後,系统即将该DLL释放。使用不明确呼叫的优点在於,使用者可以完全不必顾虑到函式的载入及释放相关问题,使用时就如同一般的静态函式般。由於此种使用方式载入函式是非主动且不可见的,因此名之为不明确呼叫。

DLL的使用次数 (Usage Count)

前面提到的载入及释放其实在定义上是不明确的。为什麽呢?因为DLL的载入及释放尚牵涉到多行程使用时的载入及释放。由於DLL是动态链结的,因此可以同时有许多程式在使用同一个 DLL,举例来说:若一个X.DLL同时被A、B、C叁个程式使用着,则X.DLL会被载入叁次。然而系统为了结省资源,当然不会重复载入,因此此时在系统内会有一个表格来记载X.DLL的使用次数。所以当A程式载入X.DLL後,B、C程式再次载入X.DLL时,此时X.DLL并没有被重复地载入,系统只是将X.DLL的使用次数加一,然後将先前载入的X.DLL位址传回给 B、C两个程式使用,如此就可以达到共享函式库的目的了。同样地在释放X.DLL时,若该DLL同时有多人使用时,系统纯粹只是将该DLL的使用次数减一,当其使用次数等於0时,系统才会『真正』地将它由系统中释放。否则若是系统不分青红皂白即将DLL释放,会造成系统的灾难。

由以上可知,无论我们使用明确呼叫或是不明确呼叫,DLL的载入及释放都和它的使用次数有关。所以DLL的生与死其实和它的使用次数有关,当它的使用次数不为0时,就表示其『阳寿未尽』,系统就会维持其活动状态;反之,若其使用次数为0时,则表示它该『寿终正寝』了,系统就将其释放,并回收其使用的资源。然而若使用该DLL的程式当掉,导致该DLL没被释放时,该DLL就会因为使用次数没有被适时减少,而一直在系统内『阴魂不散』了。这种利用使用次数来治理共享资源的方法,也同时使用在OLE之中。

新知识的实践

现在我们已了解DLL的使用,尚有另一种明确呼叫的方式,我们可以将前面的范例程式修改为使用明确呼叫的方法来使用 DLL。

void (*ShowImage)(void);

void __fastcall TForm1::ShowButtonClick(TObject *Sender)

{

HINSTANCE hInst;

hInst = LoadLibrary("DLLSAMP.DLL");

(FARPROC &)ShowImage=GetProcAddress(hInst,"ShowImage");

ShowImage();

FreeLibrary(hInst);

}

以上就是修改後的程式,因为程式已改成明确呼叫的方式,因此不需要使用DLLSAMP.LIB了,所以关於BCB和VC所使用的LIB档格式不同的问题也不存在了。在此我简单地说明所使用的几个函式

hInst = LoadLibrary("DLLSAMP.DLL") 是用来载入DLLSAMP.DLL ,同时传回该DLL的HINSTANCE值,它是据以使用DLL的权杖。

(FARPROC &)ShowImage=GetProcAddress(hInst,"ShowImage") 利用前面得到的HINSTANCE值,呼叫GetProcAddress来得到ShowImage函式的位址,因为GetProcAddress所传回的值为FARPROC ,因此我们必须做型别转换。在此我是利用 (FARPROC &) 以reference做型别转换。

FreeLibrary(hInst) 使用完後,利用FreeLibrary 将该DLL释放。

输入函式及输出函式的标准写法

前面我们使用输入函式及输出函式时,为了简化程式的写法,因此使用了Borland为了和16位元程式相容而使用的 _export编译指令,在此我必须指出,这种写法是非标准的写法,其实Microsoft在32位元程式中使用了另一种定义输入函式及输出函式的写法,那才是一个放诸四海皆准的写法,使用 _export式的旧有写法在诸如Visual C++ 的编译器中是无法通过编译的。

在理论上,我们希望可以使用单一的要害字来定义一个输出函式,就如同 _export一般,然而Microsoft却在它的32位元程式中使用了另一种要害字来定义输入及输出函式,那就是 __declspec要害字,它可以传入dllimport及dllexport两个参数,用来分别代表输入函式及输出函式。

换句话说,若你要撰写输出函式,你必须使用 __declspec(dllexport) 来定义该函式,反之若你要使用输入函式,则你必须使用 __declspec(dllimport) 来定义该函式。

因此由於输入及输出函式的使用方式不同,你必须使用两个不同的include档来分别定义之。若你不想如此麻烦,那麽就必须要使用巨集定义来达到一体多用的目的罗,这对少数人持反对论点的人来说,简直是罪恶(还有人称之为巨集巫毒--macro woodoo)。

Windows的实作名家Jeffrey Richter,也就是Advanced Windows的作者建议我们使用以下的方法来达到一体多用的效果(同样是透过巨集巫毒)。

#ifndef _SHOWIMG_H_

#define _SHOWIMG_H_

#ifndef IMGDLL

#define EXTERN __declspec(dllimport)

#else

#define EXTERN __declspec(dllexport)

#endif

void EXTERN ShowImage(void);

#endif

如此一来,当你在撰写DLL时撰写可以撰写如下函式:

#define IMGDLL

#include "image.h"

当使用者在使用DLL时,则只要直接含入image.h即可。如此一来算是解决了利用 __declspec(dllimport) 和 __declspec(dllexport) 的不便了。

必也正名乎的DLL函式命名

谈完了标准写法,再来我们要谈谈一个更轻易搞混的函式命名原则。本来在正常情况下,我们是不需要理会编译器的函式命名规则的,因为在使用同一样编译器的情况下,不会有什麽太大的问题。然而问题来了,由於DLL是动态连结函式库,因此它的目标就是希望可以让多个程式共享程式及资源。所以若是DLL只能为同一种编译器所使用,那麽它的用途就大打折扣了。因此我们还是必须了解函式的命名方法。同时由於函式命名方式在各种不同的编译器各不相同,因此我们也必须了解其相异处,最重要的是,我们必须找出其沟通的方式。

C++ Builder的命名规则

除了前面提到的 __declspec编译指令之外,在C++ Builder尚有几种修饰字会影响到函数的命名, 它们就是 __cdecl,__stdcall,__pascal,__fastcall四个修饰字。为了了解该修饰字对於函式命名的影响,我们可以用以下的程式来测试之:

#ifndef _DLLNAME01_H_

#define _DLLNAME01_H_

#ifndef DLLNAME

#define EXTERN __declspec(dllimport)

#else

#define EXTERN __declspec(dllexport)

#endif

EXTERN void DllName01(void);

EXTERN void _stdcall DllName02(void);

EXTERN void _cdecl DllName03(void);

EXTERN void _pascal DllName04(void);

EXTERN void _fastcall DllName05(void);

};

#endif

以上为程式的定义,同时我们可以在 .CPP档中撰写相对应的空函式,然後将其编译成DLL档,再利用TDUMP.EXE或是VC++ 内的DUMPBIN.EXE来观察其内容,由於TDUMP会将函式命名解码,反而会使混淆原来的名称,因此以下的输出是由DUMPBIN.EXE得来。

函式定义 DLL内的函式名 摘要说明

void DllName01(void) @DllName01$qv 因为是CPP程式码

void _stdcall DllName02(void) @DllName02$QQsv 所以函式名都被修

void _cdecl DllName03(void) @DllName03$qv 饰过。

void _pascal DllName04(void) @DLLNAME04$QV

void _fastcall DllName05(void) @DllName05$qqrv

以上结果是否令你丈二金钢、摸不着头绪。这是因为我们的程式名称若以CPP为延伸名,C++Builder会以C++ 特有的命名方式来为函式命名,这种命名方式会在函式名称後加上其使用参数的性质,如参数类别等。这在C++ 中有一个非凡的名称,叫做mangled name,这是一种为了要实作出多载函式所发出的命名规则。(注:在C++ 中Add(int) 和Add(double) 可以同时存在,因此必须在object code区分之)。同时这种命名方式由於各个编译器厂商使用的方式各不相同,因此在撰写DLL时要避免使用之。为了要避开以上问题,我们改以下列的宣告方式:

#define _DLLNAME01_H_

#ifndef DLLNAME

#define EXTERN __declspec(dllimport)

#else

#define EXTERN __declspec(dllexport)

#endif

extern "C" {

EXTERN void DllName011(void);

EXTERN void _stdcall DllName022(void);

EXTERN void _cdecl DllName033(void);

EXTERN void _pascal DllName044(void);

EXTERN void _fastcall DllName055(void);

};

#endif

其中extern "C" ; 是用来告诉编译器使用C的命名方式,不要使用C++ 的mangled name。若是其中只有一个函式时,你可以直接以下列方式宣告之:

extern "C" void __stdcall ShowImage();

现在我们可以检视除去mangled name後的函式名称:

函式定义 DLL内的函式名 摘要说明

void DllName01(void) _DllName01 名称加底线

void _stdcall DllName02(void) DllName02 名称未变

void _cdecl DllName03(void) _DllName03 名称加底线

void _pascal DllName04(void) DLLNAME04 名称大写

void _fastcall DllName05(void) @DllName05 名称加@

以上我们可得知,在未加修饰字时和使用_cdecl修饰字时的名称是一样的。而 _pascal修饰字所产生的函式名则和16位元的标准DLL 函式名相同(这在VC++ 是不被接受的),__fastcall的函式名称则加上 @。

其中在WIN32中使用最多的是 _stdcall修饰字,这也是你要撰写一个可以和其他语言共同使用时所使用的修饰字,其次则为 __cdecl修饰字,这是用来传送不定参数型别的函式如printf、sprintf等使用的。其馀两者几乎在DLL没有机会使用。

结论:由上可知,在C++Builder中撰写DLL时必须注重以下事项:

使用 __declspec(dllimport)及 __declspec(dllexport)的标准型式。

注重C++ 的函式名称编码(mangled name)。

注重修饰字的使用。除非使用不定参数的函式,否则必使用 __stdcall修

饰字。

(4) 不要把 __declspec的使用和 __stdcall混淆了。此二者并没有绝对的相关性。即使是程式老手都可能栽在此处,切记,切记!

怎麽样,在看完了以上的介绍後,是否有晃然大悟的感觉。在了解以上的规则後,今後不论在撰写或是使用DLL时遭遇连结的问题时,应该难不倒你吧!

最後,我们将标准的DLL宣告方式列於後,以加深你的印象:

#ifndef _SHOWIMG_H_

#define _SHOWIMG_H_

#ifndef IMGDLL

#define EXTERN __declspec(dllimport)

#else

#define EXTERN __declspec(dllexport)

#endif

extern "C" EXTERN void __stdcall ShowImage(void);

#endif

语言双雄' C++Builder 和Visual C++ 连结

前面我们已经把关於C++Builder撰写DLL所应注重到的事项介绍完了,现在我们来谈另一个重点 - C++Builder和Visual C++ 的连结。若是你没有使用过Visual C++ 的话,可以将此部份略去。若是你在程式设计时必须使用到Visual C++ 的DLL或是必须提供DLL给VC++ 或是VB使用时,也许会带给你意想不到的收获。

VC++ 使用C++Builder的DLL函式

在Visual C++ 中使用C++Builder的DLL的函式方法和在C++Builder中使用大同小异,唯有几件事情必须要注重。

(一)Visual C++ 的LIB档格式和C++Builder的LIB格式不同,因此你必须重新产生一个 LIB。不过,可惜的是VC++ 在32位元的版本中并未提供IMPLIB.EXE函式(这点一直令许多人百思不解),因此你无法很方便地产生LIB档。解决方法有二:其一是在VC++ 内撰写一个同名称的空的DLL函式,令其产生LIB档,其二则是使用 LoadLibrary、GetProcAddress式的明确呼叫方式。

(二)使用前面提到的标准写法。

C++Builder中使用VC++ 的DLL函式

在C++Builder中使用VC++ 的DLL函式时要注重的是Microsoft在Visual C++ 中使用的非凡命名规则。在VC++ 中命名规则除了前面谈到的几项之外,它还使用了一个非凡的参数命名法,简言之,就是在函数名称後面加上参数的大小,这种命名方法会造成C++Builder,VB,Delphi使用的上的困扰。举例来说

extern "C" _declspec(dllexport) void __stdcall ShowImage(void);

在VC++ 中产生的函式名称为ShowImage@0(其中0表示参数大小),而不是如在C++Builder中产生的ShowImage,这是VC++ 已知的问题,这个问题也造成了很多使用non-VC++ 的使用者的问题,解决之道是在该DLL的DEF档中加上以下的叙述

EXPORTS

ShowImage=ShowImage@0

如此便可以产生正确的函式名了,若是你不想修改DEF档,你也可以在程式中加入以下的连结指引

#pragma comment(linker,"/exports:ShowImage=ShowImage@0")

假设你不确定其正确的名称,可以利用DumpBin或是TDump观察之。

以上是针对VC++ 的程式设计的所作的额外说明。最後我们以一个VC++ 程式呼叫本单元的About Dialog DLL做为结束。

此程式的要害程式码如下:

void CVcusedllApp::OnAppAbout()

{

void (*ShowImage)(void);

HINSTANCE hInst;

hInst = LoadLibrary("DLLSAMP2.DLL");

(FARPROC &)ShowImage=GetProcAddress(hInst,"ShowImage");

ShowImage();

FreeLibrary(hInst);

}

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有