Microsoft issued Windows 10 Preview SDK Build 17754 that includes a bunch of bug fixes and improvements. features. The limelight of this update is C++/WinRT Update for build 17709, new attributes, Better code gen, and other. You may encounter a few errors on the SDK build kept under the known issues but you get this palliated in the upcoming release.
This SDK edition will work in conjunction with minimum Windows 10 Insider Build 17754. You can download the update from the Developer mode field of Windows Settings.
Windows 10 Preview SDK Build 17754 –
Table of Contents
Windows 10 Preview SDK Build 17754 Fixes and Improvements, Changes Details
Important points
Windows 10 Preview SDK Build 17754 works in conjunction with earlier promulgated SDKs and Visual Studio 2017. You are able to install this Developer kit and yet also continue to submit your applications that target Windows 10 V1803 or previous to the store.
You can get script access to the SDK through the following URL: https://go.microsoft.com/fwlink/?prd=11966&pver=1.0&plcid=0x409&clcid=0x409&ar=Flight&sar=Sdsurl&o1=17754 once the static URL is published.
C++/WinRT Update for build 17709
This update comes up with multiple changes and fixes for C++/WinRT. Significantly, it started the ability to build C++/WinRT and this is not having a dependency on the Windows SDK. The feature lets the repository, not itself include any Windows headers. Thus, a developer becomes able to typically pull in a smaller number of or no dependencies inadvertently. So C++/WinRT developer must guard against fewer macros. The portability and standard of Now C++/WinRT are increased and onward they are trying to make it a cross-compiler and cross-platform library. This also indicates that macros can’t mangle C++/WinRT headers. Now you will need to include various Windows headers on your own instead of relying on C++/WinRT. It is always supposed to be good practice to add headers you depend on explicitly and not rely on another library.
Windows 10 Preview SDK Build 17754 Highlights
SDK Build 17754 Supports get_strong and get_weak – You can apply “get_strong” moreover “get_weak” in place of a raw this pointer at the time of developing a delegate pointing to a member function.
Add async cancellation callback – Plenty of developers were requesting repeatedly for C++/WinRT coroutine support. This has been the addition of a cancellation callback.
Make the APIs expecting IBuffer parameters easier – However, maximum Application Programming Interfaces would rather choice collections or arrays, enough rely on IBuffer that it should be simpler to use from C++. This build gives straight access to the data behind the application of IBuffer with the identical data naming convention applied by the C++ standard library containers. The method prevents the collision with metadata names that conventionally start with an uppercase letter.
Conformance – The present build provides better support for Clang including Visual C++’s stricter conformance modes.
Better code gen – You will find different changes to decrease code size, increase inlining, and optimize factory caching.
The build eliminates useless recursion – If command targets to a folder instead of a particular winmd, cppwinrt willn’t search recursively for winmd files. This creates performance issues in OS build and can start usage errors that are hard to detect. It occurs if developers inadvertently try cppwinrt to use winmds in a greater extent than expected. You must be happy to know that the cppwinrt compiler also now manages duplicates more intelligently. For this purpose, the compiler makes it more flexible to user error and bad winmd files.
Declare both “WINRT_CanUnloadNow” as well as “WINRT_GetActivationFactory in base.h”: – After receiving the update, callers no longer require to declare them directly. Caller’s signatures have gone altered, amounting to a breaking change. The changes are made because of the C++/WinRT that will not depend on the Windows headers. These modifications remove the dependency on the types from the Windows headers.
Strengthen smart pointers – The current update solved com_ptr and updated the event revokers to manage move semantics properly to confirm that they revoke upon assignment. It also hardened the class template by removing the implicit constructor.
Windows 10 Preview SDK Build 17754 Breaking Changes
Windows SDK Developers let you enable the support for non-WinRT interfaces in this build. In this concern, Just #include <unknwn.h> prior to any C++/WinRT headers.
“winrt::get_abi(winrt::hstring)” further returns void* replacing “HSTRING”. The Code that needs the HSTRING ABI can barely use a static_cast.
“winrt::put_abi(winrt::hstring)” returns void** in the place of HSTRING*. The code that requisites the HSTRING ABI can just apply a reinterpret_cast.
Windows 10 Preview SDK Build 17754 projects winrt::hresult for HRESULT. The code that needs an HRESULT can only static_cast if you want to do type checking or support type traits. But it is otherwise convertible so long as <unknwn.h> is included first.
The build projects winrt::guid for GUID. That’s why the code that implements APIs with GUID parameters must input winrt::guid, but it is alternatively convertible so long as <unknwn.h> is included first.
In the SDK build, “WINRT_CanUnloadNow” and “WINRT_GetActivationFactory” Signatures have altered. Therefore code must avoid the declaration of these functions and but include winrt/base.h to include their declarations.
After the arrival of Windows 10 Preview SDK Build 17754, winrt::handle constructor is explicit. So the code that assigns a raw handle value must call the attach method.
“winrt::clock::from_FILETIME” has been deprecated. Hence, the code should apply winrt::clock::from_file_time.
What’s New in Windows 10 Preview SDK Build 17754
MSIX Support
Windows 10 Preview SDK Build 17754 facilitates you to package your applications as MSIX! You are able to install these applications and run on any device running build 17682 or later.
The MakeAppx tool comes as a utility to install the application. Simply click the MSIX file. Follow this video to learn – MSIX: Inside and Out.
MSIX is presently not supported by the App Certification Kit (ACK) nor the Microsoft Store.
MC.EXE
The SDK developers input some improvements into the C/C++ ETW code generation of mc.exe –
In Windows 10 Preview SDK Build 17754, -mof parameter is deprecated. This makes MC.exe develop ETW code compatible with Windows XP and former. The feature will be terminated in a future edition of mc.exe.
C/C++ header is compatible with kernel-mode as well as user-mode until the -mof parameter is not used. This does not care for whether -km or -um was specified on the command line. In this process, header will apply the _ETW_KM_ macro to itself detect whether kernel-mode or user-mode is going to use it. This will call the suitable ETW APIs for each of both modes.
The sole dissimilarity between -km and -um. This is EventWrite[EventName] macros generated with -km includes an Activity ID parameter. Whereas EventWrite[EventName] macros generated with -um does not include an Activity ID parameter.
After Windows 10 Preview SDK Build 17754, The “EventWrite[EventName] macros” fuctions as a default to call EventWriteTransfer user mode or kernel mode.
The new header onwards supports multiple customization macros. You can configure the MCGEN_EVENTWRITETRANSFER macro if you want the generated macros to call anything different from EventWriteTransfer.
The manifest supports new attributes.
Event name – non-localized event name.
Event attributes – extra key-value metadata for an event, for example, file name, line number, component, and function name.
Event tags indicate 28-bit value along with user-defined semantics (in accordance with event).
Field tag – 28-bit value moreover with user-defined semantics (for each -field – can be applied to data or struct elements).
You are able to now define provider traits in the manifest (aka provider group). The “EventRegister[ProviderName] macro” will register without your effort when you utilize provider traits in the manifest.
MC will now show an error when a localized message file is absent in a string.
MC can now provide Unicode (UTF-8 or UTF-16) output with the -cp utf-8 or -cp utf-16 parameters.
Known Issues
Once you obtain Windows 10 Preview SDK Build 17754 on your machine, the headers are developed with types in the ABI namespace. This prevents clashes with “C++/CX” and “C++/WinRT” clients that require to expend types straight at the “ABI layer[1]”. With the built-in configuration, types emitted by MIDL are *not* put in the ABI namespace. Although, this has the verisimilar to outset conflicts from teams attempting to eat ABI types from Windows WinRT MIDL and non-Windows WinRT MIDL generated headers.
To make sure that developers have a persistent look over the WinRT API surface, Microsoft has added validation to the generated headers. This will confirm that the ABI prefix is invariable between the Windows 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 indicates that certain MIDL developed headers are not consistent with the system generated headers.
There are two methods to fix this –
1st choice – Compile your IDL file with the /ns_prefix MIDL command line switch. This method will send all your types to the ABI namespace consistent with the Windows headers. This may require changes in your code, however.
2nd choice – Add “#define DISABLE_NS_PREFIX_CHECKS” prior to including the Windows headers. This method will suppress the validation.
Source – Windows Developer blog.