There is a pretty big difference between WPF, and the XAML UI Framework that you get in UWPs. When it comes to desktop apps, at least, WPF had a lot more features, and was generally more flexible and extensible. XAML UI is much closer to Silverlight, if anything.
When a new UI framework comes out, my test is: "Can Adobe build the next version of Photoshop with this?".
WinForms and WPF failed the test because they can only be run from within .NET applications. I was hopefull for Direct2D, but D2D is only a drawing API, there are no native widgets. XAML with C++ is nice in Windows 10, but I understand your application must run in the sandbox (for better and for worse) and when you use Win10 XAML you cannot use any UI code that uses any of the old-world code (e.g. Photoshop plugins). I'm also concerned that XAML prevents you from getting lower-level control over hardware (e.g. Deep-color support, hosting low-latency OpenGL contexts, etc). The sandbox requirement itself kills it for a lot of applications anyway.
Today, if you're writing a C/C++ program for Windows that needs to display a native Windows checkbox on screen (i.e. the Common Controls library or the raw Checkbox window class), and you want to customise how that checkbox is rendered, then you're still stuck with GDI - the WM_Paint message gives you access to s GDI device context in RAM - so you have to jump through hoops to use it with another 2D library or widget toolkit. How do I get an opaque handle to the window's texture surface in VRAM for ultra-fast painting or low-level control?
The future is sandboxed Windows, there is no way around it.
So while XAML with C++ does indeed require WinRT and sanboxing. That is where future Windows versions will be.
For high performance graphics there is DirectX and it interoperates perfectly fine with XAML. There are quite a few examples, including VS templates.
As for Win32, the Anniversary edition will bring the productified version of project Centennial, which allows running Win32 applications as sandboxed WinRT apps.
This is intended as a porting aid to bring Win32 apps into the new world, not as as something to use for new applications.
Depends on the direction where you’re extending them.
I’ve extended both WPF and XAML with 3D rendered content.
WPF still uses Direct3D 9 under the hood. Interop with modern D3D took some time to implement and debug: DXGI surface sharing is complicated, I remember hunting several bugs related to lost devices and concurrency.
Win8/XAML already uses Direct3D 11; interop with custom 3D content is painless, I don’t recall any issues.
It might be, but that is where Windows on the desktop is headed, even Project Centennial is only intended as a means to bring existing applications into the new sandboxed world, not for greenfield applications.
So in the new WinRT world, C++ has a XAML stack and it is quite ok for me.
I seldom use the more powerful features from WPF that aren't in XAML.
The new WinRT world is not quite here yet - there will be a point when Win10 is so dominant that support for lower versions can be dropped, but that won't happen anytime soon; not with Win7 being as entrenched as it is.
So, for now, it's still WPF for most practical purposes on the Windows desktop. Indeed, that is even the case for Microsoft software - note how e.g. Visual Studio is still mostly a WPF app.
Should the OSDev stop doing 64 bit support, just because the VS team doesn't want to upgrade their tools?
The Office team is making use of WinRT.
As for Windows 7, it might be the new XP, but this time Microsoft is bullying the move into the new WinRT world, so lets see how long it will be around.
The reluctance to move VS to 64-bit is for a different reason. It's doable, but very costly, because of how much old native code is in that thing even today.
On the other hand, as far as UI frameworks go, VS offers a lot of flexibility - it's already a mashup, with some parts using native Win32 controls directly, some parts using WinForms, some parts using WPF, and some parts using HTML5. Basically, as new and better frameworks appeared, new parts of VS adopted them (and occasionally old parts would, as they got rewritten).
But there are no parts of VS that use WinRT (outside maybe of some stuff that relates to WinRT development). For a very obvious reason - there are too many users still on Win7.
BTW, did you know that VC++ guys still have to support the standard library on XP, because the users demand it? I don't mean old versions of it, but even the most recent releases...
Not for those of us on Windows 8 onwards.
The way forward for C++ UIs is XAML, which is just the underlying foundation of WPF.