自從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++開發環境是

關於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框架。適當的機會我會提供例子……

一些感想 

        一時心血來潮，就發了這個帖子，很難說是有心，還是無意。幾天前我在新浪網上看應氏杯圍棋決賽，我覺得該贏了吧，作為一個圍棋迷，我們等了十幾年，等到了屬於國人的應氏杯。記得7、8年前在還在大學工作的時候，有一次，一位同事興致沖沖的走道我面前對我說：“嗨，昨天馬XX贏了李昌鎬！”，當時我在系辦公室正在看報紙，那位仁兄見我頭都沒擡，非常不滿的搶下報紙，對我吼道：“喂！馬XX贏了李昌鎬！！你聽到沒有！！！”，我對他說：“你大驚小怪個啥？！馬XX輸了李昌鎬多少盤，你知道嗎？”，馬XX幾乎一直在輸給李昌鎬，人們已經不奇怪了，偶爾贏一次，國人就把他捧得北都找不到了，李昌鎬弱冠17的時候就傲視這個世界了，可至今面孔不變，幾天前的農心杯，中日聯軍5個人，被他打個落花流水，李昌鎬是公認的世界第一，以至於有的高手知道下一個對手如果是他，就會去訂回程機票。這次應氏杯，國人竟然感謝崔哲瀚，何也？因為這個弱冠19的小子，擋住了他的大哥李昌鎬才使得應氏杯有了懸念。當國人媒體在說韓國僅李昌鎬一人厲害的時候，不知道是出何居心還是自欺欺人，李昌鎬年方30，不知道要力壓中、日多少年！面對這個名字，真有點麻木了，這個太極虎！軟體界又來了我們一向不齒的印度虎，2001年我們的軟體出口額僅是印度的四十分之一，我們震驚了，怎麼可能呢？這個四十分之一水分很大，很可能更可憐！當時我在大連參加一個關於“大連軟體出口國內第一”的官方會議，那位大人在會上說：“據說，我們大連軟體出口國內排名第一，市有關領導希望今天的會議給出這個第一的數字依據，希望你們把資料報上來，去年的資料也可申報，注意