The State of C++ on Windows

As the 2019 State of the Union Address appears to be postponed, I thought I would offer you the State of C++ on Windows instead!

C++ continues to be an important programming language in general and the only systems programming language of any consequence on the Windows platform. The Visual Studio 2019 release has some incredible improvements that I hope to share more about in the coming weeks, but right now I want to give you an update on the state of C++/WinRT.

C++/WinRT continues to gain adoption as developers eschew WRL and C++/CX in favor of modern and standard C++. You may have heard that the Windows UI Library was recently open sourced. Did you also notice that it is written entirely in C++/WinRT? That’s just one high-profile example, but there are many teams that have made the switch and we are strongly discouraging anyone from using WRL or C++/CX going forward.

Even as C++/WinRT is used to implement large parts of Xaml, adoption of C++/WinRT for building Xaml apps is slow. It helps to recognize that there are three categories or scenarios where C++/WinRT comes into play most frequently.

1. Using or calling Windows APIs (otherwise known as consuming WinRT types)
2. Authoring Windows APIs (otherwise known as producing WinRT types)
3. Authoring Xaml apps and controls

The first one involves making API calls using C++/WinRT to do things like communicate using Bluetooth, stream and present video, integrate with the Windows shell, and so on. The second involves authoring APIs that provide such capabilities, the graphics APIs, the storage and file system APIs, the networking APIs, and so on. The third involves writing apps and controls built on the Xaml framework. While Xaml is just one of those APIs, it is the dominant UI framework on Windows today and it has an outsized influence over WinRT, so it deserves its own category.

C++/WinRT fully and uncompromisingly supports the first category. Authoring brand new WinRT APIs is a little more involved because a developer must use IDL to define the shape of the API before the developer can implement the API. This is however not substantially more complicated than using C++/CX and, given the many benefits of using C++/WinRT, developers are generally very happy with the trade. It is the third category where things fall apart. Xaml was designed for .NET and assumes and effectively requires reflection to function as intended. While you can write Xaml apps with C++/WinRT, it is pretty cumbersome. This is where the C++ reflection proposal would be very valuable.

Still, I am hopeful that we can turn that around. It pains me that Windows does not have a good UI story for C++ developers. C++ reflection may well help to solve that problem in the long run, but we cannot wait for that to arrive, so we are also exploring some other options that may prove useful in the near future. Some of those include alternative approaches to Xaml that does not require reflection, as well as discussions with DevDiv to get Visual Studio to do a better job of supporting a C++/WinRT developer experience.

Stay tuned for more on C++/WinRT and xlang. A lot has been going on – I’ve just been heads down getting it done, but I plan to start writing again and sharing some of the work that we’ve been doing.

Next: build your first console app (nothing to do with UWP) with xlang and C++/WinRT.

19 thoughts on “The State of C++ on Windows

  1. MT

    There is a good C++ solution for windows – Qt. It has for many years been vastly better than any of the official windows offerings

  2. Niall Daly

    So NOW in C++ we are told we can call Win API’s 2019. We have being doing this with VB5 and VB6 for years and people critisised VB for doing so. Just saying… Is this progress???

  3. J. Kelly Wilkerson

    Borland/Inprise/Borland/CodeGear/Embarcadero/Idera’s C++Builder has a really good UI/UX development framework that it shares with Delphi and isn’t driven by XAML. Why can’t Visual C++ have the same or similar UI development semantics as the different iterations of Visual Basic? WinForms kicks the crap out of XAML in terms of ease of use and quickness of getting a UI put together. Even with .NET, the big push to XAML really isn’t warranted since the use of WinForms is so prevalent; developers of LOB applications have been creating UI’s for their respective companies for decades now using WinForms, and having learn a new way to put a UI together because of XAML being pushed so hard by Microsoft is an extreme waste of resources. Rolling WinForms back into the mix and including it into the Visual C++ toolset would solve the C++ UI issue nearly immediately. XAML isn’t needed or necessary in order for Visual C++ to create functional user friendly interfaces. The .NET Framework for C++ isn’t necessary either. It just adds a layer of complexity to what should be simple and fast…put together a simple user interface to run really fast code on Windows.

  4. Mark S.

    The only thing really driving me toward XAML (and in my case, wpf) from WinForms is the prevalence of higher DPI screens. WinForms doesn’t [visibly] scale well.

    1. Kenny Kerr Post author

      I loved Windows Forms. Unfortunately, it was a .NET technology and I prefer a native solution. When I need a UI today, I tend to use Windows Composition along with Direct2D and DirectWrite. Has great DPI support. Admittedly not a great story for LOB apps.

  5. Max Yaffe

    What is the connection between C++/WinRT and COM? In Microsoft’s Introduction to C++/WinRT they make a big deal about this. “The Windows Runtime is based on Component Object Model (COM) APIs, and it’s designed to be accessed through language projections. A projection hides the COM details, and provides a more natural programming experience for a given language.”
    Should one be writing nouvelle COM wrappers around C++ classes to make the transition to C++/WinRT easier? Since COM provides a reflection mechanism, should it be called into service for XAML?
    BTW, I agree about Qt. If they could just get their licensing model straightened out…

  6. PELock

    State of C++ for Windows is pathetic, I can’t remember when I wrote C++ UI app for Windows last time, I remember you used to write cool UI apps and now you’re an advocate of some strange technologies nowhere to be found in real world applications. Nobody is using it except Microsoft itself, I don’t know a single developer using WinRT in C++ and I know plenty of devs. You should see how Embarcadero does it to encourage developers get back to Windows platform, you should thank them. Qt is there like @MT said, why do we need this monstrosity from Microsoft? You’re just adding layers and layers of interfaces and technologies nobody understands, nobody uses and nobody wants. And when we will start using it Microsoft will probably forgets about it and make it obsolete like they did to Silverlight and WinForms (someone must fall on his head to leave WinForms without major updates for so long).

    Why would anyone even use WinRT if it’s not backward compatible? I want my applications to be compatible, what’s wrong with that? And you force us to use technology that will lock us down to latest OS system, who in their right mind would write an app like this and cut himself from any other potential customers running older version of Windows?

    What are the pros Kenny?

    That’s why people started to write resource hogs like the Electron apps, because they couldn’t do it in Visual Studio in a simple way, WPF is a such an UI disaster I feel stressed out whenever I need to use it. Use it with C++? Please. I just want to code and not to spend half of my time wondering how to read checkbox state. If you look at StackOverflow you will find many similar voices about WinRT, WPF & XAML. Nobody wants it.

    If Qt lower their prices, Microsoft with their “innovative” technologies would be gone very shortly.

    Kenny, maybe if you could show us some real world usages of the technologies you are talking about – you might convince us, but this blog and your technical articles are so confusing to me and I suppose for others too.

    1. Kenny Kerr Post author

      Wow, that’s a lot of frustration. Firstly, I have nothing to do with Xaml. That’s a separate team. I don’t work on Xaml and clearly know very little about it as I’ve never used it and have never written about it. If you read some of my “confusing articles” you might have noticed. 😉

      WinRT is not a UI technology. It is just the evolution of COM, a way for components and apps to communicate over a stable ABI. C++/WinRT just makes that technology approachable for standard C++ developers. As for backward compatibility, it works all the way down to Windows 8. We even announced an initiative called xlang to bring something like WinRT to Windows 7 as well as other platforms.

      As for real world uses, Windows relies very heavily on WinRT. The Windows shell, the Xbox shell, many new apps from Microsoft and others rely on WinRT to light up cool Windows features. And many 3rd party apps like Adobe Photoshop and Spotify rely on C++/WinRT to work great on Windows.

  7. Alastair

    Kenny, I have been following this work for a while now and whilst I think it’s amazing what you have done I really can’t see (currently) how I would ever use it.

    For reference I maintain a number of complex Windows desktops apps that use MFC and are 100% C++ with lots of OpenGL/Direct 2D etc. Whilst MFC is ancient and poorly supported – rather like WinForms – it does enable me to “quickly” create dialogs for the LOB side of things whilst the nicer things are done using OpenGL/D2D etc. If you keep a lot of the MFC just for the UI layer then it isn’t awful.

    We have over the years resisted moving anything to .NET as we don’t want to have a glue layer from the UI to the C++ code (we did experiment with C++/CLI for a while but that was not fun)

    Now, one of the reasons we can’t even consider UWP is we still have a huge number of clients on < W10 and until this changes we are basically stuck as I see it.

    What I guess I am asking is when will we have something that seriously replaces MFC for desktop C++ apps? The standard response most people say is use QT but we really don't want to go down that route as the licencing is not overly friendly as I understand it. But what is the selling point of using this given I believe the UI tooling side of things isn't (currently) great?

    I have this horrible feeling I will be stuck on good old MFC for the rest of my days!


    1. J. Kelly Wilkerson

      Alastair – you may want to consider C++Builder from Embarcadero; you can try C++Builder Community Edition to see if it fits. You’ll have to get used to the tooling as it’s completely different than that of Visual Studio. But, it supports C++17 and can be used to create truly native applications for macOS, iOS, Android, Linux, and of course Windows. And, using either there VCL or FireMonkey libraries, you can create applications for Windows 7 (32 & 64 bit) as well as Windows 10 Anniversary Edition (and later) Windows Store apps (.appx files) through the Centennial Bridge. If MFC is only being used for UI/UX, moving that portion of an application to C++Builder shouldn’t be a terrible stretch.

      1. Alastair

        Will admit I have never heard of it before.

        At this point in time I really can’t see the point in rewriting the UI unless I was sure I was backing the right horse and I would get some tangible benefits other than working on a more modern technology than MFC. What would be nice is perhaps for MS to open source MFC so we can get some C++11/14/17 things it it. Or some modern replacement that would be fully supported by MS.

        As I mentioned I have in the past looked at QT but the licencing put me off (and the fact it didn’t at the time look like native Windows UI

      2. J. Kelly Wilkerson

        Honestly, it’s not a more modern technology than MFC. C++Builder was first released by Borland in February 1997. It uses the same IDE as Delphi and was released in tandem with Delphi 3 (which itself was released in 1995 and is currently on version 26). Borland changed it’s name to Inprise, then back to Borland, was purchased by CodeGear, then by Embarcadero Technologies. But, they have a steady release cycle and it’s well supported. I’ve been using their Delphi product for years, well since Delphi originated – moving from Turbo Pascal for Windows back in the day. I totally understand not wanting to rewrite a UI, but I really think you’d get some hugely tangible benefits. For instance, the whole multi-platform opportunity for one – from a single set of source code. I’ve used and still use Visual Studio and .Net for some things, but for many new applications, I’ve moved back to Delphi simply for the cross-platform opportunity (and ability to write nice, native REST APIs that can be consumed over HTTP.) I’m just a paying customer for both Microsoft MSDN Enterprise and Embarcadero’s RAD Studio Enterprise, so I don’t “have a dog in the hunt” so to speak. Just sharing a bit of info.

Comments are closed.