windows中，鏈接庫分為兩種類型：靜態鏈接庫.lib和動態鏈接庫.dll。其中動態鏈接庫在被使用的時候，通常還提供一個.lib，稱為引入庫，它主要提供被Dll導出的函數和符號名稱，使得鏈接的時候能夠找到dll中對應的函數映射。
靜態鏈接庫和動態鏈接庫的作用相似，都是提供給其他程序進行調用的資源。其中，動態鏈接庫的調用方法分隱式調用（靜態導入調用）和顯示調用（動態導入調用）。
編譯環境：
Microsoft Visual Stdio 2010
--------------------------------------------------------------------------------
DLL導出符號
例，首先生成一個dll1.dll和dll1.lib
代碼如下：
// DLL1工程，dll1.cpp
// _declspec(dllexport)為導出符號
_declspec(dllexport) int add(int a, int b)
{
return a + b;
}
利用微軟的depends工具查看dll1.dll，導出的符號如下：
其中各字段意義：Ordinal（符號序號，後面使用GetProcAddress的時候，參考的數值），Hint（這個我也不是太明白，據說是不用了解），Function（這個就是函數導出後的符號名稱了），EntryPoint（這個是函數在DLL中的地址）。
這裡之所以函數的名稱變成了這樣子，是因為使用的編譯器默認使用C++方式進行編譯，由於C++支持重載，那麼需要給函數名增加額外的符號，來使與同名的重載函數區分開來，才能在DLL中通過符號名來進行定位。
這裡可以做個簡單的測試，新建控制台測試工程DllTest如下。
代碼如下：
// DllTest工程，DllTest.cpp
#include <iostream>
using namespace std;
int main(void)
{
// extern int add(int a, int b);
// _declspec(dllimport)是導入聲明，這種方式比上面的方式更有效，同時編譯器能邊編譯出更加高效的代碼。
_declspec(dllimport) int add(int a, int b);
cout << add(1,2) << endl;
getchar();
return 0;
}
編譯鏈接，提示鏈接錯誤 error LNK2019: unresolved external symbol "__declspec(dllimport) int cdecl add(int,int)" (__imp_?add@@YAHHH@Z) referenced in function _main，很明顯的編譯器在編譯的時候，把add函數也給重命名了，並且和上面用depends查看的一樣。意思是沒有找到這個符號的定義。
添加代碼後如下：（注意，我這裡兩個工程的輸出目錄都是在和解決方案同目錄的debug下，為了避免每次修改都重新拷貝lib文件，直接使用相對路徑聲明。）
代碼如下：
// DllTest工程，DllTest.cpp
#include <iostream>
using namespace std;
#pragma comment(lib, "../debug/dll1.lib") // 顯示的聲明要鏈接dll1.lib，隱式調用
int main(void)
{
// extern int add(int a, int b);
// _declspec(dllimport)是導入聲明，這種方式比上面的方式更有效，同時編譯器能邊編譯出更加高效的代碼。
_declspec(dllimport) int add(int a, int b);
cout << add(1,2) << endl;
getchar();
return 0;
}
編譯運行後，使用depends工具對DllTest.exe查看其依賴的輸入信息如下：
可以看出，DllTest.exe通過dll1.lib，引入了對dll1.dll的依賴。
--------------------------------------------------------------------------------
DLL提供的頭文件 通常情況下，當得到一個.dll的時候，我們無法得知其提供了哪些函數調用（准確來說，應該是調用方式。因為我們可以利用depends工具查看dll導出的函數及其序號，當然也許可能有其他的方式去知道具體怎麼使用，但是肯定無法得知內部具體實現細節。），因此為了方便被使用，通常會提供一個對應該dll的.h文件，來聲明其提供給客戶端使用的方式和說明等信息。客戶端使用該頭文件對所使用的接口進行導入。但是為了避免很多地方都出現這些函數的聲明，通常在客戶端直接在.h文件中對所有接口進行導入，而在Dll編譯時，則作為導出使用。方法如下：
代碼如下：
// DLL1工程，dll1.h
#ifndef DLL1_API
#define DLL1_API _declspec(dllimport)
#endif
// 以上代碼表示，如果在包含該頭文件之前，沒有定義DLL1_API宏，那麼後面所有DLL1_API宏都展開為_declspec(dllimport)，即導入。
// 因為通常情況下客戶端不會去定義這個宏（當然，假設這個宏不會被客戶端中其他文件定義），所以客戶端使用該頭文件的時候，都是用於導入。
DLL1_API int add(int a, int b);
代碼如下：
// DLL1工程，dll1.cpp
#define DLL1_API _declspec(dllexport)
// 注意上面這行，在頭文件被包含前，先定義了DLL1_API這個宏，使得頭文件中DLL1_API都被展開為_declspec(dllexport)了，從而聲明函數作為導出。
#include "dll1.h"
// 在頭文件中進行了導出聲明的函數，就不用再聲明導出了。
int add(int a, int b)
{
return a + b;
}
相應的，TestDll工程中包含.h文件後，也不用再去申明了。
代碼如下：
// DllTest工程，DllTest.cpp
#include <iostream>
using namespace std;
#include "../dll1/dll1.h" // 包含該頭文件之後，後面就不需要再申明了
#pragma comment(lib, "../debug/dll1.lib") // 顯示的聲明要鏈接dll1.lib，隱式調用
int main(void)
{
cout << add(1,2) << endl;
getchar();
return 0;
}
以上基本解釋了為什麼通常引用dll的時候都有一個頭文件，並且頭文件內有很多#ifndef之類的東東了。
--------------------------------------------------------------------------------
動態鏈接庫導出類 當然，動態鏈接庫也能導出類，要注意的是聲明的方式為class DLL1_API CSample，而不是DLL1_API class CSample。
同時，要注意導出類的同時，其所有成員函數也已經導出，但是仍然遵循類成員變量訪問權限限制。
如果單獨導出類的成員函數（聲明方式和全局函數一樣），那麼在客戶端可以實例化類對象，並調用導出的成員函數，不能調用沒導出的成員函數（即使是public的）。
--------------------------------------------------------------------------------
改編了的符號名 在導出符號時，講過C++會對函數名進行改編，以支持函數重載。那麼就會存在一個問題，如果使用不用的C++編譯器（導致編譯出的符號名不同）或者客戶端使用C編譯器調用，就會出現LNK2019這樣的鏈接錯誤，找不到符號。這個問題很大的限制了DLL的使用范圍。
解決方法1： 使用extern “C”(注意這個C一定要大寫）前置申明，表明函數是以C的方式編譯鏈接的。C方式編譯連接導出的函數不會改編符號名，因而可以避免上述問題。
代碼如下：
// DLL1工程，dll1.h
#ifndef DLL1_API
#define DLL1_API extern "C" _declspec(dllimport)
#endif
// 以上代碼表示，如果在包含該頭文件之前，沒有定義DLL1_API宏，那麼後面所有DLL1_API宏都展開為_declspec(dllimport)，即導入。
// 因為通常情況下客戶端不會去定義這個宏（當然，假設這個宏不會被客戶端中其他文件定義），所以客戶端使用該頭文件的時候，都是用於導入。
DLL1_API int add(int a, int b);
//class CSample
//{
//public:
// DLL1_API int substract(int a,int b);// 這種情況下，導出類成員函數，編譯不能通過的
//};
這裡要注意.h和.cpp中都要加上extern “C”，使得導入和導出都用C編譯方式。
代碼如下：
// DLL1工程，dll1.cpp
#define DLL1_API extern "C" _declspec(dllexport)
// 注意上面這行，在頭文件被包含前，先定義了DLL1_API這個宏，使得頭文件中DLL1_API都被展開為_declspec(dllexport)了，從而聲明函數作為導出。
#include "dll1.h"
// 在頭文件中進行了導出聲明的函數，就不用再聲明導出了。
int add(int a, int b)
{
return a + b;
}
//
//int CSample::substract(int a,int b)
//{
// return a - b;
//}
然後用depends進行查看：
導出的函數符號名和函數聲明時一樣了。由於客戶端使用的時候，導入也是用的extern “C”方式，因此客戶端在編譯鏈接的時候，也使用的是函數原名稱符號。
顯示，由於使用的是C編譯鏈接方式，C++的類和成員函數的導出就不能用這種方式了。
此外，如果我們在給函數聲明加上標准調用約定：DLL1_API int _stdcall add(int a, int b);（注意，在函數的定義中也要加上_stdcall）。那麼編譯出來的結果使用depends查看符號名為_add@8，也就是說符號名稱又改了。
解決方法2： 使用模塊定義文件.def，這種文件的格式規范查看MSDN，搜索.def即可。其中LIBRARY命令用於指名該def文件用於導出庫文件，EXPORTS用於指名導出函數符號名。也就是說，.def文件主要就用於控制導出符號等信息。
代碼如下：
LIBRARY dll1
EXPORTS
add11=add
我這裡給add函數別名為add11，注意同時需要在.h文件中聲明add為add11（作用就是提供給客戶端使用，當然其實也可以直接在客戶端聲明函數為add11，前提是你知道該函數的定義方式等）。一旦提供了.def之後，.cpp中提供的任何調用約定都不再生效，因為.def指定了生成的符號名了。這裡只要明白，.def控制了Dll的導出符號，客戶端使用的時候，只要提供了聲明，並且鏈接上.lib文件，就能夠使用了。
補充一句：VC6.0以後的IDE都需要在鏈接選項（LINK）的input-》module define file中，指明.def文件，編譯器才會去使用這個.def文件。
備注： 這一塊關於調用約定，以及加不加extern “C”，目前我還比較混亂。等了解了之後，再來這裡進行補充，歡迎看客給我提供有關這一塊比較好的介紹資料。
--------------------------------------------------------------------------------
顯示鏈接（動態導入鏈接） 前面有提到讓導出的函數沒有名字，那麼客戶端如何對其進行調用呢。就是使用符號表中的ordinal了（可以通過工具進行查看），當然也可以使用函數名進行導入。動態導入不需要lib文件和.h文件（如果知道函數名的話）。
代碼如下：
// DllTest工程，DllTest.cpp
#include <iostream>
using namespace std;
#include <windows.h>
int main(void)
{
HMODULE hModule = ::LoadLibraryA("dll1.dll");
if(NULL != hModule)
{
typedef int (*ADDPROC)(int a, int b);
//ADDPROC add = (ADDPROC)::GetProcAddress(hModule, "add11"); // 通過函數名導入
ADDPROC add = (ADDPROC)::GetProcAddress(hModule, MAKEINTRESOURCEA(1)); // 通過ordinal導入，注意第二個參數此時數值要放在低字節位置，具體參見MSDN說明。
if(NULL != add)
cout << add(1,1) << endl;
::FreeLibrary(hModule);
}
getchar();
return 0;
}
值得一提的是，根據函數名稱進行動態導入的時候，實際上也是根據符號名的，也就是說，dll提供的符號名要和提供給用戶的函數聲明一致。
此外，動態導入動態鏈接庫時，.exe時無法查看到需要的輸入信息的。
--------------------------------------------------------------------------------
後記 第一次寫這麼詳細和這麼長的博文，可以看出來寫到後面的時候已經越來越粗糙了。因為寫到後來的時候，自己都已經不知道要寫什麼了，因為如果再擴展下去，需要增加的東西就太多了。同時也有一部分原因是後面的內容我理解的不是太透徹，同時使用的也很少。總之這會我腦子已經相當混亂了。在這裡對那些寫博客的大俠們表示深深的敬佩。
最後要申明的是，這些都是我自己參考視頻整理總結出來的，肯定有不專業甚至不對的地方，懇請提出指導，我在學習理解之後，會及時進行修改，謝謝。
