[cptskippy]

Eh... not exactly.

MinWin was the response to Longhorn. When most of the major goals of Longhorn failed to ship and those that did resulted in Vista, Microsoft did a reset. The MinWin project was a massive cleanup effort that promoted cleaner API boundaries and layer separation that defined a minimal bootable NT core at the bottom with reduced overall dependencies.

WinRT was introduced as an alternative API/runtime layer alongside Win32. Both WinRT and Win32 used COM concepts and ran ontop of the NT executive. WinRT was a modern async first object oriented natively sandboxed capability-based runtime that supported built-in projections over manual COM.

Microsoft tried to encourage everyone to adopt WinRT and the new sandboxed App Model on Windows 8, Windows RT, and Windows Phone. It used modern concepts and was more secure than the uncontrolled legacy surface area that Win32 exposed. They shipped those devices with Metro, a new "desktop" interface and didn't allow Win32 Apps. Unfortunately they shot themselves in the foot by shipping full Win32 based Office on Windows RT. This demonstrated that yes Win32 could run on ARM. After that, things fell apart and Microsoft decoupled many WinRT features from the WinRT/UWP model.

WinUI is an interesting UI framework that sits on top of this stack and is decoupled from it. This allows it to be updated independent of the operating system.

[pjmlp]

MinWin was a kernel refactoring mostly, still during Windows 7 days.

Missed the parts about the multiple reboots of the WinRT API surface between 8, 8.1 and 10.

The deprecation of .NET Native and C++/CX, replaced by tooling without feature parity to this day.

The set of Win32 APIs not available in UWP, even after the 8 and 8.1 (UAP) reboots.

WinUI 2.0 features not yet available on WinUI 3.0.

The pivot from Project Reunion, that six years later hasn't yet delivered on the goals from the BUILD 2020 announcement.

Microsoft is its worst enemy when it turns the hardest advocates in tale tellers from past wars.