[轉帖]珍愛生命，遠離微軟，一點感覺源自知乎上的某人評論

http://blog.sina.com.cn/s/blog_8ba3f5130102vty7.html

小俠(2015-06-07 13:34:53)

如下來自知乎上的某人評論，除了Qt之外，其餘觀點我基本都贊同。針對Qt，爭議仍是比較大的，我的認爲像Java、Delphi、Gtk等這樣的開發語言、工具、框架都是有本身的亮點的，不管怎樣，都比微軟的強。

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

1. MFC：Win31時代出生，Win9五、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，遠離微軟的技術。可是完蛋了，一堆人上來圍攻，那我真得正兒八經的把微軟這事情說的清楚點才行了，不然我變成誤導題主了。

其實世界是歡迎微軟改變的，咱們這些從小學電腦就用着盜版微軟系統的人，對微軟也仍是有感情的。可是微軟此次可否迎來新生，還得看微軟本身，咱們是幫不了他的。