(PART 3):

What I've written so far makes it sound like WPF should have saved the Windows desktop app development story and everything from Microsoft since then should have been based on WPF - but here we are, almost 20 years later, and Microsoft Office doesn't use WPF, very few in-box components in Windows use WPF, in fact, other than Visual Studio, I honestly cannot think of any WPF-based applications I use on a daily basis. So why isn't WPF being used if it's so great?

...it's because WPF could only be used if an application used the .NET Framework - and the .NET Framework for-all-intents-and-purposes is just "Microsoft's Java": if your a company like Adobe, Macromedia, Autodesk, a web-browser vendor like Netscape or Mozilla, or even Microsoft's own Office division, then you've got millions, perhaps billions, of dollars invested in your existing native C/C++/Ada/Delphi/etc applications that use Win32 and GDI directly. If you want your application to use WPF for its desktop GUI then you'll need to find a way to host the .NET CLR in-process and then start to rebuild your entire UI in WPF XAML. A small blessing is that WPF can co-exist in the same top-level window as other native/Win32 widgets (this is what Autodesk did when they added a tabbed-ribbon UI to 3ds Max: the ribbon was a WPF control while the rest of the UI was their existing UI). So in short, Microsoft was asking these independent software vendors, the same vendors Microsoft ultimately depends upon to legitimize the Windows desktop platform, to take a huge bet on the viability of WPF - and the .NET Framework - and to take-on both WPF and .NET as additional external dependencies with their own releases and versioning that were (and still are) completely separate from Windows OS releases (as .NET and WPF are "owned" by a completely separate division in Microsoft than the Windows org: the separation goes right-up to the highest level: there is no-one at Microsoft with the job-responsibility of ensuring that WPF and Windows stay coordinates - which explains a lot).

Secondarily: those companies above that I mentioned, like Adobe and Autodesk, have another huge reason to be reluctant to use WPF as the entire basis for their desktop app GUIs: industrial-grade tools like Photoshop and 3ds absolutely need high-performance, low-level access to the computer's GPU - but WPF only gets in the way. While you can do things like offscreen rendering and blit those surfaces into your WPF UI, that adds at least 1 frame of latency, even more with how the DWM works. Also, remember how I said there's no-one at Microsoft ultimately responsible for maintaining cohesion between WPF/Windows? That became a problem when WPF was effectively frozen around 2010 and stuck on DirectX 9 which means it's impractical to run any modern Direct3D code from the past 10 years in the same process as a WPF GUI. It's 2022, and WPF (even on .NET 6) is still stuck on Direct3D 9. It's insane: this is is holding back the platform and has irreparably damaged the Windows desktop developer story.

The end result today is that WPF is a very compelling UI framework for internal and line-of-business applications that now absolutely depend on the ability to embed treeviews inside datagrids inside other treeviews, it's still a huge blinking red no-go-area for major software vendors, legacy non-.NET codebases, and those needing to low-level hardware access for their top-level windows (e.g. deep-color in Photoshop).

Microsoft did add a largely unnoticed (but now utterly essential, IMO) feature in Windows 8 which improved on Longhorn/Vista's GDI-free top-level hWnds: WS_EX_NOREDIRECTIONBITMAP. Finally, any application (or, more likely: UI frameworks) can now have top-level windows with blazing fast performance, deep-color, and more without double-buffering in the DWM that (I understand) can even be used from OpenGL just as well as Direct3D... but Windows doesn't come with any UI framework or widget-library for it, much less anything like RAD tooling for it. At least this gives companies like Adobe and Autodesk an escape-hatch for Photoshop and AutoCAD, and it should be possible for them to port their own proprietary existing UI/widget libs over to it it's just another render target.

But while Windows 8 helped, it's also where things really went-off-the-rails: WPF had been frozen for at least a half-decade at this point and Microsoft was trying (and failing) to turn Windows into a touch-friendly OS experience to compete with Apple's iPad, which I honestly believe Microsoft saw as an major, if not existential threat (if it weren't for Apple keeping iPad OS dumbed-down, with siloed applications and continuing to make it unsuitable for true multitasking, then any iPad with a keyboard would likely suit 90% of the needs of 80% of existing (non-business) Windows PC users). As part of this strategy, Microsoft had this obsession with thinking having their own Apple-style App Store for Windows, which would only sell extremely restricted sandboxed applications was necessary to compete - rather than treating Windows' open-platform nature as an advantage. So Microsoft created a new platform-within-a-platform named "Universal Windows Platform" (UWP) which was a Frankenstein's monster comprised of a new, tightly-restricted and sandboxed execution-environment (which at least supported native x86/x64/ARM rather than being yet another .NET port), a COM-based platform API, and a WPF-derived XAML UI framework that didn't even have its own name). While this platform, including the XAML UI framework, no-longer required the use of .NET to work (hurrah!) it did require applications to be recompiled with a special C runtime lib (due to the sandboxing) and all UWP platform API calls had to go through Visual C++ language extensions named "C++/CX", so you were SOL if you were a gcc or Clang user. While the sandboxing made UWP an instant deal-killer for any "real" software (excepting yet another Netflix app), there was strong developer interest in getting to use UWP's new XAML-based UI framework (internally named "Jupiter") outside of the sandbox: by classic Win32 desktop software badly in need of a facelift. Inexplicably, Microsoft disregarded that interest and kept Jupiter only accessible to sandboxed applications and instead ploughed resources into the rest of the sandboxed UWP platform for the sake of the not-dead-yet Windows Phone platform. Even if a developer was willing to rework their application for UWP's sandbox to get to use Jupiter, the built-in widget/control library was still very anemic: all of the widgets and controls were clearly touch-first, mouse-second, keyboard-third (i.e. big and chunky, suited to only a 10-foot-UI or touch device experience) and clearly inappropriate for traditional desktop use-cases or anywhere when information-density is essential: anyone using UWP/Jupiter for those kinds of applications would need to invest in a third-party control library, or build their own. UWP/Jupiter still didn't come with any kind of data-grid control at this point, even though it should have been very straightforward to port it over from WPF, which shows you exactly where Microsoft's priorities lay.