(This reply is PART 4 of 4, you'll need to scroll way down for Part 1)
Anyway, flash-forward a half-decade and Microsoft finally had some sense knocked into them and started to open-up UWP (or rather: export the nice(r) parts of UWP to the Win32 world, outside of the sandbox). There was more confusion (and popped blood-vessles) when "Windows UI Library 2" dropped. Fortunately no-one ever used it. "WinUI 3" is now meant to be the future: it's a XAML-based UI framework that can be used by native code, without the UWP sandbox - the only thing holding it back (imo) is the
lack of many essential controls and widgets in the in-box library: it's still missing a data-grid, for example. The other major issue is that XAML is definitely not a RAD platform: XAML is still excessively verbose, wiring-up control events directly to event-handler functions is discouraged (as markup-based databinding is far superior in most cases), but XAML's data-binding system doesn't scale and relies on mutable viewmodel classes, side-effects, reentrancy, event-broadcasting, and other things that make people used to Redux/React's unidirectional flow of data scream and bash their head against the wall, just because XAML data-binding really is so backward.
So here we are, in 2022 - if you want to make a "native" GUI desktop app for Windows 10 then your options are:
* Win32/USER32/ComCtrl: too low-level to be practical for building applications today. VisualC++ comes with MFC, but that's like giving a glass of water to someone in hell.
* WinForms: poorly-disguised wrapper over GDI, USER32 and ComCtl32. Microsoft would prefer you pretended it didn't exist. The only thing going for it is that it's currently (still) the only way to do RAD desktop UI development.
* WPF: only suitable for greenfield programs built on .NET. Stock controls have been neglected since Windows 8 and have lost their sophisticated visual aesthetic from Windows 7 and are now hideous (solid grey buttons? not even inset borders?!), fortunately theme/resources like MahApps.Metro make WPF apps a pleasure to use again. WPF still remains the best option for building maintainable line-of-business applications, but I recommend avoiding two-way data-binding to your viewmodel: try to be at close to the Redux-pattern as possible. And here's to hoping there's a migration path to WinUI when it reaches feature-parity, especially w.r.t. datagrids, etc.
* Sandboxed UWP: ahahahah, no.
* WinUI 3+: Looks promising, but despite being available for a couple of years now, at least WinUI has the dignity of actually being used by some of Microsoft's own software unlike WPF and UWP (mostly things already built-in to Windows, like the Calculator app since Windows 11).
* Honorable mention HTA: HTAs (Hypertext Applications) were added to Windows 98: basically it was using MSHTML (Internet Explorer) to render the UI, with the DOM being fully scriptable with JS or VBScript and could interact with the rest of an application via COM. Basically exactly what Electron is today but 25 years ago (and without any sandboxing... erk!). This was a surprisingly well-designed and implemented platform option in Windows, and even used by many of Microsoft's own software - but Microsoft didn't really advertise it, and when Internet Explorer 11 came out it basically broke HTAs for good (HTAs used IE7 compatibility mode, if you wanted to use IE11 mode then it would break HTA-exclusive features like Win32/COM integration).
* So given those are today's options, it's no surprise that today's generation of developers, who invariably cut-their-teeth learning HTML and CSS as kids, instead of on VBA/VB6 Forms, are increasingly looking at Electron - especially if they want any kind of custom UI or branded themeing, even if they don't want cross-platform compatibility. Even with XAML-based WinUI 3, it's still absurdly difficult to do things that deviate from the stock themes, especially fonts/typefaces, colors/themes, etc.
[1] Technically, Windows 98 and Windows 2000 (which were completely separate OS codebases) did have built-in support for a very limited form of window compositioning named "layered windows"[3], which supported top-level alpha-blending effects and complex window shapes (While Windows 95 did support non-rectangular top-level windows it was only with indexed transparency without antialiasing) however opting-in to a layered hWnd required the user to have ample VRAM (for double-buffered windows) and a highly-capable 2D graphics chipset (for fast alpha-blending), and if you wanted per-pixel alpha-blending then your UI thread's performance sank like a stone - oh, and you had to use GDI too. Ultimately I think this was only used for UI gimmicks for desktop apps like Trillian which would turn semi-transparent when on-focused.
[2] Llate-1990s PC gamers will remember that running 3D games in a window (as opposed to in exclusive-mode) was awful for performance due to all the excessive frame blitting, I think XP did mitigate it somewhat, but I'm unsure how.
[4] Win32's window/hWnd subclassing doesn't literally mean using an OOP language like C++ to subclass some class representing a USER32 widget or ComCtl button (as that's meaningless: C++-style classes don't exist in natively compiled programs), what it refers to is described here ( https://docs.microsoft.com/en-us/windows/win32/controls/subc... ) - and it's when an application, at runtime, creates a new Win32 hWnd or instantiates a widget like a button or checkbox, and uses owner-level overrides of certain OS-level window-messages, such as painting or how it responds to mouse and keyboard input - so it's more akin to message-passing OOP (i.e. Smalltalk-style OOP) than C++-style OOP.
[5] Consider this (somewhat contrived) scenario: an application that subclasses a Win32 button control hWnd class so that the button will now respond to a middle-mouse-button-click the same way as a left-button-click. This would be implemented by Things work fine until the next OS release where Microsoft suddenly decides that middle-clicking all Win32/USER32/ComCtl32 buttons will start a cheesy fireworks display on the user's desktop wallpaper.
Anyway, flash-forward a half-decade and Microsoft finally had some sense knocked into them and started to open-up UWP (or rather: export the nice(r) parts of UWP to the Win32 world, outside of the sandbox). There was more confusion (and popped blood-vessles) when "Windows UI Library 2" dropped. Fortunately no-one ever used it. "WinUI 3" is now meant to be the future: it's a XAML-based UI framework that can be used by native code, without the UWP sandbox - the only thing holding it back (imo) is the lack of many essential controls and widgets in the in-box library: it's still missing a data-grid, for example. The other major issue is that XAML is definitely not a RAD platform: XAML is still excessively verbose, wiring-up control events directly to event-handler functions is discouraged (as markup-based databinding is far superior in most cases), but XAML's data-binding system doesn't scale and relies on mutable viewmodel classes, side-effects, reentrancy, event-broadcasting, and other things that make people used to Redux/React's unidirectional flow of data scream and bash their head against the wall, just because XAML data-binding really is so backward.
So here we are, in 2022 - if you want to make a "native" GUI desktop app for Windows 10 then your options are:
* Win32/USER32/ComCtrl: too low-level to be practical for building applications today. VisualC++ comes with MFC, but that's like giving a glass of water to someone in hell.
* WinForms: poorly-disguised wrapper over GDI, USER32 and ComCtl32. Microsoft would prefer you pretended it didn't exist. The only thing going for it is that it's currently (still) the only way to do RAD desktop UI development.
* WPF: only suitable for greenfield programs built on .NET. Stock controls have been neglected since Windows 8 and have lost their sophisticated visual aesthetic from Windows 7 and are now hideous (solid grey buttons? not even inset borders?!), fortunately theme/resources like MahApps.Metro make WPF apps a pleasure to use again. WPF still remains the best option for building maintainable line-of-business applications, but I recommend avoiding two-way data-binding to your viewmodel: try to be at close to the Redux-pattern as possible. And here's to hoping there's a migration path to WinUI when it reaches feature-parity, especially w.r.t. datagrids, etc.
* Sandboxed UWP: ahahahah, no.
* WinUI 3+: Looks promising, but despite being available for a couple of years now, at least WinUI has the dignity of actually being used by some of Microsoft's own software unlike WPF and UWP (mostly things already built-in to Windows, like the Calculator app since Windows 11).
* Honorable mention HTA: HTAs (Hypertext Applications) were added to Windows 98: basically it was using MSHTML (Internet Explorer) to render the UI, with the DOM being fully scriptable with JS or VBScript and could interact with the rest of an application via COM. Basically exactly what Electron is today but 25 years ago (and without any sandboxing... erk!). This was a surprisingly well-designed and implemented platform option in Windows, and even used by many of Microsoft's own software - but Microsoft didn't really advertise it, and when Internet Explorer 11 came out it basically broke HTAs for good (HTAs used IE7 compatibility mode, if you wanted to use IE11 mode then it would break HTA-exclusive features like Win32/COM integration).
* So given those are today's options, it's no surprise that today's generation of developers, who invariably cut-their-teeth learning HTML and CSS as kids, instead of on VBA/VB6 Forms, are increasingly looking at Electron - especially if they want any kind of custom UI or branded themeing, even if they don't want cross-platform compatibility. Even with XAML-based WinUI 3, it's still absurdly difficult to do things that deviate from the stock themes, especially fonts/typefaces, colors/themes, etc.
[1] Technically, Windows 98 and Windows 2000 (which were completely separate OS codebases) did have built-in support for a very limited form of window compositioning named "layered windows"[3], which supported top-level alpha-blending effects and complex window shapes (While Windows 95 did support non-rectangular top-level windows it was only with indexed transparency without antialiasing) however opting-in to a layered hWnd required the user to have ample VRAM (for double-buffered windows) and a highly-capable 2D graphics chipset (for fast alpha-blending), and if you wanted per-pixel alpha-blending then your UI thread's performance sank like a stone - oh, and you had to use GDI too. Ultimately I think this was only used for UI gimmicks for desktop apps like Trillian which would turn semi-transparent when on-focused.
[2] Llate-1990s PC gamers will remember that running 3D games in a window (as opposed to in exclusive-mode) was awful for performance due to all the excessive frame blitting, I think XP did mitigate it somewhat, but I'm unsure how.
[3] https://docs.microsoft.com/en-us/windows/win32/winmsg/window...
[4] Win32's window/hWnd subclassing doesn't literally mean using an OOP language like C++ to subclass some class representing a USER32 widget or ComCtl button (as that's meaningless: C++-style classes don't exist in natively compiled programs), what it refers to is described here ( https://docs.microsoft.com/en-us/windows/win32/controls/subc... ) - and it's when an application, at runtime, creates a new Win32 hWnd or instantiates a widget like a button or checkbox, and uses owner-level overrides of certain OS-level window-messages, such as painting or how it responds to mouse and keyboard input - so it's more akin to message-passing OOP (i.e. Smalltalk-style OOP) than C++-style OOP.
[5] Consider this (somewhat contrived) scenario: an application that subclasses a Win32 button control hWnd class so that the button will now respond to a middle-mouse-button-click the same way as a left-button-click. This would be implemented by Things work fine until the next OS release where Microsoft suddenly decides that middle-clicking all Win32/USER32/ComCtl32 buttons will start a cheesy fireworks display on the user's desktop wallpaper.
[6] https://en.wikipedia.org/wiki/Referential_transparency