windows核心程式設計－－DLL基本

• 它們擴充套件了應用程式的特性。由於D L L能夠動態地裝入程式的地址空間，因此應用程式能夠在執行時確定需要執行什麼操作，然後裝入相應的程式碼，以便根據需要執行這些操作。例如，當一家公司開發了一種產品，想要讓其他公司改進或增強該產品的功能時，那麼就可以使用D L L。

• 它們可以用許多種程式語言來編寫。可以選擇手頭擁有的最好的語言來編寫D L L。也許你的應用程式的使用者介面使用Microsoft Visual Basic編寫得最好，但是用C + +來處理它的商用邏輯更好。系統允許Visual Basic程式載入C++ DLL、Cobol DLL和Fortran DLL等。

• 它們簡化了軟體專案的管理。如果在軟體開發過程中不同的工作小組在不同的模組上工作，那麼這個專案管理起來比較容易。但是，應用程式在銷售時附帶的檔案應該儘量少一些。我知道有一家公司銷售的產品附帶了1 0 0個D L L——每個程式設計師最多有5個D L L。這樣，應用程式的初始化時間將會長得嚇人，因為系統必須開啟1 0 0個磁碟檔案之後，程式才能執行它的操作。

• 它們有助於節省記憶體。如果兩個或多個應用程式使用同一個D L L，那麼該D L L的頁面只要放入R A M一次，所有的應用程式都可以共享它的各個頁面。C / C + +執行期庫就是個極好的例子。許多應用程式都使用這個庫。如果所有的應用程式都連結到這個靜態庫，那麼s p r i n t f、s t r c p y和m a l l o c等函式的程式碼就要多次存在於記憶體中。但是，如果所有這些應用程式連結到DLL C/C++執行期庫，那麼這些函式的程式碼就只需要放入記憶體一次，這意味著記憶體的使用將更加有效。

• 它們有助於資源的共享。D L L可以包含對話方塊模板、字串、圖示和點陣圖等資源。多個應用程式能夠使用D L L來共享這些資源。

• 它們有助於應用程式的本地化。應用程式常常使用D L L對自己進行本地化。例如，只包含程式碼而不包含使用者介面元件的應用程式可以載入包含本地化使用者介面元件的D L L。

• 它們有助於解決平臺差異。不同版本的Wi d n o w s配有不同的函式。開發人員常常想要呼叫新的函式（如果它們存在於主機的Wi n d o w s版本上的話）。但是，如果你的原始碼包含了對一個新函式的呼叫，而你的應用程式將要在不能提供該函式的Wi n d o w s版本上執行，那麼作業系統的載入程式將拒絕執行你的程式。即使你實際上從不呼叫該函式，情況也是這樣。如果將這些新函式儲存在D L L中，那麼應用程式就能夠將它們載入到Wi n d o w s的老版本上。當然，你仍然可以成功地呼叫該函式。

• 它們可以用於一些特殊的目的。Wi n d o w s使得某些特性只能為D L L所用。例如，只有當D L L中包含某個掛鉤通知函式的時候，才能安裝某些掛鉤（使用S e t Wi n d o w s H o o k E x和S e t Wi n E v e n t H o o k來進行安裝）。可以通過建立必須在D L L中生存的C O M物件來擴充套件Windows Explorer的外殼程式。對於可以由We b瀏覽器載入的、用於建立內容豐富的We b頁的A c t i v e X控制元件來說,情況也是一樣.

DLL的顯示和隱試的使用方法 



一些經驗：
一般使用extern "C" _declspec(dllexport)匯出變數，函式等，一般不匯出類，為了何其他的相容。。。。。。。。。

e x t e r n“C”用於c＋＋編譯為能夠讓c相容的，即保證函式名不被修改。
若要使用與其他編譯器供應商的工具連結的M i c r o s o f t的工具建立一個可執行模組，必須告訴M i c r o s o f t的編譯器輸出沒有經過改變的函式名。可以用兩種方法來進行這項操作。第一種方法是為程式設計專案建立一個. d e f檔案，並在該. d e f檔案中加上類似下面的E X P O RT S節：

EXPORTS
   MyFunc

如果想避免使用. d e f檔案，可以使用第二種方法輸出未截斷的函式版本。在D L L的原始碼模組中，可以新增下面這行程式碼：

#pragma comment(linker, "/export:MyFunc=_MyFunc@8")