Lucene是一個高性能的java全文檢索工具包，它使用的是倒排文件索引結(jié)構(gòu)。該結(jié)構(gòu)及相應(yīng)的生成算法如下：

0）設(shè)有兩篇文章1和2
文章1的內(nèi)容為：Tom lives in Guangzhou,I live in Guangzhou too.
文章2的內(nèi)容為：He once lived in Shanghai.

1)由于lucene是基于關(guān)鍵詞索引和查詢的，首先我們要取得這兩篇文章的關(guān)鍵詞，通常我們需要如下處理措施
a.我們現(xiàn)在有的是文章內(nèi)容，即一個字符串，我們先要找出字符串中的所有單詞，即分詞。英文單詞由于用空格分隔，比較好處理。中文單詞間是連在一起的需要特殊的分詞處理。
b.文章中的”in”, “once” “too”等詞沒有什么實際意義，中文中的“的”“是”等字通常也無具體含義，這些不代表概念的詞可以過濾掉
c.用戶通常希望查“He”時能把含“he”，“HE”的文章也找出來，所以所有單詞需要統(tǒng)一大小寫。
d.用戶通常希望查“live”時能把含“lives”，“lived”的文章也找出來，所以需要把“lives”，“lived”還原成“live”
e.文章中的標點符號通常不表示某種概念，也可以過濾掉
在lucene中以上措施由Analyzer類完成

經(jīng)過上面處理后
文章1的所有關(guān)鍵詞為：[tom] [live] [guangzhou] [i] [live] [guangzhou]
文章2的所有關(guān)鍵詞為：[he] [live] [shanghai]

2) 有了關(guān)鍵詞后，我們就可以建立倒排索引了。上面的對應(yīng)關(guān)系是：“文章號”對“文章中所有關(guān)鍵詞”。倒排索引把這個關(guān)系倒過來，變成：“關(guān)鍵詞”對“擁有該關(guān)鍵詞的所有文章號”。文章1，2經(jīng)過倒排后變成
關(guān)鍵詞 文章號
guangzhou 1
he 2
i 1
live 1,2
shanghai 2
tom 1

通常僅知道關(guān)鍵詞在哪些文章中出現(xiàn)還不夠，我們還需要知道關(guān)鍵詞在文章中出現(xiàn)次數(shù)和出現(xiàn)的位置，通常有兩種位置：a)字符位置，即記錄該詞是文章中第幾個字符（優(yōu)點是關(guān)鍵詞亮顯時定位快）；b)關(guān)鍵詞位置，即記錄該詞是文章中第幾個關(guān)鍵詞（優(yōu)點是節(jié)約索引空間、詞組（phase）查詢快），lucene中記錄的就是這種位置。

加上“出現(xiàn)頻率”和“出現(xiàn)位置”信息后，我們的索引結(jié)構(gòu)變?yōu)椋?
關(guān)鍵詞 文章號[出現(xiàn)頻率] 出現(xiàn)位置
guangzhou 1[2] 3，6
he 2[1] 1
i 1[1] 4
live 1[2],2[1] 2，5，2
shanghai 2[1] 3
tom 1[1] 1

以live 這行為例我們說明一下該結(jié)構(gòu)：live在文章1中出現(xiàn)了2次，文章2中出現(xiàn)了一次，它的出現(xiàn)位置為“2,5,2”這表示什么呢？我們需要結(jié)合文章號和出現(xiàn)頻率來分析，文章1中出現(xiàn)了2次，那么“2,5”就表示live在文章1中出現(xiàn)的兩個位置，文章2中出現(xiàn)了一次，剩下的“2”就表示live是文章2中第 2個關(guān)鍵字。

以上就是lucene索引結(jié)構(gòu)中最核心的部分。我們注意到關(guān)鍵字是按字符順序排列的（lucene沒有使用B樹結(jié)構(gòu)），因此lucene可以用二元搜索算法快速定位關(guān)鍵詞。

實現(xiàn)時 lucene將上面三列分別作為詞典文件（Term Dictionary）、頻率文件(frequencies)、位置文件 (positions)保存。其中詞典文件不僅保存有每個關(guān)鍵詞，還保留了指向頻率文件和位置文件的指針，通過指針可以找到該關(guān)鍵字的頻率信息和位置信息。

Lucene中使用了field的概念，用于表達信息所在位置（如標題中，文章中，url中），在建索引中，該field信息也記錄在詞典文件中，每個關(guān)鍵詞都有一個field信息(因為每個關(guān)鍵字一定屬于一個或多個field)。

為了減小索引文件的大小，Lucene對索引還使用了壓縮技術(shù)。首先，對詞典文件中的關(guān)鍵詞進行了壓縮，關(guān)鍵詞壓縮為<前綴長度，后綴>，例如：當前詞為“阿拉伯語”，上一個詞為“阿拉伯”，那么“阿拉伯語”壓縮為<3，語>。其次大量用到的是對數(shù)字的壓縮，數(shù)字只保存與上一個值的差值（這樣可以減小數(shù)字的長度，進而減少保存該數(shù)字需要的字節(jié)數(shù)）。例如當前文章號是16389（不壓縮要用3個字節(jié)保存），上一文章號是16382，壓縮后保存7（只用一個字節(jié)）。

下面我們可以通過對該索引的查詢來解釋一下為什么要建立索引。
假設(shè)要查詢單詞 “live”，lucene先對詞典二元查找、找到該詞，通過指向頻率文件的指針讀出所有文章號，然后返回結(jié)果。詞典通常非常小，因而，整個過程的時間是毫秒級的。
而用普通的順序匹配算法，不建索引，而是對所有文章的內(nèi)容進行字符串匹配，這個過程將會相當緩慢，當文章數(shù)目很大時，時間往往是無法忍受的。

推薦比較大應(yīng)用程序都由很多模塊組成，這些模塊分別完成相對獨立的功能，它們彼此協(xié)作來完成整個軟件系統(tǒng)的工作。其中可能存在一些模塊的功能較為通用，在構(gòu)造其它軟件系統(tǒng)時仍會被使用。在構(gòu)造軟件系統(tǒng)時，如果將所有模塊的源代碼都靜態(tài)編譯到整個應(yīng)用程序EXE文件中，會產(chǎn)生一些問題：一個缺點是增加了應(yīng)用程序的大小，它會占用更多的磁盤空間，程序運行時也會消耗較大的內(nèi)存空間，造成系統(tǒng)資源的浪費；另一個缺點是，在編寫大的EXE程序時，在每次修改重建時都必須調(diào)整編譯所有源代碼，增加了編譯過程的復(fù)雜性，也不利于階段性的單元測試。

　　windows/" target=_blank>Windows系統(tǒng)平臺上提供了一種完全不同的較有效的編程和運行環(huán)境，你可以將獨立的程序模塊創(chuàng)建為較小的DLL(Dynamic Linkable Library)文件，并可對它們單獨編譯和測試。在運行時，只有當EXE程序確實要調(diào)用這些DLL模塊的情況下，系統(tǒng)才會將它們裝載到內(nèi)存空間中。這種方式不僅減少了EXE文件的大小和對內(nèi)存空間的需求，而且使這些DLL模塊可以同時被多個應(yīng)用程序使用。Microsoft Windows自己就將一些主要的系統(tǒng)功能以DLL模塊的形式實現(xiàn)。例如IE中的一些基本功能就是由DLL文件實現(xiàn)的，它可以被其它應(yīng)用程序調(diào)用和集成。

　　一般來說，DLL是一種磁盤文件（通常帶有DLL擴展名），它由全局數(shù)據(jù)、服務(wù)函數(shù)和資源組成，在運行時被系統(tǒng)加載到進程的虛擬空間中，成為調(diào)用進程的一部分。如果與其它DLL之間沒有沖突，該文件通常映射到進程虛擬空間的同一地址上。DLL模塊中包含各種導(dǎo)出函數(shù)，用于向外界提供服務(wù)。Windows在加載DLL模塊時將進程函數(shù)調(diào)用與DLL文件的導(dǎo)出函數(shù)相匹配。

　　在Win32環(huán)境中，每個進程都復(fù)制了自己的讀/寫全局變量。如果想要與其它進程共享內(nèi)存，必須使用內(nèi)存映射文件或者聲明一個共享數(shù)據(jù)段。DLL模塊需要的堆棧內(nèi)存都是從運行進程的堆棧中分配出來的。

　　DLL現(xiàn)在越來越容易編寫。Win32已經(jīng)大大簡化了其編程模式，并有許多來自AppWizard和MFC類庫的支持。

　　一、導(dǎo)出和導(dǎo)入函數(shù)的匹配

　　DLL文件中包含一個導(dǎo)出函數(shù)表。這些導(dǎo)出函數(shù)由它們的符號名和稱為標識號的整數(shù)與外界聯(lián)系起來。函數(shù)表中還包含了DLL中函數(shù)的地址。當應(yīng)用程序加載DLL模塊時時，它并不知道調(diào)用函數(shù)的實際地址，但它知道函數(shù)的符號名和標識號。動態(tài)鏈接過程在加載的DLL模塊時動態(tài)建立一個函數(shù)調(diào)用與函數(shù)地址的對應(yīng)表。如果重新編譯和重建DLL文件，并不需要修改應(yīng)用程序，除非你改變了導(dǎo)出函數(shù)的符號名和參數(shù)序列。

　　簡單的DLL文件只為應(yīng)用程序提供導(dǎo)出函數(shù)，比較復(fù)雜的DLL文件除了提供導(dǎo)出函數(shù)以外，還調(diào)用其它DLL文件中的函數(shù)。這樣，一個特殊的DLL可以既有導(dǎo)入函數(shù)，又有導(dǎo)入函數(shù)。這并不是一個問題，因為動態(tài)鏈接過程可以處理交叉相關(guān)的情況。

　　在DLL代碼中，必須像下面這樣明確聲明導(dǎo)出函數(shù)：

__declspec(dllexport) int MyFunction(int n);

　　但也可以在模塊定義(DEF)文件中列出導(dǎo)出函數(shù)，不過這樣做常常引起更多的麻煩。在應(yīng)用程序方面，要求像下面這樣明確聲明相應(yīng)的輸入函數(shù)：

__declspec(dllimport) int MyFuncition(int n);

　　僅有導(dǎo)入和導(dǎo)出聲明并不能使應(yīng)用程序內(nèi)部的函數(shù)調(diào)用鏈接到相應(yīng)的DLL文件上。應(yīng)用程序的項目必須為鏈接程序指定所需的輸入庫（LIB文件）。而且應(yīng)用程序事實上必須至少包含一個對DLL函數(shù)的調(diào)用。

　　二、與DLL模塊建立鏈接

　　應(yīng)用程序?qū)牒瘮?shù)與DLL文件中的導(dǎo)出函數(shù)進行鏈接有兩種方式：隱式鏈接和顯式鏈接。所謂的隱式鏈接是指在應(yīng)用程序中不需指明DLL文件的實際存儲路徑，程序員不需關(guān)心DLL文件的實際裝載。而顯式鏈接與此相反。

　　采用隱式鏈接方式，程序員在建立一個DLL文件時，鏈接程序會自動生成一個與之對應(yīng)的LIB導(dǎo)入文件。該文件包含了每一個DLL導(dǎo)出函數(shù)的符號名和可選的標識號，但是并不含有實際的代碼。LIB文件作為DLL的替代文件被編譯到應(yīng)用程序項目中。當程序員通過靜態(tài)鏈接方式編譯生成應(yīng)用程序時，應(yīng)用程序中的調(diào)用函數(shù)與LIB文件中導(dǎo)出符號相匹配，這些符號或標識號進入到生成的EXE文件中。LIB文件中也包含了對應(yīng)的DLL文件名（但不是完全的路徑名），鏈接程序?qū)⑵浯鎯υ贓XE文件內(nèi)部。當應(yīng)用程序運行過程中需要加載DLL文件時，Windows根據(jù)這些信息發(fā)現(xiàn)并加載DLL，然后通過符號名或標識號實現(xiàn)對DLL函數(shù)的動態(tài)鏈接。

　　顯式鏈接方式對于集成化的開發(fā)語言（例如VB）比較適合。有了顯式鏈接，程序員就不必再使用導(dǎo)入文件，而是直接調(diào)用Win32 的LoadLibary函數(shù)，并指定DLL的路徑作為參數(shù)。LoadLibary返回HINSTANCE參數(shù)，應(yīng)用程序在調(diào)用GetProcAddress函數(shù)時使用這一參數(shù)。GetProcAddress函數(shù)將符號名或標識號轉(zhuǎn)換為DLL內(nèi)部的地址。假設(shè)有一個導(dǎo)出如下函數(shù)的DLL文件：

extern "C" __declspec(dllexport) double SquareRoot(double d);

　　下面是應(yīng)用程序?qū)υ搶?dǎo)出函數(shù)的顯式鏈接的例子：

typedef double(SQRTPROC)(double);
HINSTANCE hInstance;
SQRTPROC* pFunction;
VERIFY(hInstance=::LoadLibrary("c:\\winnt\\system32\\mydll.dll"));
VERIFY(pFunction=(SQRTPROC*)::GetProcAddress(hInstance,"SquareRoot"));
double d=(*pFunction)(81.0);//調(diào)用該DLL函數(shù)

　　在隱式鏈接方式中，所有被應(yīng)用程序調(diào)用的DLL文件都會在應(yīng)用程序EXE文件加載時被加載在到內(nèi)存中；但如果采用顯式鏈接方式，程序員可以決定DLL文件何時加載或不加載。顯式鏈接在運行時決定加載哪個DLL文件。例如，可以將一個帶有字符串資源的DLL模塊以英語加載，而另一個以西班牙語加載。應(yīng)用程序在用戶選擇了合適的語種后再加載與之對應(yīng)的DLL文件。

　　三、使用符號名鏈接與標識號鏈接

　　在Win16環(huán)境中，符號名鏈接效率較低，所有那時標識號鏈接是主要的鏈接方式。在Win32環(huán)境中，符號名鏈接的效率得到了改善。Microsoft現(xiàn)在推薦使用符號名鏈接。但在MFC庫中的DLL版本仍然采用的是標識號鏈接。一個典型的MFC程序可能會鏈接到數(shù)百個MFC DLL函數(shù)上。采用標識號鏈接的應(yīng)用程序的EXE文件體相對較小，因為它不必包含導(dǎo)入函數(shù)的長字符串符號名。
比較大應(yīng)用程序都由很多模塊組成，這些模塊分別完成相對獨立的功能，它們彼此協(xié)作來完成整個軟件系統(tǒng)的工作。其中可能存在一些模塊的功能較為通用，在構(gòu)造其它軟件系統(tǒng)時仍會被使用。在構(gòu)造軟件系統(tǒng)時，如果將所有模塊的源代碼都靜態(tài)編譯到整個應(yīng)用程序EXE文件中，會產(chǎn)生一些問題：一個缺點是增加了應(yīng)用程序的大小，它會占用更多的磁盤空間，程序運行時也會消耗較大的內(nèi)存空間，造成系統(tǒng)資源的浪費；另一個缺點是，在編寫大的EXE程序時，在每次修改重建時都必須調(diào)整編譯所有源代碼，增加了編譯過程的復(fù)雜性，也不利于階段性的單元測試。

　　windows/" target=_blank>Windows系統(tǒng)平臺上提供了一種完全不同的較有效的編程和運行環(huán)境，你可以將獨立的程序模塊創(chuàng)建為較小的DLL(Dynamic Linkable Library)文件，并可對它們單獨編譯和測試。在運行時，只有當EXE程序確實要調(diào)用這些DLL模塊的情況下，系統(tǒng)才會將它們裝載到內(nèi)存空間中。這種方式不僅減少了EXE文件的大小和對內(nèi)存空間的需求，而且使這些DLL模塊可以同時被多個應(yīng)用程序使用。Microsoft Windows自己就將一些主要的系統(tǒng)功能以DLL模塊的形式實現(xiàn)。例如IE中的一些基本功能就是由DLL文件實現(xiàn)的，它可以被其它應(yīng)用程序調(diào)用和集成。

　　一般來說，DLL是一種磁盤文件（通常帶有DLL擴展名），它由全局數(shù)據(jù)、服務(wù)函數(shù)和資源組成，在運行時被系統(tǒng)加載到進程的虛擬空間中，成為調(diào)用進程的一部分。如果與其它DLL之間沒有沖突，該文件通常映射到進程虛擬空間的同一地址上。DLL模塊中包含各種導(dǎo)出函數(shù)，用于向外界提供服務(wù)。Windows在加載DLL模塊時將進程函數(shù)調(diào)用與DLL文件的導(dǎo)出函數(shù)相匹配。

　　在Win32環(huán)境中，每個進程都復(fù)制了自己的讀/寫全局變量。如果想要與其它進程共享內(nèi)存，必須使用內(nèi)存映射文件或者聲明一個共享數(shù)據(jù)段。DLL模塊需要的堆棧內(nèi)存都是從運行進程的堆棧中分配出來的。

　　DLL現(xiàn)在越來越容易編寫。Win32已經(jīng)大大簡化了其編程模式，并有許多來自AppWizard和MFC類庫的支持。

　　一、導(dǎo)出和導(dǎo)入函數(shù)的匹配

　　DLL文件中包含一個導(dǎo)出函數(shù)表。這些導(dǎo)出函數(shù)由它們的符號名和稱為標識號的整數(shù)與外界聯(lián)系起來。函數(shù)表中還包含了DLL中函數(shù)的地址。當應(yīng)用程序加載DLL模塊時時，它并不知道調(diào)用函數(shù)的實際地址，但它知道函數(shù)的符號名和標識號。動態(tài)鏈接過程在加載的DLL模塊時動態(tài)建立一個函數(shù)調(diào)用與函數(shù)地址的對應(yīng)表。如果重新編譯和重建DLL文件，并不需要修改應(yīng)用程序，除非你改變了導(dǎo)出函數(shù)的符號名和參數(shù)序列。

　　簡單的DLL文件只為應(yīng)用程序提供導(dǎo)出函數(shù)，比較復(fù)雜的DLL文件除了提供導(dǎo)出函數(shù)以外，還調(diào)用其它DLL文件中的函數(shù)。這樣，一個特殊的DLL可以既有導(dǎo)入函數(shù)，又有導(dǎo)入函數(shù)。這并不是一個問題，因為動態(tài)鏈接過程可以處理交叉相關(guān)的情況。

　　在DLL代碼中，必須像下面這樣明確聲明導(dǎo)出函數(shù)：

__declspec(dllexport) int MyFunction(int n);

　　但也可以在模塊定義(DEF)文件中列出導(dǎo)出函數(shù)，不過這樣做常常引起更多的麻煩。在應(yīng)用程序方面，要求像下面這樣明確聲明相應(yīng)的輸入函數(shù)：

__declspec(dllimport) int MyFuncition(int n);

　　僅有導(dǎo)入和導(dǎo)出聲明并不能使應(yīng)用程序內(nèi)部的函數(shù)調(diào)用鏈接到相應(yīng)的DLL文件上。應(yīng)用程序的項目必須為鏈接程序指定所需的輸入庫（LIB文件）。而且應(yīng)用程序事實上必須至少包含一個對DLL函數(shù)的調(diào)用。

　　二、與DLL模塊建立鏈接

　　應(yīng)用程序?qū)牒瘮?shù)與DLL文件中的導(dǎo)出函數(shù)進行鏈接有兩種方式：隱式鏈接和顯式鏈接。所謂的隱式鏈接是指在應(yīng)用程序中不需指明DLL文件的實際存儲路徑，程序員不需關(guān)心DLL文件的實際裝載。而顯式鏈接與此相反。

　　采用隱式鏈接方式，程序員在建立一個DLL文件時，鏈接程序會自動生成一個與之對應(yīng)的LIB導(dǎo)入文件。該文件包含了每一個DLL導(dǎo)出函數(shù)的符號名和可選的標識號，但是并不含有實際的代碼。LIB文件作為DLL的替代文件被編譯到應(yīng)用程序項目中。當程序員通過靜態(tài)鏈接方式編譯生成應(yīng)用程序時，應(yīng)用程序中的調(diào)用函數(shù)與LIB文件中導(dǎo)出符號相匹配，這些符號或標識號進入到生成的EXE文件中。LIB文件中也包含了對應(yīng)的DLL文件名（但不是完全的路徑名），鏈接程序?qū)⑵浯鎯υ贓XE文件內(nèi)部。當應(yīng)用程序運行過程中需要加載DLL文件時，Windows根據(jù)這些信息發(fā)現(xiàn)并加載DLL，然后通過符號名或標識號實現(xiàn)對DLL函數(shù)的動態(tài)鏈接。

　　顯式鏈接方式對于集成化的開發(fā)語言（例如VB）比較適合。有了顯式鏈接，程序員就不必再使用導(dǎo)入文件，而是直接調(diào)用Win32 的LoadLibary函數(shù)，并指定DLL的路徑作為參數(shù)。LoadLibary返回HINSTANCE參數(shù)，應(yīng)用程序在調(diào)用GetProcAddress函數(shù)時使用這一參數(shù)。GetProcAddress函數(shù)將符號名或標識號轉(zhuǎn)換為DLL內(nèi)部的地址。假設(shè)有一個導(dǎo)出如下函數(shù)的DLL文件：

extern "C" __declspec(dllexport) double SquareRoot(double d);

　　下面是應(yīng)用程序?qū)υ搶?dǎo)出函數(shù)的顯式鏈接的例子：

typedef double(SQRTPROC)(double);
HINSTANCE hInstance;
SQRTPROC* pFunction;
VERIFY(hInstance=::LoadLibrary("c:\\winnt\\system32\\mydll.dll"));
VERIFY(pFunction=(SQRTPROC*)::GetProcAddress(hInstance,"SquareRoot"));
double d=(*pFunction)(81.0);//調(diào)用該DLL函數(shù)

　　在隱式鏈接方式中，所有被應(yīng)用程序調(diào)用的DLL文件都會在應(yīng)用程序EXE文件加載時被加載在到內(nèi)存中；但如果采用顯式鏈接方式，程序員可以決定DLL文件何時加載或不加載。顯式鏈接在運行時決定加載哪個DLL文件。例如，可以將一個帶有字符串資源的DLL模塊以英語加載，而另一個以西班牙語加載。應(yīng)用程序在用戶選擇了合適的語種后再加載與之對應(yīng)的DLL文件。

　　三、使用符號名鏈接與標識號鏈接

　　在Win16環(huán)境中，符號名鏈接效率較低，所有那時標識號鏈接是主要的鏈接方式。在Win32環(huán)境中，符號名鏈接的效率得到了改善。Microsoft現(xiàn)在推薦使用符號名鏈接。但在MFC庫中的DLL版本仍然采用的是標識號鏈接。一個典型的MFC程序可能會鏈接到數(shù)百個MFC DLL函數(shù)上。采用標識號鏈接的應(yīng)用程序的EXE文件體相對較小，因為它不必包含導(dǎo)入函數(shù)的長字符串符號名。
四、編寫DllMain函數(shù)

　　DllMain函數(shù)是DLL模塊的默認入口點。當windows/" target=_blank>Windows加載DLL模塊時調(diào)用這一函數(shù)。系統(tǒng)首先調(diào)用全局對象的構(gòu)造函數(shù)，然后調(diào)用全局函數(shù)DLLMain。DLLMain函數(shù)不僅在將DLL鏈接加載到進程時被調(diào)用，在DLL模塊與進程分離時（以及其它時候）也被調(diào)用。下面是一個框架DLLMain函數(shù)的例子。

HINSTANCE g_hInstance;
extern "C" int APIENTRY DllMain(HINSTANCE hInstance,DWORD dwReason,LPVOID lpReserved)
{
if(dwReason==DLL_PROCESS_ATTACH)
{
TRACE0("EX22A.DLL Initializing!\n");
//在這里進行初始化
}
else if(dwReason=DLL_PROCESS_DETACH)
{
TRACE0("EX22A.DLL Terminating!\n");
//在這里進行清除工作
}
return 1;//成功
}

　　如果程序員沒有為DLL模塊編寫一個DLLMain函數(shù)，系統(tǒng)會從其它運行庫中引入一個不做任何操作的缺省DLLMain函數(shù)版本。在單個線程啟動和終止時，DLLMain函數(shù)也被調(diào)用。正如由dwReason參數(shù)所表明的那樣。

　　五、模塊句柄

　　進程中的每個DLL模塊被全局唯一的32字節(jié)的HINSTANCE句柄標識。進程自己還有一個HINSTANCE句柄。所有這些模塊句柄都只有在特定的進程內(nèi)部有效，它們代表了DLL或EXE模塊在進程虛擬空間中的起始地址。在Win32中，HINSTANCE和HMODULE的值是相同的，這個兩種類型可以替換使用。進程模塊句柄幾乎總是等于0x400000，而DLL模塊的加載地址的缺省句柄是0x10000000。如果程序同時使用了幾個DLL模塊，每一個都會有不同的HINSTANCE值。這是因為在創(chuàng)建DLL文件時指定了不同的基地址，或者是因為加載程序?qū)LL代碼進行了重定位。
模塊句柄對于加載資源特別重要。Win32 的FindResource函數(shù)中帶有一個HINSTANCE參數(shù)。EXE和DLL都有其自己的資源。如果應(yīng)用程序需要來自于DLL的資源，就將此參數(shù)指定為DLL的模塊句柄。如果需要EXE文件中包含的資源，就指定EXE的模塊句柄。

　　但是在使用這些句柄之前存在一個問題，你怎樣得到它們呢？如果需要得到EXE模塊句柄，調(diào)用帶有Null參數(shù)的Win32函數(shù)GetModuleHandle；如果需要DLL模塊句柄，就調(diào)用以DLL文件名為參數(shù)的Win32函數(shù)GetModuleHandle。

　　六、應(yīng)用程序怎樣找到DLL文件

　　如果應(yīng)用程序使用LoadLibrary顯式鏈接，那么在這個函數(shù)的參數(shù)中可以指定DLL文件的完整路徑。如果不指定路徑，或是進行隱式鏈接，Windows將遵循下面的搜索順序來定位DLL：

　　1． 包含EXE文件的目錄，
　　2． 進程的當前工作目錄，
　　3． Windows系統(tǒng)目錄，
　　4． Windows目錄，
　　5． 列在Path環(huán)境變量中的一系列目錄。

　　這里有一個很容易發(fā)生錯誤的陷阱。如果你使用VC＋＋進行項目開發(fā)，并且為DLL模塊專門創(chuàng)建了一個項目，然后將生成的DLL文件拷貝到系統(tǒng)目錄下，從應(yīng)用程序中調(diào)用DLL模塊。到目前為止，一切正常。接下來對DLL模塊做了一些修改后重新生成了新的DLL文件，但你忘記將新的DLL文件拷貝到系統(tǒng)目錄下。下一次當你運行應(yīng)用程序時，它仍加載了老版本的DLL文件，這可要當心！

　　七、調(diào)試DLL程序

　　Microsoft 的VC＋＋是開發(fā)和測試DLL的有效工具，只需從DLL項目中運行調(diào)試程序即可。當你第一次這樣操作時，調(diào)試程序會向你詢問EXE文件的路徑。此后每次在調(diào)試程序中運行DLL時，調(diào)試程序會自動加載該EXE文件。然后該EXE文件用上面的搜索序列發(fā)現(xiàn)DLL文件，這意味著你必須設(shè)置Path環(huán)境變量讓其包含DLL文件的磁盤路徑，或者也可以將DLL文件拷貝到搜索序列中的目錄路徑下。

     摘要: 隨著人們對應(yīng)用程序的要求越來越高，單進程應(yīng)用在許多場合已不能滿足人們的要求。編寫多進程/多線程程序成為現(xiàn)代程序設(shè)計的一個重要特點，在多進程程序設(shè)計中，進程間的通信是不可避免的。Microsoft Win32 API提供了多種進程間通信的方法，全面地闡述了這些方法的特點，并加以比較和分析，希望能給讀者選擇通信方法提供參考。  閱讀全文 轉(zhuǎn)自：http://www.cnblogs.com/sideandside/archive/2007/04/04/699637.html

        進程是系統(tǒng)分配資源的單位，每一個進程對應(yīng)與一個活動的程序，當進程激活時，操作系統(tǒng)就將系統(tǒng)的資源包括內(nèi)存、I/O和CPU等分配給它，使它執(zhí)行。線程是CPU分配時間的單位，每一個線程對應(yīng)于它在進程中的一個函數(shù)，也就是內(nèi)存中的代碼段，多個線程執(zhí)行時CPU會根據(jù)它們的優(yōu)先級分配時間，使它們完成自己的功能。 一般來說，進程中至少一個線程，一個主線程和其他線程組成一個進程。多個線程的目的在于分享CPU的時間片，從而完成并行任務(wù)。
下面是自己整理的：
 線程和進程的比較：
線程是比進程更小的能獨立運行的基本單位，通常一個進程都有若干個線程，至少也需要一個線程。
        1.調(diào)度
線程師調(diào)度和分派的基本單位，進程是資源擁有的基本單位。
        2.并發(fā)性
進程之間可以并發(fā)執(zhí)行，在一個進程中的多個線程之間也可以并發(fā)執(zhí)行。
        3.擁有資源
進程是擁有資源的一個獨立單元，線程自己不擁有系統(tǒng)資源（也有一點比不可少的資源）但它可以訪問其隸屬進程的資源。
        ４．系統(tǒng)開銷
創(chuàng)建或撤消進程時，系統(tǒng)都要為之分配或回收資源，如內(nèi)存空間、I/O設(shè)備等，OS所付出的開銷顯著大于在創(chuàng)建或撤消線程時的開銷；進程切換的開銷也遠大于線程切換的開銷。

        進程是指在系統(tǒng)中正在運行的一個應(yīng)用程序；線程是系統(tǒng)分配處理器時間資源的基本單元，或者說進程之內(nèi)獨立執(zhí)行的一個單元。對于操作系統(tǒng)而言其調(diào)度單元是線程。一個進程至少包括一個線程，通常將該線程稱為主線程。一個進程從主線程的執(zhí)行開始進而創(chuàng)建一個或多個附加線程，就是所謂基于多線程的多任務(wù)。
　　那進程與線程的區(qū)別到底是什么？進程是執(zhí)行程序的實例。例如，當你運行記事本程序（Nodepad）時，你就創(chuàng)建了一個用來容納組成Notepad.exe的代碼及其所需調(diào)用動態(tài)鏈接庫的進程。每個進程均運行在其專用且受保護的地址空間內(nèi)。因此，如果你同時運行記事本的兩個拷貝，該程序正在使用的數(shù)據(jù)在各自實例中是彼此獨立的。在記事本的一個拷貝中將無法看到該程序的第二個實例打開的數(shù)據(jù)。

　　以沙箱為例進行闡述。一個進程就好比一個沙箱。線程就如同沙箱中的孩子們。孩子們在沙箱子中跑來跑去，并且可能將沙子攘到別的孩子眼中，他們會互相踢打或撕咬。但是，這些沙箱略有不同之處就在于每個沙箱完全由墻壁
和頂棚封閉起來，無論箱中的孩子如何狠命地攘沙，他們也不會影響到其它沙箱中的其他孩子。因此，每個進程就象一個被保護起來的沙箱。未經(jīng)許可，無人可以進出。

　　實際上線程運行而進程不運行。兩個進程彼此獲得專用數(shù)據(jù)或內(nèi)存的唯一途徑就是通過協(xié)議來共享內(nèi)存塊。這是一種協(xié)作策略。下面讓我們分析一下任務(wù)管理器里的進程選項卡。

　　這里的進程是指一系列進程，這些進程是由它們所運行的可執(zhí)行程序?qū)嵗齺碜R別的，這就是進程選項卡中的第一列給出了映射名稱的原因。請注意，這里并沒有進程名稱列。進程并不擁有獨立于其所歸屬實例的映射名稱。換言之
，如果你運行5個記事本拷貝，你將會看到5個稱為Notepad.exe的進程。它們是如何彼此區(qū)別的呢？其中一種方式是通過它們的進程ID，因為每個進程都擁有其獨一無二的編碼。該進程ID由Windows NT或Windows 2000生成，并可以循環(huán)使用。因此，進程ID將不會越編越大，它們能夠得到循環(huán)利用。第三列是被進程中的線程所占用的CPU時間百分比。它不是CPU的編號，而是被進程占用的CPU時間百分比。此時我的系統(tǒng)基本上是空閑的。盡管系統(tǒng)看上去每一秒左右都只使用一小部分CPU時間，但該系統(tǒng)空閑進程仍舊耗用了大約99%的CPU時間。

　　第四列，CPU時間，是CPU被進程中的線程累計占用的小時、分鐘及秒數(shù)。請注意，我對進程中的線程使用占用一詞。這并不一定意味著那就是進程已耗用的CPU時間總和，因為，如我們一會兒將看到的，NT計時的方式是，當特定的時鐘間隔激發(fā)時，無論誰恰巧處于當前的線程中，它都將計算到CPU周期之內(nèi)。通常情況下，在大多數(shù)NT系統(tǒng)中，時鐘以10毫秒的間隔運行。每10毫秒NT的心臟就跳動一下。有一些驅(qū)動程序代碼片段運行并顯示誰是當前的線程。讓我們將CPU時間的最后10毫秒記在它的帳上。因此，如果一個線程開始運行，并在持續(xù)運行8毫秒后完成，接著，第二個線程開始運行并持續(xù)了2毫秒，這時，時鐘激發(fā)，請猜一猜這整整10毫秒的時鐘周期到底記在了哪個線程的帳上？答案是第二個線程。因此，NT中存在一些固有的不準確性，而NT恰是以這種方式進行計時，實際情況也如是，大多數(shù)32位操作系統(tǒng)中都存在一個基于間隔的計時機制。請記住這一點，因為，有時當你觀察線程所耗用的CPU總和時，會出現(xiàn)盡管該線程或許看上去已運行過數(shù)十萬次，但其CPU時間占用量卻可能是零或非常短暫的現(xiàn)象，那么，上述解釋便是原因所在。上述也就是我們在任務(wù)管理器的進程選項卡中所能看到的基本信息列。

     摘要: 簡述組件的定義  閱讀全文      摘要: 如題  閱讀全文      摘要: 如題  閱讀全文      摘要: swt調(diào)用系統(tǒng)程序  閱讀全文