應用程序之間的數(shù)據(jù)交換（互相通訊）一直是困擾廣大程序員的難題，盡管已經(jīng)出現(xiàn)了各式各樣的解決方案，但迄今為止沒有哪一種方案是完美無缺的。因此，只有學習并了解了它們的優(yōu)缺點后，才能在特定的情況下選擇最佳方案，以滿足最終的要求。

　　1、共享

　　在硬盤上建立一個文件，一個應用程序往該文件里寫數(shù)據(jù)（可以不關閉文件，但必須刷新緩沖區(qū)），另一個應用程序以共享方式打開這個文件并讀取其中的內(nèi)容，這便是最簡單的一種數(shù)據(jù)交換方式。對于網(wǎng)絡用戶而言，只要兩臺終端上安裝的都是Win311 For Workgroup或Windows 95（或NT），則只要設置一下目錄共享，映射成網(wǎng)絡驅(qū)動器，同樣可以簡單地實現(xiàn)數(shù)據(jù)交換。但它的缺點也是顯而易見的：只能采取輪詢的方式獲得最新數(shù)據(jù)（效率低下），網(wǎng)絡映射的驅(qū)動器絕對不能變動或取消（可靠性差），所以這是一種“低級”的通訊方式。

　　2、DDE

　　每個Windows程序員都不會對DDE（動態(tài)數(shù)據(jù)交換）感到陌生，它是最早的基于Windows的數(shù)據(jù)交換方法，有三種方式可供選擇：冷連接、溫連接和熱連接。一般都是由客戶端向服務器端發(fā)出連接申請，并且必須指明服務器端的名字和標題。在連接建立后，數(shù)據(jù)可以雙向流動。典型的例子如抓圖軟件SnagIt，它提供了DDE接口，能夠讓其它應用程序來控制它。DDE是完全向后兼容的，從16位平臺轉(zhuǎn)到32位，源代碼幾乎不用修改。

　　DDE還有網(wǎng)絡功能。使用過Win311 For Workgroup的人大概都還記得，它自帶一個非常吸引人的小程序“Chat”，能使兩臺計算機通過網(wǎng)絡實時交談，這在當時幾乎是一項創(chuàng)舉。可是很少有人知道“Chat”使用的是一種特殊的DDE，即NetDDE。它的基本工作原理仍然是DDE，但它能使一臺計算機向在同一個網(wǎng)絡中的另一臺終端發(fā)消息，而不像普通DDE 只能局限在同一臺機器上。與其它的數(shù)據(jù)交換方式相比，DDE已不夠先進，而且Microsoft也不再積極支持DDE，所以它的前景不被看好。

　　3、WM_COPYDATA

　　Windows消息WM_COPYDATA功能強大，知之者卻甚少。它的確切定義是：一個應用程序向另一個應用程序傳遞數(shù)據(jù)時所發(fā)出的消息。眾所周知，Windows 在很大程度上依賴于消息機制，那么我們?yōu)槭裁床话褦?shù)據(jù)放在消息中一起發(fā)送出去呢？這樣，我們只要調(diào)用SendMessage（），以對方窗體的句柄作為第一個參數(shù)，以含有指向?qū)嶋H數(shù)據(jù)的指針結(jié)構(gòu)的地址作為第二個參數(shù)，就可以把整個數(shù)據(jù)塊當作消息發(fā)向另一個應用程序。也許有的程序員會說，一個自定義的消息同樣可以完成這樣的工作。他只說對了一半。自定義消息的確可以發(fā)送到其它的應用程序上去，但其原始數(shù)據(jù)所在的內(nèi)存區(qū)只有在發(fā)送過程中才是合法的，若在其它模塊中存取該內(nèi)存區(qū)就會導致“Access Violation”。而使用WM_COPYDATA 則不存在這個問題，因為Windows 本身會替你處理這一切。深入鉆研下去，你會發(fā)現(xiàn)它其實是先創(chuàng)建了一個文件映射的對象，將發(fā)送方的原始數(shù)據(jù)先拷貝至映射文件，然后再在接收方對這個映射文件打開一個“視圖”。WM_COPYDATA 的不足之處在于：必須要有一個窗體來接收消息和數(shù)據(jù)（缺乏靈活性），數(shù)據(jù)在使用之前先得拷貝到一個映射文件（浪費資源）。

　　4、NetBIOS

　　從80年代開始，NetBIOS就是開發(fā)Client/Server類程序的標準接口。而當時其它的解決方案幾乎都是從UNIX系統(tǒng)上發(fā)展而來的。當然，對于今天的用戶而言，NetBIOS已不是唯一的選擇，他們可以從各種方案中擇優(yōu)選取。在Windows 95和NT平臺上，可以通過API函數(shù)Netbios()來調(diào)用NetBIOS功能。

　　NetBIOS兼容以下幾種低層協(xié)議：NetBEUI協(xié)議（NBF）、NWLink NetBIOS(NWNBlink)、NetBIOS over TCP/IP(NetBT)。NetBIOS的優(yōu)點是速度較快，缺點是可靠性較差。

　　5、標準的Sockets和WinSock

　　Sockets是15年前在UNIX系統(tǒng)上提出來的，一開始主要是用于本地通訊，但很快就應用在Client/Server體系上了。它的內(nèi)核很簡單：你可以將一個Socket看作是一個雙向的節(jié)點，一個應用程序可以通過它先與另一個程序建立連接（建立在一個雙方都認可的端上，以便于區(qū)分同時運行的幾個通訊線程），然后就可以彼此交換數(shù)據(jù)了。

　　微軟公司在其基礎上創(chuàng)建了WinSock，專門用于Windows接口，與Socket完全兼容。近年來基于TCP/IP協(xié)議的網(wǎng)絡大行其道，Socket也隨之獲得了更加廣泛的應用。

　　如今，Sockets已在Internet上獲得了最廣泛的應用，主要是因為它的可移植性好：

　　Socket應用程序無論在任何平臺間都能互相進行通訊（不管是PC機還是Macintosh,也不管是Windows平臺還是UNIX平臺）。而最新推出的WinSock 2.0，已不僅僅只基于TCP/IP協(xié)議，還可基于其它幾種傳輸協(xié)議（如IPX）。

　　Socket的缺陷是它工作在通訊的低層，所以實現(xiàn)起來較為復雜（如果是Win 95或NT平臺，則不存在這個問題，微軟公司提供了相應的控件）。但是，如果要在多個平臺間互相通訊，則Socket是不二之選。

　　6、Mailslot和Pipe

　　Mailslot和Pipe有很多相同點，即都是高層的、基于內(nèi)存的通訊系統(tǒng)。Mailslot由Server端創(chuàng)建，代碼如下：

　　myMailslot = CreateMailslot(pSlotName, 0, MAILSLOT_WAIT_FOREVER, NULL);

　　然后，Client端就可以像打開文件一樣打開這個Mailslot，再通過API函數(shù)WriteFile()來將數(shù)據(jù)寫入到消息隊列中。

　　與此相類似，Pipe也是由Server端創(chuàng)建的，代碼如下：

　　pipe = CreateNamedPipe(pPipeName, PIPE_ACCESS_DUPLEX, PIPE_TYPE_MESSAGE |PIPE_READMODE_MESSAGE | PIPE_WAIT, PIPE_UNLIMITED_INSTANCES, BUFSIZE,BUFSIZE, 20000, NULL);

　　接著，Client端就可以通過一般的文件API讀寫數(shù)據(jù)，代碼如下：

　　pipe = CreateFile(pPipeName, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING,0,NULL);

　　success = WriteFile(pipe, pMessage, strlen(pMessage) + 1, &bytesWritten, NULL);

　　Pipe分兩種，即命名Pipe和匿名Pipe。匿名Pipe是以句柄而不是以名字來進行標識的，因而也就限制了它只能在同一臺機器上通訊，而不能應用于網(wǎng)絡。命名Pipe則提供了以名字來進行標識，所以能在網(wǎng)絡上的其它任何地方打開它。需要注意的是：命名Pipe只能在 Win NT而不是Win 95上創(chuàng)建（即Server端），Client端則可以是任意平臺。

　　Pipe既可以單向通訊也可以雙向通訊，Mailslot則只能單向通訊。Client端可以發(fā)送消息給mailslot，但不能接收消息；如果你想要接收消息，則只能創(chuàng)建一個新的mailslot。但mailslot有一個很大的優(yōu)點：它支持數(shù)據(jù)廣播。也就是說，若Client端發(fā)送一條消息，則整個網(wǎng)絡中的同名對象都能收到。這是因為mailslot的名字的作用域只是在本臺機器上，所以可在不同機器上創(chuàng)建同名的mailslot，當Client端發(fā)來消息時則每一臺機上的mailslot都得到了該消息的一份拷貝，并在本機上作出相應的反應。Mailslot的最大缺陷是不可靠，因為它的數(shù)據(jù)是以數(shù)據(jù)報格式來傳送的，網(wǎng)絡錯誤或負荷過重都會導致數(shù)據(jù)丟失。

　　Pipe則較為可靠，但它不能廣播。所以，如果你不需要進行廣播，則Pipe是更好的選擇。選擇Mailslot，則要對此后遇到的麻煩有充分的準備。

　　7、剪貼板（Clipboard）

　　大家對Windows的剪貼板應該不會感到陌生吧？它的出現(xiàn)就是為了實現(xiàn)應用程序間的互相數(shù)據(jù)交換。Windows提供了一系列的API函數(shù)來讓應用程序安全地打開剪貼板，讀寫其中的數(shù)據(jù)。

　　剪貼板的缺陷也是顯而易見的：當有新的數(shù)據(jù)放在剪貼板上時，則先前的數(shù)據(jù)就會被沖掉，而在Windows中用到剪貼板的時候又實在太多了，所以這種方式用于程序間的通訊顯然不夠安全。

　　8、COM和DCOM

　　公共對象模式（COM）是一種協(xié)議，它建立了一個軟件模塊同另一個軟件模塊之間的連接，然后將其描述出來。當這種連接建立起來之后，則兩個模塊之間就可以通過稱為“接口”的機制來進行通訊。COM可以用不同的語言（VB、VC、Delphi）進行編制，又能被其它語言編寫的程序所使用，并且不用管通訊雙方實際所處的位置（是在同一臺機上，還是在同一個網(wǎng)絡上的不同機上）。事實上，Internet上有大量的COM控件可供人們下載使用，其中有相當一部分就是用于應用程序間的相互通訊（甚至是Internet程序間的通訊），硬盤上能夠看到的大量的.ocx文件其實就是一種COM。

　　COM對象為外部調(diào)用提供了一個標準的界面，COM Client通過創(chuàng)建COM Server的一個實例獲得指針，轉(zhuǎn)向所需的函數(shù)定義處并執(zhí)行相應的程序。講得通俗一點，也就是先正確定義好COM對象的屬性（Property），再執(zhí)行相應的方法（Method）。

　　DCOM（分布式公共對象模式）是COM在網(wǎng)絡上的一種擴展，它通過把分布式對象間的通訊變成一個實體來實現(xiàn)通訊。

　　COM如今被微軟公司大力提倡，最著名的有OLE、ActiveX、DirectX和Win95、WinNT的外殼。由于微軟公司目前在軟件業(yè)處于霸主地位，所以COM很有可能成為將來的業(yè)界標準，其前途也較為看好。但COM的龐大也會使一些經(jīng)驗豐富的程序員望而卻步，他們寧可自己多寫一些代碼以使整個程序更為簡潔、有效而不愿使用COM。

　　以上介紹的只是現(xiàn)今流行的一些通訊方法，它們各有各的優(yōu)缺點，沒有哪一種是萬能的。因此，只有在合適的場合采用合適的方案，才是最好的解決辦法。