原文地址：http://blog.csdn.net/benkaoya/archive/2008/06/02/2504781.aspx
1 DLL的进入/退出函数
1.1 DllMain简介
跟exe有个main或者WinMain入口函数一样，DLL也有一个入口函数，就是DllMain。以“DllMain”为关键字，来看看MSDN帮助文档怎么介绍这个函数的。
The DllMain function is an optional method of entry into a dynamic-link library (DLL)。（简要翻译：对于一个Dll模块，DllMain函数是可选的。）这句话很重要，很多初学者可能都认为一个动态链接库肯定要有DllMain函数。其实不然，像很多仅仅包含资源信息的DLL是没有DllMain函数的。
1.2 何时调用DllMain
系统是在什么时候调用DllMain函数的呢？静态链接时，或动态链接时调用LoadLibrary和FreeLibrary都会调用DllMain函数。DllMain的第三个参数fdwReason指明了系统调用Dll的原因，它可能是DLL_PROCESS_ATTACH、DLL_PROCESS_DETACH、DLL_THREAD_ATTACH和DLL_THREAD_DETACH。以下从这四种情况来分析系统何时调用了DllMain。
1.2.1 DLL_PROCESS_ATTACH
大家都知道，一个程序要调用Dll里的函数，首先要先把DLL文件映射到进程的地址空间。要把一个DLL文件映射到进程的地址空间，有两种方法：静态链接和动态链接的LoadLibrary或者LoadLibraryEx。
当一个DLL文件被映射到进程的地址空间时，系统调用该DLL的DllMain函数，传递的fdwReason参数为DLL_PROCESS_ATTACH。这种调用只会发生在第一次映射时。如果同一个进程后来为已经映射进来的DLL再次调用LoadLibrary或者LoadLibraryEx，操作系统只会增加DLL的使用次数，它不会再用DLL_PROCESS_ATTACH调用DLL的DllMain函数。不同进程用LoadLibrary同一个DLL时，每个进程的第一次映射都会用DLL_PROCESS_ATTACH调用DLL的DllMain函数。
可参考DllMainTest的DLL_PROCESS_ATTACH_Test函数。
1.2.2 DLL_PROCESS_DETACH
当DLL被从进程的地址空间解除映射时，系统调用了它的DllMain，传递的fdwReason值是DLL_PROCESS_DETACH。当DLL处理该值时，它应该执行进程相关的清理工作。
那么什么时候DLL被从进程的地址空间解除映射呢？两种情况：
◆FreeLibrary解除DLL映射（有几个LoadLibrary，就要有几个FreeLibrary）
◆进程结束而解除DLL映射，在进程结束前还没有解除DLL的映射，进程结束后会解除DLL映射。（如果进程的终结是因为调用了TerminateProcess，系统就不会用DLL_PROCESS_DETACH来调用DLL的DllMain函数。这就意味着DLL在进程结束前没有机会执行任何清理工作。）
注意：当用DLL_PROCESS_ATTACH调用DLL的DllMain函数时，如果返回FALSE，说明没有初始化成功，系统仍会用DLL_PROCESS_DETACH调用DLL的DllMain函数。因此，必须确保没有清理那些没有成功初始化的东西。
可参考DllMainTest的DLL_PROCESS_DETACH_Test函数。
1.2.3 DLL_THREAD_ATTACH
当进程创建一线程时，系统查看当前映射到进程地址空间中的所有DLL文件映像，并用值DLL_THREAD_ATTACH调用DLL的DllMain函数。
新创建的线程负责执行这次的DLL的DllMain函数，只有当所有的DLL都处理完这一通知后，系统才允许进程开始执行它的线程函数。
注意跟DLL_PROCESS_ATTACH的区别，我们在前面说过，第n(n>=2)次以后地把DLL映像文件映射到进程的地址空间时，是不再用DLL_PROCESS_ATTACH调用DllMain的。而DLL_THREAD_ATTACH不同，进程中的每次建立线程，都会用值DLL_THREAD_ATTACH调用DllMain函数，哪怕是线程中建立线程也一样。
1.2.4 DLL_THREAD_DETACH
如果线程调用了ExitThread来结束线程（线程函数返回时，系统也会自动调用ExitThread），系统查看当前映射到进程空间中的所有DLL文件映像，并用DLL_THREAD_DETACH来调用DllMain函数，通知所有的DLL去执行线程级的清理工作。
注意：如果线程的结束是因为系统中的一个线程调用了TerminateThread，系统就不会用值DLL_THREAD_DETACH来调用所有DLL的DllMain函数。
1.3 为DllMain换名
在早期的SDK版本中，DllMain是叫做DllEntryPoint。其实有一件鲜为人知的事：一个Dll的入口函数名是可以自己定义的。下面我将以VC++6.0为例来演示如何更改。首先要说明一点，虽然DllMain可以换成其他函数名，但函数的参数和返回值必须和DllMain一样。而且这个函数要为__stdcall类型（DllMain本身也是__stdcall类型）。
打开VC++菜单Project\Settings\Link tab\ Output in the Category box，如下图，在Entry-point symbol中输入要替换DllMain的函数名（当然这个函数名是你程序中已经实现的函数）。Entry-point symbol是干么的呢？可以以关键字“Entry-point symbol”搜索MSDN帮助文档查看，搜索时，打钩“仅搜索标题”会更快定位。
按OK后，如果马上编译的话会出现如下错误：
LIBCMTD.lib(crt0.obj) : error LNK2001: unresolved external symbol _main
Debug/Dll.dll : fatal error LNK1120: 1 unresolved externals
打开VC++菜单Project\Settings\C/C++选项卡，如下图，在Project Options：末尾的地方添加”/D”（图中蓝色高亮的地方），要注意位置，我试了，要把/D放到/GZ后面也会链接错误，我也不懂为什么，^_^。按OK，再次编译，成功。大家可以自己测试下到底有没有更改成功，什么，如果测试？打出调式信息啊。
1.4 DisableThreadLibraryCalls
看帮助就知道它是干么用的：
The DisableThreadLibraryCalls function disables the DLL_THREAD_ATTACH and DLL_THREAD_DETACH notifications for the dynamic-link library (DLL) specified by hLibModule. This can reduce the size of the working code set for some applications.
原文地址：http://www.blogjava.net/Yipak/articles/182025.html
DllMain函数是DLL模块的默认入口点。当Windows加载DLL模块时调用这一函数。系统首先调用全局对象的构造函数，然后调用全局函数 DLLMain。DLLMain函数不仅在将DLL链接加载到进程时被调用，在DLL模块与进程分离时（以及其它时候）也被调用。下面是一个框架 DLLMain函数的例子。
如果我们在DllMain中写入下面的代码（在原来的gandll.c中添加下面的代码）：
BOOL APIENTRY DllMain(HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved)
{
printf("hModule.%p lpReserved.%p \n", hModule, lpReserved);
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
printf("Process attach. \n");
break;
case DLL_PROCESS_DETACH:
printf("Process detach. \n");
break;
case DLL_THREAD_ATTACH:
printf("Thread attach. \n");
break;
case DLL_THREAD_DETACH:
printf("Thread detach. \n");
break;
}
return (TRUE);
}
同时将dlltest\dlltest.c修改为：
#include <stdio.h>
#include "dlltest.h"
int main(int argc, char **argv)
{
printf("Simple DLL test start. \n");
printf("Call DLL function: \n");
printf("Test DLL values: %d \n", add2(1, 2));
printf("Call DLL function end. \n");
printf("Simple DLL test end. \n");
return (0);
}
我简单的测试一下输出结果为：
C:\gandll\dlltest>dlltest
hModule.10000000 lpReserved.0012FD30
Process attach.
Simple DLL test start.
Call DLL function:
Test DLL values: 3
Call DLL function end.
Simple DLL test end.
hModule.10000000 lpReserved.00000001
Process detach.
也就是说DLL加载和应用程序退出的使用都会调用该函数（DllMain）的哦， 是应用程序一上来就调用的，不是用到该函数时才调用的！
好象有个问题：
下面的话来源： http://waiguai.blogdriver.com/waiguai/989918.html
采用隐式链接方式，程序员在建立一个DLL文件时，链接程序会自动生成一个与之对应的LIB导入文件。该文件包含了每一个DLL导出函数的符号名和可选的标识号，但是并不含有实际的代码。LIB文件作为DLL的替代文件被编译到应用程序项目中。当程序员通过静态链接方式编译生成应用程序时，应用程序中的调用函数与LIB文件中导出符号相匹配，这些符号或标识号进入到生成的EXE文件中。LIB文件中也包含了对应的DLL文件名（但不是完全的路径名），链接程序将其存储在EXE文件内部。当应用程序运行过程中需要加载DLL文件时，Windows根据这些信息发现并加载DLL，然后通过符号名或标识号实现对 DLL函数的动态链接。
我们看他说的“当应用程序运行过程中需要加载DLL文件时”， 我做的实验测试的是，在输出
Simple DLL test start.
Call DLL function:
这两行应该是不需要DLL的啊， 怎么应用程序在前面输出了：
hModule.10000000 lpReserved.0012FD30
Process attach.
这个呢？ 这就说明其实应用程序一上来就调用了DLL的（还有一种可能就是他是正确的，由于编译器优化的原因使的该DLL一上来就被调用了）。
到地是为什么？ 再查，再查。。。。。。
创建一个简单的DLL工程。
MyDllMain.
修改MyDllMain.cpp
#include "stdafx.h"
#include <stdio.h>
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
printf("hModule.%p lpReserved.%p \n", hModule, lpReserved);
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
printf("Process attach. \n");
break;
printf("Process detach. \n");
break;
printf("Thread attach. \n");
break;
printf("Thread detach. \n");
break;
}
return TRUE;
}
创建一个.CPP文件
#include "StdAfx.h"
{
return a + b;
}
新建一个测试工程：
TestMainDll
TestMainDll.cpp
#include "stdafx.h"
#include <iostream>
#include <windows.h>
using namespace std;
HINSTANCE hInstance;
Fun fun;
{
hInstance = LoadLibrary("MyDllMain.dll");
cout<<"Not Find this Dll"<<endl;
fun = (Fun)GetProcAddress(hInstance, "add");
cout<<fun(12,3)<<endl;;
FreeLibrary(hInstance);
printf("Hello World!\n");
return 0;
}