為什麼微軟在推出 MFC 技術之後，就沒有發布過其他的 C++ 桌面GUI框架技術？

01-04

比如Apple，以前是carbon，在進入OS X之後開始轉型cooca框架作為桌面GUI框架。相比之下，微軟是專業開發桌面客戶端的，反而從MFC之後，再也沒推出過官方C++桌面GUI框架。鑒於微軟的實力強大，不可能沒有能力開發。為何微軟放棄C++轉而開發基於C#的WPF呢？WPF雖然開發速度快，但是基於虛擬機的語言，很多應用不：比如遊戲、視頻播放器等這種應用都無法運用到WPF

你連wtl都沒有聽說過，居然問出這種問題。。。

做一個框架，首先得定目標市場。要是微軟現在來推一個庫的話，肯定是要支持多種語言的，比如GDI+在.Net裡面就重新封了一遍成了System.Drawing。原來C++程序員是主力，現在不是了，不給別的語言開介面，其他語言的程序員會叫的。給每個語言開發一套界面框架現在看來是非常浪費的行為。原來MFC的賣點是面向對象，現在新的界面API本身就面向對象了。那麼「C++ 桌面GUI框架技術"這裡的C++就可以去掉了，把目標市場限定於只有C++程序員是給自己自縛手腳。

就算做了出來，還有個程序員買不買賬的問題。比如SysLink、SysAnimate32和SysPager都是做了程序員不用的。Visual Studio 2008里MFC做的一些封裝類，比如CSplitButton、CPagerCtrl，這麼多年了搜索結果都還沒上百，2008 SP1里從BCG授權而來的一大堆界面類，被人抱怨是浮腫。很多人根本不用C++來做程序的界面部分，即使有的話也有自己的一套，比如遊戲開發者們用基於DirectX的遊戲引擎。對於性能不敏感的商業程序，像Visual Studio這樣的，用WPF也馬馬虎虎，更別說微軟在做.Net Native，用C++的後台優化來加快WPF程序的啟動啟動速度。重新做一個新的通用界面庫，現在看來很可能仍舊是吃力不討好。

對於Visual C++項目組來說，收到的請求更加集中於對跨平台開發和開源代碼的支持，最近Visual Studio的幾次更新，Visual C++的更新都是集中在對於標準的支持，在標準兼容性上的改進可以讓所有程序員受益而不僅僅是界面開發人員。比如你現在可以在VC里編譯FFMPEG，可以在Windows商店應用中用boost了。VC項目組也在自己開發跨平台的類庫（比如C++ REST SDK)以滿足需要跨平台開發的C++程序員的需求。想讓微軟自己來開發一個僅支持桌面的C++界面類庫的要求目前看來並不實際。

你連atl都沒有聽說過，居然問出這種問題。。。

alt和mfc不是替代關係（alt和com才是一對姦夫淫婦），wtl是被ms叫停的（我個人認為：wtl此嬰，即便不被斷奶，也長不成健康人，頂多一侏儒。當然，我不敢肯定這一點，因為，既然ms要斷其奶，肯定是覺得它有成人的可能。）。

轉回樓主話題，理由是，ms不希望你用C++開發應用（雖然MFC和C++關係不大），而是希望你用ms家的私有語言來開發應用（看到「私有」這裡有人開始反駁了，反駁個球呀，我只說事實，不談假名頭）。

和那些說「語言不重要，重要的是思想」、「語言只是工具」等等言論的碼畜不一樣，MS認為語言是重要的。這一點我認同M$，語言才是一切的載體，思想的濃縮體現。只有被MS的私有語言（.net這種平台也算）鎖住，才是令MS放心的佃戶。

MS是暗暗打壓C++的。舉例，某g??+，是用C++寫的，但一開始的時候用shit封裝後不讓C++調用；某shit，提前放話，不提供C API介面，觀察程序員的反應。等等，照目前的趨勢，若無變故，以後C/C++在windows上寸步難行，我不是在危言聳聽。

MS作為一家商業公司，這麼做無可厚非，但能不能成功是另一回事。畢竟windows的影響力不如當年那麼健壯（當年也不會成功，VB/COM已作明證）。另外，強迫別人站隊，是有風險的。甲乙對砍，周圍一幫人圍觀，一會兒給甲遞瓶水，一會兒給乙擦擦汗，打的熱鬧，看的興奮。現在，甲突然說「你們要麼幫我砍乙，要麼我就砍你們。」，會出現什麼情況？圍觀者為了自己的小命作想會去幫助人多的一方，哪邊一開始人多哪邊就會繼續多下去，哪邊人少哪邊就會繼續少下去。