為什麼微軟不大力支持C ，而重點支持C#，難道今後windows平台開發就告別以前的MFC那一套了？

01-04

這話說的，就彷彿開發C++程序應當用MFC一樣。。。

這哥們還活在上個世紀嗎??

如果不願意學C#,可以用QT開發,比MFC爽多了

對啊，今後windows平台開發就告別以前的MFC那一套了

MFC也還在演進啊，但是.NET是微軟對抗Java的重要戰略，C/C++開發畢竟門檻高，.NET開發門檻低，可以讓大量濫竽充數的程序員都進來寫業務代碼，而且微軟一直想發展跨平台能力，.NET也是唯一的選擇。UI設計也越來越複雜，性能要求越來越高，以後流行的會是WPF或者Qt這樣的繞過GDI層的框架。但是Win32離死還遠著呢。

有的人也不要動不動嘲諷了MFC了，人家C++程序員好歹也是身經百戰，比你們不知道高到哪去了……由於微軟在移動端失利，C#和.NET的使用領域以後只會越來越窄。

MFC都已經停止吹牛十幾年了，題主後知後覺啊

任何超過5年的大型軟體項目，如果你是開發者而且如果可能，你基本都會有想把底層代碼徹底重寫一遍的衝動的。

何況以軟體行業發展的速度而言，這根本就是必然啊。看看伺服器/web開發方面有多少種不同的語言以及多少種不同的框架……誰都別說誰了。

是的，Visual Studio 2015 安裝的時候，如果不選「自定義」的話， Visual C++都不會默認安裝。

誰跟你說MFC是C了

關於這個問題， Joel on Software 十幾年前就有過兩篇文章精確地描述了微軟的風格。

Fire And Motion

How Microsoft Lost the API War

文章的內容不轉了，建議每個想投身微軟開發平臺的人都仔細看看，自己評判。

只引用其中幾小段關鍵的：

Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now http://ADO.NET - All New! Are these technological imperatives? The result of an incompetent design group that needs to reinvent data access every goddamn year? (That"s probably it, actually.) But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can"t spend writing new features. Look closely at the software landscape. The companies that do well are the ones who rely least on big companies and don"t have to spend all their cycles catching up and reimplementing and fixing bugs that crop up only on Windows XP. The companies who stumble are the ones who spend too much time reading tea leaves to figure out the future direction of Microsoft. People get worried about .NET and decide to rewrite their whole architecture for .NET because they think they have to. Microsoft is shooting at you, and it"s just cover fire so that they can move forward and you can"t, because this is how the game is played, Bubby. Are you going to support Hailstorm? SOAP? RDF? Are you supporting it because your customers need it, or because someone is firing at you and you feel like you have to respond? The sales teams of the big companies understand cover fire. They go into their customers and say, "OK, you don"t have to buy from us. Buy from the best vendor. But make sure that you get a product that supports (XML / SOAP / CDE / J2EE) because otherwise you"ll be Locked In The Trunk." Then when the little companies try to sell into that account, all they hear is obedient CTOs parrotting "Do you have J2EE?" And they have to waste all their time building in J2EE even if it doesn"t really make any sales, and gives them no opportunity to distinguish themselves. It"s a checkbox feature -- you do it because you need the checkbox saying you have it, but nobody will use it or needs it. And it"s cover fire.

記住這是 2002 年寫的，現在是 2016 年，套用現在的微軟提供給開發者的技術上仍然適用。考慮微軟提供的那麼多 GUI 編寫框架， Win32API、MFC、ATL、WinForms、WPF、UWP，這些東西層出不窮。我們不得不承認這些東西的確一代比一代好用，的確有技術改進，但是仔細想想，這些東西必須革命性地拋棄老舊技術然後重新構建新技術麼？爲什麼微軟要花這麼大的精力不斷構建新技術，培養新開發者，編寫新開發環境，而不是沿用老技術然後在其上加入新功能呢？

答案很顯然，微軟希望應用程序開發者們不斷跟隨微軟的腳步，微軟有團隊有精力做這些新技術新框架，同時有另一批人做底層創新和真正的技術改進。而作爲跟隨微軟腳步的開發者們，我們沒有那麼多空閒的精力，於是必須不斷學新技術新框架，疲於跟隨，從而開發者們都止步於開發表層的應用程序而不是底層的核心技術，我們不會有精力研究存儲框架，用微軟提供的雲就好了；我們不會有精力研究佈局引擎，用微軟提供的IE/Edge核心就好了；我們不會有精力研究通訊協議，用微軟提供的WCF就好了。微軟希望開發者們都跟在他後面，這樣他就能保住他技術壟斷的地位了。

There are two opposing forces inside Microsoft, which I will refer to, somewhat tongue-in-cheek, as The Raymond Chen Campand The MSDN Magazine Camp.
Raymond Chen is a developer on the Windows team at Microsoft. He"s been there since 1992, and his weblog The Old New Thing is chock-full of detailed technical stories about why certain things are the way they are in Windows, even silly things, which turn out to have very good reasons.
The most impressive things to read on Raymond"s weblog are thestories of the incredible efforts the Windows team has made over the years to support backwards compatibility…
That"s one camp. The other camp is what I"m going to call the MSDN Magazine camp, which I will name after the developer"s magazine full of exciting articles about all the different ways you can shoot yourself in the foot by using esoteric combinations of Microsoft products in your own software. The MSDN Magazine Camp is always trying to convince you to use new and complicated external technology like COM+, MSMQ, MSDE, Microsoft Office, Internet Explorer and its components, MSXML, DirectX (the very latest version, please), Windows Media Player, and Sharepoint... Sharepoint! which nobodyhas; a veritable panoply of external dependencies each one of which is going to be a huge headache when you ship your application to a paying customer and it doesn"t work right. The technical name for this is DLL Hell. It works here: why doesn"t it work there?
The Raymond Chen Camp believes in making things easy for developers by making it easy to write once and run anywhere (well, on any Windows box). The MSDN Magazine Camp believes in making things easy for developers by giving them really powerful chunks of code which they can leverage, if they are willing to pay the price of incredibly complicated deployment and installation headaches, not to mention the huge learning curve. The Raymond Chen camp is all about consolidation. Please, don"t make things any worse, let"s just keep making what we already have still work. The MSDN Magazine Camp needs to keep churning out new gigantic pieces of technology that nobody can keep up with.
Inside Microsoft, the MSDN Magazine Camp has won the battle.
The first big win was making Visual http://Basic.NET not backwards-compatible with VB 6.0. This was literally the first time in living memory that when you bought an upgrade to a Microsoft product, your old data (i.e. the code you had written in VB6) could not be imported perfectly and silently. It was the first time a Microsoft upgrade did not respect the work that users did using the previous version of a product.
And the sky didn"t seem to fall, not inside Microsoft. VB6 developers were up in arms, but they were disappearing anyway, because most of them were corporate developers who were migrating to web development anyway. The real long term damage was hidden.
With this major victory under their belts, the MSDN Magazine Camp took over. Suddenly it was OK to change things. IIS 6.0 came out with a different threading model that broke some old applications. I was shocked to discover that our customers with Windows Server 2003 were having trouble running FogBugz. Then .NET 1.1 was not perfectly backwards compatible with 1.0. And now that the cat was out of the bag, the OS team got into the spirit and decided that instead of adding features to the Windows API, they were going to completely replace it. Instead of Win32, we are told, we should now start getting ready for WinFX: the next generation Windows API. All different. Based on .NET with managed code. XAML. Avalon. Yes, vastly superior to Win32, I admit it. But not an upgrade: a break with the past.

對於想要投身微軟開發平臺的人，Joel 在2004年做了明確的預言，事情不止於此：

Oh, Wait, There"s More Coming!

是的，微軟開發新的開發平臺的腳步永遠不會停，因爲他們的目的很明確：用完善的開發技術吸引開發者，掉入他們精心準備的蜜罐，然後只做應用程序開發，沒人再去研究底層，沒人再能和微軟競爭。

真切建議所有準備全身心投入微軟開發平臺的人看看上面兩篇文章。哦忘了說明一點，Joel on Software 的作者 Joel ，是 stack exchange （stackoverflow）的核心開發者之一，他們的網站架構直接建立在微軟的 ASP 技術棧上。

補充一點，最近微軟貌似很擁抱開源，又是 bash on windows 又是開源 CoreClr 什麼的。結合上面的背景，諸位自己想想微軟這麼做到底是爲了什麼。

==============================

EDIT

在 Joel 正經地指出微軟的問題若干年後，還有一篇用詼諧調侃的語氣描述同樣問題的文章：

A Brief History of Windows Programming Revolutions

酷殼上有中文翻譯： Windows編程革命簡史

同樣貼幾段：

首先，是 Windows API 和 DLL Hell。（譯註：DLL Hell——DLL災難，就是微軟的DLL升級時因為不同版本可能造成應用程序無法運行的災難，首當其衝的是COM編程，相信大家都知道某些木馬或是病毒更改了一些系統的DLL可以導致整個Windows不舉，這就是DLL Hell）於是，第一次革命是DDE——我們可以創建一個狀態條在上面顯示Microsoft的股票價格

在那個時候，Microsoft 創建了 VERSIONINFO 資源來管理版本信息，當然，是用來消除DLL Hell。但是，另一個微軟內部的小組發現了DDE的致命缺陷：這不是他們做的！
為了解決這個問題，他們創造了OLE（很像DDE，只是名字不一樣），而且，我還記得在一次 Microsoft 大會上，某個微軟的演講者正式宣布—— Windows API 馬上就會被 OLE API 所重寫並取代，我還盲目地相信了這一說法。而且，所有的在圖形界面的控制項都會是OCX，那是OLE引入的介面，同樣，其目的是為了消除DLL Hell。相信大家都記得，那個時候，我們是怎麼地夢想著有一天，我們的應用程序（當然是非常大的程序）可以完全地被嵌入到Word文檔中。
然而，在Microsoft的某處，Microsoft有些人開始信仰 C++，其確信MFC的出現並可以解決所有的一切問題，但是，因為歷史原因，OLE並沒有出局，其改了一個名字，叫COM，此時，我們立馬意識到OLE（以前的DDE？）真正意味著什麼——其用精心的版本管理系統來消除DLL Hell。與此同時，Microsoft的一個變節小組發現了一個MFC的致命缺陷：這不是他們做的！

在這一點上，Microsoft已經很不安地窺視著Internet好幾年了，他們終於意識到Internet上有一個致命缺陷：嗯，你應該知道這是什麼（譯註：Internet不是做他們做的！）。於是他們開始培養我們和.NET約會（.NET的發音很像「doughnut」圓環圖，不過，這只是他們的唯一不同），這和Internet很相似，只不過.NET有更多的印刷品。其讓我們清楚再清楚地了解一件事：.NET會消除DLL Hell。.NET包含了一個新的編程語言，叫C#（為了解決已經死翹翹的Active++ J++的缺陷）。.NET還包含一個虛擬機，所有的語言都運行在上面（這主要是為了解決依賴於Intel CPU的缺陷）。.NET還包含了一個單一的登錄系統（這主要是為了解決「不把口令存放在Microsoft伺服器上」的缺陷）。實際上，我們更容易做的是把.NET不包含的事給列出來。.NET絕對是一個劃時代地Windows編程革命……當然，僅到明年。

這就是你的不對了，

老一輩早就告誡過了:

MFC == 沒飯吃

微軟早就告別MFC了好不好，不過還兼容MFC的程序，所以公司還可以繼續用那些歷史代碼編的程序，新編的MFC程序也可以用，不過你不是工作需要，當然就不用學MFC了

樓主是在校大學生么？我國教材落後市場一個世紀呀！

你才知道嗎？心疼加安慰

看來題主對自己的C水平很有信心啊。

看到mfc，就想起了孫鑫。。。。還有那一集兩小時的視頻。。

M$ build大會全都是c#的。mfc是什麼？能吃么？

目前微軟在大力發展.NET，而C#(C Sharp)是微軟(Microsoft)為.NET Framework量身訂做的程序語言，C#擁有C/C++的強大功能以及Visual Basic簡易使用的特性，是第一個組件導向(Component-oriented)的程序語言，和C++與Java一樣亦為對象導向(object-oriented)程序語言。但是C#與Java有著明顯的不同,它借鑒了Delphi的一個特點,與COM(組件對象模型)是直接集成的,並且它是微軟公司.NET windows網路框架的主角。所以微軟現在在大力支持C#的發展

界面交互巴不得用html和js，反正千萬不要用win32寫

C#才是微軟親兒子

不大力支持的根本原因是C#丶F#丶http://VB.Net都是完全受微軟掌控的語言，但C++不是。這樣一來，微軟為了讓C++兼容.Net平台和uwp開發傷透了腦筋。