Windows 10 SDK Preview Build 17763 released.
Support get_strong and get_weak to create delegates: This update allows a developer to use either get_strong or get_weak instead of a raw this pointer when creating a delegate pointing to a member function.
Add async cancellation callback: The most frequently requested feature for C++/WinRT’s coroutine support has been the addition of a cancellation callback.
Simplify the use of APIs expecting IBuffer parameters: Although most APIs prefer collections or arrays, enough APIs rely on IBuffer that it should be easier to use such APIs from C++. This update provides direct access to the data behind an IBuffer implementation using the same data naming convention used by the C++ standard library containers. This also avoids colliding with metadata names that conventionally begin with an uppercase letter.
Conformance: Improved support for Clang and Visual C++’s stricter conformance modes.
Improved code gen: Various improvements to reduce code size, improve inlining, and optimize factory caching.
Remove unnecessary recursion: When the command line refers to a folder rather than a specific winmd, cppwinrt will no longer search recursively for winmd files. It causes performance problems in the OS build and can lead to usage errors that are hard to diagnose when developers inadvertently cause cppwinrt to consume more winmds than expected. The cppwinrt compiler also now handles duplicates more intelligently, making it more resilient to user error and poorly-formed winmd files.
Declare both WINRT_CanUnloadNow and WINRT_GetActivationFactory in base.h: Callers don’t need to declare them directly. Their signatures have also changed, amounting to a breaking change. The declarations alleviate most of the pain of this change. The change is necessitated by the fact that C++/WinRT no longer depends on the Windows headers and this change removes the dependency on the types from the Windows headers.
Harden smart pointers: The event revokers didn’t revoke when move-assigned a new value. This lead me to take a closer look at the smart pointer classes and I noticed that they were not reliably handling self-assignment. This is rooted in the com_ptr class template that most of the others rely on. I fixed com_ptr and updated the event revokers to handle move semantics correctly to ensure that they revoke upon assignment. The handle class template has also been hardened by the removal of the implicit constructor that made it easy to write incorrect code. This also turned bugs in the OS into compiler errors fixed in this PR.
Support for non-WinRT interfaces is disabled by default. To enable, simply #include <unknwn.h> before any C++/WinRT headers.
winrt::get_abi(winrt::hstring) now returns void* instead of HSTRING. Code requiring the HSTRING ABI can simply use a static_cast.
winrt::put_abi(winrt::hstring) returns void** instead of HSTRING*. Code requiring the HSTRING ABI can simply use a reinterpret_cast.
HRESULT is now projected as winrt::hresult. Code requiring an HRESULT can simply static_cast if you need to do type checking or support type traits, but it is otherwise convertible as long as <unknwn.h> is included first.
GUID is now projected as winrt::guid. Code implementing APIs with GUID parameters must use winrt::guid instead, but it is otherwise convertible as long as <unknwn.h> is included first.
The signatures of WINRT_CanUnloadNow and WINRT_GetActivationFactory has changed. Code must not declare these functions at all and instead include winrt/base.h to include their declarations.
The winrt::handle constructor is now explicit. Code assigning a raw handle value must call the attach method instead.
winrt::clock::from_FILETIME has been deprecated. Code should use winrt::clock::from_file_time instead.
It’s finally here! You can now package your applications as MSIX! These applications can be installed and run on any device with 17682 build or later.
To package your application with MSIX, use the MakeAppx tool. To install the application – just click on the MSIX file
We’ve made some important changes to the C/C++ ETW code generation of mc.exe (Message Compiler):
The “-mof” parameter is deprecated. This parameter instructs MC.exe to generate ETW code that is compatible with Windows XP and earlier. Support for the “-mof” parameter will be removed in a future version of mc.exe.
As long as the “-mof” parameter is not used, the generated C/C++ header is now compatible with both kernel-mode and user-mode, regardless of whether “-km” or “-um” was specified on the command line. The header will use the _ETW_KM_ macro to automatically determine whether it is being compiled for kernel-mode or user-mode and will call the appropriate ETW APIs for each mode.
- The only remaining difference between “-km” and “-um” is that the EventWrite[EventName] macros generated with “-km” have an Activity ID parameter while the EventWrite[EventName] macros generated with “-um” do not have an Activity ID parameter.
The EventWrite[EventName] macros now default to calling EventWriteTransfer (user mode) or EtwWriteTransfer (kernel mode). Previously, the EventWrite[EventName] macros defaulted to calling EventWrite (user mode) or EtwWrite (kernel mode).
- The generated header now supports several customization macros. For example, you can set the MCGEN_EVENTWRITETRANSFER macro if you need the generated macros to call something other than EventWriteTransfer.
- The manifest supports new attributes.
- Event “name”: non-localized event name.
- Event “attributes”: additional key-value metadata for an event such as filename, line number, component name, function name.
- Event “tags”: 28-bit value with user-defined semantics (per-event).
- Field “tags”: 28-bit value with user-defined semantics (per-field – can be applied to “data” or “struct” elements).
- You can now define “provider traits” in the manifest (e.g. provider group). If provider traits are used in the manifest, the EventRegister[ProviderName] macro will automatically register them.
- MC will now report an error if a localized message file is missing a string. (Previously MC would silently generate a corrupt message resource.)
- MC can now generate Unicode (utf-8 or utf-16) output with the “-cp utf-8” or “-cp utf-16” parameters.
The SDK headers are generated with types in the “ABI” namespace. This is done to avoid conflicts with C++/CX and C++/WinRT clients that need to consume types directly at the ABI layer. By default, types emitted by MIDL are *not* put in the ABI namespace, however this has the potential to introduce conflicts from teams attempting to consume ABI types from Windows WinRT MIDL generated headers and non-Windows WinRT MIDL generated headers (this is especially challenging if the non-Windows header references Windows types).
To ensure that developers have a consistent view of the WinRT API surface, validation has been added to the generated headers to ensure that the ABI prefix is consistent between the Windows headers and user generated headers. If you encounter an error like:
5>c:\program files (x86)\windows kits\10\include\10.0.17687.0\winrt\windows.foundation.h(83): error C2220: warning treated as error – no ‘object’ file generated
5>c:\program files (x86)\windows kits\10\include\10.0.17687.0\winrt\windows.foundation.h(83): warning C4005: ‘CHECK_NS_PREFIX_STATE’: macro redefinition
5>g:\<PATH TO YOUR HEADER HERE>(41): note: see previous definition of ‘CHECK_NS_PREFIX_STATE’
It means that some of your MIDL generated headers are inconsistent with the system generated headers.
There are two ways to fix this:
- Preferred: Compile your IDL file with the /ns_prefix MIDL command line switch. This will cause all your types to be moved to the ABI namespace consistent with the Windows headers. This may require code changes in your code however.
- Alternate: Add #define DISABLE_NS_PREFIX_CHECKS before including the Windows headers. This will suppress the validation.
Windows App Certification Kit
When testing your app with the Windows App Certification Kit, the test may crash if your app includes 2 or more TargetDeviceFamily entries in the Package.appxmanifestfile. For example:
You can work around the issue by removing one of the TargetDeviceFamily entries.
Read more about API Updates, Additions and Removals here.