本文轉自CSDN albb252，在此表示感謝！
1.1.5自從2005年3月8日下午16時“十年MFC經歷認識的Microsoft技術”以帖子的方式發表於CSDN論壇後，引起了許多網友得好評，使得筆者誠惶誠恐，考慮到該貼過長(人氣指數爲5000)，因此轉移到Blog上，許多網友對此帖的評語只好省略，在此鄙人謝過了！爲感謝網友的支持，本人希望今後能發出新的帖子以回報網友對我的鼓勵，再一次謝謝！
初識MFC
我最初知道MFC大概是在1993年，那個時候Visual C++還沒面世，當時Microsoft的C++編譯器還很弱，官方的名字是Microsoft C/C++ 7.0，MFC的版本是1.0，幾乎沒有引起什麼反響，那個時期最好的C++開發環境是Borland C++ 3.1，其實，大概是1992年11月份，一個偶然的機會，我領略到Borland公司的厲害，記不得在什麼地方，我看到一個絕妙的集成開發環境，即Turbo C++ 3.0 for Windows，這是我記憶中第一個真正的Windows環境下的C++集成開發環境，那種激動的感覺至今仍記憶猶新，不客氣的說，當時至少在C++方面，Microsoft與Borland不是一個水平的，Borland明顯的要高於Microsoft ，Borland的產品在技術上給我留下深刻的印象。那個時候Microsoft最好的開發平臺是Visual Basic 3.0，而Borland的Delphi正處於開發階段（Delphi 的代碼名稱是：“VB Killer”）……，想起這些十幾年前的往事，我不禁感慨萬千。
十幾年來，我用過許多開發環境，關於Visual Basic，我用過最早的DOS版本，Windows版的Visual Basic我基本上全都用過，至今我還記得每個版本的VB安裝盤磁盤的盤數。同樣，我用過各個版本的Delphi，特別是Delphi 2.0，給我留下極好的印象。Delphi提供真正編譯的可視化開發環境，那個時候（1994年左右），Delphi就可以開發帶有GUI的動態鏈接庫，你可以想象，在Microsoft Access 2.0的應用程序中可以加載一個Delphi Form並進行程序交互，那種感覺真是棒極了。
Borland C++是我心中無法抹掉的遺憾，從Turbo C到C++ Builder，我深刻的體驗到Borland的輝煌和無奈，Delphi從VB Killer走到爲VB護航（你可以想象Delphi一步到位的ActiveX 控件開發技術有多牛，早期的VB有多土，早期的VB不能開發動態鏈接庫，因此無法開發ActiveX 控件，想起來真令人噓唏不已），Borland C++的命運也是不濟。Borland C++ 3.1的輝煌永遠不再了，十幾年的開發工作中，我在C++上投入了大量的精力，Borland C++曾經給我帶來無數的激動，然而這個經典的名字卻在與Microsoft的競爭中漸漸的流逝了……。
MFC4.0的出現，使得人們感覺Microsoft在C++方面趕上來了，這一版的MFC是Win95推出後出現在Visual C++ 4中（Microsoft沒有VC 3，VC4以前的版本是2.2、2.1、2.0、1.51、1.5、1.0）。也許是對Borland C++的潛意識的失望，我不知不覺的接受了MFC，VC 4.2推出時，我通過正常渠道購買了這個編譯器的企業版。
關於Microsoft
關於Microsoft，有無數的人要對這個名字敘說感覺，這個令人討厭的名字！不知道是喜歡還是憎惡，你是程序員，你的心思可能就要因Microsoft的存在而動，即使你用Linux，你可能也是因爲Microsoft技術因素。多少年來，這個名字每天都出現在你、我、他的面前，因爲你不得不面對Windows的存在，可是你憎恨這個名字嗎？你討厭這個名字嗎？我不知道是否已經對這個名字麻木了。1998年我個人訂了Microsoft MSDN Universal 版，我開始比較全面接觸這個公司的開發技術，你可以想象，1998年當你面對上百張技術光盤的時候，你就知道什麼叫做“厚度”，當我們有時說出“趕上”或 “達到”Microsoft某些產品的水平的時候，可能我們缺乏對這個公司“厚度”的真實瞭解。進入MSDN，我感覺Microsoft簡直不是一個“公司”，而是（或者正在形成）一個“社會”。當時著名的技術網站http://www.codeguru.com全部的技術資料是可下載的（那個時候http://www.codeguru.com提供整個網站內容下載服務，大約3M左右），大名鼎鼎的www.codeproject.com還不存在。一開始，我始終潛意識在技術上對比Microsoft與Borland，應當說技術上Borland不比Microsoft弱，即使現在也有人持有這個看法，可是爲什麼Borland走到今天這個地步？而Microsoft卻如日中天？若干年前，這兩個公司競爭何等激烈，而現在卻是另一番“合作”的景象？可能很多人想過，如果Borland不存在，對Microsoft不是更有力嗎？其實Microsoft可能精通中國歷史，讀過《三國》、十分了解戰國時期的中國，其實Borland形式上的存在，對Microsoft是十分有利的，至少形式上還有競爭對手，而事實上Borland已經受控於Microsoft（Microsoft是Borland的大股東）。你可以看到一些微妙的現象：Borland爲Microsoft提供了大量的人才，其中包括Delphi總設計師以及Borland C++編譯器的核心成員；同時也爲Microsoft .NET提供強有力的護航服務（看看C# Builder、Delphi .NET）。1998年Microsoft 的COM技術基本已經成熟，這個技術使人感到震撼，當時Microsoft的對手們提出“OpenDoc”用於對抗“COM”，你看看“OpenDoc”陣營的幾個成員：IBM、Apple、Borland、Novell，你會感到這個陣營十分豪華、強大。但結果卻差強人意，“OpenDoc”無疾而終，而“COM”依然生機勃勃。
有人說“COM”沒落了，那麼就太不瞭解Microsoft了。在與“OpenDoc”的競爭中，“COM”是個徹底的勝利者，在與“Java”的競爭中，“COM”成功的進化了，在這個過程中Microsoft體現了強大的吸收能力、以及無法想象的韌勁。.NET只不過是COM的“別名”而已。對於一個經驗豐富的C++程序員而言，.NET就是COM的進化，而Microsoft內部.NET就是“COM 3.0”（OLE2就是COM 2.0），而“CLR”就是一個不擇不扣的COM對象。曾經有人問我，既然牛頓時代就奠定了基礎（想想著名的牛頓-萊布尼茨公式），幾百年後的今天，數學還研究“微積分”嗎？回答當然是依然在研究！“微積分”早期是針對函數的，現代“微積分”是針對“流形（Manifold）、纖維叢（Fiber Bundle）”的，概念深奧了，可是基本思想不變，只是“微積分”的思想得到合理的延拓與進化，你瞭解Microsoft嗎？Microsoft Research有一批超一流的數學家在爲Microsoft工作，其中一些是斐爾茲獎的得主，Microsoft正在實現如同“微積分”進化到“微分流形”一樣將“COM”進化到“.NET”。從科學概念角度上分析COM與Java，可能COM更全面、精確，從實現的成熟度上Java可能更成熟，可是你看到，Microsoft正在不緊不慢的追趕。Microsoft令人聯想起戰國時期的強秦。
戰國時期的秦國，採取“遠交近攻”“撫弱掠強”等措施傲視六國，今天的Microsoft也是這樣，VB1.0時，Microsoft推出“VBX”控件技術，衆多的小公司得以生存，Microsoft自己不開發“VBX”組件，同樣“VBX”進化爲“OCX”時，Microsoft並不十分強大，可是這種試探得到衆多小公司的響應。1997年Microsoft Office 97、1998年Microsoft推出Visual Studio 6.0，給衆多中、小公司提供了生存、發展的機會，例如Microsoft Office 97中集成了Visual Basic for Application 5.0，這項技術使得幾百家軟件開發商與Microsoft簽署了VBA技術許可協議，即使AutoDesk這樣的公司都與Microsoft簽署了這個協議，這個協議使得每個集成VBA的產品的給個用戶許可爲Microsoft付40$的許可費，如果你瞭解VSIP（Visual Studio Integration Protocol）協議，以及有多少公司簽訂了VSIP協議，你就真正感覺到Microsoft的可怕；Microsoft Office 97、Visual Studio 6.0的用戶界面十分漂亮，爲什麼Microsoft自己的開發工具不提供類似的軟件組件？你看到衆多第三方的Microsoft盟友紛紛推出自己的界面庫以模仿Microsoft，他們不會反對Microsoft，因爲他們已經形成了使得Microsoft以及這些公司得以生存的生態圈。
Microsoft的技術儲備有多少，Microsoft之外的人很難說清楚，Microsoft中國公司也未必瞭解多少，1999年WTL類庫剛剛出現的時候，人們就希望WTL能得到官方的支持，或授權給一個Microsoft之外的一個公司（你能想象出Borland C++ 5.0內置的ActiveX開發機制是基於Microsoft ATL類庫嗎？），直到今天，WTL依然如故，我們完全相信，如果Microsoft強力推廣WTL，WTL完全可以流行，可是Microsoft不缺類似的技術，類似的類庫還有BCL(Base Control Library，一個用於開發輕量級ActiveX控件的類庫)，Microsoft還有一個基於ATL的類庫，這個類庫用於開發ActiveX Designer，ActiveX Designer是絕大多數程序員不瞭解得一類對象，如果你熟悉Office開發，你知道Office VBA 中有一類對象，即Form2，此外VB6.0 中的報表設計器（以及著名的Active Reporter），都屬於此類對象，用這個類庫，你可以爲VB6.0以及集成VBA的系統提供定製化的可視化設計機制等等，如今ActiveX Designer已經演化爲集成於Visual Studio .NET中的設計器。
向Microsoft學習
無論從什麼角度評價Microsoft，我覺得Microsoft是值得我們學習的，如果說生活在這個時代有Microsoft存在是一場災難，你就應該痛恨這個傢伙，但你首先要向這個傢伙學習！我無意爲Microsoft歌功頌德，我只是想說出十幾年我對Microsoft技術的感受。
Microsoft在研究式的開發中受益極大，如果你有興趣，你可以訪問http://research.microsoft.com/，雖然部分中國公司也有研究院，但與Microsoft相比，真有“米粒之珠，也放光華？”的感覺。2003年，我在北京的一個地方現場體驗了Microsoft亞洲研究院的招聘會，我看到中國的精英們進入Microsoft的渴望，事實上，在中國大陸，Microsoft亞洲研究院的人力資源已經延伸到各著名高校的相關專業的核心層，我感到，Microsoft幾乎不需要“求賢”，因爲，只要Microsoft需要，精英們會“蜂擁而至”，每個人都有“可以理解”的理由而嚮往那個地方，如果爲搞數學研究蜂擁到加州大學，我覺得可以理解，因爲那裏有數學土壤，出了成果國人也會感到自豪，因爲“科學無國界”。技術是否有國界？不知道是否有定論？！想想DVD等技術專利給國內業界帶來的災難，不知道應不應該痛定思痛，在Microsoft校園招聘現場的氣氛中，我似乎明白了爲什麼國人“原創技術”少得可憐。我讀過幾本Microsoft亞洲研究院的高手寫的書，明顯可以看出，Bill gate 是他們的精神領袖以及他們對Microsoft的虔誠，國內的研究機構應當研究一下Microsoft的用人之道，Microsoft好像是三國裏的人物，不知是劉備還是曹操，或者二者的混合物。我經常路過西格瑪大廈，第一次西格瑪大廈進入真有“朝聖”的感覺，也與Microsoft中國的幾個層次的人打過交道，各中滋味實在一言難盡。
在Office大戰中，國產軟件的確在一些方面與Microsoft進行較量，其實給人的感覺很勉強，界面上的似是而非，或用戶習慣方面的接近並不能解決根本的問題，一個好的軟件開發人員必須是一個軟件使用的高手，很難想象一個軟件操作水平很拙劣的開發人員能開發出高水平的軟件，我最早使用的軟件之一就是Microsoft Word，當時的版本是2.0，大概是1992年的事情，給我留下深刻印象的是集成於Word中的Word Basic，後來，我接觸到Excel 3.0，不出所料，Excel中集成的是Excel Basic，後來使用的Access中自然內置Access Basic 1.0，在這些軟件集成捆綁成Office之前，我就感覺這些產品的構思十分了不起，很具有Microsoft的風格，因爲你知道，即使是一個DOS，Microsoft都要提供一個內置的QBasic或GW Basic。雖然關於Microsoft的產品評論很多，作爲一個技術人員，我認爲Microsoft的產品構思絕對是第一流的，從1994年早期的Office系列到1997年形成的Office 4.2，我認爲，技術構思上均領先於我國2002年以後的Office產品，你聽說過如下說法嗎？“Dos 作爲操作系統的時代，Windows是應用軟件；Windows是操作系統時，Office成爲Dos時代的Windows；那麼如果按此規律，Office會不會替代Windows而成爲操作系統？”，現在在開發領域Visual Studio( .NET)正在成爲另一個Office，你注意到了嗎？控制Visual Studio( .NET)集成開發環境的仍然是一個Basic語言引擎（Visual Basic .NET）。
與許多公司不同的是，在技術體系上，Microsoft幾乎所有的產品是息息相關的，Windows、Office、Visual Studio .NET雖然各不相同，但公共的核心即將形成，我們已經看到，核心組件方面，Office與Visual Studio .NET日漸趨於一致，例如Microsoft正在將Office 2003的核心組件VBA 6.X逐步用新的Visual Studio Tools for Office替代，而我們依然在一些似是而非的現象上與Microsoft的產品比較差距，國家採購或政府採購支持的公司，不去鑽研核心技術，只是急功近利的採用短期行爲急於與Microsoft相爭，不知是否有蚍蜉撼樹的感覺，個人的體驗是，先學習Microsoft，踏踏實實的學，瞭解Microsoft，深入的瞭解，然後再喊口號。
爲什麼用MFC？
經過若干年的競爭，Borland 的OWL幾乎消失了，這個OWL是個非常漂亮的C++類庫，在Borland C++ 3.1風光無限的年代，OWL真正的做到了獨領風騷。然而，Borland C++ 4.0錯過了進入32位程序的最佳時機，BC 4.0推出後不久，迎來了Win95，Borland倉促上陣，以一個小的“Pack”使得BC4可以編譯基於Win4的程序，當時的Visual C++是2.0版，支持Window16的版本爲Visual C++1.51，有意思的是Borland可以用同一個編譯器同時支持Win16、Win32，而Microsoft卻不得不爲Win16、Win32提供不同的編譯器。然而，非正式版本的Visual C++ 2.1與Visual C++ 2.2卻悄悄地支持了Win95的最新特徵，即Win95新提供的一組公共控件，在我的印象中，Borland對Win95新特徵的支持不利使得MFC與OWL的距離極大的縮短了。稍後到來的Borland C++ 4.5沒有改變這個狀況，儘管Borland C++ 5.0同時支持OWL與MFC，可是敗象已經顯露，Borland C++非常遺憾的只走到了5.5版。C++ Builder雖然形式上引入了Delphi的VCL庫，可是許多C++程序員並不買賬，因爲許多以C++爲樂的人更喜歡以編輯的模式進行編碼。Visual C++ 4.0的出現，在C++這個戰場上，Borland開始落敗了。
MFC發展到今天，已經十多年了，儘管褒貶不一，但可以肯定，十幾年的技術積累已經奠定了MFC的生存基礎，即使Microsoft的長角發佈，MFC也不能推出Windows的舞臺，事實上，長角（Longhorn）之後的Visual Studio .NET仍將MFC作爲一個重要的組成部分，在今年的Visual Studio .NET 2005中，MFC在C++中的位置依然如故。MFC的未來，應該不必擔心，只要你深入考察.NET類庫，你會發現，MFC的許多思想機制正悄然進入.NET，與此同時，Microsoft的第三方盟友十多年來已爲MFC開發了大量的擴展庫，如果Microsoft是船，第三方盟友就是載舟之水。許多人認爲MFC不發展了，其實是一種錯覺，Visual C++ 6的界面十分經典，特別是其中的Docking控制條機制，其實Visual C++ 6的IDE完全就是MFC寫的，可是MFC類庫中控制條相關的類功能很弱，爲什麼？你會看到許多與Microsoft友好的公司，他們很快的在MFC基礎上實現了Visual C++ 6 的Docking機制，這就是Microsoft的高明之處，Microsoft很會給盟友提供機會，其一貫的做法就是在自己的商品化產品中預先提供一些有趣的特徵，使得其它一些公司進行模仿以帶動用戶羣體。Borland不具備這樣的儲備。MFC第三方市場的繁榮，得益於Microsoft的策略與明智。MFC可否跨平臺？理論上完全可以，Microsoft不做，也是策略，但是有許多重要的產品Microsoft卻默許MFC移植到其它平臺，事實上，Microsoft的合作伙伴之一Mainsoft公司（Windows源碼就是從這家公司流失的），幾年來就是負責移植MFC程序移植到UINIX、Linux、AIX等操作系統之上。
新版的Visual C++中MFC已經支持.NET開發了，MFC與ATL的協作更好了。根據我的經驗，MFC、ATL與.NET庫三者完全可以融合在一起綜合應用到實際的開發工作中去，如果你是MFC行家，我希望ATL與.NET庫能成爲你的忠實的左右手。那麼有沒有同時支持MFC、ATL與.NET庫的程序？當然有，Visual Studio .NET IDE就是！而且Visual Studio .NET IDE還支持用ATL與.NET庫擴展的Addin。
認識Application對象
如果你熟悉Microsoft Office，你應該進一步的剖析這個大型軟件，Microsoft Office中幾乎每個程序都是可二次開發的，這一點得益於Microsoft Office內置的二次開發機制，一個是基於COM機制的VBA模型，另一個是基於.NET框架的託管模型：Visual Studio Tools for Office。作爲一名程序員，你應當在技術角度解析Office的技術結構。Microsoft的大多數軟件的對象結構可以通過Visual Studio提供的工具OLE/COM Object Viewer考察其類型庫得到，通過引用類型庫，你甚至可以得到描述對象信息的C++頭文件。這樣做真是好處多多。一個典型的Office通常都有一個Application對象（或其它一個與之相當的對象），這個對象相當於軟件樞紐，在這裏，我們不討論Office，藉此話題說說Application對象。大多數支持擴展（Addin、Plugin）的軟件都存在類似的構造。通常，一個系統得Application對象或者是一個COM對象，或者是一個.NET對象，如果你的系統存在這類對象，你的系統就基本具備支持Addin、Plugin的機制了。一個理想的做法就是在一個MFC系統中，內置一個ATL對象或.NET對象，稍後我們給出方案如何做到這一點。設計Application對象的關鍵是如何規劃這個對象的屬性、方法、事件。如果你希望系統具備良好的擴展性，Application對象是十分關鍵的，這也是構架藝術的體現。所謂Addin(Plugin)，是系統運行時根據需要加載的對象庫，Addin(Plugin)之所以可以擴展系統，關鍵的因素就是系統加載Addin(Plugin)時，將Application對象傳遞給Addin(Plugin)庫，設想一下，如果Application恰到好處的觸發了系統事件，而Addin(Plugin)庫如願的解釋了事件，一個Addin(Plugin)庫的任務不就OK了嗎！因此Application對象是系統設計的關鍵。
如果你精通ATL對象，在你的MFC系統中添加一個ATL對象，這個任務可以用VC Wizard完成。你已經接受了一個事實，就是MFC程序中存在一個CXXXApp對象（CWinApp的派生類），現在你要做的是增加一個對應得ATL對象。這個對象可以在CXXXApp::InitInstance()中創建，如果ATL對象的類是CXXXAppObject，建議你在CXXXApp對象對象中增加一個成員變量，例如：
CComObject <CXXXAppObject >* m_pAppObj，然後可以入下初始化m_pAppObj：
m_pAppObj = new CComObject <CXXXAppObject >；
注意程序結束時在CXXXApp::ExitInstance()中釋放m_pAppObj，語句如下：
delete m_pAppObj；
你可以將系統得關鍵屬性設置成CXXXAppObject的屬性，例如系統得標題、是否爲多文檔等等。系統希望外部調用的功能可以實現爲CXXXAppObject的方法，這一點取決於你的需要。系統需要外部擴展的功能，表現爲CXXXAppObject的事件，關鍵是在恰當的位置觸發事件以及提供的事件參數。例如，你可以在CXXXApp::InitInstance()觸發應用程序開始的事件OnStartUp，Plugin捕獲事件後，可以進行特定的初始化（身份確認、初始信息查詢等等）；
你可以在CXXXApp::ExitInstance()觸發應用程序結束事件，Plugin捕獲事件後，處理用戶需要的系統退出工作。所有的設計取決於具體設計。
如何加載Plugin，是一個有趣的問題，如果Plugin實現爲一個COM範疇（Category），可以運用COM技術枚舉這個Category；可以將Plugin安裝到一個特定目錄，也可以通過註冊表。Plugin的實現可以用COM技術、也可以用.NET框架。適當的機會我會提供例子……