微软承认 Windows 11 仍基于90年代的 Win32 架构，出人意料
当你在Windows 11中右键点击文件或启动传统桌面应用时，你正在与诞生于商业互联网之前的代码交互。Win32 API诞生于Windows 95时代，仍然是全球最流行桌面操作系统的重要组成部分。但微软高层表示，这并非他们最初的设想。
Windows Latest首次发现，微软Azure首席技术官、Sysinternals传奇创始人Mark Russinovich在微软官方Dev Docs账号发布的一段视频中承认，Win32的存活是公司历史上最大的意外之一。
https://www.windowslatest.com/wp-content/uploads/2026/05/Microsoft-statement-on-Win32.mp4“90年代有人预计Win32能在2026年依然是一流API吗？我可以肯定地说，没有。”Russinovich解释道。“没人会想到，因为我们那时候想到的是2026年有飞行汽车、月球站，而不是Windows 95时代设计的Win32。”
虽然世界万物都在改变，但让我惊讶的是，和我一样古老的计算机代码仍然存在价值，而我周围的环境却在过去10年中完全不同了。
磁盘管理工具是Windows 11中仍然相关的Win32应用程序那么，这个30岁的API如何在几十年内部努力被替代的情况下依然存活？Russinovich说，这全归功于其庞大的生态系统。“我认为它具有持久力的原因之一是，它是Windows内部的基础层，许多应用都建立在它之上……它就像基石一样。”
Russinovich以自己的Sysinternals工具为例。该工具创建于1996年，他说“我曾赌一百万美元”，认为最早的工具不会在2026年还相关，但事实正相反。Sysmon成为2026年3月更新的内置功能，正被直接集成到Windows中；早在2000年代开发的Zoomit今天依然是PowerToys内非常流行的工具。
微软积压了众多Win32替代框架
几年前我初识Win32，听到的第一句话就是它非常强大。那么如果Win32如此强大，微软为何二十年来一直试图淘汰它？
和许多人一样，我PC上的Win32应用比网页应用或现代框架的应用更多。它们运行极快，和操作系统硬件深度集成，但视觉上极难现代化。为了满足现代用户界面需求，微软迫切需要新框架。
随后是长达数十年的框架荒废史。微软曾推MFC（C++封装）、后续的.NET开发者WinForms，虽然它们不是Win32的替代，而是Win32之上的抽象层。
之后出现Windows Presentation Foundation (WPF)，真正替代的努力开始，带入XAML和硬件加速渲染。
WPF曾被寄予Windows应用的未来，直到Silverlight短暂成为跨平台聚焦，最终被HTML5崛起终结。
最激进的Win32替代尝试来自Windows 8及WinRT。微软希望开发者构建安全、触摸友好、全屏应用。
Windows 8界面失败后，微软转向Windows 10的Universal Windows Platform (UWP)。
在我Windows 10 Mobile时代，我曾告诉大家UWP会带来跨手机、Xbox和PC的强大统一应用平台。但现实并非如此。
UWP限制过多，沙箱机制严重，还完全疏远了需要深入系统访问的传统桌面开发者。
正如Russinovich所说：“微软历史上多次尝试重启Windows API表面，比如WinRT，但都未如许多人预期，仍然存在传统客户端、Win32和基于HTML、JavaScript的浏览器的分离。”
内存危机下开发者仍偏爱Windows上的WebView2
我询问多位开发者为什么仍制作耗内存的Windows网页应用。这也怪微软。
微软频繁推出又弃用原生框架，造成开发者对Windows平台失去信心。我在Windows Latest详细报道中解释过，有位开发者告诉我为何Windows 11反复出现网页应用，缺乏原生应用。
WhatsApp网页应用停留在加载界面他们说开发原生Windows应用变得像巨大负担，这无法责怪他们。为何要投入多年时间研发一个微软明天可能弃用的框架？
讽刺的是，是微软转向了网页。微软推出WebView2控件，实质上将基于Chromium的Edge浏览器引擎嵌入桌面应用。Windows迅速充斥着网页应用，包括Microsoft Teams、Clipchamp、新版Outlook、OneDrive、Windows 11小部件板，甚至最新的Copilot也是网页应用。
任务管理器中的Copilot网页应用虽然开发成本低，跨平台维护方便，但本质上并不适合桌面计算。将完整浏览器引擎嵌入每个独立应用，系统资源消耗极大，是灾难配方。
对WebView2和Electron的依赖是Windows 11变成内存大户的原因。我每天使用WhatsApp桌面应用，体验极差。测试显示，WhatsApp在待机时就消耗大量内存，完全因为它使用了沉重的网页包装器，而非过去UWP时代的轻量原生代码。
微软的Clipchamp也是另一网页应用，我曾用它做基础视频编辑，后来弃用，因为微软内置的视频编辑器竟然需要OneDrive同步才能用！
当我将Windows与macOS对比时，愤怒更甚。Apple用户可以免费享用高度优化的原生应用，如iMovie或Pages套件，而像我这样的Windows忠实用户只能依赖需要持续联网、缺乏深度系统集成且占用大量内存的网页替代品Clipchamp。
微软Clipchamp是基于WebView2的视频编辑器所幸，苹果成功以不到600美元的预算笔记本促使雷德蒙德巨头重新思考应用开发优先级。
微软正借助WinUI 3回归原生应用
幸运的是，形势终于开始逆转。微软意识到把Windows变成一个美化版的Chrome OS正在疏远高级用户，并破坏系统性能。
几个月前，微软合作架构师Rudy Huyn确认正在组建专门团队，致力于为Windows 11打造“100%原生”应用。重点已转向WinUI 3，这是Windows App SDK旗下的最新原生UI框架。
WinUI 3正是微软赢回开发者所需的解决方案。它允许构建华丽、现代、符合Fluent设计的应用，同时仍能完全无阻访问底层Win32“基石”。微软近期发布了Windows App SDK 2.0重大更新，带来了语义版本控制、重构的Windows ML栈和急需的拖拽支持，使WebView2内容无缝融入原生WinUI 3壳层。
微软用正确方式淘汰传统Win32
微软终于开始自我革新，清理Windows 11。
微软没有像WinRT那样强行重启，而是逐步剔除Windows 11中最老最丑（有些人可能不同意）的Win32 UI元素，用高度优化的WinUI 3原生代码替代。最近我们发现，Windows 95时代的文件资源管理器属性对话框终于被WinUI 3新版替代，且完全支持暗黑模式。
传统运行对话框（Win + R）被完全重写为极速WinUI 3应用。使用新旧版本后，我可以自信地说新运行对话框不逊色甚至优于旧版本，尤其是其外观之美观。
基于.NET AOT编译，新运行对话框达到惊人的94毫秒平均响应时间，甚至快于旧版本，证明现代WinUI 3框架完全能匹配传统Win32代码的速度与效率。
随着微软持续用原生WinUI 3组件替换沉重的WebView2包装器，Windows 11将不再消耗大量冗余内存。2026年虽无飞行汽车和月球站，但经历数十年失误后，我们终于可能迎来一款快速、原生、且尊重自身传承的Windows操作系统。