Microsoft Officially Deprecates UWP – Thurrott.com | Hacker News Reader

Microsoft Officially Deprecates UWP – Thurrott.com

thurrott.com

15 pointsredbell30 comments

As someone who hasn't developed windows applications since XP, can someone explain what the API landscape is today, especially for GUI work.

Win32 was dead, I thought, but I've seen the rise and fall of a few successors at this point, and it still seems to be the option with the best long term prospects.

I'd actually really love an answer to this as well.

Last time I did any windows development was about 8 years ago, and win32 was very much the default for most of the folks I worked with (myself included). UWP was just starting to come out, but absolutely nobody I knew was interested in using it.

From some viewpoints all of the successors are the "same", just evolutionary generation shifts (rather than revolutionary replacements): it's almost always XAML defined UI and COM's grown up replacements (though that did shift from a .NET focus with WPF/Silverlight to the "modern Windows runtime" often still referred to as WinRT and at the core mostly just COM with a .NET-style IDL format and a lot more standardized raw types).

WinUI 3 is a XAML defined UI stack with a lot of WinRT COMponents. That hasn't changed with this "UWP deprecation". Unlike some of the other deprecations (WPF/Silverlight) there aren't really any changes to the XAML format either: WinUI 1 and WinUI 2 were the names of different stages and UWP UI frameworks, and WinUI 3 lifts all of it out of UWP's app lifecycle sandbox and almost all of it out of components that ship with Windows itself (and thus only update with Windows feature releases) to libraries that applications can ship themselves with their own update cycles (to any supported Windows version, including limited Windows 7 support and Windows 10 support all the way back to the first Anniversary Update). More so than any of the other transitions/deprecations, this is a "simple" version upgrade 2 -> 3 from the UI/XAML standpoint (though with the semver major implication of some compatibility breaks). (It's the app lifecycle stuff that is most broken in this transition. Though even then there are transition options.)

All of that is tied together with much greater WinRT bindings/"projections" for many languages without custom language extensions (nor deep language runtime dependencies) and the ability to use far more components in existing "brownfield" Win32 apps such as dropping in entire XAML files as if they were a Win32 control, or vice versa supporting needing to bury an old Win32 control in the middle of a XAML stack somewhere to keep using an old but not broken component.

Additionally, anyone reading about C++/WinRT shouldn't be fooled about "modern" references.

The team that pushed it over C++/CX, brought back ATL style development, without any kind of IDL tooling support on Visual Studio, and after C++ files get generated by the XAML and midl compilers, it is on us to merge the files manually.

Whereas C++/CX provided an experience similar to C++ Builder or Qt, but politics, and now it is deprecated, while C++/WinRT team seems to be quite happy reliving the ATL/WRL experience.

The C++ variants are where I really lose track and get confused. Win32 I understand. COM I understand. C++/WinRT, C++/CX, wtf is that? Is it a different language like Objective-C++? I recall .NET had some C++ dialect, is it a derivative of that? At some point they had custom syntax for .NET pointers, some sort of hat operator. Can you mix C++/WinRT with normal portable C++? Can you use GCC or just MSVC?

Honestly I don't understand why anyone would write a Windows-specific app these days. Windows seems to have actually lost interest in high level languages over time. Seems like they have renewed their love affair with C++ and that's the "future" now.

C++/CX was the different language kind of like Objective-C++ with custom operators for WinRT COM controls, that in turn was similar to (but also very different from) C++/CLI which was an older language for .NET interop.

The current approach C++/WinRT despite retaining the weird IBM-esque use of a slash, is mostly "just" an IDL precompiler and bundle of macros intended for use with "modern" C++ (I believe it needs C++17 support or higher).

«Can you mix C++/WinRT with normal portable C++? Can you use GCC or just MSVC?»

That is one of the supposed advantages of/reasons for C++/WinRT over C++/CX. I've heard offhand mentions on blogs of using clang with C++/WinRT. I'm not a C++ developer and have no idea how well that works in practice.

«Windows seems to have actually lost interest in high level languages over time. Seems like they have renewed their love affair with C++ and that's the "future" now.»

I think that is related with pjmlp's complaint above with C++/WinRT (versus the older C++/CX) is that it does feel a lot like going back to the bad old days of MFC and (especially) ATL. The "WRL" templates library of C++/WinRT from my understanding is intentionally designed a lot like ATL. I can appreciate that Windows developers with a lot of C++ Win32 experience and massive brownfields of C++ Win32 apps like it much more for exactly those sorts of reasons: it looks/acts/smells a lot more like 90s COM, there's less relearning, there's far more interoperability with existing code structures/patterns/compiler choices (beyond the "need to upgrade to at least C++17").

I wouldn't necessarily phrase that as Windows seeming to have "lost" interest in high level languages. On the one hand I don't think "Windows" has ever really cared about high level languages in one way or another. That's as much "the Fall of the House of Longhorn" story as any other: the infighting between core Windows which has always been C++ and seemingly likely always will and the Developer Division trying to prioritize Developer Productivity and higher languages especially via .NET doing as much damage to Longhorn's goals as any other reason for slips/delays/production issues.

In all those fights .NET still exists and higher level languages still have a seat at the table. (Though JS got knocked out late in Windows 8 from having a direct WinRT story and subsequently/relatedly Electron is winning. Though React Native is sort of making a stand. Sort of.) Of course even .NET at this point seems to think that Windows-specific apps are on the way out and there's seemingly a lot more focus on MAUI and cross-platform apps than WinUI apps.

It goes beyond that, I wouldn't complain that much if they created a proper developer experience for C++/WinRT.

However it basically goes like this, you edit the IDL files with the same editing capabilities as if you were in Notepad, because to this day they still haven't bothered to add syntax highlighting or code completion to IDL files editing experience.

Then to top that, your C++ files get generated, and then it is up to you to track down the changes between the newly generated code and the last time you edited the IDL files. So you manually merge that generated code into the C++ files of your project.

Naturally a wonderful experience to those of us on .NET that occasionally need to deal with C++.

You are right regarding high level languages on Windows, the political might of WinDev means that something like iOS with Swift, or Android/Kotlin, where C and C++ play a minor role, will never happen.

Every time .NET gets a bit more of focus, they spoil the fun.

Interesting fact, the new context menu for Windows 11 requires a COM implementation to add entries for your application.

Which new context menu is that?

Windows 11 File Explorer now defaults to a new context menu when right clicking [1] with the modern "command bar" approach (first seen in OneNote for a number of years now, with the most common options collapsed to icons on a "toolbar" at the top/bottom closest to the mouse).

It shouldn't be a surprise that extensions to it still use COM (extensions to File Explorer have always used COM). Especially because these new COM interfaces for Shell Extension have been added retroactively all the way back to Windows 7. (The new ones differ from the old ones in providing more data to Windows for grouping/merging the extensions into submenus than previously supported.)

[1] Random image search example: https://cdn.mos.cms.futurecdn.net/LNbaeoqJymdkQ3uSK7MeKY-970...

(ETA: Useful blog post: https://blogs.windows.com/windowsdeveloper/2021/07/19/extend...)

Ah ha, very useful, thanks. I guess I can see why they used COM for this, it's the path of least resistance for them given the existing code, and I suppose it means you can write extensions in other languages too (though my memories of doing this are pretty horrible).

vb6 still works great :)

I have actually a few of these living dead on life support, so I hate your guts for daring to even think this. Have an upvote ;-)

(And its SP5, not SP6)

I don’t understand how Microsoft expects developers to adopt any of their Win32 API “replacements” if they keep deprecating them.

You just need to look at their org chart to see what is going on:

https://en.m.wikipedia.org/wiki/Manu_Cornet#/media/File%3A%2...

This just feels like a developer side of the Windows 11 release the "Windows 10 is our last version of Windows" but for devs. UWP is being deprecated in favor of another technology, WinUI which will annex much of the philosophy and ethos of UWP. Essentially UWP but with a new fancy version and not (supposedly) tied to a Windows release...

Press x for doubt.

Silverlight, WPF, UWP.. what's the next "dead technology" MSFT will send to its graveyard?

.NET Framework in favor of .Net Core

With very little way to easily convert a large app.

What are you specifically referring to? .NET core has pretty much everything and more than .NET Framework did.

In my personal experience, and that of colleagues, it was a pretty smooth experience. We mostly had issues due to some API changes here and there, and of course ASP.NET

It’s a different story when it comes desktop applications.

Outside of WCF it's not that different. I agree that the removal of WCF feels like a huge gut punch, but if you were following WCF tenets all along and had nice separation of your Data and Service and Operation Contracts it really shouldn't be that hard to drop all your WCF Binding wizardry and write new implementations of your contracts (interfaces) against HTTP REST or gRPC or GraphQL or Raw UDP Sockets or whatever your heart desires as your next communication tool, then dependency inject those implementations like any other dependency injection.

Are you going to do that for free?

Someone has to pay for the contracting project to do that.

Also Microsoft themselves have stuff that is .NET Framework only on VS plugins, SharePoint, Dynamics and SQL Server.

The point I was making was that WCF done well is a lot fewer billable hours to rewrite to use anything but WCF than people often think it is. I've done those rewrites before, and WCF is one of the few frameworks in existence that went so far out of its way to try to not leak abstractions that unless you were dependent on some truly baroque bindings, it's easier than most people seem to think. I've heard a lot of projects avoiding the .NET Framework to .NET 5+ transition solely because of WCF and how much work they think it would be based almost more on sunk "debts" feelings of existing tech debt from debugging WCF bindings/magic rather than maybe seeing it for what it is as more of a "unit testing DI exercise" where you've got existing test mocks (WCF) and just need a clean new implementation of existing interfaces.

Sure, but someone has to pay for that work, and many places don't have developers in-house, which means someone has to feel motivated enough to do a request to finance.

That is the exact opposite of my experience.

Outside of UI components which MSFT is getting to, they’ve worked very hard to make the transition as easy as possible.

If anything, the backwards compatibility has led to making some things worse, IMO, e.g. switching from the simple JSON based project file format they had to the XML based .csproj style one, which I’m pretty sure was done to be able to support .Net framework projects.

Classical .NET Framework CMS like Sitecore are now API first, and migrating away from .NET into a mixture of .NET, Java and JavaScript offerings.

Back in .NET Core 2.1 days, I had a two months project to port an application from .NET Framework into Java and deployed into Red-Hat Linux, because if a rewrite was required, then better away from Microsoft ecosystem, as this specific company already had enough from rewrites.

This is how well some customers have been taking the .NET Framework => Core migration.

If someone wants to have some popcorns, this is how it is being taken over at AppSDK github,

https://github.com/microsoft/WindowsAppSDK/discussions/1615

My arguing for UWP has been long, time to assume defeat and eat my hat, I really don't get how they managed to mess this worse than Vista.

Win32 => WinRT (8) => UAP (8.1) => UWP (10) => sorry guys back to Win32.

Plus the corpses from anyone that invested into .NET Native or C++/CX.

Also let not fool that HoloLens or XBox still use UWP, HoloLens is now using OpenXR/Unity, and XBox has released GDK (Win32 based).

If anyone still wonders why developers would choose Electron…

Something called universal sure passed rather quickly.

Soon enough the only thing left will be MS Access

Reply on news.ycombinator.com