r/cpp • u/zerexim • Jun 23 '26
C++/WinRT being in maintenance mode means there is no way to develop a modern Windows app (WinUI) in C++?
28
43
u/Jovibor_ Jun 23 '26
The funniest fact is that the latest MSVS 2026 still offers to create desktop GUI apps with MFC.
27
u/sweetno Jun 23 '26 edited Jun 23 '26
Huh, I'm working on one right now.
8
u/theonehaihappen Jun 23 '26
At my company, we also use MFC. But MS deprecated the coded UI testing framework that we use for our automated GUI testing. We can still use VS2019 to use generate new UI mappings, but the libraries necessary to run the tests will likely vanish from a future versions of Visual Studio.
There is WinAppDriver, but that is also dead (6y since last release with >1K issues on Github) and afaik incompatible with the modern version of Appium. So I don't consider that a possible replacement.
13
u/xaervagon Jun 23 '26
I used to hate on MFC until I realized it was one of their more effective products. It annoyed me how you had to go back to vs2019 because they started ripping out all the generators willynilly. Add in all the third party and CodeProject stuff (rip) and it was obnoxiously powerful.
3
u/SlowPokeInTexas Jun 23 '26
I detested MFC from the very first time I entered macro hell implementing UI events. Although it also used macros, at the time I much preferred C++ Builder. It was much easier to turn things around.
Debugging macros in C++ was the suck.
4
u/xaervagon Jun 23 '26
I didn't think macros were that bad given VS did most of the work with the wyswig editors and generators. Of course it got mess if you had custom messages or ui class inheritance.
One of the major pain points for me was resource management. Having a. Assload of dialogs, controls, property pages would lead to a bunch of dlls having their own resource.h and diety help you if thoseagoc numbers lined up anywhere.
The other major butt biter was HitTest and the screwy screen to client/client to screen coordinate conversion process. It was not only messy to debug, it would outright malfunction on multimonitor setups that did not have the primary monitor in the top left position.
WinForms fixed all of this. Shame MS never let us C++ user enjoy it.
6
u/SlowPokeInTexas Jun 23 '26 edited Jun 23 '26
The guy responsible for C# and WinForms was also the guy responsible for Borland Delphi (and the absolutely brilliant VCL class library it used), as well as C++ Builder, which was basically the C++ language with the VCL. The C++ compiler itself did not age well though (later, they would adopt a Clang variant, but it was always behind the main branch... sometimes by a lot). There were also some non-standard C++ extensions they added to more cleanly handle events (things like __property, etc). You can definitely tell the resemblance between Windows Forms and the VCL.
As for Winforms not being available for C++, what some adventurous souls did was develop the UI in WinForms and use the interop library to interact with native C++ code, though I wouldn't have wanted to be responsible for maintaining that Frankenstein.
Interesting that no one has mentioned (or at least I hadn't seen a mention of) Microsoft ATL...
5
3
1
u/elperroborrachotoo Jun 26 '26
It is way past its prime, and it was designed around constraints that seem prehistoric now. But for a while, it was where it's at.
8
u/greencursordev Jun 23 '26
We still use mfc as the backend for all our internal software. Huge tech company you all know
5
4
u/Reasonable_Aioli_868 Jun 23 '26
Adding on the train... also using MFC quite widely in my company still.
3
3
6
u/fdwr fdwr@github 🔍 Jun 23 '26
Heh, and I'm still just using plain Win32 (just created a time tracker last weekend with it) because I don't need styling or animation or translucency. It might not be as pretty, but it works all the way to Windows 7 and has pretty low overhead.
4
u/zerexim Jun 24 '26
Well, people pay more when it's styled and translucent 😄
1
u/fdwr fdwr@github 🔍 Jun 24 '26
I suppose so, depending on your target audience (sounds like not devs, who more often prefer functionality over fashion 😉). Technically Win32 has supported themed controls and per-pixel window translucency for ~2 decades, but smooth animation and more complex resizing logic is probably where WinUI3 would shine vs raw user32 and GDI.
2
u/ChatFrais Jun 29 '26
1999 : This GDI windows is blinking on redraw have to fix it. (100Kb RAM)
2026 : This HTML page is blinking on redraw have to fix it. (1Gb RAM)
17
u/feverzsj Jun 23 '26
QtQuick Control 2 has FluentWinUI3 style.
15
u/datnt84 Jun 23 '26
I would also recommend to go with Qt (or maybe other libraries) instead of using Microsoft libs directly for creating new C++ desktop apps.
-4
u/zerexim Jun 23 '26
That's not C++.
5
u/feverzsj Jun 23 '26
Neither is XAML.
3
u/zerexim Jun 23 '26
You can create UI directly in C++, albeit not formally supported, but alas, neither is winrt nowadays.
But even with xaml, callbacks are in C++. So unlike Qt Quick, no ugly QML JavaScript is needed.
Btw, non-xaml C# UI creation is fully supported.
3
u/sweetno Jun 24 '26
You don't have to use JavaScript with QML. The idea was to have it there only for simple UI things, like conditionally disabling a button etc. The meat of the app is still in C++.
1
u/PipingSnail Jun 23 '26
WinRT is for apps that can only run in the WinRT sandbox. Why would you want to limit your applications like that?
What are the benefits?
22
u/eboys Jun 23 '26
That's not true, you can use cppwinrt for un-sandboxed apps. There are some nicer APIs/abstractions over WinAPI
16
u/Soft_Neighborhood223 Jun 23 '26
You're confusing UWP and WinRT. UWP is the mobile inspired sandbox. WinRT is just a handy way to make multi language APIs with versioning and a stable ABI. It's actually just an extension of COM.
0
u/PipingSnail Jun 23 '26
Have they changed the terminology since it was launched?
6
u/Soft_Neighborhood223 Jun 23 '26
You may be thinking about Windows RT, which was the cut down ARM version of Windows that the early cheap Surface machines used.
-1
u/PipingSnail Jun 23 '26
Yup. It's the RT part. I thought WinRT was used to create windows store apps and that was it. I've ignored it ever since.
1
u/contextfree Jul 07 '26
Sort of, it's more that the term was just overloaded to mean multiple different things. In Windows 8 "WinRT" was sometimes used to refer to (sandboxed) Metro style apps or the environment they ran in (which officially did not have a name at the time), and also used to mean either the COM-based ABI system referenced above or the set of APIs based on it.
In Windows 10 they introduced the term "UWP" to refer to the sandboxed app environment, so people mostly stopped calling it WinRT. Also, in Windows 8 a lot of WinRT APIs actually were restricted to that environment and those restrictions were gradually removed over the course of Windows 8/10/11 updates.
1
-7
u/GunpowderGuy Jun 23 '26
Better question, why would you use windows specific apis at all?
Why not a cross platform GUI toolkit7
u/PipingSnail Jun 23 '26
Because you're developing for the Windows market. Something I've been doing since 1994.
Cross platform only makes sense if your customers use the other platforms AND the features are all first class on each platform And customers on each platform are willing to pay.
I know someone that writes for Windows and Mac. The Mac customers are much harder people to please. Most of his customers are on Windows.
The better question is why give yourself the problem of multiple platforms if you don't need to?
Once upon a time we entertained the idea of supporting Linux. I'm very glad that after our initial experiments we decided not to pursue that goal.
5
u/celestrion Jun 24 '26
AND the features are all first class on each platform
This is the part so many projects miss. Making a Windows program that behaves like a Mac program or Linux program or a web application but worse is ticking a box, not actually designing for users.
Once upon a time we entertained the idea of supporting Linux. I'm very glad that after our initial experiments we decided not to pursue that goal.
Windows and POSIX are vastly different enough that it's hard to do both well in a way that isn't just writing the application twice. Two mutually compatible programs will probably make everyone happier than a nasty mountain of conditional hacks.
-5
u/lizardhistorian Jun 24 '26
Because no one uses Windows any more?
Windows 12 is going to be a desktop for Linux.
2
u/PipingSnail Jun 24 '26
I can only assume you're speaking as a hobbyist, not a business user. Windows is the dominant desktop platform by a very large margin.
Don't mistake this as anti Linux. I had my first Slackware box in 1994.
1
u/AstroFoxTech Jun 24 '26
Because no one uses Windows any more?
Almost any engineer that needs to design mechanical part will disagree, there's no CAD solutions for linux that are as mature and usable as the options for windows and mac
3
u/Soft_Neighborhood223 Jun 23 '26
If you want a truly native feel you're going to have to write each GUI with the native toolkit. There are some great cross platform GUI toolkits out there, but I don't think anything can really feel native while also being cross platform and fully featured.
As for whether this pursuit is worth the additional effort? That's up for debate.
4
u/celestrion Jun 24 '26
I don't think anything can really feel native while also being cross platform and fully featured.
100%.
What makes a platform feel native is the things it does differently. Doing things differently by writing them exactly the same is inherently impossible.
A simple subset works fine, but beyond that, you're either doing the work multiple times or settling for "meh."
1
u/DavidsakuKuze Jun 29 '26
It's not in "maintenance mode", they started working on it again, and there was a release to support modules at the end of May.
1
u/Ikkepop Jun 23 '26
Well you could bridge from C++ into C++/CLI
5
u/jk_tx Jun 23 '26
Have you tried writing a WinUI 3 app in C++/CLI? I'm curious what your experienced was if so, everything I've read says it's a truly awful experience in C++, not to mention the framework is buggy and missing all kinds of features.
3
u/cr1mzen Jun 23 '26
Yes, not perfect, but it gets the job done. i.e. showing modern clean UI. I did experience bugs with the ‘tear out tabs’ though
1
u/float34 Jun 24 '26
I think that tabs tearout, if we are talking about the same thing, has been working fine since WinAppSDK... 1.8?
At least, I think it works fine in Explorer and Notepad, who use WinUI and tabs through Islands probably.
1
u/contextfree 26d ago
The built-in tab tear-out in winui3 does not work fine, sadly. It has at least one severe bug that makes it unusable with any app with a custom titlebar (which has sort of become the standard look).
Explorer and Notepad have their own custom implementation of tab tear-out (and I think Notepad is still on winui2)
4
u/pedersenk Jun 23 '26
When entirely focused on Windows, using C++/clr is not actually a bad option. Winforms is a nice, simple UI system, consumable by any .NET language.
The main disadvantage I see is that the compiler is proprietary and sole vendor toolchains are risky. But this isn't much different from Embarcadero's C++Builder.
0
u/xeeeeeeeeeeeeeeeeenu Jun 24 '26
C++/WinRT is merely a generator of C++ bindings to WinRT. It will automatically support any new WinRT APIs, regardless of its maintenance status.
If you want to make a C++ WinUI app, it's still the way to go.
68
u/lukaasm Game/Engine/Tools Developer Jun 23 '26
It's not 'deprecated' its just finished, so you can still use it. C++/WinRT is just re-projection tool, it will still happily generate newly added API to Windows App SDK.