十年MFC經歷認識的Microsoft技術[轉]
在CSDN看見一個老程式設計師的感想，雖然是關於MFC的討論，但是對其他語言的開發者也有借鑑之處。
一、初識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簡直不是一個“公司”，而是（或者正在形成）一個“社會”。當時著名的技術網站
有人說“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中的設計器。
（不是待續。要繼續看的話就去點上面的連結，這邊不會續了）