Windows桌面GUI开发介绍
2023-08-17 15:07:58 
阿炯
在桌面软件开发领域，有多种流行的框架可供选择。继《Linux桌面GUI开发介绍》，本文将介绍在Windows下基于 Electron、Qt、WPF 和 WinForms 这四种框架开发的桌面软件，探讨它们的特点、优势和适用场景，帮助开发者更好地选择适合自己项目的框架。其中Electron与QT均为跨平台的解决方案，适用于多个操作系统平台，尤其是前者，借助于浏览器内核能运行在几乎所有的操作系统下。一、Electron
Electron 是一个基于 Web 技术的跨平台桌面应用程序开发框架。它使用 HTML、CSS 和 JavaScript 来构建应用程序界面，并借助 Chromium 渲染引擎提供强大的页面渲染能力。微软对这项技术口头上到没有说太多，但身体却是很实诚。
特点包括：
跨平台：Electron 可以在 Windows、macOS 和 Linux 等多个主流操作系统上运行，为开发者提供了广泛的目标平台选择。
Web 技术栈：Electron 使用 Web 技术栈进行开发，开发者可以利用熟悉的前端工具和框架来构建应用程序界面。
大量的开发者社区和资源：由于 Electron 的流行和活跃的社区，开发者可以轻松获得丰富的插件、工具和文档资源。
适用场景：Electron 适用于构建跨平台、具有丰富界面和多媒体功能的桌面应用程序，如通讯工具、编辑器和音乐播放器等。2023年年中改版后的QQ就是基于其所构建的，桌面版本的微信亦是如此。
二、Qt
Qt 是一个跨平台的 C++ 应用程序开发框架，被广泛应用于桌面软件开发。
特点包括：
跨平台：可以在多个主流操作系统上运行，并且提供了一致的 API 接口，使得开发者可以轻松实现跨平台的应用程序。
强大的 GUI 组件和工具：提供了丰富的 GUI 组件和工具，开发者可以快速构建具有吸引力和交互性的用户界面。
高性能和可扩展性：通过 C++ 的底层支持，提供了高性能和可扩展性，适用于开发复杂的桌面应用程序。
适用场景：适用于构建要求高性能、可扩展性和定制性的桌面应用程序，如图形设计工具、CAD 软件和游戏编辑器等。当然最为成功的当数KDE桌面环境了。
三、WPF（Windows Presentation Foundation）
WPF 是微软提供的用于开发 Windows 平台的桌面应用程序的框架。
特点包括：
强大的数据绑定和样式系统：WPF 提供了强大的数据绑定和样式系统，使开发者能够轻松实现复杂的数据展示和界面定制。
XAML 定义界面：WPF 使用 XAML（可扩展应用程序标记语言）来定义用户界面，使界面设计与代码逻辑分离，提高开发效率。
内置的动画和多媒体支持：WPF 内置了丰富的动画和多媒体支持，使得开发者可以轻松实现交互式和视觉吸引力的应用程序。
适用场景：WPF 适用于开发要求丰富、具有复杂数据展示和交互的 Windows 平台应用程序，如企业级数据管理系统、可视化工具和教育软件等。
四、WinForms
WinForms 是微软提供的用于开发 Windows 平台的桌面应用程序的框架，使用 C# 或 Visual Basic.NET 进行开发。
特点包括：
快速开发：提供了丰富的预定义控件和事件模型，使开发者能够快速构建 Windows 应用程序，并通过可视化设计工具进行界面布局。
简单易学：使用 C# 或 VB.NET 进行开发，结合直观的设计工具，使得初学者能够轻松上手并快速开发应用程序。
良好的兼容性：应用程序可以充分利用已有的 Windows 平台资源和功能，并与其他 .NET 技术集成。
适用场景：适用于需要快速开发简单界面和利用现有 Windows 平台资源的应用程序，如内部工具、小型业务应用和个人应用。
小结：以上介绍了基于 Electron、Qt、WPF 和 WinForms 开发的桌面软件的特点和适用场景。Electron 适合跨平台的 Web 技术栈应用程序，Qt 适用于高性能和可扩展性要求的应用程序，WPF 适用于复杂的 Windows 平台应用程序，而 WinForms 适合快速开发简单界面的应用程序。开发者可以根据自己的需求和技术栈选择合适的框架，以提高开发效率和应用程序质量。
作为一名Windows桌面开发者是否曾困惑过：微软到底有多少个UI框架？Win32、MFC、WinForms、WPF、UWP、WinUI……这些名词让人眼花缭乱。在此来简单梳理一下Windows UI框架的发展历程。
回顾Windows桌面开发的历史，其UI框架可大致划分为三个阶段：
第一代：原生时代 — Win32 / MFC
Win32 API 是Windows最底层的界面编程接口，直接与操作系统对话。用Win32开发桌面应用，需要手动处理窗口消息（WM_PAINT、WM_CLOSE等），管理句柄和资源。优点是性能极高、控制力强，但缺点是开发效率低，即便是创建一个按钮也需要几十行代码。
MFC（Microsoft Foundation Classes） 是对Win32的C++封装，将窗口、控件等抽象为C++类，简化了开发流程。在90年代到2000年代初，MFC曾是Windows桌面开发的主流选择。但由于其依赖C++的复杂性和历史遗留问题，如今已逐渐退出舞台。
特点：底层、高性能、开发效率低、现代开发中较少使用。
第二代：托管时代 — WinForms / WPF
随着.NET Framework的推出，微软带来了两款重磅的托管UI框架：
WinForms 于2002年随.NET Framework 1.0发布。它采用“所见即所得”的设计理念，拖拽式开发极为直观，代码简单易懂。对于传统的业务系统开发（如进销存、ERP），WinForms至今仍有大量应用。
WPF（Windows Presentation Foundation）于2006年发布，带来了革命性的变化：采用XAML声明式UI、矢量图形、数据绑定、MVVM模式。WPF让界面与逻辑分离，实现了真正的“UI与代码解耦”。目前仍有大量企业级应用运行在WPF之上。
特点：托管代码、开发效率高、生态成熟、WPF适合复杂界面开发。
第三代：现代时代 — WinRT / UWP / WinUI
WinRT（Windows Runtime）随Windows 8推出，为触摸屏和Metro风格而生，引入了一种新的应用模型和API设计。
UWP（Universal Windows Platform）是WinRT的进化版，口号是“一次开发，多端运行”（PC、Xbox、HoloLens等）。UWP支持现代UI特性（如亚克力效果、流畅动画），但由于应用分发必须通过Microsoft Store，且API受限，开发者接受度不高。
WinUI 3 是微软最新的原生UI框架，可以看作是UWP的“解绑版”——它将UWP的现代UI控件库独立出来，不再强制要求通过Store分发，允许开发者使用完整的Windows API。是微软目前唯一重点投入的桌面UI框架。
特点：现代UI、完全原生、无分发限制、微软当前可能的主力方向。
Windows常用运行库(DirectX、VC++、Net Framework等)
Windows 操作系统上有许多常用的运行库（Runtime Libraries），它们用于支持应用程序运行所必需的文件和组件，是其可以正常运行的基础依赖。微软常用运行库是一组由微软开发的动态链接库（DynamicLinkLibrary），包含了一系列用于支持应用程序正常运行所需的函数和资源；这些运行库可被不同的应用程序共享使用，从而减小了软件的体积，并提供了更好的兼容性和稳定性。用户在安装某些微软产品或服务时，这些运行库往往会被自动安装在计算机上。以下是一些常见的 Windows 运行库：
1.Microsoft Visual C++ Redistributable：这是一组由 Microsoft 提供的 C++ 运行库，它们是许多应用程序和游戏所依赖的基本组件。不同的应用程序可能需要不同版本的 Visual C++ Redistributable。它包含了许多由C++编写的函数和资源，为应用程序提供了必要的支持。
2..NET Framework：它是 Microsoft 开发的一个应用程序开发平台框架，它包含了一系列库和组件，用于开发和运行 Windows 应用程序；使用了一种称为公共语言运行时（CommonLanguageRuntime）的虚拟机来执行应用程序。不同的 Windows 版本可能预装了不同版本的 .NET Framework。
3.DirectX：是 Microsoft 开发的多媒体和图形库，用于支持游戏和多媒体应用程序的图形和音频功能。该运行库是用于支持图形和多媒体应用程序的常用运行库，它提供了一组API（应用程序接口），用于控制图形、声音和输入设备等硬件资源。许多游戏和图形应用程序都依赖于DirectX运行库以实现高性能和多媒体效果。不同的 Windows 版本可能预装了不同版本的 DirectX。
4.Windows Installer：其是 Windows 上的一个安装和卸载服务，它允许应用程序以一致和可管理的方式进行安装和卸载。这是许多应用程序安装所必需的组件。
5.Windows PowerShell：是一个强大的命令行工具和脚本语言，用于自动化和管理 Windows 系统任务。它通常包括在 Windows 操作系统中。
6.Microsoft Silverlight：Silverlight 是一种用于开发富互联网应用程序的框架，它可以在多种浏览器上运行。虽然 Silverlight 的使用逐渐减少，但某些旧应用程序可能仍然需要它。
7.Microsoft Data Access Components (MDAC)：MDAC 是用于数据库访问和数据连接的组件集合，用于支持应用程序与各种数据库之间的交互。
运行库就是支持大部分程序运行的基础，由于很多常用软件都是采用 Microsoft Visual Studio 编写的，所以这类软件的运行需要依赖微软Visual C++运行库，比如像 QQ、迅雷、Adobe 软件等等，如果没有安装VC++运行库或者安装的版本不完整，就可能会导致这些软件启动时报错，提示缺少库文件。
微软常用运行库在支持微软产品和服务的正常运行方面起着关键的作用。没有这些运行库，许多应用程序将无法正常启动或运行，并可能出现各种错误和异常。因此用户在安装微软产品或服务时，需要注意安装相应版本的运行库，以确保其正常运行。此外微软常用运行库还具有以下重要特点：
1.共享性：多个应用程序可以共享同一个运行库，减小了软件的体积，节省了存储空间。
2.兼容性：微软常用运行库经过严格测试和验证，可以确保在不同的操作系统和硬件平台上正常工作。
3.稳定性：微软常用运行库提供了一致的接口和功能，减少了应用程序的错误和崩溃的可能性。
4.更新和升级：微软定期发布更新版本的运行库，修复了一些已知的问题和漏洞，并提供了一些新的功能和改进。
微软常用运行库的使用注意事项
用户在安装和使用微软常用运行库时，需要注意以下事项：
1.版本匹配：不同的应用程序可能需要依赖不同版本的运行库，用户在安装应用程序时应确保安装正确版本的运行库。
2.安全性：由于运行库是共享的，安装和使用时要确保下载源可靠，并及时更新运行库以修复一些已知的安全漏洞。
3.清理和维护：定期清理不再需要的运行库，可以释放存储空间并提高系统的性能。
综上所述，微软常用运行库是支持微软产品和服务正常运行的重要组成部分。它们的共享性、兼容性和稳定性为用户提供了良好的使用体验。
Windows.h
Windows.h 是 Windows 操作系统中的一个关键头文件，它包含了用于创建和管理窗口应用程序所需的各种函数、数据类型和宏定义；这个头文件是 Windows API（应用程序编程接口）的一部分，为开发者提供了与 Windows 操作系统交互的接口。
主要功能
窗口创建和管理：Window.h 提供了创建和管理窗口的函数，如CreateWindow和DestroyWindow。
消息处理：它包含了处理窗口消息的函数和数据结构，如WndProc 和MSG结构体。
事件处理：提供了注册和处理系统事件的函数，如RegisterClass和DispatchMessage。
资源管理：包含了加载和管理资源（如图标、光标、菜单等）的函数。
绘图和图形：提供了绘制图形和文本的函数，如BeginPaint和EndPaint。
主要数据结构和函数
WNDCLASS 结构体：定义窗口类的属性，包括窗口过程、类名、背景画刷等。
MSG 结构体：包含窗口消息的信息，如消息类型、参数等。
CreateWindow 函数：创建一个窗口实例。
DestroyWindow 函数：销毁一个窗口实例。
RegisterClass 函数：注册一个窗口类。
UnregisterClass 函数：注销一个窗口类。
DispatchMessage 函数：将消息分发到窗口过程进行处理。
DefWindowProc 函数：提供默认的窗口消息处理。
示例代码
以下是一个简单的 Windows 应用程序示例，展示了如何使用 Window.h 创建一个窗口：
#include <windows.h>
// 窗口过程函数
LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam) {
switch (msg) {
case WM_DESTROY:
PostQuitMessage(0);
break;
default:
return DefWindowProc(hwnd, msg, wParam, lParam);
}
return 0;
}
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) {
// 注册窗口类
WNDCLASS wc = {0};
wc.lpfnWndProc = WndProc;
wc.hInstance = hInstance;
wc.lpszClassName = "MyWindowClass";
RegisterClass(&wc);
// 创建窗口
HWND hwnd = CreateWindow("MyWindowClass", "My Window", WS_OVERLAPPEDWINDOW,
CW_USEDEFAULT, CW_USEDEFAULT, 640, 480, NULL, NULL, hInstance, NULL);
if (!hwnd) {
return 0;
}
// 显示窗口
ShowWindow(hwnd, nCmdShow);
UpdateWindow(hwnd);
// 消息循环
MSG msg;
while (GetMessage(&msg, NULL, 0, 0)) {
TranslateMessage(&msg);
DispatchMessage(&msg);
}
return (int)msg.wParam;
}
Windows.h 是 Windows 编程中的核心头文件之一，它为开发者提供了创建和管理窗口应用程序所需的所有工具。通过理解和使用这个头文件中的函数和数据结构，开发者可以构建功能丰富、交互性强的 Windows 应用程序。无论是初学者还是有经验的开发者，掌握 Windows.h 都是进行 Windows 编程的关键一步。
Windows.h包含了最重要的Windows头文件，这些头文件的某些也包含了其他头文件，其中最重要的和最基本的是：
Windef.h 基本数据类型定义。
Winnt.h 支持Unicode的类型定义。
Winbase.h Kernel(内核)函数。
Winuser.h 用户界面函数。
Wingdi.h 图形设备接口函数。
这些头文件定义了Windows的所有资料型态、函数调用、资料结构和常数识别字，是Windows文件中的一个重要部分。
前微软高管痛批Win1x图形框架混乱：14年14次转向
2026年3月消息，前微软首席技术官 Jeffrey Snover 于3月中旬发布长文详细剖析了 Windows 图形用户界面（GUI）策略的混乱现状。
他直言，微软长期缺乏连贯的开发者指引，导致当前的 Windows 技术栈严重碎片化。Snover 将这种局面戏称为“聪明人做傻事”，认为这不仅让开发者无所适从，也严重损害了 Windows 生态的健康发展。他在回顾历史时指出，1980 年代的 Win32 API 曾为开发者提供了统一的标准。然而自 2003 年展示 WPF（最初名为 Avalon）以来，微软的 GUI 策略便开始偏离正轨。
由于 Windows 工程团队与.NET 团队之间存在严重分歧，内部斗争导致 WPF 最终被边缘化，随后的 Silverlight 和通用 Windows 平台（UWP）也接连遭遇失败。在过去 14 年里，微软在 GUI 框架的官方推荐上竟然转向了 14 次。从 WinRT、HTML5 到 Project Reunion 和 WinUI 3，不同部门各自为战，向开发者传递着相互矛盾的信息。
Snover 强调这种朝令夕改的做法并非战略，而是一场消耗开发者信任的“饥饿游戏”，迫使众多企业级开发者彻底放弃了 UWP 等现代框架。持续的内部消耗最终酿成了苦果。Windows 系统内目前共混杂着由 5 种编程语言驱动的 17 种不同 GUI 技术。令人讽刺的是，当前 Windows 平台上部署最广泛的桌面 GUI 技术并非出自微软之手，而是第三方的 Electron 框架。
作为在微软效力 23 年的资深高管，Snover 认为微软推出的技术本身往往非常出色。这些技术之所以走向消亡，根本原因在于内部倾轧、开发者大会上的仓促表态以及令人费解的商业策略。这种不可预测的碎片化趋势，正是导致众多经典 Windows 开发指南最终停更的核心原因。
公开资料显示，Jeffrey Snover 是一位在微软工作长达 20 多年的传奇技术领袖，也是 PowerShell（早期代号为 Monad）的发明者。
微软在 2000 年代初内部极度推崇图形界面（GUI），Snover 却坚持 Windows 需要强大的命令行工具来实现自动化管理。为了能够专注于 PowerShell 的开发，他甚至接受了从资深职位“降级”的待遇，这一转折后来成为科技圈坚持技术愿景的佳话。他在 1999 年加入微软，先后担任过多个核心高管及架构师职位：
1. Technical Fellow（技术院士）：2015 年晋升为微软最高级别的技术头衔。
2. Windows Server 首席架构师：主导了 Windows Server 的管理技术方向。
3. Azure 相关职务：曾任 Azure 存储与云边缘组（Azure Storage & Cloud Edge）首席架构师。
4. M365 首席技术官：在离开微软前，他担任 Microsoft 365 现代劳动力转型 (MWT) 的 CTO 及其 AI 架构师。
Windows GUI混局：14次转向、17条路线，一群聪明人做出了愚蠢的决定
如果你曾在 Windows 平台上做过开发，大概率都经历过类似的困惑：框架很多，路线各异，但就是没有一个“明确答案”。这些年，从 Win32 到 WPF，从 Silverlight 到 UWP，再到2026年的 WinUI 和 MAUI，技术一轮轮更迭，方向却始终摇摆不定。
这其中究竟是微软的技术战略问题，还是另有隐情？
2026年3月，前微软技术研究员、Office AI 架构师 Jeffrey Snover 带来了一篇长文，以亲历者的视角，把过去三十多年 Windows GUI 技术演进中的关键节点一一拆开，讲清楚问题是如何一步步积累、失控，并最终演变成今天这个“百花齐放却无所适从”的局面。他直言，很多技术的兴衰，并非源自技术本身，而是内部团队的权力博弈、开发者大会上对尚未成熟平台的过早押注，或者一次突如其来的商业战略转向，把开发者直接“晾在一边”。让开发者在十四年间的十四次转向，提供了 17 种路径、五种编程语言、三种渲染思路，这样的局面，就是一群聪明人，做出了愚蠢的决定。
作者 | Jeffrey Snover 责编 | 苏宓
出品 | CSDN（ID：CSDNnews）
几年前我参加了一场开发者会议。有人抛出了一个看似再简单不过的问题：“如果要做一个新的 Windows 桌面应用，应该选哪个框架？”
现场一片沉默。过了好一会，才有人提了 WPF，另一个人说用 WinUI 3，还有人反问要不要干脆用 Electron。争论之下，讨论的话题很快就跑偏了，直到最后这个问题也没能得到答案。
事实上，这段沉默，本身就是答案。而这个问题的根源，可以追溯到三十多年前。当一个平台连“我该怎么做 UI”这种问题都无法在十秒内给出清晰答案时，它其实已经辜负了开发者。没有任何借口。
1、Windows 上一次给出明确答案是什么时候？
1988 年，Charles Petzold 出版了《Programming Windows》。全书 852 页，用 C 语言讲解 Win16 API。尽管内容厚重，但它代表了一件极其难得的事情：关于“如何开发 Windows 应用”，它给出了一个统一、清晰且权威的答案。
在业内将这种情况称之为“策略”。随后出现的 Win32 体系更庞大，但依然保持一致性：消息循环、窗口过程、GDI。虽然当时它的思维模型多少有点古怪，但终归只有这一套模型。Petzold 把它讲清楚了。这就像 Windows 世界里的“F=ma”公式：简单、强大。你学会它，用它，就能做出想要的成果。
清晰明了就是最好的情况！一个操作系统、一套 API、一种语言、一本书。没有人争论托管代码的替代方案，没有委员会反复拉扯。只有 Win32 和 Petzold，而且它确实奏效。这更像“物理学”，而不是“化学”——不是那种“在特定元素周期表的一小块区域才成立、还得满足特定压力、温度，甚至月亮位置都要刚好”的复杂体系。
接下来发生的事情，可以说是一堂典型案例：一家拥有顶尖人才和雄厚资源的公司，是如何在三十年时间里，因为优化错了方向，搞出一连串混乱局面的。换言之，就是一群聪明人做出了愚蠢的决定。
2、面向对象的狂热幻象（1992–2000）
Win32 确实存在不少局限，于是微软做了它一贯会做的事：在开发者大会上推出“新东西”。而且不是一个，是一堆。
MFC（1992）用 C++ 封装了 Win32。如果说 Win32 已经不够优雅，那 MFC 就像是给 Win32 穿了一件由更多“西装”拼出来的西装——复杂到有点滑稽。
随后出现了 OLE、COM、ActiveX。这些东西本质上都不是 GUI 框架，而是组件模型，但它们渗透进了 Windows 开发的每一个角落，引入了一种认知复杂度。
我至今记得自己在 90 年代末参加过一场会议，整整一个小时都在试图搞清楚 OLE 文档、COM 对象和 ActiveX 控件之间的区别。那一整场，我看着台上的讲者，感觉就像他嘴里挂着一截老鼠尾巴——完全无法理解他在说什么。
微软当时并没有提供一个连贯的整体叙事，它只是不断推出各种技术“零件”，然后让开发者自己去拼出一套体系。这就是典型的“发布会主旨演讲灾难”——微软优化的是高管在台上如何讲得让人惊艳，而不是开发者和用户最终能不能真正成功。
3、PDC 2003：一个自我吞噬的愿景
在 2003 年的 PDC 大会上，微软发布了 Longhorn——可以说，这是它曾经向开发者展示过的最具吸引力的技术愿景之一。
Longhorn 由三大支柱构成：
WinFS（关系型文件系统）
Indigo（统一通信框架
Avalon，后来演变为 WPF——一个基于 GPU 加速、矢量化的 UI 子系统，由名为 XAML 的声明式 XML 语言驱动。开发者看到 Avalon 的演示几乎沸腾，这个方向本身没有问题。但用 Jim Allchin 在 2004 年 1 月内部备忘录中的话来说，这个项目“就是一头猪”。
到了 2004 年 8 月，微软宣布全面重置开发：推倒重来，从 Server 2003 的代码库重新起步。重置之后，管理层还下达了一条几乎没有公开的指令：Windows 中禁止使用任何托管代码。所有新代码一律使用 C++。WPF 最终会随 Vista 发布，但 Windows 自身的外壳却不会使用它。
Windows 团队对 .NET 的怨气，从此再也没有消散。
在他们看来，押注一个全新的托管代码框架，直接导致了公司历史上最尴尬的一次失败。这种情绪演变成了一场持续了十三年的“体制内内战”：Windows 团队对抗 .NET 团队。最终的结果是——WPF 被边缘化，Silverlight 被放弃，UWP 走向失败，也造就了今天这个一团乱麻的 Windows GUI 生态。
4、Silverlight：模式就此形成（2007–2010）
WPF 在 2006 年末正式发布。它相当惊艳——XAML、硬件加速渲染、真正可用的数据绑定。如果当时微软把它确立为“唯一答案”，并持续坚定投入，后面的故事也许会完全不同。
但 2007 年，微软推出了 Silverlight：一个精简版的浏览器插件，用来对抗 Flash。它跨平台、优雅，同时还是 Windows Phone 的技术基础。大约在 2010 年前后，它看起来像是富客户端的未来。
然而在 MIX 2010 的一次问答环节中，一位微软高管却表示：Silverlight 并不是一个跨平台战略，它的重点在 Windows Phone。HTML5 才是新的方向。而 Silverlight 团队事先对此毫不知情。那些把核心业务应用押在 Silverlight 上的开发者，也是通过这场现场问答才第一次听说这件事。
Silverlight 并不是死于技术失败。技术本身没有问题。它死于一次商业战略决策，而开发者是最后才知道的人。记住这个模式，后面还会反复出现。
5、Metro 的焦虑与“两条战线”的内耗（2012）
当时，Apple 已经卖出了 2 亿部 iPhone，iPad 也在蚕食 PC 市场。微软的回应是 Windows 8 和 Metro——一个以触控优先为核心的运行时 WinRT，而且刻意不基于 .NET 构建。
还记得 Windows 团队对 .NET 的怨气吗？这里就是它的体现：WinRT 是一个原生 C++ 运行时，直接与 WPF、WinForms，以及开发者过去十年在 .NET 上的投入切割开来。
更混乱的是，当时微软内部其实同时在讲两套完全不同的故事：Windows 团队在推进 WinRT，而 .NET 团队还在继续推广 WPF。不同的办公楼、不同的副总裁、不同的路线图。
开发者在 2012 年的 Build 开发者大会上听到的是什么？未来属于 WinRT，同时 HTML + JS 是一等公民，同时 .NET 仍然可用，同时 C++ 强势回归，同时你应该写 Metro 应用，同时你的 WPF 代码也还能正常运行。
这根本不是什么战略，而是一场“饥饿游戏”的竞技场——六支队伍同时在争夺你的注意力。
企业开发者很快做出了选择：他们看了一眼 UWP 的沙盒限制、必须通过应用商店分发的要求，以及缺失的 Win32 API，然后转身离开。
这个本该带他们进入“现代应用时代”的框架，实际上却是为一个从未真正成立的平板应用商店而设计的。
UWP 与 WinUI 的蔓延（2015–至今）
Windows 10 带来了 UWP（Universal Windows Platform）：一次编写，多端运行，覆盖 PC、手机、Xbox、HoloLens。表面上看很美好，问题在于：Windows Phone 正在走向消亡，而微软自家的旗舰应用（Office、Visual Studio，甚至 Windows 自身的外壳）都没有采用 UWP。
6、即使没人公开谈论，这个信息已经足够明显了。
当 UWP 推进受阻之后，官方给出的答案变成了：“看情况”。新应用用 UWP，旧应用继续用 WPF，通过 XAML Islands 引入新 API，等待 WinUI 3，同时 UWP 里还有专用的 WinUI 2，再加上 Project Reunion 会解决一切——不过它后来改名叫 Windows App SDK，而且依然不能完全替代 UWP。
同时一群聪明人，做着让人费解的决策。这更像是技术版的布朗运动——无规则、无方向的随机游走。
Project Reunion / WinUI 3 确实代表了一定程度的进步。但你也可以反过来问一句：这个问题为什么一开始会存在？UWP 的控件之所以与操作系统深度绑定，是因为它们归 Windows 团队所有，而不是 .NET 团队，也不是开发工具团队。Project Reunion，本质上是一个组织结构问题的“技术化补丁”。
有开发者在 2024 年这样总结自己的经历：“我一路跟着微软的各种变化走过来：UAP、UWP、C++/CX 被 C++/WinRT 取代却没有配套工具、XAML Islands、XAML Direct、Project Reunion、WinAppSDK 的重启，还有 WinUI 2.0 和 3.0 之间的混乱切换……”
十四年，十四次转向。这个人，应该先拿一枚勋章，然后再得到一句道歉。
7、没有管理员的“动物园”
下面这些，都是今天仍然在 Windows 上实际存在、被使用的 GUI 技术：
微软原生框架：
Win32（1985）—— 仍在，还被广泛使用。Petzold 的那本书到现在依然适用。
MFC（1992）—— 基于 Win32 的 C++ 封装。进入维护期，在企业软件和 CAD 领域依然活跃。
WinForms（2002）—— .NET 对 Win32 的封装。“可以用，但不推荐。”不过做数据录入界面依然是最快的选择。
WPF（2006）—— 基于 XAML、由 DirectX 渲染、已开源。但微软已经不再新增投入。
WinUI 3 / Windows App SDK（2021）—— 被称为“现代答案”，但路线仍不明朗。
MAUI（2022）—— Xamarin.Forms 的跨平台继任者，也是 .NET 团队当前押注的方向。
微软的 Web 混合方案：
Blazor Hybrid —— 在原生 WebView 中运行 .NET 的 Razor 组件。
WebView2 —— 在 Win32 / WinForms / WPF 应用中嵌入 Chromium。
第三方方案：
Electron —— Chromium + Node.js。VS Code、Slack、Discord 都在用。如今 Windows 上部署最广泛的桌面 GUI 技术，但和微软没什么关系。
Flutter（Google）—— 使用 Dart，自带渲染引擎，跨平台。
Tauri —— 基于 Rust 的轻量级 Electron 替代方案。
Qt —— 支持 C++ / Python / JavaScript，严肃的跨平台解决方案。
React Native for Windows —— 微软支持的 Facebook 移动框架移植版。
Avalonia —— 开源的“WPF 精神续作”。被 JetBrains、GitHub、Unity 等采用——这些开发者已经不再等待微软。
Uno Platform —— 把 WinUI API 带到所有平台上，在某种意义上比微软自己更坚持 WinUI。
Delphi / RAD Studio —— 还活着，还很高效，在垂直行业软件中依然占有一席之地。
Java Swing / JavaFX —— 是的，还在生产环境中运行。企业世界从不轻易遗忘。
一共十七种路径，五种编程语言，三种渲染思路。这已经不能叫“平台”了。也许我没法给 “boof-a-rama” 下一个精确定义，但我一眼就能认出来。
8、教训
几乎所有失败的 GUI 尝试，都可以追溯到三类原因之一：内部团队的权力博弈（Windows vs .NET）、在开发者大会上过早押注尚未成熟的平台（Metro、UWP），或者一次突如其来的商业战略转向，把开发者直接“晾在一边”（Silverlight）。
这些都不是技术失败。很多技术本身其实是优秀的——WPF 是好的，Silverlight 是好的，XAML 也是好的。
真正失败的，是组织本身。
要么你有一套完整、可信的“成功路径”理论，覆盖从采用、投入、维护到迁移的整个生命周期；要么你就只是在做一场开发者大会的主旨演讲。
前者是战略，后者只是三十年的混乱循环。
Charles Petzold 曾为了跟上微软每一次推出的新东西，撰写了六个版本的《Programming Windows》。最终，第六版停在了 Windows 8 的 WinRT，也就是 2012 年。
这事我不怪他。