CL.exe
1. cl /c [filename] /c為只編譯不鏈接的意思，默認cl.exe工具會在編譯之后自動調用LINK.EXE進行鏈接
2. cl.exe運行需要指定include、lib等環境變量
3. [filename]需要指定文件全名（包含后綴名）
4. C/C++的編譯是針對文件進行的
lib.exe Microsoft庫管理工具
用于打包編譯后的庫文件(obj)，使生成一個庫文件(lib)
obj文件和lib文件一樣，可以直接用于link.exe鏈接工具中，生成exe可執行文件。lib.exe的作用只是打包，將多個obj打包為一個
link.exe 鏈接工具
link [file(s)] /dll選項用來生成一個動態鏈接庫(dll)
庫文件的編寫：
庫文件中只包含需要的函數及數據即可，不需要main函數，也不能有main函數
庫文件的調用者，需要用extern關鍵字申明要調用的外部函數
目前以lib后綴的庫有兩種，一種為靜態鏈接庫(Static Libary，以下簡稱“靜態庫”)，另一種為動態連接庫(DLL，以下簡稱“動態庫”)的導入庫(Import Libary，以下簡稱“導入庫”）。
靜態庫是一個或者多個obj文件的打包，所以有人干脆把從obj文件生成lib的過程稱為Archive，即合并到一起。比如你鏈接一個靜態庫，如果其中有錯，它會準確的找到是哪個obj有錯，即靜態lib只是殼子。
動態庫一般會有對應的導入庫，方便程序靜態載入動態鏈接庫，否則你可能就需要自己LoadLibary調入DLL文件，然后再手工GetProcAddress獲得對應函數了。有了導入庫，你只需要鏈接導入庫后按照頭文件函數接口的聲明調用函數就可以了。
導入庫和靜態庫的區別很大，他們實質是不一樣的東西。靜態庫本身就包含了實際執行代碼、符號表等等，而對于導入庫而言，其實際的執行代碼位于動態庫中，導入庫只包含了地址符號表等，確保程序找到對應函數的一些基本地址信息。
動態鏈接庫(dll)
一般為提高程序可讀性，使用#define DllExport __declspec(dllexport)宏定義Dll中需要導出的函數；在每個需要導出的函數前使用DllExport，例如DllExport int multiple(int x,int y)
生成一個Dll的方法：1.使用cl.exe /c [filename]將源文件生成庫文件 2.使用link.exe /dll [filename.obj]將此obj文件生成dll
調用Dll的方法一：1. 使用extern指定外部函數名 2.在程序中直接使用將要調用的Dll的函數名 3.鏈接時加入上一步驟中生成的庫文件(.lib)
方法二：運行時動態加載
C代碼示例：
//lib.c
#define DllExport __declspec(dllexport)
DllExport int multiple(int x,int y)
{
return x*y;
}
//libCaller.c
#include "windows.h"
//extern int multiple(int x,int y);
typedef UINT (CALLBACK* LPFNDLLFUNC1)(int,int);
HINSTANCE hf;
LPFNDLLFUNC1 func;
main()
{
hf= LoadLibrary("lib.dll");
if(hf!=0)
{
func = (LPFNDLLFUNC1)GetProcAddress(hf,"multiple");
printf("Multiple:%d\r\n",func(5,12));
FreeLibrary(hf);
}
}
Windows中的.lib文件分兩種類型
1.靜態庫文件，用于編譯時供其他對象引用 2.動態鏈接庫的導出文件。鏈接時使用，無需使用LoadLibrary動態加載。
Link.exe工具在使用.def文件生成DLL時的兩種命令行語句：
1. 如果DEF文件中沒有LIBRARY語句，需要同時指定/DEF /DLL選項
2. 如果DEF文件中有LIBRARY語句，只需指定/DEF選項即可生成DLL
Microsoft Visult Studio開發工具中CL.exe工具CL的意思及Compile和Link
生成DLL的方式（listed in recommended order of use）：
1. 在源文件中使用VC++自定義關鍵字__declspec(dllexport)
2. 使用包含EXPORTS語句的.def文件
3. 使用Link.exe工具的/EXPORT選項（定義導出函數）
//DEF源文件Sample
EXPORTS
add
//DLL源文件Sample
int add(int x,int y)
{
return x + y;
}
int substract(int x,int y)
{
return x-y;
}
我總是鼓勵 C/C++ 的學習者，在剛接觸這個程式語言的時候，先以 console mode（DOS-like）程式為目標。換言之，不要一開始就想寫 GUI 程式、想開視窗、想有眩目亮麗的畫面 -- 那只是未走先飛，揠苗助長罷了。
所謂 console 程式，就是文字模式的程式，我們可以在其中好好把 C/C++ 的語言根基練好，而不會分心於其他暫無必要的 GUI 枝節上。
我一直以為，這是理所當然的事情，卻也一直發現，有不少大專院校的大一 C/C++ 課程，同學們必須寫個小作家、小畫家、小算盤┅做為期中或期末作業。
果然世界不能大同，各人看法殊異 :)
我不但認為 C/C++ 程式開發對象初期要以 console mode 為主，我也認為，C/C++ 的程式開發環境，初期也要以 console mode 為主。換言之，不要一開始就進入整合環境（IDE）。整合環境中那麼多視窗、那麼多功能、那麼多預設值，會讓程式新手眼花撩亂，無法掌握程式編譯過程中一些有價值的知識與經驗。
等我們對編譯程序有了起碼的了解，再來使用整合環境，我認為這才最好。
所以不論在 <深入淺出 MFC> 或 <多型與虛擬> 書籍中，我都會簡述console mode 下的作業方式。<深入淺出 MFC> 在 p.224 列出，<多型與虛擬> 在 p.233 列出。
但仍然偶而會收到網友（不論是否上兩本書的讀者）的詢問，詢問console mode 的編譯方式，或詢問他們所遭遇的問題。
我再次整理這個題目。再有類似問題，我就可以整篇 mail 給發問者了。
★★ 注意：以下適合 PC 環境 ★★
●C/C++ 編譯器需要的環境變數設定
古早以來，PC 上的 C 編譯器，就需要兩個環境變數：
LIB：這個環境變數告訴編譯器說，必要的 libraries 在哪里（哪個磁碟目錄下）
INCLUDE：告訴編譯器說，必要的 header files 在哪里（哪個磁碟目錄下）
另外，為了讓我們能夠在任何 working directory 都叫得到編譯器，當然我們必須設定 PATH。
從古早以來，一直到現在，C/C++ 編譯器都需要這三個環境變數。
●以 Visual C++ 為例
以 Visual C++ 為例，如果安裝後的檔案布局如下：
C:\MSDEV\VC98\BIN : 這里放有編譯器 CL.EXE
C:\MSDEV\VC98\INCLUDE : 這里放有 C/C++ header files
C:\MSDEV\VC98\LIB : 這里放有 C/C++ standard libraries
那麼你可以寫一個批次檔如下：
set PATH=C:\MSDEV\VC98\BIN;C:\MSDEV\COMMON\MSDEV98\BIN
set INCLUDE=C:\MSDEV\VC98\INCLUDE
set LIB=C:\MSDEV\VC98\LIB
之所以需要另外設定 PATH=C:\MSDEV\COMMON\MSDEV98\BIN，是因為編譯器 CL.EXE 執行時需要 MSPDB60.DLL，而它被安裝於 C:\MSDEV\COMMON\MSDEV98\BIN 之中。
如果你寫的程式不只是單純的 C/C++ 程式，還用到了 MFC，一樣可以在 console mode 下編譯，這時候你的環境變數應該如此設定：
set PATH=C:\MSDEV\VC98\BIN;C:\MSDEV\COMMON\MSDEV98\BIN
set INCLUDE=C:\MSDEV\VC98\INCLUDE;C:\MSDEV\VC98\MFC\INCLUDE
set LIB=C:\MSDEV\VC98\LIB;C:\MSDEV\VC98\MFC\LIB
多指定了 MFC\INCLUDE 和 MFC\LIB，就可以讓編譯器和聯結器找到 MFC 的 header files 和 libraries。如果你還需要用到 ATL，就得在 INCLUDE 環境變數中再加上 C:\MSDEV\VC98\ATL\INCLUDE。
●以 Borland C++Builder 為例
以 Borland C++Builder 為例，如果安裝後的檔案布局如下：
C:\BORLAND\CBuilder3\BIN : 這里放有編譯器 BCC32.EXE
C:\BORLAND\CBuilder3\INCLUDE : 這里放有 C/C++ header files
C:\BORLAND\CBuilder3\LIB : 這里放有 C/C++ standard libraries
那麼你可以寫一個批次檔如下：
set PATH=C:\BORLAND\CBuilder3\BIN
set INCLUDE=C:\BORLAND\CBuilder3\INCLUDE
set LIB=C:\BORLAND\CBuilder3\LIB
●如何在 console 中編譯 C/C++ 程式
首先，開啟一個 DOS Box（DOS Prompt, DOS VM），然後在該 DOS box 中執行上述寫好的批次檔，完成環境變數的設定。你可以再在 DOS 提示號下鍵入 set 命令，看看環境變數的設定內容正確與否。
然後就可以直接在 DOS 提示號下鍵入編譯器名稱，開始編譯了。如果你使用 Visual C++，就這麼做：
C:\> CL test.cpp
如果你使用 C++Builder，就這麼做：
C:\> BCC32 test.cpp
至於特殊情況下需要什麼特殊的 options，就必須自己查一下啦。只要執行 CL /? 或 BCC32（其後不加任何引數），便可看到所有的 compile options。
●編譯器與聯結器的關系
早期的編譯過程與聯結過程是分開的。換句話說我們必須做兩個動作：
C:\> Cl test.cpp
C:\> LINK test.obj xxx （xxx 代表各個必要的 libraries）
或是：
C:\> BCC32 test.cpp
C:\> TLINK32 test.obj xxx （xxx 代表各個必要的 libraries）
如今的編譯過程與聯結過程當然還是分開的，但是我們的動作只需一個：
C:\> CL test.cpp
或是：
C:\> BCC32 test.cpp
這是因為編譯器變聰明了，除非你指定 /c option（表示只編譯不聯結），否則它便自動為你呼叫聯結器進行聯結動作。過去以來頗令 programmer煩惱的「該使用哪些 libraries」的問題，編譯器也有了聰明的解決方案：它將程式中用到的 library functions 記錄起來，同時也錄下它們所屬的library 名稱，於是聯結器就可以從這個表格中知道要聯結哪些 libraries 了。
●環境變數與 DOS VM（Virtual Machine）的關系
你可以同時開起多個 DOS Box，但是你不能夠在某個 DOS Box 中執行上述批次檔而在另一個 DOS VM 中享受其環境設定。
這是因為每個 DOS Box 都是一個 Virtual Machine，彼此誰也看不到誰，互不相干。
除非你在 autoexec.bat 中就設定好上述那些環境變數。這麼一來，任何一個新開啟的 DOS VM 便會因為繼承最原始的 DOS VM 環境，而繼承了那些變數設定。
●環境空間（environment space）不足
最易造成大家困擾的，就是環境空間（environment space）不足的問題。
當你安裝好 Visual C++，會在其 BIN 子目錄中發現一個名為 VCVARS32.BAT 的檔案。這個檔案其實就是做上述的環境變數設定動作（這在 Visual C++ 安裝過程的最後一個步驟有說明。哎，有多少人安裝軟體不看說明！）。所以，你可以在任何 DOS Box 中執行此檔，取代前述我們自己的批次檔。
但是通常大家都有失敗的經驗，得到 "Out of environment space" 的錯誤訊息。這是因為 VCVARS32.BAT 使用以下句法：
set INCLUDE=%MSVCDir%\ATL\INCLUDE;%MSVCDir%\INCLUDE;%MSVCDir%\MFC\INCLUDE;%INCLUDE%
set LIB=%MSVCDir%\LIB;%MSVCDir%\MFC\LIB;%LIB%
意思是把 INCLUDE 的原始設定（%INCLUDE%）再附加其他設定，并把LIB 的原始設定（%LIB%）再附加其他設定。如果原始設定已經很長，多來這麼幾次，便 "Out of environment space" 啦！
做法之一是調高環境空間的大小。請在 c:\config.sys 檔中加上這行：
shell=C:\COMMAND.COM C:\ /E:1024 /P
其中 /E:1024 便是表示將環境空間調為 1024 bytes。（不夠？再調）
做法之二是不要使用 VCVARS32.BAT 的那種「附加」句型，改用前述我們自己的批次檔。要知道，我們可能有好幾個編譯器環境（VC、BCB、G++ ┅），需要輪番測試我們的程式；如果使用「附加」句型，多來幾次，再大的環境空間也會消磨殆盡。
方法一和方法二要雙管齊下唷。
●有任何規模上的限制嗎？
使用 console 模式（或稱 command line 模式）來編譯聯結程式，程式的大小可否有任何規模上的限制？答案是沒有！
它的缺點是沒有工具幫你管理檔案、沒有預設值讓你少打幾個字、沒有分析工具幫你整理 objects，讓你瀏覽 objects、symbols┅。所以一旦你基本功學會了，要開始中大型程式的設計，當然以整合環境（IDE）為佳。
●不要誤會
我這不是開倒車，要大家回到茹毛飲血的時代，都回頭去做山頂洞人。而是我覺得，對於一位 C/C++ 初學者，整合環境（IDE）的運用恐怕帶來一頭霧水，不如先在 console mode 下作業。一方面多認識一些環境設定方面的常識，滿好的，一方面比較方便好用，也不必寫個 1000 行的小小練習還得啟動 五五加農炮，一方面求知的力量可以全部放在語言的練習上頭。
等有了一定的程度，再使用整合環境，就不會如墜五里霧了。