別用微軟的東西。商業目的性太強，千萬別被微軟牽著鼻子走，血淋淋的教訓。微軟推出的垃圾多了去了。它什么都想做，很多都沒做好：

1. MFC：Win31時代出生，Win95、98時壯大，雖然一直在更新，但是接口和概念都太老氣。你要做現代界面，大量東西要自己手工去弄。同一個界面，一個熟悉MFC的程序員需要開發2周，而一個剛剛學習 Qt（我認為Delphi、Java做界面也很快，不比Qt差，甚至更好）一個月的大學生，三天就搞定了。

2. WTL：好幾個百萬 DAU量級產品都試用過，最后都放棄沒用了，微軟也不怎么管了。

3. SilverLight：對抗 Flash，當年剛推出的時候，被微軟碰成下一代桌面/web的統一解決方案，有的人真的去用了，結果呢？傻逼了。想找點第三方控件，少的要死，想招人也招不到，最后切換會flash去。

4. ASP.Net：當年微軟到高校里面忽悠大學生學，學了半天，就業了，發現網頁全部是 linux下的解決方案，傻逼了。一線的互聯網公司就沒有使用 SqlServer+ASP?Net的，都是清一色開源免費。

5. C#：這個還算好的了，十多年前照樣當年騙著大學生學，說是比 java好很多。我很多年收到的學生簡歷都是精通C#，問題是十多年都過去了，看看今天的 TIOBE排行榜，java的分值是 c#的 4倍以上，服務端開發web/非web，企業級開發，java都是完爆 c#，更別說java開發 android設備的app了。微軟的話再次沒算數，當年學了很長時間 c#的學生，工作后碰都不會碰一下。

6. XNA：笑話一個，當年搞了好多 XNA游戲開發大賽，告訴大家 XNA就是游戲開發的明天，可以快速搭建小型游戲，或者快速編寫游戲demo供驗證。我們在評估使用什么給新人做 Demo用，最后評估下來，Python+Panda3D，易用性比 xna強幾條街呀。

7. DirectMusic+DirectInput+DirectPlay：全都傻逼了。

8. 聲音方面： Wave接口 -> DSound接口 -> CoreAudio接口，它就穩定不下來的。

---

微軟的思路就是看著一個開發工具好，然后自己也要搞一套，然后借著自己強大的影響力，哄騙所有人來用他們的東西，最后大家用下來還是覺得開源的好。

微軟的界面解決方案：GDI/Win32自己畫，MFC/GDI自己畫，基于Win32的各種界面庫，WPF，SilverLight，Direct2D，看得你都不知道選哪個，但是你要做現代流行界面的話，一個Qt（我認為Delphi、Java不比Qt差，甚至更好，當然甩MFC多少條街）直接秒殺他們所有。

再給你說個血淋淋的教訓，公司的游戲當年用的dx8開發，開發了兩年，內測時微軟開始推所謂革命性的dx9了，但是微軟強調說，dx9兼容dx8，但是dx9性能更好，而且今后不會再有dx8的大更新。好吧，先不管，游戲先上著，但是競爭對手的游戲馬上聲稱，完美支持dx9，充分發揮dx9的xxxx，我擦，沒辦法，既然今后趨勢是dx9，那就改，學起來也挺快的，不就是api嘛，改了三個月基本改完。但是碰到各種坑，各種文檔上找不到答案，網上還沒人遇到的坑（當年dx9比較新），前前后后折騰了1年半，游戲才算ok了。跑了沒多久，這時微軟的 dx10出來了，號稱完美兼容dx9，但是dx9不會再有本質上的更新了，你們快學dx10吧，性能很好，等你學會了 dx11又來了。

試想你一個程序員，一大半的時間都在給微軟交學費，值得么？人生有多少時間呀？這就叫做被微軟牽著鼻子走。再回過頭來看看 OpenGL，到現在為止，還在用著 1.2/2.0標準，ES 3.0剛出，這就叫做穩定。一旦被商業利益捆版你就傻逼了，.Net到現在好像都5.0了吧？

跨平臺：

我之前對寫一些客戶端的代碼，用很多 VC的特性是抱容忍態度的，畢竟每個程序員有自己熟悉的領域。在項目時間有限的情況下，讓熟悉 Windows的程序員在用很多 VC Only的特性，如： DWORD, DibSection, CString, #pragma once 等東西也是可以容忍的，畢竟當年客戶端一般都是 Windows。

后來客戶端發生了變化，一份代碼需要同時運行于多個平臺。除了vc編譯外，還需要gcc, clang編譯。當我們一份代碼需要同時運行在 win32, 移動平臺和 flash(crossbridge) 中時，當年積累的這些 vc only的代碼化了不少時間翻新成跨平臺的代碼了。盡管vc有 #pragma once這些還是比較先進的語法糖，但 gcc/clang沒有的情況下，只能退而求其次。

通過這次翻新，今后客戶端也跟服務端執行一樣要求，清一色的跨平臺，再也看不到任何vc only的代碼了。所有項目去 vs化。

---

答疑1：【商業目的性太強，給微軟教學費這幾句非常可笑，現在還想學一個東西保一輩子么，學什么不是學，網頁游戲火，學Flash，手機來了學objectc，學android開發，游戲引擎變成了Cocos和unity3d，做網站后來流行PHP等等，這類例子太多了，樓mfc，vb，asp，這些當年都帶來了很多就業機會，讓人入了門，樓主主觀情緒太強】

沒錯正式學了新的，才會拋棄微軟的東西，比如學了Qt（當年可是n多人學了Delphi立馬可以笑傲MFC多年）才會拋棄 MFC/WPF，學了 php才會拋棄 asp，學了 java才會拋棄 c#，學了 flash才會拋棄 silverlight，學了 MySQL才會拋棄 SqlServer。然后你會發現，我當初干嘛學微軟的那些東西呀，浪費我時間么？

當年很多人是靠mfc vb開發，那是因為沒有更好的，今天有那么多的其他選擇，mfc vb已經可以退居二線了。也正是因為有那么多平臺需要應對，特別如果是C/C++程序員，才不能用太多CString這些只能在vs下跑，沒法到android和服務端用gcc編譯，沒法到ios下用clang編譯的代碼。這叫去微軟化。

再者如果你沒得選，比如你用dx，那么你就受苦吧，它每隔兩年出一代，搞那么多版本到底是一開始接口就沒設計好需要不斷重構呢？還是故意非要重新弄一套？當初出9我沒記錯的話就是為了推winxp的，只有xp能跑。而dx10又是為了推vista和win7，逼著你游戲要更好效果必須dx10，而你想玩好游戲的話你可能被迫升級你的操作系統。這就叫商業利益驅動。

反觀其他平臺開發，很多圖形工作站用ogl，游戲主機用ogl，android用ogl，ios用ogl，mac用ogl，而ogl幾十年到今天主要版本還是2.0，包括es2.0，這就叫沒有商業利益驅動的情況。

如此類推，出一個新平臺，有微軟的vs2015和Qt、Java，那么用Qt或Java吧。

如果你覺得vs作為ide很好用的話，在沒有更好替代的ide前，你可以用vs這個ide來寫Qt或者Java代碼嘛。這叫逐步去微軟化。

---

更新：擦，本來只有一句話，推薦Qt或Java，遠離微軟，有人追問，補充了點，有人又追問，又補充了點，然后出了趟門回來，感覺跟捅了馬蜂窩一樣。既然都說到微軟了，那就接著展開一下。

問題的本源

微軟就是戰線太長了，忙著去主導各種標準，制訂各種框架，這樣的話，才能更好的夾帶私貨，用一個你必須用的東西推進另外一個他想讓你用的東西，諸如dx和windows，諸如c#和 asp.net，而又因為主導了開發者，才能進一步主導用戶，而主導了用戶，大量的利潤便會隨之到來。在整個鏈條中，如果消費者沒得選擇，開發者也沒得選擇時，微軟就能想賣啥就賣啥，完全基業長青了。出個新東西沒關系，不符合我的利益我就不支持。如果新東西很有前途，那我自己搞一套，然后再把我的開發者和用戶綁架過去。

到底哪一個方向會有前途呢？微軟自己也說不清。到底哪個領域對今后的軟件生態影響比較大呢？微軟自己也道不明。只能朝著各種有苗頭的地方去努力，以前技術領域比較窄，微軟可以囊括整條產業鏈，編譯器/IDE/框架，開發者基本可以躲在微軟的圈子里不出來。后面各個技術領域蓬勃發展，分支越來越多，微軟就有些力不從心了。但是戰略依舊沒變，任然試圖去主導任何一個技術領域的標準。利用自己的影響力去忽悠各種開發者：“跟我來吧，有美好的明天”，但技術領域每天都在推陳出新，產生新的細分。為了主導更多的新領域，稱霸完一個領域后，微軟的重心并不是完善該領域，而是繼續集中精力稱霸其他新的領域。

對于支持期的技術，微軟會利用自己強大的影響力進行各種捆版整合，告訴你：“新的革命又到來了，你準備好了么？”，告訴你：“用了它之后，你就什么都不愁了”，“XXX即將停止支持”，然后各種社區中，一堆mvp前撲后擁的進行推廣：“XXX大法好，MS法力無邊”；書店的柜臺上，瞬間多出幾十本紅色封面黑色封面的寶典；CSDN的主頁里，各種微軟 TechED, 夏令營。很多人一看，我靠，全世界都在用，我再不用是不是就要被淘汰了呀？

完成支持后，微軟進入綁架期，為了不讓你用其他的東西，微軟想盡一切你的需求，然后為滿足你可能的一切需求，開始拼命的飆版本，來兼容各種各樣的東西。很多人覺得這個東西好像挺強的，什么都能做，不用學其他了，微軟就笑開花了，覺得可以綁架大家了，于是開始瘋狂的用該技術夾帶越來越多的私貨，或者是新技術，或者是為了強迫其他人用另一個東西，為了兼容這些私貨，繼續飆版本，這就叫綁架。

等到你積累了越來越多的代碼，或者成熟框架后，你突然發現，原來你能做的事情，就是只能在微軟給你劃定的一畝三分地里面不斷的耕耘。想用它開發一個微軟商業上不支持的東西？沒門。依賴微軟越久，做出選擇的成本越來越高。這時會有兩種結局，第一種，微軟給你指出下一個革命的方向，你別無選擇，斬斷原有積累投入到下一個革命中。異或，微軟覺得自己在這個領域江山穩固了，競爭對手都沒了，不會再出什么幺蛾子了，于是徹底開始不思進取，你用著過時的技術干著急。

曾任微軟副總裁的李開復回憶：“一個產品隊伍一旦失去了假想敵，就會松懈，蓋茨和鮑爾默也會撤回對它的投資和支持。比如說，微軟IE擊敗網景之后，微軟就降低了投資，致使它的瀏覽器多年沒有再進步，直到又出現了‘火狐’這個敵人，才又開始振作。”火狐就是網景的“遺孤”。

微軟的綁架

MFC就是一個很好的例子，當年同 VCL競爭時挺上進的，VCL一死，MFC也跟著死了，現代的界面系統都是 windowless直接繪制控件了，笨重的mfc還在基于系統控件。大量的onpaint自己做，人招不到不說，工作效率奇低，熟練的mfc工程師還比不過學習Qt、Delphi、Java一個月的學生開發效率高，你說我會選啥？mfc還需要各種奇巧淫技才能達到qt、delphi、java的效果，弄那些技巧的人變動，項目就傻逼了，考慮到這一點，你說我又會選啥？最近兩年界面開發又開始腳本化了，你會發現 Qt、Java有各種支持腳本（除了內嵌支持 js的 QtScript外，還有 Python的 PyQt，還有 Lua）任你選擇。核心代碼C++，邏輯界面python，用過腳本開發UI的人都不會想用回C++寫UI，因為界面邏輯腳本化可以提高至少兩倍以上的生產力。微軟的策略呢？想用腳本？沒門，因為我不推腳本但是我推c#，所以你想方便的寫高級界面？還是跟著我去弄 .net和wpf去吧，這就叫綁架。面對綁架你別無選擇，開發者微軟系的代碼和經驗積累越多，想離選擇非微軟的東西成本就越高，想不被微軟綁架的代價就越大。

為啥有人愿意給 Qt腳本化而不愿意給微軟的界面系統腳本化呢？并不是微軟的技術就比不過Qt，而是大家唾棄微軟的臭脾氣，外加Qt是開源的，為它實現腳本各種方便。這里并不是說開源的東西就一定比微軟的東西好，微軟有很多領先的技術甩開源幾條街，主要問題在于微軟的封閉性。所以我的論點并不是一定要用開源，而是建議大家有選擇的余地下，選擇非微軟技術，比如qt, flash這種。

死也要主導行業標準

為了引導行業標準，微軟很多設計的很好的東西，各種音視頻格式，還有最近的 HD Photo圖片格式，比 jpg2000 和google的webp好多了。但是很多人由于微軟的封閉不買微軟的帳，很多框架和軟件都直接支持webp了，也沒幾個人支持wdp，在這種情況下，我寧肯選擇次一等級的 webp。

微軟的出過很多標準性的東西，比如wmv, wma格式，當年挺先進的，微軟也天天忽悠人去用這兩個格式，但是由于封閉，最終失去支持，大家選擇了更加開放的方案來代替，微軟也就不思進取了，最終視頻領域 現在是 h.264/265，音頻領域是 he-aac v2。

微軟又試圖代替 pdf，引領該領域的標準，然后自己出了一個 xps。論技術，確實高于 pdf很多，但是沒人用呀，沒軟件支持呀，連打印機都只支持掃描成pdf格式。所以我選擇 pdf并不是因為 pdf技術比微軟強，而是因為它不是微軟的。而且我估計個兩年出個 pdf2，xps也就跟 wmv一樣進棺材了。

再比如 SilverLight，微軟在沒有太大把握的情況下硬推這個東西，就是因為怕c#由于滿足不了RIA使得C#開發的開發者流失到微軟以外去，為此 .Net還逼迫大家升了幾個版本。可惜，大家都知道的，于是微軟自己對它的支持都少了很多。

你說微軟技術弱么？不弱。那為啥這些明顯亂七八糟的東西微軟都要硬撐著試圖主導行業標準但是最終又主導不了呢？那是因為我們先前提到的微軟戰略，從幾十年前到現在都從來沒有變過，然而時代變了。

Win32 API

Win32 是系統層最穩定的接口，一切功能的基礎。這么基礎的東西，微軟該化大力氣持續發展對不對嘛？非也，隨便舉兩個例子你就會發現其實它已經落后世界很多了。微軟是任性的，覺得我提供的開發模型可以解決一切問題，為什么要參考其他操作系統改進呢？即便其他操作系統提供的功能很好，我也要給你挑挑刺。而按照微軟一貫的規律，系統 API領域，我完全控制了，那么我改進的動力也就不那么強了，庶民們豈能妄自議論 Win32 API，更別說想提交改動 patch給我了。

線程同步：如果你寫線程同步，你會發現 Win32 API缺很多關鍵的東西比如：條件變量，讀寫鎖，這兩個最基本的能夠組合成其他任何同步模型的東西，微軟直到 Vista的年代才提供支持（msdn Condition Variable），這就意味著，你如果用了，你將面臨很難在 xp下跑的情況。你問微軟 xp怎么辦，微軟說用 event去 wait嘛。你就奇怪了，event這么弱智的東西能代替條件變量么，為啥不再xp年代就支持了？

單次初始化：pthread_once，沒錯，windows下面由于缺少這個東西，你再做一個全局變量供你的接口訪問時，你需要保證該變量只被初始化一次。即便多線程同時調用訪問該變量的接口，也不會出現兩次初始化的情況，pthread_once就是做這個事情的。直接把代碼寫成：if (inited == false) { init(); inited = true;} 線程又不安全，外面加一個 CriticalSection，那你又需要在更前面去 Init這個 CriticalSection，還要保證不會發生多次 Init，問題還是沒解決。于是很多人在 Windows下的解決方案是，在全局變量聲明一個類的靜態實例，這樣 main()之前，那個類的構造函數能夠提前被調用，進而又引入了新的問題，及多個全局實例又會存在誰先誰后被構造的問題，你又得用惡心的 #pragma宏來解決，最后初始化代碼一團亂麻。而如果微軟提供 pthread_once類似方法，那或許這一切都會變的很清爽。

網絡接口：用過 winsock接口的人都覺得簡陋，你想實現高性能的網絡服務，需要控制 TCP的大量細節參數，比如 TCP_NOPUSH, TCP_CORK, 還有 QUICKACK這些控制調整 TCP面向流量優化或者面向流速進行化的基本功能，winsock上看都看不到。更別說 Google的 TCP速率優化（Kernel 3.2.12收錄的 Google patch）等現代功能了。即便是對比最基本最傳統的 posix套接字，winsock的行為也是錯亂的，比如 REUSEADDR，再比如 Win32下你監聽一個 UDP端口，給遠端發送 UDP數據包，如果遠端沒有監聽該UDP端口，那么你服務端收到 icmp: port unreachable后，那個udp socket就徹底被 reset了，后續什么數據都讀不進來，持續給你報 10054，搞笑吧。除非你創建udp套接字時做一大堆 windows獨有的 專門的設置，否則vista之前，你都會被 10054。vista之前，默認情況下，客戶端如果拒絕收服務端的 udp包的話，服務端的 udp套接字就用不了了，這是不是在搞笑么？還有各種基礎功能限制，比如：缺乏poll支持（強迫你用iocp代替），select最多64個fd，沒有 socketpair。當然，沒有這些也可以寫網絡應用，但寫慣 unix下的網絡代碼突然來 win下寫，就會覺得這真是個玩具呀。

TLS：TLS有數量限制也不管了，但是線程本地存儲這個東西是需要 destructor的，即我創建了一個本地存儲來存一個對象，我可以設置一個 destructor函數指針，在線程退出時，這個函數會被自動調用到。比如你想實現一個 per-thread cache（比如類jemalloc的 arena），線程退出時能夠被自動析構，這個最基本操作在 Win下卻可以把你別扭死，原生TLS API沒有這個支持，你又不想所有線程退出都要強迫使用者調用一下 destructor，那么你開一個線程監聽所有線程？還是怎么招？看看 boost和 jemalloc這些在 win下的 destructor實現，你就會發現惡心的要死，就像要在一塊工整的電路板上，焊接一根非常礙眼的飛線一樣。

GDI/GDI+: GDI是牛逼的，出生早又承當了 GUI的基礎工作，畢竟那么多年了，做成這樣是無可厚非的。但是XP年代的 GDI+一出生就落后于時代。比同期的同一個級別的開源項目 Cairo（gtk后端，wine用來模擬gdi/gdi+的后端，webkit/mono后端）和 Quartz（OS X圖形后端）來，GDI+除了速度卡外，圖像質量差，功能簡陋，不支持抗鋸齒，對GDI的字體效果也并沒有質的改進。所以 Windows下的應用軟件，一直因為字體和圖像質量受到詬病。直到后面的 Direct2D出來希望改進這個局面，也已經是好多年以后的事情了。大量兼容 xp的程序還在跑在 GDI/GDI+上。

（ 問題有很多，以下省略若干字）

按微軟的能力，想改進這些基礎接口，應該不是難事。但基礎接口的長期滯后，折射出的是該公司全勝時期的傲慢。

統治與分治

微軟的接口設計向來是缺乏美感的，喜歡復雜化，喜歡什么東西都攪合在一起。什么叫做大一統？就是什么都能做，貌似很強大，一個東西能做的事情很多，開始是好的，但是隨著時間的推移，耦合度高，各種盤根錯節，一旦其中一個設計很 “巧妙”的東西過時了，那所有依賴它的東西將面臨死亡。什么叫做分治？就是保證簡單性和可拆分性，每個系統專心做好一件事情。一個不行，換掉即可，整個解決方案是由若干全部可以替換的子模塊組成的，這叫分治。

Windows技術棧就是一個典型的大一統設計，他有很多很巧妙，依賴性很強的東西。比如，“一切都是窗口”，這個思想，從設計上來說就是有問題的。舉個簡單例子，WSAAsynSelect 用過的人都知道，這是一個網絡接口，用來判斷哪個套接字上有事件。但是卻又要傳一個窗口句柄過去，讓窗口來接受網絡事件，這就是一個很搞笑的例子。微軟為什么這么設計呢？因為應用程序本身有一個消息循環了，就是窗口消息循環，但是如果處理網絡的應用程序使用類似 unix poll的方法，去等待消息的話，窗口消息就得不到處理了。如果把poll放到一個線程里的話，那UI線程要找網絡線程做點事情，那網絡線程在 poll的等待周期中，如果沒有新的網絡數據過來，可能短時間內沒辦法理會 UI線程的請求。于是微軟的解決方案，就是讓網絡層的事件合并到 UI的窗口事件中，這樣就比較方便了，全部在窗口消息隊列，你要把UI和網絡放到一個線程也可以，兩個線程也罷。這樣把兩個風馬牛不相及的事情攪在了一起的：“巧妙” 設計在微軟的技術棧里數不勝數。

合理的處理方法應該是啥？應該是繼續使用 Poll，每次 poll可以設一個比較短的時間，并且可以被外面線程喚醒，這樣就不會出現之前的問題了，兩件事情不會攪在一起，這就叫可拆分性。結果呢，不關網絡，大量的其他東西都和窗口攪起來了，等到 Windows程序要移植的時候，就會變得萬分痛苦。有人說不是有 IOCP么？看看有多少一流的服務器支持 iocp？再說java可以把所有不同操作系統的異步事件模型封裝成NIO，對 Windows對的 iocp卻提供單獨的接口，而且直到 7.0以后才有，微軟總喜歡和全人類反著來。

缺乏審美的設計，才會導致 Win32 API被 GUI所束縛這樣一種結果。這在其他系統對比來說，這時聽都沒聽過的事情。這是設計上的偶合，還有商業上利益的選擇。比如網頁開發，C# 和 asp.net綁定太緊，asp.net和 iis綁定太緊，iis和 windows又綁定太緊。微軟的東西才出來都是先進的，可封閉的微軟不愿意同外面合作。你要用我先進的東西，你就一個系列都要用。最終全部都攪在一起了，風險是相當大的，系統就像一個吞噬了各種化學物的怪獸一般，蹣跚前行。

而所謂簡單性和可拆分性的東西，是四處皆可替換的東西。比如你做 web開發，你選一門語言，python，語言就做好語言的事情。外部的網絡框架，可以用 django，flask, web.py等等，接口可以用 fastcg / cgi / wsgi / uwsgi / apache_mod, 而外部的服務器，可以用 apache, nginx, lighthttpd。清晰的被分成：語言層、框架層、協議層、服務層 四個不同的層次，每個層次若干備選方案，互相兼容，web.py過時了，我換 flask，apache過時了，我換nginx。每個產品都專注做好自己的事情，并前后適配其他層次的方案，python出問題了，我換 ruby，換php，協議任然用 apache_mod或者 fastcgi。這就是分治，具備美感的設計。

這樣的情況在微軟的技術體系里很難出現，這些技術運行到windows下水土不服不說，微軟自己就不讓你選：你要寫asp .net，那語言你就用 c#（vb比較小眾），用了asp.net你就要用iis，而iis只能跑在 windows下。外部的人很難兼容進來，本來微軟就不太愿意支持其他技術。那么好，一開始可能領先，但是隨著時間推移，這么長的鏈條中間一環出問題，可能會導致其他的跟著他一起被人拋棄。

微軟一方面出于商業考慮，生怕自己技術鏈中哪個環節被人替換，一方面有些接口設計充滿耦合，考慮不周，導致后面大量的主動升級和被動升級，什么 ocx, com, atl, ole，dx1-7類似的東西都可以搞出那么多來折騰人，系統內核 GUI，網絡、多媒體，大量的 API偶合在一起。最終簡單的一個 Office和 Windows一樣臃腫丑陋，這就叫缺乏美感的設計。

C#

C#是一門簡潔優雅的好語言，是微軟中比較少見有品味的設計，這是因為 C#之父 Anders就是來源于微軟之外的 Borland。Anders 早年為 Borland 設計的 Turbo Pascal 和 Delphi 就以編譯速度快，使用簡單和功能強大受到大眾的喜愛，所以在設計 C# 時融入了很多早年的審美觀。C#語言層面上勝過 java不少。我經常邊用邊罵 java到9到10了，也沒想著好好的學學 C# 的一些特性。Java 這么多年連個 get/set 都不抄一下，連個unsigned都不肯給我用用。用 C#寫代碼比 java流暢不少，但應用范圍太窄呀，我沒辦法還得接著用 java呀，應用范圍廣呀。我用 java寫的程序隨便運行在幾乎任何平臺上，大量最新的開源成果可以直接應用。可憐的C#卻被微軟畫了一個圈，死死的呆在圈里出不來。其實大家都是歡迎 C#的，不然也不會有 mono這個項目了，但 mono運行效率比 jvm低不少，比原生的 .Net運行時低很多，庫也不全，實在難以承當大任。

除了部分人專門從事 C#的工作外，現在互聯網企業，幾乎很難看得到 C#的身影：做移動應用，用原生的 java和 objc。做服務端用 C++/java/各種動態腳本，做頁面用 Js 頁游用 Flash。做PC游戲用C++/腳本，沒C#什么事情。移動游戲主要也在使用 C++/腳本（unity只是眾多游戲開發引擎中一個單例未來是否被代替未知，XNA就是個玩具）。唯一只有微軟的老本行PC桌面應用，沒錯，是C#，但是現在也面臨諸多挑戰： CEF（Chromium Embedded Framework）用js直接寫Windows本地應用，如網易云音樂用CEF效果拔群；Qt系列+腳本（越來越多互聯網公司在用，如Wps）；自己C++UI庫/腳本（例子太多了）。這些方案你或多或少都能挑出些問題來，但不可否認的是她們正從各個方向蠶食 C#的傳統地盤。你可能說C#在客戶端能做很多非 UI的事情（比數據庫和網絡還有圖像），但 CEF/Qt 這些播放點流媒體、訪問下網絡、弄下圖像或者請求下數據庫同樣很簡單。現在 GUI開發的腳本化進程正在席卷各種桌面開發方案， js等腳本運行速度越來越快，C#速度上并不能體現出數量級的優勢，而且基于泛型的腳本語言開發效率比原來高很多，同時這些解決方案全是跨平臺的。而整個進程中 C# 被排除在外了，這才是 C#真正危機的地方。

DirectX

有人奇怪我為何喜歡 OpenGL，話說白了只有一個理由，它是開放的而且它不是微軟的。如今很多人會說你看 d3d 接口不錯，兼容性高，CPU占用低而且畫面好。沒錯，但記心好點的同志們把時間拉長一點，Win95時代微軟強推 DirectX而封鎖 OpenGL很多系統調用的事情各位還記得到吧？那各位還記得到 DX才出來時爛成什么樣子么？當時業內罵聲一片，很多人看了眼接口就扔了，直到 DX5出來的時候，你稍不留神，還會把整個屏幕畫花了，或者弄死機了。當年 OpenGL領先 DX不是一個量級。直到 DX8出來了，才算完善了一些。微軟為了商業利益，把整個行業拖后了數年之久。直到2006年，很多 3A大作還是以 OpenGL為圖形底層，不鳥微軟的 D3D。

微軟的技術架構，向來不太優雅，耦合度又高。Dx7以前，DirectDraw的表面和 D3D設備還有紋理攪在一起，DSound的坐標系統又可以和 D3D的坐標系統攪在一起。大量的數據結構被定義出來，一個矢量一個矩陣還要單獨定義一下，不準我跨平臺庫用自己的定義么？你就不能用個數組么？你強大是強大，但是你耦合度實在太高了。一個環節更新，所有環節被迫更新，然后就飆版本的原因之一。DirectX的設計就是沒有品味的，如果按照簡單性和可拆分性的思路來重新考慮，Dx軟件包中，應該隔的比較開才行，能不定義的對象和結構體，盡量不定義，用C原始的類型或者數組來接口，這樣不會妨礙我外面靈活使用。然后游戲開發者靠一門膠水語言把這些獨立模塊根據需要粘合在一起，這樣的方式是不是更清爽一些呀？

開放的東西能自我適應性，自我修正。Real Networks估計很多人還沒忘記，當年的他開發的 RM / RMVB視頻格式，因為壓縮比高，同信噪比下碼率能有更低的碼率，畫面質量更好，而贏得了廣泛的支持。但是 RM / RMVB卻是一個封閉的視頻格式，雖然領先了業界數年之久，但是數年后即被開放的 H264所代替，H264雖然一開始接受度不高，但是數以萬計的人在幫他完善。學院派今天發研究出一種更有效的宏塊搜索方式，不出兩個月工程界就跟進了。今天有人發現一個運動估計的改進，明天有人實現個更低延遲的緩存管理，或者提升下錯誤恢復能力。免費的 x264不論從延遲，性能，畫質，碼率都直接秒殺很多商業公司的編碼器，ffmpeg又可以輕易的播放h.264視頻。最終 Real Networks抱著它的 rm/rmvb一起進了墳墓，死前還不忘叫一句它正在開發 rmvb2，超越 h.265標準的編碼格式，業內嗤之以鼻。視頻領域的玩法已經變了，H.264通過不斷發展，最終顛覆了RMVB的商業模式，這就是一項技術自我適應，自我修正的例子。

今天的 D3D就像當年的 RMVB，就算他用商業手段狠狠惡心了 OpenGL一把，導致后面 OGL數年發展不順，但是老話說得好：理勝力為常，力勝理為變；一時之強弱在力，千古之勝負在理。隨著 OpenGL新標準的不斷完善，雖然暫時不能徹底拋棄 DX，但封閉的 Dx必然會隨著微軟 Windows 逐漸邊緣化，這就叫得道多助失道寡助。

全世界玩一套，微軟自己玩一套

還是因為微軟最初的戰略沒有改變，導致全世界一套，微軟自己玩一套；微軟看不起開源界，開源界也不理微軟。再次強調，并不是只有開源才好，而是這么多家公司里，只有微軟一家試圖自己從頭到尾建立一套完整的技術體系，只有微軟一家采取如此封閉的策略。然而早年微軟可以罩住整條產業鏈，并且活的很爽，但是現在大量基于開源界的最新成果都和微軟技術棧水土不服。

所以開發者會面臨：依賴微軟和不依賴微軟兩種選擇。依賴微軟，很容易和外界形成隔離。而不依賴微軟，你得到的是滿天下的選擇。前者強調高度集成統一，后者強調可拆分替換。然而，世界潮流，浩浩蕩蕩，順之者昌逆之者亡。

成也蕭何，敗也蕭何

早年的微軟，象一個潛伏在叢林里的獵手，利用自己操作系統的優勢地位，尋找著產業鏈最高端的用戶需求。一旦一項技術可以滿足用戶某種根本需要，微軟就不惜犧牲眼前的現金流，來換取未來的行業領導地位和盈利。或快速收購，或惡意打壓，或自家出一套，任何一個領域只要有新的東西出現，微軟就試圖去控制它，并綁架獲出錢養活接受了微軟標準的軟件開發商讓他們支持，出錢扶持低端的開發者讓他們學習微軟標準，于是巨大的利潤，隨之而來。

這樣的戰略，使微軟茁壯成長，并成為接二連三的行業標準擁有者。然而這樣的戰略有一個致命的BUG，就是標準必須是與時俱進的，微軟需要不斷調整已有標準，否則越來越多的標準就會成為束縛住微軟的一條條繩索，越來越多的兼容性問題象一座座大山一樣壓得微軟喘不過氣來。掌握的標準越多，微軟越難改變，隨著時間的推移，將會被微軟體系外更加迎合用戶偏好的競爭者們所取代。

有人說：“微軟錯過了移動化浪潮，錯過了云計算，是因為鮑爾默的誤判。智者千慮必有一失，再牛逼的人也有判斷失誤的地方”。但是通過上面的分析，我們可以看出這種說法的荒謬性，我們需要清醒的指出，就算沒有鮑爾默，微軟即便趕上了云計算，他也會錯過霧計算；他即便趕上了霧計算，他照樣會錯過煙計算。

這樣的戰略，使微軟早年站到了時代的風口浪尖，又使如今的微軟，變得越來越與時代背道而馳，不是微軟不想融合，而是融合的成本越來越高。世異則事異，事異則備變，理解了微軟的核心戰略，就不難理解微軟為什么會去弄什么 xps, silverlight；理解了微軟的戰略，就能理解為何微軟的精力總是在制定新標準，而不是改進老標準了；理解了微軟戰略，就不難理解為何進入2000年以后，微軟總是昏招迭出了。

病在肌膚，還可以醫治，病在肺腑，人就危險了。沿襲了那么多年的戰略，成就了微軟和他的下游開發商，也害了微軟，讓微軟想改變都改變不了。就像一輛陸地上上裝甲車，裝甲越厚越堅固，然而現在要到水里開戰了，所有裝甲一夜之間全成了負擔，要尋求救贖，除非把自己從頭到尾全拆了才行。進入2009年后，看到當年一致支持自己標準的下游開發商們，粉粉判離微軟轉投敵營時，微軟深刻的意識到，老天已經再也不像原來一樣眷顧微軟了，這真可謂是：成也蕭何，敗也蕭何！

微軟的選擇

人什么時候會感覺到壓力？就是擁有一個東西，但是看著這個東西一天天的減少，越努力抓住他，卻又越抓流失的越快，改變意味著放棄，等待意味著死亡。在這樣的壓力下，微軟昏招迭出，這并不能怪微軟高管愚昧，也不能說微軟運氣差，而是自從步入 2000年以后，沿襲了幾十年的一家統治世界的戰略與時代變得格格不如了。早年的成功讓微軟無視各種問題，繼續靠慣性又活了15年，錯過了自我救贖的最佳時機。

核心戰略出問題，不是一朝一夕的決策對錯，很多人還不愿意承認，認為換了鮑爾默就能解決，認為開源 .Net，就能救 C#，就能救微軟，其實這是一個天真的想法。微軟戰略從頭到尾就沒變過，開源其實相當于承認先前戰略是失敗的，可它卻又沒有提出一套新的思路和新的戰略。事實上早在2000年時微軟就進入了戰略迷茫期，所以東一榔頭西一棒子，沒有重點，缺乏主題。雖然如此，還是能靠慣性繼續生存，但是自我否定之后，新戰略是什么呢？戰略層的自我否定會極大的傷害企業向心力，讓微軟在未來變得更加艱難，同時又沒有確立能夠經得住實踐驗證的新戰略，這又會使整個企業變得比原來更加迷茫。

但微軟能改變么？不能。微軟沒有辦法提出一套和原來戰略不兼容的新戰略，除非完全把自己和多年經營的生態鏈砸碎。15年前的最佳改變期被其錯過后，如今再怎么變都只能在原有戰略框架下尋求小改變，時代的巨流，象一股巨大的引力場，吸引著身軀龐大的微軟，無可奈何的掉進自己挖的坑里。

無可奈何的結局

直接送貨上門發達了，便利店就蕭條了。網上購物興起了，實體零售業也就死亡了。這就叫做 “新經濟體” 代替老經濟體。判斷一個經濟體是否衰落，看的從來不是它銀行里還有多少錢，而是看它的商業模式是不是還成立。如今的微軟，就是一個核心商業模式被顛覆了的企業。這不是開源能夠救得了的，更不是蓋茨復出能夠救得了的。

聽到微軟開源，讓我想起之前 Sun公司 Solaris開源為 Open Solaris，希望用開源來挽救自己的頹勢，沒多久它就倒閉了。如今一項根本技術，比如操作系統，已經很難被一家公司所壟斷。商業模式一旦被顛覆了，開源也不能成為救命稻草。

事物強弱變換，新舊更替，本來就是自然界的基本規律。蓋茨是一個聰明人，看到了未來的局面，知道什么叫月滿則虧，水盈則溢，在微軟最鼎盛的時候功成身退，高風亮節的做起了慈善，將最苦的差事留給了鮑爾默。所以，聰明的蓋茨也是不會復出的，所以，其實我挺同情老鮑的。

結尾故事

一開始就沒想噴微軟，我不是一個極端的人，一開始只是回答問題，建議題主用 Qt，遠離微軟的技術。但是完蛋了，一堆人上來圍攻，那我真得正兒八經的把微軟這事情說的清楚點才行了，否則我變成誤導題主了。

其實世界是歡迎微軟改變的，我們這些從小學電腦就用著盜版微軟系統的人，對微軟也還是有感情的。但是微軟這次能否迎來新生，還得看微軟自己，我們是幫不了他的。