⭐⭐⭐⭐⭐ Windows原生应用开发完全指南
摘要
一位资深开发者尝试构建一个简单的Windows工具后，写下了这篇"劝退"文章。结论：为什么现在没人写原生Windows应用，而是转向Electron。
📜 Windows UI框架演变
Win32 C APIs → MFC → WinForms → WPF → WinRT XAML → UWP XAML → WinUI 3每几年就有一个"新框架"，但每个新框架都有gap，需要回退到旧API。
🔧 作者构建的应用功能
- 枚举机器显示器及其边界
- 放置无边框、无标题栏、非激活的黑色窗口
- 拦截全局键盘快捷键
- 可选开机启动
- 存储持久设置
- 显示托盘图标和菜单
😰 现代Windows App SDK的问题
1. 选择技术栈是痛苦的
- C++: 内存不安全，在2026年写C++是犯罪
- .NET框架依赖部署: Windows 11只预装了.NET 4.8.1，最新版是10
- .NET AOT: 编译整个运行时，9MiB二进制文件做一个黑色窗口！
2. 功能实现需要大量P/Invoke
| 功能 | 状态 |
|---|---|
| 枚举显示器 | ✅ 可用，但监视变化需要P/Invoke |
| 放置黑窗口 | 大部分可做，但非激活需要P/Invoke |
| 全局快捷键 | ❌ 需要P/Invoke |
| 开机启动 | ✅ 可用 |
| 持久设置 | ✅ 可用 |
| 托盘图标 | ❌ 不可用，需要P/Invoke |
3. 微软自己也用Electron
从Visual Studio Code到Outlook到开始菜单，都是用Web技术写的。
4. 分发是噩梦
- MSIX格式需要代码签名证书，非美国居民每年$200-300
- 侧载体验很糟糕，需要PowerShell命令
- 微软商店拒绝应用因为"没有独特持久价值"
🤔 结论
"整个原生Windows应用开发项目感觉不是微软的优先事项。相关的问题跟踪器里满是开发者的痛苦经历，几乎没有微软工程师的回应。"
💡 洞察: 这解释了为什么整个社区决定自己走自己的路，投资于第三方UI框架如Electron。当官方SDK如此混乱时，Web技术反而成了更可靠的选择。