【文章內(nèi)容簡(jiǎn)介】 lass libraries），以 C++類的形式封裝了 Windows 的 API，并且包含一個(gè)應(yīng)用程序框架，以減少應(yīng)用程序開(kāi)發(fā)人員的工作量。其中包含的類包含大量 Windows 句柄封裝類和很多 Windows 的內(nèi)建控件和組件的封裝類。 的確 ， MFC 給我們提供了很便捷的編程方式，我們幾乎可以不需要寫任何代碼就能生成一個(gè)帶有菜單，工具欄和視圖的窗口， MFC也提供了豐富的控件類 ，在設(shè)計(jì)對(duì)話框的時(shí)候，我們也只需要直接將控件拖進(jìn)對(duì)話框里，而不用寫任何代碼。 iMessaging 就是典型的ＭＦＣ應(yīng)用程序， 采用了ＭＦＣ對(duì)話框設(shè)計(jì)框架，但是 為了設(shè)計(jì)一個(gè)友好 美觀的操作界面，僅用微軟提供的控件類庫(kù)達(dá)不到預(yù)期的 基于局域網(wǎng)的聊天軟件的設(shè)計(jì)與實(shí)現(xiàn) 4 效果， 因此，就必 須重新繪制其對(duì)話框和控件 的界面。而正由于微軟將這些控件封裝得很好，對(duì)于要修改它的屬性，派生一些美觀的子控件難度就顯得比較大。一般來(lái)說(shuō)，實(shí)現(xiàn)對(duì)控件的重繪技術(shù)主要有子類化，自繪和重繪技術(shù)，由于ＭＦＣ框架太過(guò)于標(biāo)準(zhǔn)化，因此實(shí)現(xiàn)這些技術(shù)也是有一定的難度，這必須要對(duì)框架的結(jié)構(gòu)有一定的了解。 iMessaging 采用了的窗體背景重繪， listctrl 自繪，按鈕貼圖等方式實(shí)現(xiàn)了操作界面的美觀 。主要 核心 技術(shù) 是 ＧＤＩ雙緩沖繪圖。雙緩沖繪圖就是將待 繪制的圖片保存到內(nèi)存里，當(dāng)需要繪制到屏幕上時(shí)，再一次性投遞到設(shè)備描述表里，這樣既避免了窗口重繪時(shí)的閃爍，又提高了繪制的速度和效率。BOOL CDC::CreatieCompatibleDC(CDC* pDC)函數(shù)用來(lái)創(chuàng)建一個(gè)兼容 DC,即在內(nèi)存里創(chuàng)建一個(gè) DC，以后的任何繪圖 所需的 操作 ，如選用何種畫筆，畫刷，字體等，都將 在內(nèi)存中進(jìn)行，而不是在 真實(shí) 設(shè)備上下文里。隨后可以創(chuàng)建一張兼容位圖，需要繪制的 圖像將 ，函數(shù)原型如下 BOOL CBitmap::CreateCiompatibleBitmap(CDC* pDC,int nWidth,int nHeight)。最后需要將兼容 DC里的東西投射到真實(shí)的 DC里， BOOL BitBlt(HDC hdcDest, int nXDest, int nYDest, int nWidth, int nHeight, HDC hdcSrc, int nXSrc, int nYSrc,DWORD dwRop )函數(shù)可以實(shí)現(xiàn)該功能，具體用法可參考 MSDN。 對(duì)話框的繪制比較容易， MFC 為對(duì)話框提供了 OnPaint 消息相應(yīng)函數(shù)，但 是在該函數(shù)下繪制并不能從根本上重繪對(duì)話框，因?yàn)樵摵瘮?shù)還會(huì)調(diào)用CDialog::OnPaint 函數(shù)， 在內(nèi)部還 會(huì) 再去 重繪背景，因此要實(shí)現(xiàn) 完全意義上的重繪背景，就必須響應(yīng) WM_ERASEBKGND 消息， 在消息響應(yīng)函數(shù)里實(shí)現(xiàn)我們自己的繪制方法，然后直接返回 TRUE，不再調(diào)用 CDialog::OnEraseBkgnd()函數(shù)。為了實(shí)現(xiàn)像 那樣的界面，必須將對(duì)話框的屬性設(shè)置為 None 屬性，即沒(méi)有標(biāo)題欄，因此只有自己去實(shí)現(xiàn)標(biāo)題欄的功能。 CListCtrl重繪的方法有兩種 ,一種是采用微軟提供的 OWNERDRAW屬性 ,通過(guò)重載 DrawItem 虛函數(shù)來(lái)進(jìn)行重繪。另外一種就是 Customdraw 屬性，通過(guò)定義自繪消息響應(yīng)函數(shù)來(lái)進(jìn)行重繪。兩種方式有不同之處，前者需要對(duì)整個(gè) ListCtrl繪制，必須考慮到每一個(gè) item 項(xiàng)的繪制情況。而后者相對(duì)比較簡(jiǎn)便，系統(tǒng)會(huì)在四個(gè)狀態(tài)的時(shí)候通知重繪，這四個(gè)狀態(tài)分別是繪制前，繪制后，擦除前，擦除后，我們就可以按照自己的需要去繪制，并且我們只用考慮其中一項(xiàng) item 的繪制方 基于局域網(wǎng)的聊天軟件的設(shè)計(jì)與實(shí)現(xiàn) 5 法，就可以應(yīng)用于所有項(xiàng)。 iMessaging 采用了后者進(jìn)行對(duì)列表控件的重繪，實(shí)現(xiàn)了好友列表控件，群列表控件類。 對(duì)于 VC6 開(kāi)發(fā)環(huán)境，微軟提供的通用 button 控件的外觀從現(xiàn)在看來(lái)的確不太美觀，無(wú)法實(shí)現(xiàn)動(dòng)態(tài)狀態(tài)的效果。那么因此就必須重新 創(chuàng)建一個(gè) 派生 于CButton 的 按鈕 類，由于該類將應(yīng)用于本軟件的所有按鈕控件，因此做成可貼狀態(tài) 圖的按鈕控件最為合適。狀態(tài)分為移出按鈕，懸浮按鈕，按下按鈕，禁用按鈕四種狀態(tài)，我們只需要提供相應(yīng)的狀態(tài)的 Bitmap 就可以。具體重繪方法就是采用前面提到的 OWNERDRAW屬性，重載虛函數(shù) DrawItem。而捕獲鼠標(biāo)的移入移出消息可以使用 _TrackMouseEvent 函數(shù)，通過(guò)設(shè)置 TRACEMOUSEEVENT 結(jié)構(gòu)體的值來(lái)捕捉該消息。其移出消息對(duì)應(yīng)的是 WM_MOUSELEAVE，移入按鈕消息是WM_MOUSEHOVER，分別定義其消息相應(yīng)函數(shù)，這樣就能實(shí)現(xiàn)狀態(tài)的更替，再進(jìn)行相應(yīng)的繪制。 Winsock 編程 Windows 下網(wǎng)絡(luò)編程的規(guī)范－ Windows Sockets 是 Windows 下得到廣泛應(yīng)用的、開(kāi)放的、支持多種協(xié)議的網(wǎng)絡(luò)編程接口。 它實(shí)現(xiàn)了標(biāo)準(zhǔn) socket 編成的函數(shù)，提供了一套屬于 windows 下的套接子 API。其 通信的基礎(chǔ)是套接 字 （ Socket），一個(gè)套接 字 是通訊的一端。在這一端上你可以找到與其對(duì)應(yīng)的一個(gè)名字。一個(gè)正在被使用的套接字都有它的類型和與其相關(guān)的進(jìn)程。套接字存在于通訊域中。通訊域是為了處理一般的線程通過(guò)套接字通訊而引進(jìn)的一種抽象概念。套接字通常和同一個(gè)域中的套接字交換數(shù)據(jù)（數(shù)據(jù)交換也可能穿越域的界限，但這時(shí)一定要執(zhí)行某種解釋程序）。 Windows Sockets 規(guī)范支持單一的通訊域，即 Inter域。各種進(jìn)程使用這個(gè)域互相之間用 Inter協(xié)議族來(lái)進(jìn)行通訊（ Windows Sockets 以上的版本支持其他的域，例如Windows Sockets 2）。套接字可以根據(jù)通訊性質(zhì)分類；這種性質(zhì)對(duì)于用戶是可見(jiàn)的。應(yīng)用程序一般僅在同一類的套接字間通訊。不過(guò)只要底層的通訊協(xié)議允許，不同類型的套接字間也照樣可以通訊。用戶目前可以使用兩種套接字，即流套接字和數(shù)據(jù)報(bào)套接字。流套接字提供了雙向的，有序的，無(wú)重復(fù)并且無(wú)記錄邊界的數(shù)據(jù)流服務(wù)。數(shù)據(jù)報(bào)套接字支持雙向的數(shù)據(jù)流， 基于局域網(wǎng)的聊天軟件的設(shè)計(jì)與實(shí)現(xiàn) 6 但并不保證是可靠，有序，無(wú)重復(fù)的。也就是說(shuō)，一個(gè)從數(shù)據(jù)報(bào)套接字接收信息的進(jìn)程有可能發(fā)現(xiàn)信息重復(fù)了，或者和發(fā)出時(shí)的順序不同。數(shù)據(jù)報(bào)套接字的一個(gè)重要特點(diǎn)是它保留了記錄邊界。對(duì)于這一特點(diǎn)，數(shù)據(jù)報(bào)套接字采用了與現(xiàn)在許多包交換網(wǎng)絡(luò)（例如以太網(wǎng)）非常類似的模型 。 其中 TCP協(xié)議就是基于流套接字，而 UDP 協(xié)議基于數(shù)據(jù)報(bào)套接字， iMessaing 聊天程序主要基于 UDP 協(xié)議，而在特殊操作下又采用 TCP 協(xié)議保證其數(shù)據(jù)的可靠性。 在設(shè)計(jì)階段，需分析該軟件適用于什么樣的地協(xié)議進(jìn)行通訊，還必須分析該系統(tǒng)應(yīng)該適合于何種套接字 IO 操作。目前， windows 提供了多種套接字 IO模型，如阻塞式 IO，非阻塞式 IO，事件 IO，重疊 IO（可提醒 IO），完成端口等，每一種 IO 模型都具有自身的優(yōu)勢(shì)和缺陷，其中完成端口可以達(dá)到目前 windows 平臺(tái)下最高 IO 性能。 由于是基于 UDP 協(xié)議，并且考慮到在同一時(shí)間處理得命令并不會(huì)很大的情況，服務(wù)器和客戶端均采用 基于非阻態(tài)的 IO模型實(shí)現(xiàn)命令的傳輸。 windows 提供了一個(gè) CAysncSocke 異步 套接字類，它是基于 非阻塞 模型，對(duì) Socket 函數(shù)進(jìn)行了良好的 封裝 ， CAsyncSocket::Create()有一個(gè)參數(shù)指明了你想要處理哪些Socket事件，你關(guān)心的事件被指定以后，這個(gè) Socket默認(rèn)就被用作了異步方式。CAsyncSocket 的 Create()函數(shù)，除了創(chuàng)建了一個(gè) SOCKET 以外，還創(chuàng)建了個(gè)CSocketWnd 窗口對(duì)象，并使用 WSAAsyncSelect()將這個(gè) SOCKET 與該窗口對(duì)象關(guān)聯(lián)，以讓該窗口對(duì)象處理來(lái)自 Socket 的事件 (消息 )，然而 CSocketWnd 收到Socket 事件之后，只是簡(jiǎn)單地回調(diào) CAsyncSocket::OnReceive()等虛函數(shù)。所以CAsyncSocket 的派生類，只需要在這些虛函數(shù)里添加發(fā)送和接收的代碼。 因此介于微軟提供的強(qiáng)大類方法，就很容易實(shí)現(xiàn)數(shù)據(jù)的通信。 基于 UDP 的文件傳輸 要實(shí)現(xiàn)文件傳輸?shù)姆绞接泻芏喾N，常用的方式就是像 MSN 那樣基于 TCP 的文件傳輸，這樣的傳輸很穩(wěn)定，可靠，容易實(shí)現(xiàn)，但傳輸?shù)乃俣?和效率會(huì)比較慢。為了提高傳輸速度，我們可以采用 UDP 協(xié)議來(lái)傳輸文件，由于 UDP 協(xié)議傳輸?shù)臄?shù)據(jù)不具有可靠性，在網(wǎng)絡(luò)環(huán)境差的地方很容易出現(xiàn)丟包，亂序等現(xiàn)象，直接采用 基于局域網(wǎng)的聊天軟件的設(shè)計(jì)與實(shí)現(xiàn) 7 UDP 來(lái)傳輸文件是不行的，那么就必須采用某種算法對(duì)其傳輸?shù)目煽啃赃M(jìn)行保證。我們可以模仿 TCP 的通訊機(jī)制來(lái)實(shí)現(xiàn)可靠的 UDP 傳輸。 實(shí)際上， TCP的三次握手的確讓通訊數(shù)據(jù)得到了有序，有效地保證，但是正是因?yàn)檫@樣繁瑣的數(shù)據(jù)驗(yàn)證，導(dǎo)致它傳輸大量數(shù)據(jù) 效率低下，在 TCP 實(shí)現(xiàn)內(nèi)部，實(shí)際上是采用了窗口大小為 1的滑動(dòng)窗口算法進(jìn)行數(shù)據(jù)驗(yàn)證，因此， UDP 可以借于此思想，采用滑動(dòng)窗口算法和 CRC 冗余效驗(yàn)來(lái)保證數(shù)據(jù)的有效性，同時(shí)也會(huì)提高傳輸?shù)乃俣?。由于基?UDP的文件傳輸在網(wǎng)絡(luò)環(huán)境差的情況下可能會(huì)大量丟包，因此不斷重復(fù)發(fā)包會(huì)導(dǎo)致網(wǎng)絡(luò)擁塞（ TCP 在內(nèi)部實(shí)現(xiàn)了流量控制，因此發(fā)生網(wǎng)絡(luò)擁塞可能性很?。?，這是其最大的缺陷。為了保證速度，就會(huì)造成網(wǎng)絡(luò)擁塞，為了網(wǎng)絡(luò)的暢通，就不能保證速度，兩種傳輸方式的各據(jù)優(yōu)劣勢(shì)。 多線程編程 多線程編成是網(wǎng)絡(luò)編成的基礎(chǔ)，幾乎所有的網(wǎng)絡(luò)編 程都將涉及到多個(gè)線程的數(shù)據(jù)傳輸 ，并且還要實(shí)現(xiàn)界面和數(shù)據(jù)處理互不影響 。多線程編成雖說(shuō)是基礎(chǔ)，但是卻是一個(gè)難點(diǎn)，因?yàn)榫€程同步的確比我們想象的復(fù)雜得多。要理解多線程編成就必須從以下幾個(gè)方面理解：一、操作系統(tǒng)多任務(wù)概念；二、 線程和進(jìn)程的聯(lián)系與區(qū)別；三、 如何創(chuàng)建并管理 銷毀 一個(gè) 線程 ；四、何謂線程同步，怎樣同步。 什么是多任務(wù)概念？用通俗易懂的話就是幾個(gè)運(yùn)行的任務(wù)“同時(shí)”進(jìn)行，比如 Windows 就是典型的多任務(wù)操作系統(tǒng)，我們可以同時(shí)進(jìn)行聽(tīng)歌，打游戲，聊，在基于這種理念的系統(tǒng)感覺(jué)就像所有的程序 在 同時(shí)運(yùn)行 一樣。但實(shí)際上在單CPU 的機(jī)子上，這些程序并不是同時(shí)在運(yùn)行（即便是在多 CPU 的電腦上，也不可能所有程序同時(shí)運(yùn)行），所有的程序都以某種調(diào)度算法，按照優(yōu)先級(jí)，依次獲取CPU 時(shí)間，每當(dāng)一個(gè)程序獲得 CPU 時(shí)間后，它就會(huì)得到運(yùn)行，而當(dāng)運(yùn)行一段時(shí)間后，操作系統(tǒng)會(huì)將其暫停，再接換新的線程來(lái)運(yùn)行。由于電腦的速度很快，這種非并發(fā)的模式卻可以達(dá)到類似并發(fā)的效果。實(shí)際上，正如前面所說(shuō)，操作系統(tǒng)并非是給某一程序分配時(shí)間片，準(zhǔn)確的說(shuō)是給這個(gè)程序里的某一 線 程分配了時(shí)間片。因此，在多任務(wù)操作系統(tǒng)中（若有線程的話），線程將是運(yùn)行的最小單位 。 在 windows 系統(tǒng)中，進(jìn)程和線程是最為重要的兩個(gè)概念，因?yàn)檎麄€(gè)系統(tǒng)就是基于進(jìn)程和線程的。那么進(jìn)程和線程有什么區(qū)別和聯(lián)系呢？進(jìn)程實(shí)際就是一個(gè)運(yùn) 基于局域網(wǎng)的聊天軟件的設(shè)計(jì)與實(shí)現(xiàn) 8 行的程序，該程序有自己的堆棧空間，有自己的線程（至少有一個(gè)主線程），并且可以創(chuàng)建其它進(jìn)程或線程。有一個(gè)概念容易搞錯(cuò)，就是進(jìn)程是否能獲得 CPU時(shí)間片？實(shí)際上，進(jìn)程是無(wú)法獲取 CPU 時(shí)間片，只有該進(jìn)程里的線程才能，所以說(shuō)，真正執(zhí)行代碼的是線程，而進(jìn)程只能管理線程，管理內(nèi)存等。 在 iMessaging 程序里，涉及了諸多對(duì)線程的創(chuàng)建， 管理和 銷毀 工作 ，特別是在服務(wù)器部分，為了 保證數(shù)據(jù)響應(yīng)的即時(shí)性 ，必須對(duì)每一個(gè)處理創(chuàng)建一個(gè)線程。常用的創(chuàng)建線程函數(shù)為 CreateThread 和 _beginthreadex,兩函數(shù)功能幾乎一樣（在某些特殊地方， 兩者用法需注意，推薦用后者 ），在創(chuàng)建前必須定義一個(gè)按照線程函數(shù)原型的函數(shù)， 將其地址傳給創(chuàng)建線程函數(shù)，讓操作系統(tǒng)知道即將從哪個(gè)地方運(yùn)行線程。除此之外，還可以傳遞參數(shù)，供線程使用。若創(chuàng)建成功，該函數(shù)會(huì)返回一個(gè) HANDLE，這個(gè)句柄標(biāo)示了剛創(chuàng)建的線程內(nèi)核對(duì)象，當(dāng)線程創(chuàng)建成功后，必須調(diào)用 CloseHandle 函數(shù)將其關(guān)閉，這是因?yàn)槿绻魂P(guān)閉該內(nèi)核句柄，當(dāng) 線程退出后，操作系統(tǒng)并沒(méi)有銷毀該線程，造成資源浪費(fèi)，這是因?yàn)楂@取一個(gè)實(shí)內(nèi)核句柄都會(huì)增加內(nèi)核使用計(jì)數(shù)，只有當(dāng)該內(nèi)核對(duì)象的使用計(jì)數(shù)為 0時(shí)，才會(huì)銷毀該內(nèi)核對(duì)象，線程也是如此。常用的銷毀線程函數(shù)是 ExitThread，TermelateThread 函數(shù)，但推薦使用函數(shù)返回的方式結(jié)束進(jìn)程，因?yàn)椴僮飨到y(tǒng)會(huì)自動(dòng)調(diào)用 ExitThread 函數(shù)，并回收分配的內(nèi)存資源。 由于多個(gè)線程在同時(shí)運(yùn)行的時(shí)候，會(huì)對(duì)共享數(shù)據(jù)進(jìn)行訪問(wèn)或修改，那么就必須要注意 數(shù)據(jù)同步， windows 給