在編程語言中，函數是一個很重要的概念，其身影無處不在。在面向過程的編程方式中，函數更是程序的基本構建模塊，在面向對象的編程方式中，函數演變為類或對象的成員（當然也可以使用與類無關的函數）。

函數由函數頭和函數體組成。函數頭包括域屬性（如external、static或類域）、返回值類型、函數名、及參數。域屬性包括其在多文件編程中的可見范圍，是否是屬于某一個類的成員？返回值類型是指函數返回的值的具體數據類型（可以理解為函數輸出的一部分）。函數名是函數保存在內存代碼區的首地址，用于函數的調用及函數指針的右值。參數可以理解為函數的輸入、輸出（如果是引用或指針作為參數，可以理解為是一個種輸出，因為其操作或更新的數據是引用或指針的地址值所指向的內存單元）。在CC++中，函數***于{}中，函數體是函數功能的具體實現。

如果用一臺手機來理解函數概念，手機***在外的操作界面就像是函數頭，外殼內的組件就像是函數體中，外殼就像是{}。

函數的開發者和使用者可以站在不同的角度去理解函數的構造，函數的開發者需要負責函數頭作為界面（interface）的友好性及穩定性，以及保證實現（implement）函數功能的函數體的空間和時間效率。而函數的使用者可以不關心函數功能的具體實現（當然了解其具體實現能更好地加深對函數的理解），也就是不心關心函數體的具體內容，只需關心函數使用的具體細節，也就是函數體的內容。

就如同一臺手機，手機開發者要負責手機從外部操作到內部零部件的全部，而手機購買者（使用者）則只需關心怎樣使用即可。

一個數據集D，以及操作這個數據集D的代碼集C如何更好地形成一個整體，在函數的概念中有一定的體現，也就是通過參數和局部變量形成數據集D，以及在函數體中包含一個函數指針，由其指向的函數代表代碼集C。但這種封裝性還是體現得不夠充分。如果把數據集D，以及操作這個數據集D的代碼集C全部歸屬（或限定）到某一個類別，并設定訪問控制（accessmodifier）的概念，這種封裝性就能得到最充分的體現，這種思想就是面向對象的類類型概念。訪問控制就像一個手機外殼，用public修飾的類（對象）的屬性（數據集D）或***（代碼集C）就是一個類（對象）提供的界面（interface），是公共的，公開的，***在外的，使用者密切關注的；而private修飾的類（對象）的屬性（數據集D）或***（代碼集C）就是一個類（對象）提供的具體實現，是私密的，隱藏在內的，使用者可以不加以密切注意的。

于是，一些編程大牛對于一些使用頻率很高的功能便開發出界面友好穩定、實現效率高的函數和類，保存在庫（library)中，也就是函數庫或類庫，實現共享。一些優秀函數庫或類庫也就成了編程語言的有機組成部分。

一種計算機語言的應用程序是運行在某一操作系統之上的，某一操作系統對某一語言的支持是通過其某一語言的函數庫或類庫來實現的。

控制臺程序程序只關心數據，不在乎界面，在一個簡單的Shell中執行。

控制臺程序用字符進行交互，不需要鼠標操作，也就是沒有圖形界面，也就是不需要使用控件做為輸入、輸出的媒介。

而windowapi與MFC主要使用控件（視窗）做為交互媒介，也就有了資源對象（不是類類型對象）的概念，同時也有了事件消息和消息響應函數的概念（MessageBased，EventDriven）。

當Windows操作系統開始占據主導地位的時候，開發Windows平臺下的應用程序成為人們的需要。而在Windows程序設計領域處于發展的初期，Windows程序員所能使用的編程工具唯有API（ApplicationProgrammingInterface）函數，這些函數是Windows提供給應用程序與操作系統的接口，他們猶如“積木塊”一樣，可以搭建出各種界面豐富，功能靈活的應用程序。所以可以認為API函數是構筑整個Windows框架的基石，在它的下面是Windows的操作系統核心，而它的上面則是所有的華麗的Windows應用程序。

WindowsAPI所提供的功能可以歸為七類：

2.1基礎服務（BaseServices），提供對Windows系統可用的基礎資源的訪問接口。比如像：文件系統（filesystem）、外部設備（device）、進程（process）、線程（thread）以及訪問注冊表（Windowsregistry）和錯誤處理機制（errorhandling）。這些功能接口位于Windows下的kernel32.dll和advapi32.dll中。

2.2圖形設備接口（GDI），提供功能為：輸出圖形內容到顯示器、打印機以及其他外部輸出設備。位于Windows下的gdi32.dll。

2.3圖形化用戶界面（GUI），提供的功能有創建和管理屏幕和大多數基本控件（control），比如按鈕和滾動條，接收鼠標和鍵盤輸入，以及其他與GUI有關的功能。這些調用接口位于Windows下的user32.dll。從WindowsXP版本之后，基本控件和通用對話框控件（CommonControlLibrary）的調用接口放在comctl32.dll中。

2.4通用對話框鏈接庫（CommonDialogBoxLibrary），為應用程序提供標準對話框，比如打開/保存文檔對話框、顏色對話框和字體對話框等等。這個鏈接庫位于Windows下comdlg32.dll中。它被歸類為UserInterfaceAPI之下。

2.5通用控件鏈接庫（CommonControlLibrary），為應用程序提供接口來訪問操作系統提供的一些高級控件。比如狀態欄（statusbar）、進度條（progressbars）、工具欄（toolbar）和標簽（tab）等。這個鏈接庫位于Windows下comctl32.dll中。它被歸類為UserInterfaceAPI之下。

2.6Windows外殼（WindowsShell），作為WindowsAPI的組成部分，不僅允許應用程序訪問Windows外殼提供的功能，還對之有所改進和增強。它位于Windows下的shell32.dll中（Windows95則在shlwapi.dll中）。它被歸類為UserInterfaceAPI之下。

2.7網絡服務（NetworkServices），為訪問操作系統提供的多種網絡功能提供接口。它包括NetBIOS、Winsock、NetDDE及RPC等。

程序員想編寫具有Windows風格的軟件，必須借助API，API也因此被賦予至高無上的地位。但是，如若沒有合適的Windows編程平臺，那么Windows開發是一項很復雜的工作。在可視化編程IDE出來之前，那時的Windows程序開發還是比較復雜的工作，程序員必須熟記一大堆常用的API函數，而且還得對Windows操作系統有深入的了解。然而隨著軟件技術的不斷發展，在Windows平臺上出現了很多優秀的可視化編程環境，程序員可以采用“所見即所得”的編程方式來開發具有精美用戶界面和功能強大的應用程序。

這些優秀可視化編程環境操作簡單、界面友好（諸如VB、VC++、DELPHI等），在這些工具中提供了大量的類庫和各種控件，它們替代了API的神秘功能，事實上這些類庫和控件都是構架在WIN32API函數基礎之上的，是封裝了的API函數的***。它們把常用的API函數的組合在一起成為一個控件或類庫，并賦予其方便的使用***，所以極大的加速了Windows應用程序開發的過程。有了這些控件和類庫，程序員便可以把主要精力放在程序整體功能的設計上，而不必過于關注技術細節。

實際上如果我們要開發出更靈活、更實用、更具效率的應用程序，必然要涉及到直接使用API函數，雖然類庫和控件使應用程序的開發簡單的多，但它們只提供Windows的一般功能，對于比較復雜和特殊的功能來說，使用類庫和控件是非常難以實現的，這時就需要采用API函數來實現。

這也是API函數使用的場合，所以我們對待API函數不必刻意去研究每一個函數的用法，那也是不現實的（能用得到的API函數有幾千個呢）。正如某位大蝦所說：API不要去學，在需要的時候去查API幫助就足夠了。但是，許多API函數令人難以理解，易于誤用，還會導致出錯，這一切都阻礙了它的推廣。

數以千計的WindowsAPIs，每個看起來都好象比重相若（至少你從手冊上看不出來孰輕孰重）。有些APIs彼此雖有群組關系，卻沒有相近或組織化的函數名稱。星羅棋布，霧列星馳；又似雪球一般愈滾愈多，愈滾愈大。撰寫Windows應用程序需要大量的耐力與毅力，以及大量的小心謹慎！

MFC幫助我們把這些浩繁的APIs，利用對象導向的原理，邏輯地組織起來，使它們具備抽象化、封裝化、繼承性、多態性、模塊化的性質。

1989年微軟公司成立ApplicationFramework技術團隊，名為AFX小組，用以開發C++對象導向工具給Windows應用程序開發人員使用。AFX的"X"其實沒有什么意義，只是為了湊成一個響亮好念的名字。

這個小組最初的「***」，根據記載，是要"utilizethelatestinobjectorientedtechnologytoprovidetoolsandlibrariesfordeveloperswritingthemostadvancedGUIapplicationsonthemarket"，其中并未畫地自限與Windows操作系統有關。果然，其第一個原型產品，有自己的窗口系統、自己的繪圖系統、自己的對象數據庫、乃至于自己的內存管理系統。當小組成員以此產品開發應用程序，他們發現實在是太復雜，又悖離公司的主流系統--Windows--太遙遠。于是他們修改***變成"deliverthepowerofobject-orientedsolutionstoprogrammerstoenablethemtobuildworld-classWindowsbasedapplicationsinC++."這差不多正是Windows3.0異軍崛起的時候。

C++是一個復雜的語言，AFX小組預期MFC的使用者不可能人人皆為C++專家，所以他們并沒有采用所有的C++高階性質（例如多重繼承）。許多「麻煩」但「幾乎一成不變」的Windows程序動作都被隱藏在MFC類別之中，例如WinMain、RegisterClass、WindowProcedure等等等。

為了讓MFC盡可能地小，盡可能地快，AFX小組不得不舍棄高度的抽象（導至過多的虛擬函數），而引進他們自己發明的機制，嘗試在對象導向領域中解決Windows消息的處理問題。這也就是MessageMapping和Messagerouting機制。注意，他們并沒有改變C++語言本身，也沒有擴大語言的功能。他們只是設計了一些令人拍案叫絕的宏，而這些宏背后隱藏著巨大的機制。

微軟公司于1992/04推出C/C++7.0產品時初次向世人介紹了MFC1.0，這個初試啼聲的產品包含了20,000行C++源代碼，60個以上的Windows相關類別，以及其它的一般類別如時間、數據處理、文件、內存、診斷、字符串等等等。它所提供的，其實是一個"thinandefficientC++transformationoftheWindowsAPI"。其32位版亦在1992/07隨著Win32SDK推出。

MFC實現了控件的可視化，其applicationWizard和classwizard可以實現程序和代碼模塊框架的自動化實現。

開發需要讀寫文件的應用程序并且有簡單的輸入和輸出可以利用單文檔視結構。

開發注重交互的簡單應用程序可以使用對話框為基礎的窗口，如果文件讀寫簡單這可利用CFile進行。

在要求在多個文檔間傳遞數據時使用多文檔視結構。

資源在WindowsAPI中使用一種特殊的結構體指針，句柄來引用。

WindowsAPI開發之初C++還沒有出現，所以windows提供的API函數使用的封裝數據類型是結構體（不是類）。隨著C++的誕生與普及，WindowsAPI+C++就誕生了MFC，且資源控件開發實現了可視化，而封裝數據類型也用類類型來實現。

常用的資源：ICON、CURSOR、BITMAP、FONT、DIALOG、MENU、ACCELERATOR、STRING、VERSIONINFO、TOOLBAR。

WindowsAPI是編程者自己把消息和響應函數聯系在一起。mfc是編程者采用微軟為我們做好了MESSAGE-MAP機制，來處理消息。

WindowsAPI和MFC都使用.lib文件。

.lib分兩種,一種是.lib文件里面包含了cpp編譯出來的代碼,鏈接的時候把需要的代碼拷貝到exe里面，mfc,、crt在選擇靜態的時候使用這種方式。

另外一種是.lib中不包含代碼,只是描述該到哪個dll里面怎么找對應的代碼.這種編譯出來的exe就需要dll一起才能運行。mfc、crt使用共享庫的時候,以及WindowsAPI就是使用的這種方式。

API的dll在windows系統的system32目錄下,圖形界面相關的API在USER32.dll里，進程、文件之類的操作在kernel32.dll里。MSDN的每個函數都會說明它在哪個頭文件,哪個lib,哪個dll里的。

C++并不是純種的對象導向語言（SmallTalk和Java才是）。所以，MFC之中得以存在有不屬于任何類別的全域函數，它們統統在函數名稱開頭冠以Afx。

SDK程序只要包含WINDOWS.H就好，所有API的函數聲明、消息定義、常數定義、宏定義、都在WINDOWS.H檔中。除非程序另調用了操作系統提供的新模塊（如CommDlg、ToolHelp、DDEML...），才需要再各別包含對應的.H檔。

關于類的繼承性在MFC的控件類中有最充分的體現，在MFC中，各種控件類的框架都已搭建好，其中包含了最通用的屬性和***以及一些虛函數，開發者可以重寫虛函數或派生控件類來實現自己的功能或個性化的需求。

－End－