【文章內(nèi)容簡介】 就是第三方 )的編程語言來進(jìn)行對(duì)Windows 下應(yīng)用程序的開發(fā) ,使這些被開發(fā)出來的應(yīng)用程序能在Windows 下運(yùn)行 ,比如 VB,VC++,JAVA,Delhpi 編程語言 函數(shù) 本質(zhì)上全部源于 API,因此用它們開發(fā)出來的應(yīng)用程序都能工作在Windows 的 消息機(jī) 制 和繪圖里 ,遵守 Windows 作為一個(gè) 操作系統(tǒng) 的內(nèi)部實(shí)現(xiàn) ,這其實(shí)也是一種必要 ,微 軟如果不提供 API,這個(gè)世上對(duì)Windows 編程的工作就不會(huì)存在 ,微軟的產(chǎn)品就會(huì)迅速從時(shí)尚變成垃圾 ,上面說到 MFC 是微軟對(duì) API 函數(shù)的專用 C++封裝 ,這種結(jié)合一方面讓用戶使用微軟的專業(yè) C++ SDK 來進(jìn)行 Windows 下應(yīng)用程序的開發(fā)變得容易 ,因?yàn)?MFC 是對(duì) API 的封裝 ,微軟做了大量的工作 ,隱藏了好多程序開發(fā)人員在 Windows 下用 C++ amp。 MFC 編制軟件時(shí)的大量內(nèi)節(jié) ,如應(yīng)用程序?qū)崿F(xiàn)消息的處理 ,設(shè)備環(huán)境繪圖 ,這種結(jié)合是以方便為目的的 ,必定要付出一定代價(jià) (這是微軟的一向作網(wǎng)絡(luò)遠(yuǎn)程通信與控制程序設(shè)計(jì) 6 風(fēng) ),因此就造成了 MFC 對(duì)類封裝中的 一定程度的的冗余和迂回 ,但這是可以接受的 。 MFC不只是一個(gè)功能單純的 界面 開發(fā)系統(tǒng) ,它提供的類絕大部分用來進(jìn)行界面開發(fā) ,關(guān)聯(lián)一個(gè)窗口的動(dòng)作 ,但它提供的類中有好多類不與一個(gè)窗口關(guān)聯(lián) ,即類的作用不是一個(gè)界面類 ,不實(shí)現(xiàn)對(duì)一個(gè)窗口對(duì)象的控制 (如創(chuàng)建 ,銷毀 ),而是一些在 Windows(用 MFC編寫的程序絕大部分都在 Windows 中運(yùn)行 )中實(shí)現(xiàn)內(nèi)部處理的類 ,如 數(shù)據(jù)庫 的管理類等 ,學(xué)習(xí)中最應(yīng)花費(fèi)時(shí)間的是消息和設(shè)備環(huán)境 ,對(duì) C++和 MFC 的學(xué)習(xí)中最難的部分是指針 ,C++面向?qū)ο蟪绦蛟O(shè)計(jì)的其它部分 ,如數(shù)據(jù)類型 ,流程控制 都不難 ,建 議學(xué)習(xí) 數(shù)據(jù)結(jié)構(gòu) C++版。 MFC 是微軟封裝了的 API。 windows 作為一個(gè)提供功能強(qiáng)大的應(yīng)用程序接口 編程的操作系統(tǒng)，的確方便了許多 程序員 ，傳統(tǒng)的win32 開發(fā)（直接使用 windows 的 接口函數(shù) API）對(duì)于程序員來說非常的困難，因?yàn)椋?API 函數(shù)實(shí)在太多了，而且名稱很亂，從零構(gòu)架一個(gè)窗口動(dòng)輒就是上百行的代碼。 MFC 是面向?qū)ο蟪绦蛟O(shè)計(jì)與Application framework 的完美結(jié)合，他將傳統(tǒng)的 API 進(jìn)行了分類封裝，并且為 使用者 創(chuàng)建 程序的一般框架 。 應(yīng)用程序框架的一種定義是 提供一般應(yīng)用程序需要的全部面向?qū)ο筌浖M件的集成集合。 C++流行的一個(gè)原因是它可以用類庫擴(kuò)充。類庫是可在應(yīng)用程序中使用的有關(guān) C++類的集合。應(yīng)用程序框架是類庫的超集。一般的類庫只是一種孤立的類的集合，用來嵌入在任何程序中，但是，應(yīng)用程序框架卻定義了程序的結(jié)構(gòu)。自從 MFC 庫發(fā)布以來， MFC 已經(jīng)成為主要的Windows 類庫。使用 MFC 類庫構(gòu)建應(yīng)用程序具有以下優(yōu)點(diǎn) 。 ? MFC 庫是 C++的 Microsoft Windows API。 ? 應(yīng)用程序框架生成的應(yīng)用程序使用了標(biāo)準(zhǔn)的結(jié)構(gòu)，具有標(biāo)準(zhǔn)化的用戶接口，這對(duì)具有標(biāo)準(zhǔn)用戶界面的 Win32 程序來說，可以極大的減輕程序員的負(fù)擔(dān)，使程序員不必過多地考慮界面，可把主要精力放在程序設(shè)計(jì)上，以提高程序設(shè)計(jì)的效率。 ? 使用應(yīng)用程序框架的應(yīng)用程序不僅小，而且運(yùn)行速度快，具有很大的靈活性。 MFC 封裝了 Win32 SDK 中的幾乎所有函數(shù)，網(wǎng)絡(luò)遠(yuǎn)程通信與控制程序設(shè)計(jì) 7 能實(shí)現(xiàn) Win32 系統(tǒng)的任何功能。 ? MFC 框架降低了編碼的復(fù)雜性。 ? MFC 庫應(yīng)用程序框架有豐富的特性，如： Windows API 的 C++接口、通用的（非 Windows 所特有的）類、 “共用根對(duì)象 ”類層次結(jié)構(gòu)、流線式多文檔界面（ MDI）應(yīng)用程序支持等。 ? 強(qiáng)大的功能。除封裝了大部分的 Win32 SDK 函數(shù)外， MFC 還提供了應(yīng)用程序本身的數(shù)據(jù)和操作及 ActiveX、 OLE、 Inter、WinSock、 DAO（ Data Access Objects）、 ODBC（ Open DataBase Connectivity）等操作類。 MFC 框架的核心是文檔 /視圖結(jié)構(gòu)（ DocumentView Architecture），這是一個(gè)很好用、但又往往較難以入門的功能。簡單的說，文檔 /視圖結(jié)構(gòu)就是將數(shù)據(jù)和對(duì)數(shù)據(jù)的觀察或數(shù)據(jù)的表現(xiàn)（顯示）相分離。文檔僅處理數(shù)據(jù)的實(shí)際讀、寫操作，視圖則是顯示和處理數(shù)據(jù)的窗口，視圖可以 操作文檔中的數(shù)據(jù) 。 MFC 的消息映射 在使用 Visual C++進(jìn)行 Win32 程序設(shè)計(jì)時(shí)，消息映射是一個(gè)非常重要的概念。 Windows 應(yīng)用程序是消息驅(qū)動(dòng)的，應(yīng)用程序不能直接得到用戶所做的操作，如鼠標(biāo)按鍵、鍵盤輸入和窗口移動(dòng)等。這些操作由操作系統(tǒng)管理，操作系統(tǒng)檢測(cè)到操作事件后，便向相關(guān)的應(yīng)用程序發(fā)送消息，應(yīng)用程序響應(yīng)這些消息來完成用戶的操作。 消息 Windows 中的消息是操作系統(tǒng)與應(yīng)用程序之間、應(yīng)用程序與應(yīng)用程序之間、應(yīng)用程序各對(duì)象之間相互控制與傳遞信息的方式。消息的基本格式如下： Message wParam lParam Message是消息名稱； wParam是與消息相關(guān)的 Word 型參數(shù)； lParam是與消息相關(guān)的 Long 型參數(shù)。消息主要有以下 3 類。 Windows 系統(tǒng)消息： Windows 系統(tǒng)向窗口發(fā)送的消息，由窗口（ Window） 或視圖（ View）進(jìn)行響應(yīng)處理。這類消息包括除WM_COMMAND 消息之外的名稱以 WM_開始的其他消息。 網(wǎng)絡(luò)遠(yuǎn)程通信與控制程序設(shè)計(jì) 8 控制通知消息：控制或子窗口傳給父窗口的 WM_COMMAND 通知的消息。 命令消息：在響應(yīng)用戶接口操作時(shí)，將產(chǎn)生 WM_COMMAND 命令消息。其參數(shù)指定 了用戶接口的標(biāo)識(shí)號(hào)，如菜單項(xiàng)和按鈕等 ID 號(hào)。 消息映射過程 在使用 AppWizard 創(chuàng)建應(yīng)用程序時(shí)， MFC 應(yīng)用程序框架設(shè)置了相應(yīng)的消息處理函數(shù)來響應(yīng)消息，以完成相應(yīng)的操作。消息處理函數(shù)是某些類（通常是窗口類）的成員函數(shù)和程序員在其中編寫響應(yīng)消息時(shí)應(yīng)進(jìn)行操作的代碼。 框架將消息和它們的處理函數(shù)連接起來就是消息映射。消息映射使應(yīng)用程序在接收到消息時(shí)調(diào)用對(duì)應(yīng)的消息處理函數(shù)來響應(yīng)和處理消息。 ClassWizard 在創(chuàng)建新類時(shí)將為其創(chuàng)建一個(gè)消息映射，并為每個(gè)類能響應(yīng)的消息和命令增加對(duì)應(yīng)的處理函數(shù)。在源代碼中 ，消息映射開始于 BEGIN_MESSAGE_MAP 宏，結(jié)束于 END_MESSAGE_MAP 宏，中間由一系列預(yù)定義的被稱為 “ 條目宏 ” 的宏組成。其基本格式如下： BEGIN_MESSAGE_MAP (classname, parentclassname) //{{AFX_MSG_MAP (classname) 條目宏 1 條目宏 2 條目宏 3 ………… //}}AFX_MSG_MAP END_MESSAGE_MAP () 其中 classname 為擁有消息映射的當(dāng)前類名， parentclassname 為當(dāng)前類的 父類名。條目宏定義了類所處理的消息與其對(duì)應(yīng)的函數(shù)。常用的條目宏類型如表 所示。 Windows 消息的處理函數(shù)在 CWnd 類中進(jìn)行了預(yù)定義，類庫以消息名為基礎(chǔ)定義這些處理函數(shù)的名稱，且 MFC 要求所有消息處理函數(shù)聲明為 afx_msg 類型。例如，消息 WM_PAINT 的處理函數(shù)在 CWnd 類中的聲明如下： afx_msg void OnPaint()。 網(wǎng)絡(luò)遠(yuǎn)程通信與控制程序設(shè)計(jì) 9 表 消息映射條目宏 消息類型 宏格式 說明 Windows消息 ON_WM_XXXX WM_XXXX 為Windows 消息名 命令 ON_COMMAND(ID,Function) ID 為命令標(biāo)識(shí)號(hào)， Function 為處理函數(shù)名 更新命令 ON_UPDATE_COMMAND_UI(ID,Function) ID 為命令標(biāo)識(shí)號(hào)， Function 為處理函數(shù)名 控制通知 ON_XXXX(ID,Function) ID 為控制標(biāo)識(shí)號(hào)， Function 為處理函數(shù)名 用戶定義消息 ON_MESSAGE(ID,Function) ID 為消息標(biāo)識(shí)號(hào)， Function 為處理函數(shù)名 用戶注冊(cè)消息 ON_REGISTERED_MESSAGE(ID,Function) ID 為消 息標(biāo)識(shí)號(hào)， Function 為處理函數(shù)名 通過 ClassWizard 在派生類中用同樣的原型定義處理函數(shù)并為該函數(shù)生成消息映射條目，然后由程序員編寫處理函數(shù)代碼，并在派生類中覆蓋了其父類的消息處理函數(shù)。在有些情況下，必須在派生類的消息處理函數(shù)中調(diào)用其父類的消息處理函數(shù)，使 Windows 和基類能對(duì)消息進(jìn)行處理。 ClassWizard 將在生成的處理函數(shù)中建議是否應(yīng)調(diào)用父類的消息處理函數(shù)及調(diào)用的次序。除此之外，用戶定義和注冊(cè)的消息、命令和控制通知都沒有默認(rèn)的處理函數(shù)，需要在定義時(shí)聲明，一般根據(jù)其 ID名稱來為函數(shù)命 名。 網(wǎng)絡(luò)遠(yuǎn)程通信與控制程序設(shè)計(jì) 10 系統(tǒng)架構(gòu)的模式 C/S 結(jié)構(gòu)，即 Client/Server(客戶機(jī) /服務(wù)器 )結(jié)構(gòu)， 軟件系統(tǒng)體系結(jié)構(gòu)，通過將任 務(wù) 合理分配到 Client 端和 Server 端，降低了系統(tǒng)的通訊開銷，可以充分利用兩端硬件環(huán)境的優(yōu)勢(shì)。 C/S 結(jié)構(gòu)模式 Client/Server 結(jié)構(gòu)，它的發(fā)展經(jīng)歷了兩個(gè)階段：從兩層結(jié)構(gòu)到三層結(jié)構(gòu)。 兩層結(jié)構(gòu)， 它由兩部分構(gòu)成 ， 前端是客戶機(jī)，通常是 PC，主要完成用戶界面顯示，接受數(shù)據(jù)輸入，校驗(yàn)數(shù)據(jù)有效性，向后臺(tái)數(shù)據(jù)庫發(fā)請(qǐng)求，接受返回結(jié)果，處理應(yīng)用邏輯；后端是服務(wù)器，運(yùn)行 DBMS，提供數(shù)據(jù)庫的查詢和管理。應(yīng)用邏輯主要在前端，如在后端則是存儲(chǔ)過程的形式。 三層結(jié)構(gòu) 則 利用中間件將應(yīng)用分為表示層、業(yè)務(wù)邏輯層和數(shù)據(jù)存儲(chǔ)層三個(gè)不同的處理層次。三個(gè)層次的劃分是從邏輯上來分的，具體的物理分法可以有多種組合。基于三層結(jié)構(gòu)的應(yīng)用系統(tǒng)不但具備了大型機(jī)系統(tǒng)穩(wěn)定、安全和處理能力高等特性，同時(shí)擁有開放系統(tǒng)成本低、可擴(kuò)展性強(qiáng)、開發(fā)周期短等優(yōu)點(diǎn)。而中間件作為構(gòu)造三層結(jié)構(gòu)應(yīng)用系統(tǒng)的基礎(chǔ)平臺(tái)，提供了以下主要功能：負(fù)責(zé)客戶機(jī)與服務(wù)器間、服務(wù)器間與服務(wù)器間的聯(lián)接和通訊；實(shí)現(xiàn)應(yīng)用與數(shù)據(jù)庫的高效連接；提供一個(gè)三層結(jié)構(gòu)應(yīng)用的開發(fā)、 運(yùn)行、部署和管理的平臺(tái)。 TCP C/S 通信原理 TCP Client/Server 的通信原理如圖 所示，服務(wù)器端首先監(jiān)聽一個(gè)固定端口，客戶端再連接到服務(wù)端，此時(shí)服務(wù)端執(zhí)行 Accept 操作，以接受客戶端的連接。此時(shí)連接創(chuàng)建成功，則進(jìn)行數(shù)據(jù)傳輸，待數(shù)據(jù)傳輸完畢，服務(wù)端和客戶端就斷開連接。 網(wǎng)絡(luò)遠(yuǎn)程通信與控制程序設(shè)計(jì) 11 圖 Client/Server 的 通信流程 C/S 結(jié)構(gòu)的優(yōu)點(diǎn) Client/Server 技術(shù)在目前程序開發(fā)中得到了廣泛的應(yīng)用，這種技術(shù)的優(yōu)點(diǎn)在于它將處理工作按照一定的比例分配到客戶端和服務(wù)器上去執(zhí)行，這樣減少了網(wǎng)絡(luò)傳輸?shù)墓ぷ髁?，從而合理地利用了資源，提高了應(yīng)用程序開發(fā)的效率。由于客戶端實(shí)現(xiàn)與服務(wù)器的直接相連，沒有中間環(huán)節(jié)，因此響應(yīng)速度快。 API HOOK技術(shù)簡介 Hook 是 Windows 中提供的一種用以替換 DOS 下 “ 中斷 ” 的系統(tǒng)機(jī)制，中文譯為 “ 掛鉤 ” 或 “ 鉤子 ” 。在對(duì)特定的系統(tǒng)事件進(jìn)行 hook 后，一旦發(fā)生已 hook 事件，對(duì)該事件進(jìn)行 hook 的程序就監(jiān)聽 Listen() Server 端 Client 端 創(chuàng)建 Socket() 接受 Accept() 數(shù)據(jù)傳輸Send() Receive() 斷開 Close() 連接 Connect() 創(chuàng)建 Socket() 數(shù)據(jù)傳輸Send() Receive() 斷開 Close() 網(wǎng)絡(luò)遠(yuǎn)程通信與控制程序設(shè)計(jì) 12 會(huì)受到系統(tǒng)的通知，這時(shí)程序就能在第一時(shí)間對(duì)該事件做出響應(yīng)。鉤子實(shí)際上是一個(gè)處理消息的 程序段，通過系統(tǒng)調(diào)用，把它掛入系統(tǒng)。每當(dāng)特定的消息發(fā)出，在沒有到達(dá)目的窗口前，鉤子程序就先捕獲該消息，亦即鉤子函數(shù)先得到控制權(quán)。這時(shí)鉤子函數(shù)即可以加工處理（改變）該消息，也可以不作處理而繼續(xù)傳遞該消息，還可以強(qiáng)制結(jié)束消息的傳遞。 API HOOK 技術(shù)是一種用于改變 API 執(zhí)行結(jié)果的技術(shù)， Microsoft 自身也在 Windows 操作系統(tǒng)里面使用了這個(gè)技術(shù)，如 Windows 兼容模式等。 API HOOK 技術(shù)并不是計(jì)算機(jī)病毒專有技術(shù)，但是計(jì)算機(jī)病毒經(jīng)常使用這個(gè)技術(shù)來達(dá)到隱藏自己的目的 。 在 windows 系統(tǒng)下編 程，應(yīng)該會(huì)接觸到 api 函數(shù)的使用，常用的 API 函數(shù)大概有 20xx 個(gè)左右。今天隨著控件， stl 等高效編程技術(shù)的出現(xiàn)， api 的使用概率在普通的用戶程序上就變得越來越小了。當(dāng)諸如控件這些現(xiàn)成的手段不能實(shí)現(xiàn)的功能時(shí)，我們還需要借助API。最初有些人對(duì)某些 api 函數(shù)的功能不太滿意，就產(chǎn)生了如何修改這些 api，使之更好的服務(wù)于程序的想