今天同學來問了一個問題：Visual Studio中生成的動態庫總是伴隨著一個靜態庫檔案，我把這兩個檔案同樣進行重新命名之後還能不能使用？

我對VS下的動態庫的生成並不是很熟悉，表示無法回答這個問題。但這個問題本身卻也讓我產生了疑問：動態庫真的需要總是伴隨著一個靜態庫？根據我在Linux下的經驗，這兩種形式的程式碼庫是沒有什麼依賴關係的。 那在Windows下到底是怎麼回事？帶著這些疑問，我去搜索了一下。下面將得到的結論和一些相關知識進行總結。

靜態連結庫（.lib檔案）其實是程式碼的簡單集合，在Linux下副檔名為.a，表示archive（歸檔）之意。它只是將編譯後的目的碼（.o檔案）進行簡單的歸檔，沒什麼特殊之處。我曾試過將Windows下的foo.lib檔案直接命名為foo.a，直接在Linux下使用 （當然，前提是他們含有的目的碼必須一樣，即編譯時目標平臺是一致的）。這些庫在連結時被連結進可執行檔案，如同.o檔案被連結一樣。靜態庫的作用無非是將多個.o整合為一個，便於管理和分享而已。

動態連結庫（.dll檔案）則相對複雜一些。動態庫中的程式碼是在執行時根據需要載入的。由於這裡面的程式碼在載入進記憶體後可以被多個程式共享，因此又稱為共享庫，在Linux下的副檔名為.so，表示shared objects（共享的目的碼）之意。

Windows下用VS建立DLL專案生成.dll檔案時，一般會伴隨生成一個.lib檔案；使用這個.dll檔案時，需要將伴隨的.lib加進連結選項。事實上，這裡的.lib檔案中只包含簡單的匯出定義，實際的程式碼還是在.dll檔案中。這裡的.lib檔案並非是上面提到的 靜態庫，而是動態連結庫的匯入庫(Import Libary)。雖然共用副檔名，但它們的內容是完全不一樣的。匯入庫只在連結的時候需要，程式執行的時候只需要.dll檔案即可。此外，DLL專案中必須至少匯出一個函式、變數或者類才會有.lib生成， 沒有匯出的話就不生成.lib檔案。由於一般情況下DLL專案都是為了匯出符號給別的專案用，所以才給人一種動態庫總伴隨著一個“靜態庫”檔案的假象。

回到同學的問題。伴隨的那個.lib檔案裡有相應的.dll檔案的名字和一個指明.dll檔案中函式入口的順序表。如果把.dll檔案的名稱改了，.lib檔案中相應的名字還是原來的檔名，應該就會找不到相應的.dll檔案了。 但其實.dll檔案在沒有.lib檔案的情況下也是可以使用的：通過WIN32 API函式LoadLibrary、GetProcAddress等函式來呼叫.dll中的函式即可。但這樣比起有.lib檔案時呼叫.dll中的函式稍微麻煩些。另外，Windows下也可以由.dll檔案得到相應的.lib檔案。 參見http://www.oschina.net/question/234345_48496

那為什麼在Linux下用GCC生成和使用.so檔案時不需要類似.lib匯入庫這樣的東西呢？直接原因是Windows下的連結器只能處理.lib這樣的非可執行檔案，不能處理.dll這樣的可執行檔案，所以用一個匯入庫（.lib）來輔助連結； 而在Linux下，.so檔案是elf格式的，這種格式既可執行又能連結，所以GCC就沒必要使用額外的檔案來輔助連結共享庫了。網上有人對Windows下匯入庫的概念給出了更深層一點的解釋： DLL中匯出的符號名未必是應用程式使用它時匯入的符號名；為了方便得到對語言中立的元件，微軟特意採用了現在的方案：在DLL裡匯出一套符號，然後通過DEF檔案或”Import Library”來使用另一套符號進行匯入，這樣就相當於多了一層轉換，可兼顧同語言和跨語言的應用。 這也是有道理的。

轉：http://blog.shengbin.me/posts/windows-dll-with-lib/