来源： https://news.qq.com/rain/a/20260325A04W3N00
前微软CTO、在微软效力23年的Jeffrey Snover近日发布长篇博文，系统梳理了微软过去数十年间在GUI（图形用户界面）上的反复摇摆，揭示了Windows开发生态为何走向碎片化的原因。
首先将时间线拉回1980年代，当时的Win16和Win32 API为所有Windows开发者提供了一致的开发范式，开发者只需要学一套东西，就能覆盖几乎所有Windows应用场景。
技术作者Charles Petzold撰写的《Programming Windows》长达852页，被视为桌面应用开发的圣经。
到了1990年代，微软试图用MFC、COM、OLE、ActiveX等技术突破Win32的局限性，Snover指出，这些组件架构"渗透了Windows开发的每个角落，引入了前所未有的认知复杂度"。
在开发者大会上，微软的技术叙事变得支离破碎，Snover毫不客气地将当时的主题演讲形容为"keynote clusterf*ck"。
2003年，微软展示了Windows Longhorn的技术愿景，其中Avalon（后更名为WPF）基于GPU加速的XAML矢量渲染子系统，技术实力极为强大。然而2004年8月，微软突然转向，要求所有新开发使用C++。
WPF虽然随Windows Vista发布，但Windows Shell本身并未采用它，这一决策在Windows工程团队和.NET团队之间埋下了深深的裂痕。
Snover指出，内部矛盾最终导致WPF被弃养、Silverlight死亡、UWP（通用Windows平台）一出世就注定失败。
2007年，微软在WPF已经证明自身实力的情况下，再次转向推出Silverlight。
2010年，微软突然宣布Silverlight不适用于跨平台开发，HTML5才是未来方向，Silverlight仅用于Windows Phone开发，大量押注Silverlight的开发者措手不及。
快进到2012年Windows 8发布，引入了基于原生C++的WinRT运行时，Windows团队对.NET的敌意导致后者十年的投资被瞬间抛弃。Snover这样描述当时的混乱局面：
"微软内部同时在讲两个故事，Windows团队在搞WinRT，.NET团队还在推WPF。不同的楼，不同的副总裁，不同的路线图。
开发者在//Build 2012上听到的是：未来是WinRT，同时HTML+JS是一等公民，同时.NET还能用，同时C++回来了，同时你应该写Metro应用，同时你的WPF代码跑得很好。这不是战略，这是《饥饿游戏》，六个团队在争夺你的注意力。
企业开发者看了一眼UWP的沙箱机制、强制应用商店分发以及缺失的Win32 API，转身就走。"
Snover指出，过去14年间，微软在推荐Windows GUI框架方面转向了14次，如今的Windows平台上共存着17种GUI技术，覆盖5种编程语言：
微软原生框架：Win32（1985）、MFC（1992）、WinForms（2002）、WPF（2006）、WinUI 3（2021）、MAUI（2022）
微软Web混合方案：Blazor Hybrid、WebView2
第三方方案：Electron（VS Code、Slack、Discord都在用，Snover特别指出，这是目前Windows上部署最广泛的桌面GUI技术，而微软跟它毫无关系）、Flutter（Google）、Tauri、Qt、React Native for Windows、Avalonia（JetBrains、GitHub、Unity在用，Snover讽刺这些开发者"不再等微软了"）、Uno Platform、Delphi、Java Swing/JavaFX
Snover用自创的词"boof-a-rama"来形容当前局面为聪明人在做蠢事，他强调，微软推出的技术本身往往并不差，真正杀死它们的不是技术缺陷，而是内部政治、开发者大会上过早宣布转向、以及混乱的商业战略。
Petzold的《Programming Windows》在2012年第六版（覆盖Windows 8/WinRT）之后便不再更新，或许就是对这种不可预测的碎片化最好的注脚。
Snover于1989年加入微软，历任Partner Architect、Distinguished Engineer（2009）、Technical Fellow兼首席架构师（2015）、CTO（2019），2022年离职加入Google，2025年正式退休，以他对微软内部运作模式的了解，这篇博文的可信度不言而喻。
Jeffrey Snover，自己就是微软内战的受害者。他是PowerShell的发明者，因为在微软内部坚持搞命令行工具，直接被降了职。从L69级别的Partner Architect，被踢到L68。他自己说过，高层还想把他再往下压到L67，只不过他顶住了。
先讲个插曲：为什么要降他？2000年代初的微软，从上到下都认定GUI是唯一正确的方向。Bill Gates曾经在keynote上打开command.exe，输入exit，然后说：这是你们最后一次看到它了。全场鼓掌。
这时候，Snover跑出来说「Windows需要一套强大的命令行和脚本系统」。
后来，他的上级直接告诉他：你从首席架构师的位置下来，去带你那个几个人的小组吧。经济待遇跟着一起砍。
这段经历，和他在文章里写的Windows GUI碎片化的原因，是同一个东西。
Snover在文章里梳理了三类失败原因：内部团队政治、开发者大会上的过早押注、突然的商业战略转向。
2004年，Longhorn项目彻底失败，微软不得不回炉重造。管理层事后得出的结论是：.NET托管代码害了我们。于是下了一道内部禁令------Windows里不许再用托管代码，所有新代码必须用C++。
WPF随Vista发布了，但Windows Shell自己不用它。
这个决定直接造成了持续十三年的分裂：Windows团队和.NET团队成了两个对立阵营，在不同的楼里办公，向不同的VP汇报，画不同的路线图。
Snover的PowerShell是用C#写的，跑在.NET上。他要把PowerShell放进Windows的时候，Windows负责人收到他的提案，20分钟内回了一封邮件：撤回这个请求。
Snover的程序经理回了一个字：不。
最后触发了内部正式的评审流程，最终由Windows Server那边的高管拍板，他认定PowerShell对服务器业务至关重要，才把PowerShell硬塞回了Windows。
一个后来被证明改变了整个微软云战略的基础工具（微软Office云化负责人曾当面对Snover说：「没有PowerShell，微软上不了云」），在进入Windows操作系统的过程中遭遇的阻碍，而且和WPF、Silverlight、UWP遭遇的阻碍，性质完全一样。
组织架构不允许好技术存活。
Snover发明了一个词叫「boof-a-rama」------一堆聪明人搞出来的大型混乱场面，用来形容微软在GUI策略上的表现。他有另一种说法：Conference Keynote Clusterfuck------发布会主旨演讲式灾难。
大概意思是：微软的很多技术决策，优化目标是让某个高管在台上讲出一个足够震撼的故事，而不是让开发者真正能用这个东西成功交付产品。
这一点，在座的Windows开发者可能深有体会。
- 2007年，WPF刚证明自己，微软就急着推Silverlight去对抗Flash。
- 2010年，一个高管在MIX大会的Q&A环节突然宣布Silverlight不做跨平台了，HTML5才是未来。Silverlight团队事先不知情。
- 2012年，Build大会上同时传达了六个方向：WinRT是未来、HTML+JS是一等公民、.NET仍然可用、C++回来了、去写Metro应用、你的WPF代码也没问题。
Snover在微软还有一段经历：他在一次Bill Gates的内部评审会上，因为汇报内容触怒了Gates（Gates误以为是Snover砍掉了他喜欢的贝叶斯诊断工具），被Gates指着鼻子喊「YOU FUCKED HIM」，唾沫星子飞过会议桌落在他眼镜上。会后Snover冲进卫生间趴在马桶上干呕。
在微软这样的巨型组织里，技术方向的生死从来不是由技术优劣决定的。它取决于哪个高管当天心情好不好，取决于两个VP之间在争夺什么资源，取决于某个keynote需要什么样的故事来「工程化一个Windows 95时刻」。
WPF是好的。Silverlight是好的。XAML本身也是好的。 Snover在文章里反复强调这一点。这些技术死于组织内耗，死于高管的战略反复，死于开发者被当作最后知情人。
如果微软内部的政治生态如此糟糕，那PowerShell为什么没被杀掉？
因为Snover在项目初期就写了Monad Manifesto。这份文档是一个完整的「可信成功路径」理论，讲清楚了用户是谁、问题是什么、解法为什么可行、和现有方案的区别在哪里、每个利益方能从中获得什么。
他用这份文档去敲每个产品组的门。Active Directory团队花了两周时间，写了几个cmdlet，拿给用户看，反响很好。于是Active Directory团队帮他去说服下一个团队，下一个团队再帮他说服再下一个。
当Windows高层要砍PowerShell的时候，Exchange团队站出来说：我们的多十亿美元业务押在这上面了，你不能砍。
PowerShell这才没有死于微软的内部政治。
反观那些死掉的GUI框架：WPF从未被Windows Shell采用------意味着Windows团队自身不给它背书。UWP的旗舰推广期，微软自家的Office、Visual Studio、甚至Windows Shell都没有使用它。Silverlight的方向调整，连自己的开发团队都是从大会Q&A环节才得知的。
没有内部利益绑定，没有跨组织的共识，一个技术在微软内部的预期寿命就取决于下一次组织架构调整。
Snover在文章还有一句：
你要么有一套完整、可信的成功路径理论，覆盖从采用、投入、维护到迁移的整个生命周期；要么你就只是在做一场开发者大会的主旨演讲。前者是战略，后者只是三十年的混乱循环。
这句话适用于微软的GUI策略，也适用于现在任何一家公司的技术决策。
如果你今天要在Windows上启动一个新的桌面应用项目，不要等微软给你答案。Snover自己在文章里列出的17种GUI技术中，当前Windows上部署量最大的桌面GUI框架是Electron------一个微软根本没参与创建的东西。Avalonia（开源的WPF精神续作）已经被JetBrains、GitHub Desktop、Unity这些不愿再等微软的团队采用了。Uno Platform在WinUI API的跨平台支持上，做得比微软自己还认真。
这就很讽刺，当平台方自己陷入组织混乱时，开发者的最优策略是绕过平台方。
任何一个依赖单一平台技术栈的工程师或团队，都需要清楚：自己押注的框架，平台方自己在用吗？它的推进者在组织内部有足够的政治资本吗？它覆盖了从采用到迁移的完整生命周期吗？
如果答案是否定的，那你大概率正在成为下一次「战略转向」的消耗品。
Charles Petzold为了跟上微软的步伐，写了六个版本的《Programming Windows》。2012年的第六版覆盖了Windows 8的WinRT之后，他不写了。
就像Snover说的，这事他不怪Petzold。