應用程序之間的數據交換（互相通訊）一直是困擾廣大程序員的難題，盡管已經出現了各式各樣的解決方案，但迄今為止沒有哪一種方案是完美無缺的。因此，只有學習並了解了它們的優缺點後，才能在特定的情況下選擇最佳方案，以滿足最終的要求。 1、共享 在硬盤上建立一個文件，一個應用程序往該文件裡寫數據（可以不關閉文件，但必須刷新緩沖區），另一個應用程序以共享方式打開這個文件並讀取其中的內容，這便是最簡單的一種數據交換方式。對於網絡用戶而言，只要兩台終端上安裝的都是Win311 For Workgroup或Windows 95（或NT），則只要設置一下目錄共享，映射成網絡驅動器，同樣可以簡單地實現數據交換。但它的缺點也是顯而易見的：只能采取輪詢的方式獲得最新數據（效率低下），網絡映射的驅動器絕對不能變動或取消（可靠性差），所以這是一種“低級”的通訊方式。 2、DDE 每個Windows程序員都不會對DDE（動態數據交換）感到陌生，它是最早的基於Windows的數據交換方法，有三種方式可供選擇：冷連接、溫連接和熱連接。一般都是由客戶端向服務器端發出連接申請，並且必須指明服務器端的名字和標題。在連接建立後，數據可以雙向流動。典型的例子如抓圖軟件SnagIt，它提供了DDE接口，能夠讓其它應用程序來控制它。DDE是完全向後兼容的，從16位平台轉到32位，源代碼幾乎不用修改。 DDE還有網絡功能。使用過Win311 For Workgroup的人大概都還記得，它自帶一個非常吸引人的小程序“Chat”，能使兩台計算機通過網絡實時交談，這在當時幾乎是一項創舉。可是很少有人知道“Chat”使用的是一種特殊的DDE，即NetDDE。它的基本工作原理仍然是DDE，但它能使一台計算機向在同一個網絡中的另一台終端發消息，而不像普通DDE 只能局限在同一台機器上。與其它的數據交換方式相比，DDE已不夠先進，而且Microsoft也不再積極支持DDE，所以它的前景不被看好。 3、WM_COPYDATA Windows消息WM_COPYDATA功能強大，知之者卻甚少。它的確切定義是：一個應用程序向另一個應用程序傳遞數據時所發出的消息。眾所周知，Windows 在很大程度上依賴於消息機制，那麼我們為什麼不把數據放在消息中一起發送出去呢？這樣，我們只要調用SendMessage（），以對方窗體的句柄作為第一個參數，以含有指向實際數據的指針結構的地址作為第二個參數，就可以把整個數據塊當作消息發向另一個應用程序。也許有的程序員會說，一個自定義的消息同樣可以完成這樣的工作。他只說對了一半。自定義消息的確可以發送到其它的應用程序上去，但其原始數據所在的內存區只有在發送過程中才是合法的，若在其它模塊中存取該內存區就會導致“Access Violation”。而使用WM_COPYDATA 則不存在這個問題，因為Windows 本身會替你處理這一切。深入鑽研下去，你會發現它其實是先創建了一個文件映射的對象，將發送方的原始數據先拷貝至映射文件，然後再在接收方對這個映射文件打開一個“視圖”。WM_COPYDATA 的不足之處在於：必須要有一個窗體來接收消息和數據（缺乏靈活性），數據在使用之前先得拷貝到一個映射文件（浪費資源）。 4、NetBIOS 從80年代開始，NetBIOS就是開發Client/Server類程序的標准接口。而當時其它的解決方案幾乎都是從UNIX系統上發展而來的。當然，對於今天的用戶而言，NetBIOS已不是唯一的選擇，他們可以從各種方案中擇優選取。在Windows 95和NT平台上，可以通過API函數Netbios()來調用NetBIOS功能。 NetBIOS兼容以下幾種低層協議：NetBEUI協議（NBF）、NWLink NetBIOS(NWNBlink)、NetBIOS over TCP/IP(NetBT)。NetBIOS的優點是速度較快，缺點是可靠性較差。 5、標准的Sockets和WinSock Sockets是15年前在UNIX系統上提出來的，一開始主要是用於本地通訊，但很快就應用在Client/Server體系上了。它的內核很簡單：你可以將一個Socket看作是一個雙向的節點，一個應用程序可以通過它先與另一個程序建立連接（建立在一個雙方都認可的端上，以便於區分同時運行的幾個通訊線程），然後就可以彼此交換數據了。 微軟公司在其基礎上創建了WinSock，專門用於Windows接口，與Socket完全兼容。近年來基於TCP/IP協議的網絡大行其道，Socket也隨之獲得了更加廣泛的應用。 如今，Sockets已在Internet上獲得了最廣泛的應用，主要是因為它的可移植性好： Socket應用程序無論在任何平台間都能互相進行通訊（不管是PC機還是Macintosh,也不管是Windows平台還是UNIX平台）。而最新推出的WinSock 2.0，已不僅僅只基於TCP/IP協議，還可基於其它幾種傳輸協議（如IPX）。 Socket的缺陷是它工作在通訊的低層，所以實現起來較為復雜（如果是Win 95或NT平台，則不存在這個問題，微軟公司提供了相應的控件）。但是，如果要在多個平台間互相通訊，則Socket是不二之選。 6、Mailslot和Pipe Mailslot和Pipe有很多相同點，即都是高層的、基於內存的通訊系統。Mailslot由Server端創建，代碼如下： myMailslot = CreateMailslot(pSlotName, 0, MAILSLOT_WAIT_FOREVER, NULL); 然後，Client端就可以像打開文件一樣打開這個Mailslot，再通過API函數WriteFile()來將數據寫入到消息隊列中。 與此相類似，Pipe也是由Server端創建的，代碼如下： pipe = CreateNamedPipe(pPipeName, PIPE_ACCESS_DUPLEX, PIPE_TYPE_MESSAGE |PIPE_READMODE_MESSAGE | PIPE_WAIT, PIPE_UNLIMITED_INSTANCES, BUFSIZE,BUFSIZE, 20000, NULL); 接著，Client端就可以通過一般的文件API讀寫數據，代碼如下： 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是以句柄而不是以名字來進行標識的，因而也就限制了它只能在同一台機器上通訊，而不能應用於網絡。命名Pipe則提供了以名字來進行標識，所以能在網絡上的其它任何地方打開它。需要注意的是：命名Pipe只能在 Win NT而不是Win 95上創建（即Server端），Client端則可以是任意平台。 Pipe既可以單向通訊也可以雙向通訊，Mailslot則只能單向通訊。Client端可以發送消息給mailslot，但不能接收消息；如果你想要接收消息，則只能創建一個新的mailslot。但mailslot有一個很大的優點：它支持數據廣播。也就是說，若Client端發送一條消息，則整個網絡中的同名對象都能收到。這是因為mailslot的名字的作用域只是在本台機器上，所以可在不同機器上創建同名的mailslot，當Client端發來消息時則每一台機上的mailslot都得到了該消息的一份拷貝，並在本機上作出相應的反應。Mailslot的最大缺陷是不可靠，因為它的數據是以數據報格式來傳送的，網絡錯誤或負荷過重都會導致數據丟失。 Pipe則較為可靠，但它不能廣播。所以，如果你不需要進行廣播，則Pipe是更好的選擇。選擇Mailslot，則要對此後遇到的麻煩有充分的准備。 7、剪貼板（Clipboard） 大家對Windows的剪貼板應該不會感到陌生吧？它的出現就是為了實現應用程序間的互相數據交換。Windows提供了一系列的API函數來讓應用程序安全地打開剪貼板，讀寫其中的數據。 剪貼板的缺陷也是顯而易見的：當有新的數據放在剪貼板上時，則先前的數據就會被沖掉，而在Windows中用到剪貼板的時候又實在太多了，所以這種方式用於程序間的通訊顯然不夠安全。 8、COM和DCOM 公共對象模式（COM）是一種協議，它建立了一個軟件模塊同另一個軟件模塊之間的連接，然後將其描述出來。當這種連接建立起來之後，則兩個模塊之間就可以通過稱為“接口”的機制來進行通訊。COM可以用不同的語言（VB、VC、Delphi）進行編制，又能被其它語言編寫的程序所使用，並且不用管通訊雙方實際所處的位置（是在同一台機上，還是在同一個網絡上的不同機上）。事實上，Internet上有大量的COM控件可供人們下載使用，其中有相當一部分就是用於應用程序間的相互通訊（甚至是Internet程序間的通訊），硬盤上能夠看到的大量的.ocx文件其實就是一種COM。 www.2cto.com COM對象為外部調用提供了一個標准的界面，COM Client通過創建COM Server的一個實例獲得指針，轉向所需的函數定義處並執行相應的程序。講得通俗一點，也就是先正確定義好COM對象的屬性（Property），再執行相應的方法（Method）。 DCOM（分布式公共對象模式）是COM在網絡上的一種擴展，它通過把分布式對象間的通訊變成一個實體來實現通訊。 COM如今被微軟公司大力提倡，最著名的有OLE、ActiveX、DirectX和Win95、WinNT的外殼。由於微軟公司目前在軟件業處於霸主地位，所以COM很有可能成為將來的業界標准，其前途也較為看好。但COM的龐大也會使一些經驗豐富的程序員望而卻步，他們寧可自己多寫一些代碼以使整個程序更為簡潔、有效而不願使用COM。 以上介紹的只是現今流行的一些通訊方法，它們各有各的優缺點，沒有哪一種是萬能的。因此，只有在合適的場合采用合適的方案，才是最好的解決辦法。
