Modern C++ for the Windows Runtime

C++/WinRT in the Windows SDK

The first step toward full C++/WinRT support within Visual Studio and the eventual retirement of C++/CX happened today with the availability of build 17025 of the Windows SDK Insider Preview. With this update it means that you no longer need to download or clone the C++/WinRT repo on GitHub and can simply #include the appropriate headers from within any C++ project. What this also means is that you no longer need to wait for us to update GitHub following the release of a new Windows SDK. Indeed, we will no longer be publishing the updated headers on GitHub at all since you can get them directly from the Windows SDK.

If you look inside the Windows SDK include folder for build 17025 you’ll notice a new cppwinrt folder.

As full Visual Studio integration is still on the way, there are a few things you need to be mindful of. First, you need to make sure that the Windows SDK Version in the project is set to 17025 or later. New projects will default to this, but existing projects may need to be updated.

Second, C++/WinRT relies on C++17 language features and as such you need to tell Visual C++ that your project requires the C++17 language standard. This may soon be the default as well.

At this point, you can simply #include any of the C++/WinRT headers and start writing code! 🙂

If you prefer, you can also link to the windowsapp lib via the project settings rather than the pragma above.

Building from the command prompt won’t work yet as Visual Studio itself needs an update to pick up the cppwinrt folder.

Unfortunately, the cppwinrt.exe tool itself did not make it into this build of the Windows SDK. You should expect that in the next update, hopefully later this month. At that point you will also have the ability to generate your own headers and try the experimental support for component authoring. Until then, I hope you enjoy the new Windows SDK experience.

Oh, I’m a little sad that this means the GitHub repo will be deprecated. I was under the impression that cppwinrt will be an opensource project. I understand that 90% of it is just projection of the current SDK, but there’s still value in building excitement for it through the opensource community.

We’re not giving up on GitHub or open source. Today we only publish the headers produced by the cppwinrt.exe compiler as well as some samples on GitHub. The samples will remain, but the headers will be available through the Windows SDK. In future, we’d like to open source the cppwinrt.exe compiler itself. That would naturally find its way on to GitHub as well.

Great stuff! Question, is there a fundamental reason why the windows sdk, driver sdk, and others have to be released as proprietary executable/installers? Are there reasons it can never be packaged and delivered via package managers like other libraries?

Thanks for forwarding it along. Since I posted, I spent a day trying to package it, but I realized that as long as it’s an MSI, it’s unadvisable. I might have been able to to get things reasonably automated, and get the package to capture all the apparent source and header files. However, even if I did, there’s no way to tell what unforeseen pitfalls await users due to missing “magic” that the installer does that I might not (I.E. in registry/environment variables/user profile/etc). With something this big, if it’s not canonical from the vendor, it represents a risk. If you don’t mind, it would be great if you could copy Robert Schumacher from the VCPKG team on that communication. I believe that within Microsoft, he probably has the best handle on the C/C++ packaging landscape right now, and what the community would need to make the SDK open to different packagers.

You should be able to use the newer SDK to target older versions of Windows 10. Although the Insider SDKs will only install on Insider builds of Windows, you can copy the project and headers (from GitHub for example) onto any Windows 10 machine running Visual Studio 2017 and it should work just fine.

I tried my best to get the sample running. So far I got the connection from the UWP-Process but my successfully registered event handlers are not called. The UWP process then crashes because the response contains no string.

The compiler error has to do with the fact that you have a co_await expression inside a function that’s not a coroutine. You need to use a coroutine type, such as Windows::Foundation::IAsyncAction, for that to work.

Regarding Desktop Bridge, I have been meaning to put a sample together. This is a popular request and I’ll hopefully get to it soon.

One problem that I encountered: as the event_revoker has an operator bool() I should be able to do this:
if(myStuff.requestReceivedToken)
wcout << “Successfully registered requestReceivedToken.” << endl;

but I got this compile error:
binary ‘!=’: no operator found which takes a left-hand operand of type ‘const winrt::weak_ref‘

Again, thank you very much for the help!

BTW, is it better to ask such question as an issue of the cppwinrt GitHub-Repo?