VC++動態(tài)鏈接庫(DLL)編程

這個(gè)問題不是一兩句話可以解釋完

1、微軟提供給我們的MFC已經(jīng)編譯成靜態(tài)LIB和動態(tài)LIB，同時(shí)，為方便調(diào)試，微軟將MFC源碼（CPP文件）也放到VC里一起發(fā)布了；這里會存在兩種情況，如果是靜態(tài)LIB，那么功能代碼會在鏈接時(shí)鏈接進(jìn)你的EXE文件中，所以這種靜態(tài)LIB方式時(shí)，EXE文件通常都比較大；如果是動態(tài)LIB的方式，那么運(yùn)行的時(shí)候就需要mfcxxx.dll文件，但EXE文件體積比較小

2、如果你理解了1，我再進(jìn)一步解釋，MFC工程配置的時(shí)候默認(rèn)會鏈接mfcxxx.lib的，所以你的工程里只需要包含對應(yīng)的頭文件，例如 afxxxx.h之類的文件即可，編譯器在編譯階段是不需要知道具體實(shí)現(xiàn)代碼在哪里的，它只需要知道聲明即可編譯通過，同時(shí)編譯器會將那些外部的函數(shù)（即不是在當(dāng)前CPP文件實(shí)現(xiàn)的函數(shù)）標(biāo)記為需要修復(fù)的（我們先把它叫做修復(fù)吧）；那么，假如我用了一個(gè)MFC的函數(shù)，現(xiàn)在我只有聲明，它是怎么找到具體的實(shí)現(xiàn)代碼呢，這就是鏈接器的工作了，剛才我說過，MFC工程默認(rèn)是會鏈接mfcxxx.lib的，所以鏈接器在工作的時(shí)候，它會遍歷所有編譯過的文件，從里面找出要修復(fù)的項(xiàng)，然后再遍歷LIB文件，如果在LIB文件里找到對應(yīng)的實(shí)現(xiàn)，那么鏈接器會把編譯階段留下的手尾FIX掉

3、如果你理解了2，我們再進(jìn)一步解釋2；鏈接器鏈接LIB的時(shí)候，會有兩種情況，第一種，這個(gè)LIB本身是一個(gè)靜態(tài)LIB，包含了具體的實(shí)現(xiàn)；第二種，這個(gè)LIB本身只是一個(gè)中介，它是指向DLL的某個(gè)函數(shù)的；對于第一種情況，鏈接器會把用到的所有代碼鏈接進(jìn)去，注意，在Release版本情況下，鏈接器只會把用的的函數(shù)鏈進(jìn)去，就是說，即使你的靜態(tài)LIB有10MB，你也不需要擔(dān)心編譯出來的EXE有10MB，它只會把用到的函數(shù)鏈進(jìn)去；；對于第二種，是指向DLL某個(gè)函數(shù)的，鏈接器會在EXE的PE部里的導(dǎo)入表部分，增加一個(gè)項(xiàng)，這個(gè)項(xiàng)指向DLL的函數(shù)，同時(shí)在修復(fù)編譯階段留下手尾的地方，讓它JMP（跳轉(zhuǎn)）或CALL（調(diào)用）到我們DLL函數(shù)里

以上純屬個(gè)人解釋，因?yàn)樵诰幾g鏈接階段是非常復(fù)雜的，一時(shí)間沒辦法完全解決齊，有問題可以繼續(xù)追問