如何看待微軟將WPF, Windows Forms (winforms), 和WinUI開源？

至此構建Windows界面的三大UX框架全部開源了，會對Windows生態的開發者帶來哪些影響？

Announcing WPF, WinForms, and WinUI are going Open Source

WPF非常依賴Windows API，應該是不可能跨平台的。這次開源是 .NET Core 3.0藍圖的一部分，即把桌面框架的開發搬到 .NET Core上面來。.NET Core性能更好，迭代更快，支持xcopy部署，比較有利於WPF未來的發展。

WinUI並不算一個完整的UI框架，只能算一個高質量的UI控制項庫，方便UWP開發者做向後兼容和提高UI Accessibility，其開源屬於意料之中的事情。比較欣慰的是這次WinUI接納社區貢獻更加謹慎，應該不會像之前Community Toolkit那樣吸收太多垃圾代碼導致不太能用的情況出現。

在WPF更新Roadmap之前不好判斷其未來發展，但是WPF作為一個UI框架的技術價值是相當高的，在任何平台做UI相關深度開發的人應該都能從中學習到很多東西，開源使得其中的設計思想和實現細節可以被更多的項目借鑒，個人覺得這點才是這次開源最讓人興奮的地方。

開源是一回事，能不能跨平台又是另一回事。目前WPF的實現和操作系統里其他DirectX之類的技術結合太緊密，微軟也說了，解耦太麻煩，所以不會自己去做這些類庫的跨平台實現。對於.Net社區來說，有Xamarin在，社區對重構十幾年二十年之前的界面庫有多大興趣還是個問題。

真要是解耦解好了，Valve的Steam Play做得好的話，DirectX層可以直接拿來用，但是現在還在搞白名單，不知道什麼時候才能出Beta。要是WPF能用這個移植，WinUI也可以。

至於WinForms開源，對於其他平台來說，也就增加下mono的兼容性而已。倒是Windows上現在有bug能自己修了。但是真要是微軟常年沒修的bug，估計早有人去pinvoke自己實現了……WinForms說到底只是個GDI+的封裝。

是好事情，但是絕大多數人並不知道WPF以及Winform開源遠比這個通知早很多很多。

15年.net的源代碼就已經全部放在ReferennceSource上面了，當然這是沒有Managed C++的部分，以及Xaml部分。

WPF最強大的技術莫過於它的屬性系統，以及附加屬性這個變態的殺器。它有效的解決了許多MFC時代無法解決的問題。

將這套技術開源，其實更多的是為微軟社區添加活力，以示自己的開源決心。可以視為提升聲望的壯舉。

從公司發展層面而言，微軟半個世紀的倔強讓它知道一切靠自己的決策走，註定會產生許多挫折與失敗。回顧Lumia系列以及Silverlight大體都知道是什麼情況。特別是IE,Edge。高度強調自己主導的規則很有可能恰得其反。微軟是個公司需要更多的利潤，閉門造車可能並不受人待見，但是製作競品這對微軟而言並不難，實際上微軟的競品(除了Office)才是最具有價值的。

所以，Edge換內核，技術開源。這些只要沒影響微軟商業競爭，的確他就會這麼幹了。

在未來，主力一定是.net core，.net framework將會以桌面拓展包形式存在，和UWP提倡的一樣。屆時跨平台就已經沒有太大的問題。

有人說WPF是桌面平台技術，捆綁在Windows平台。

WPF裡面，主要是XAML Markup，WPF框架，消息系統，託管部分渲染核心，非託管部分渲染核心幾個部分組成。

其中WPF到非託管層之間的通訊使用命令封送的，解耦合程度還算比較高，只要OpenGL的Native Wrapper實現了每個命令，換個渲染器內核跑在其他平台，也是分分鐘的事情。

但是為什麼現在還沒辦法跨平台？無非就是消息循環那邊還沒很好的解耦合，和封裝。

WPF的文本渲染功能除了用DirectWrite之外還用到了WIN32 API。輸入法還有消息循環這一塊已經困在了Windows上面了。

解決了這幾個問題再把反射的功能放寬一點，XAML Standard就已經問世了。

WPF的邏輯部分與渲染部分(DirectX)是分離的，如果需要跨平台只需要寫個抽象中間層根據系統調用不同的硬體介面即可，問題在於邏輯層是怎麼寫的，只可惜雖然開源了，微軟卻在擠牙膏。

WinForms底層渲染與GDI+強制綁定，想要跨平台基本和重寫沒多大區別，mono那套就是基於GTK重新寫的。

WinUI基本上和跨平台沒關係。

所以在.net core 3.0出來之前繼續觀望即可。

WinForms看成是GDI,GDI+ 的封裝， 這個做平台適配的工作很早mono有跨平台實踐過。

WPF看成是對DirectX的封裝，這個跨平台換成OpenGL 不是不可能的，交給社區來做更好的實現。

關於UWP沒有了解過底層的封裝細節。

你要知道一個地方編譯多處運行就一定要有人干適配多平台的活， Java醜陋無比的UI下面也是做了多平台的適配工作。他們在一開始設計目標就是多平台多Api適配所以很多漂亮的效果要做出來幾乎是不可能的（比如WPF的視覺效果）。

設計本身就是對需求的取捨，對當下與未來的取捨。

歷史包袱這件事情，如果官方出來支持就必須背， 如果是社區支持就可以扔。

我就想知道先跨到linux的ui會是xamarin還是wpf，我是說比較正式的支持

然後看誰才是親兒子，如果微軟親自把wpf跨平台了那麼肯定就是親兒子無疑了

能不能將silverlight也開源？oob的sl本身天然的已經是一個跨平台的gui解決方案。而且精緻小巧，純非同步設計，配合現在core的加成簡直完美。

我看著很簡單，就是想把 wpf 等桌面程序 也可以跨平台

微軟: 我微軟開源和你寫不寫得出優秀代碼有什麼關係。

微軟還在搞Windows原生桌面開發啊！之前聽說Office都要用Javascript + HTML之流重寫UI了。

Java Swing, Java SWT, Gtk, Qt, 這條路上屍橫遍野，以後還是看Google的Flutter能否逆襲

要不回去搞MFC, VCL，Lazarus吧，老歸老，打包後體積小，運行快，佔用資源少。

用Direct2D替換GDI+，WinForm還能再戰30年。

WPF就是個帶硬體加速繪製的超高速渣渣。

看來是Github把微軟收購了，Github收購了微軟之後，為了穩固自己的市場，把微軟裡面的東西源代碼都放出來了，再接再厲，下次把windows，office的一起放出來，這樣國產操作系統就有望了！

說正經的，結合今天發布.net core 3.0預覽版，微軟的戰略很明確，.net core 3.0支持winform，wpf，但是僅限windows平台，linux兼容winform，wpf，微軟感覺力不從心，就乾脆開源出來，等社區去做winform，wpf對linux的支持，這樣.net core 4.0的時候也許就能藉助社區的力量補完這最後一塊拼圖，.net core從此變成真正的全功能跨平台的.net framework,.net framework就此退出歷史舞台。

補充一下，其實這三者裡面最有價值的應該是WPF，WPF那一套mvvm思想，前端三大框架都是在此基礎上發展出來的，xaml寫UI是真的爽。

更新1212：

評論區很多討論winform，wpf到linux平台的移植性，繼承wpf遺志的Xamarin forms目前能夠跨ios，Android，uwp，macos，wpf(beta)，而xamarin的前身是mono，mono很早就實現了.net framework程序在linux上運行，而xamarin又被微軟收購了，所以winform，wpf上linux只要微軟願意，移植起來的難度並不大。但是微軟雖然說Love Linux，但是心底里是不希望linux桌面崛起的，這樣會蠶食windows的市場，這就是為社么office沒有linux版的原因，說到底，無論是微軟，還是谷歌，開源其實都是為了自己盈利的，不可能去斷自己的財路。哪天windows被砍了，那麼這些linux缺失的東西就會發布了，我甚至覺得微軟已經做出來了，只是沒有發布而已。

完了， @vczh 的GacUI徹底涼了（逃

昨晚的 Connect();2018 看了半截兒，一上來就是 VS CODE 巴拉巴拉巴拉，個人興趣不是那麼大，看這次的主題，基本都是 AI, Cloud，VSCODE 之類的。完全沒有 Windows 的字眼兒。現在的微軟真的不是以前的那個 Windows的微軟了，包括之前 Windows10 1809幾次嚴重BUG和推遲發布就可以看出來....

作為一名 UWP 為主的開發者，看到開源我竟然感覺有一點點不高興...不過估計以後遇上BUG可以看源代碼了吧！

_________

需要改改，感覺開源也不是壞事兒，似乎微軟要在.net core的基礎下，構建一個大而統一的 UI 開發框架，本質上也是希望開發者跟進.net core

刪除原答案。

鑒於輪子哥關注了超越的問題，我今天義務吹捧一下win系的技術棧！

和新興的前端技術，尤其是以js為主力的web UI技術棧相比，winform應該是要擁有性能優勢的。據我所知的一些大型UI項目，受限制於高刷新要求和巨大的數據展示壓力，winform仍然是優先的選擇。人眼的自然刷新是10HZ左右，為了實時展示數據，某些系統要求刷新必須達到15HZ，且延時低於5ns，我了解到該系統選擇了winform作為技術棧.

WPF的設計思路很先進，MVVM也是良好的程序設計規範。當然，WPF對CPU和內存的壓力仍然偏大，不過用來製作一般的windows程序還是合格的。

WinUI沒用過，不過一般的windows觸摸屏體驗實在太差，UWP的應用用起來會好一些。

輪子哥點贊了，更新一波winfrom 和 WPF能做到而Web UI迄今為止（2018年底）都完全做不到的事情：chrome的內存佔用限制是4G，如果你的前端頁面內存佔用超過2.5G，你的chrome表現會下降。如果內存佔用超過4G你的應用就GG。 不要說前端用不了那麼多內存，我見過被這個問題折磨的死去活來的項目，是一個web based 可視化IDE，讀取邏輯圖之後內存應用就飆升到2.5G，複雜的邏輯繪圖內存輕鬆過4G然後完蛋。。。。當然後來他們組優化了邏輯系統能用了，我並不知道是怎麼優化的，但是這個卡死的問題折磨了一堆人大半年。

對於有前端開發需求的人來說，了解一下winform，WPF，還是能豐富自己的計算機發展史知識，為自己未來學好用好react，打下基礎，也能培養自己從不同角度看前端開發的能力。

最後，身為村民希望為超越妹妹打一個廣告！感謝大家觀看。

www.bilibili.com

不是學計算機的。

大學入門學的VB，用WinForms ,後來畢業自己學編程從WPF入手，中間還學了QT，想自己做點iOS和Mac的APP就又學了Cocoa，同學找我幫忙做網站又看了幾天HTML和JS搞起了React

感覺啥UI的框架都沒學精通，哎。。。。。。

看了WPF代碼，目前開源的東西還不如去看微軟放的參考源代碼。

託管部分，開放了，有興趣的底層渲染部分，還是沒有的。

比如 MilCore DirectX Render 等部分，因為開放的目的是為NET CORE 3.0 做配套，所以可能有捨棄或者走另一種實現。

ReactOS 和 Wine 社區也許會受益。

相當於正式宣判WPF的死刑了……

「以後WPF再有什麼bug我們就不管了，交給你們社區處理了」（逃