@
shayuvpn0001 WinForms 永远干不翻最大的设计上的坑：依赖 HWND 。
所以一旦遇到控件这个层次上不能解决的问题（比如说，自己实现不能通过组合现有控件完全实现的新控件），问题就很可能陡然恶心起来：很可能用户就得把 Win32 UI 的花里胡哨的屎味咖喱过一遍，还比原生 Win32 破事更多（因为涉及互操作）。
Win32 的屎味咖喱也是为什么传统的搞 Win32 UI 的受不了纷纷跳出来搞新的一套所谓的 DirectUI 。
讲道理，原生的 HWND 其实确实是希望用户按传统意义的方式扩展的。这特别体现在任何一个像样的 Win32 控件都是桌面隐喻的所谓“窗口”（ Windows 这个名字也指的是这个）上，而不是现在大多数最终用户理解的窗体和对话框。
但是 Win32 API 用 C 提供，不管对用户使用还是维护者扩展都有天坑（用户看不到 HWND 实现，微软也没可能让用户彻底看到），加上一些底层设计问题（如滥用低效的异步窗口消息、WndProc 的签名扩展性差甚至要用户折腾 thunk ）和 Windows API 固有的更新周期导致跨操作系统版本体验碎片化（比如分层子窗口只在 Windows 8 后支持）导致这种方式最终是无药可救的。
在扩展 HWND 无望的情况下，Windowless 是自然选项了。如果把扩展 HWND 实现这样的权利看作是用户（桌面系统开发者）的自由，那么所有健全的 GUI 天生都是所谓的 DirectUI （所以这词虽然是微软开发者发明的，但也挺 low 的），而基于 HWND 封装的方案（包括 MFC 和 WinForms ）只是残废版而已。
WinForms 这种咖喱味的屎在常规 Win32 用户的面前解决了旧的 Win32 C API 的一些屎味和随着操作系统版本分发导致的部分表面问题，但没办法解决根本问题（而且 .NET Framework 的分发周期早年一样挺欠揍的）。对原有 Win32 的就是只想搓出来个能看的 GUI 的最传统的用户，API 和工具易用性提升的开发效率已经足够可观，所以才能忍受；但对原本就受不了 HWND 又没法找到现成方案的用户再说，最终需要 hack Win32 的问题也是忍无可忍的。（所以现在还流行的就包括大部分倒腾工控机的，因为这些用户大多对干掉后者的屎味感知不大。）
（题外话，任意不是靠模拟来实现的“原生”GUI 风格的解决方案，不管是什么平台的，一样很可能有这里的残废屎味；至少遇到 Windows 就很可能放纵了；其实还有少数比 Win32 还烂的，比如各种 CAD 之类的私有界面扩展 API ……不过不提也罢。）
WPF 甩掉了 HWND 的包袱，才算是一个相对“完整”的 GUI 解决方案；而且相对 Win32 过渡到 WinForms ，工具的改进使过渡的体验更加平滑，这才是 WPF 的基本盘。至于 MVVM 和 XAML ，其实不像一些用户理解的那么适合传统桌面开发，既是加分项又是减分项（不过最传统的一些用户有些就只是待在 WinForms 觉得够用挺好，也就不会有什么有效反馈了）。当然，光说完成度，WPF 就够打翻 UWP 和现在的 WinUI 的了。