Windows 10 SDK Preview Build 17758 arrived to work in conjunction with Windows 10 Build 17758 or later. The new kit version includes bug fixes, underdevelopment changes, features, and improvements to the API surface area. Since the Build 17444, Microsoft has removed some APIs and gives you a list here.
You can receive Windows 10 SDK Preview Build 17758 from the developer section on Insider. They offer you to request, submit an issue, and feedback on the Uservoice platform.
Table of Contents
Windows 10 SDK Preview Build 17758 Details of Changes, Fixes and Improvements
Important things
This current update will work in conjunction with the earlier release of SDKs including Visual Studio 2017. You are able to install this SDK and nevertheless also submit your apps that target Windows 10 1803 or previous to the store.
The Windows Software Developer’s Kit will now formally only be supported by Visual Studio 2017 and the subsequent. You can download the Visual Studio 2017 here.
This Windows SDK build will onward install on Insider Preview builds and supported Windows OS.
With a view to assisting with script access, the ISO can also be accessed through this link.
C++/WinRT Update for build 17709 and later
Windows 10 SDK Preview Build 17758 initiates several improvements and fixes for C++/WinRT. Most important, it comes up with the capability of building C++/WinRT without taking a help of any dependency on the Windows SDK. This is not specifically intriguing to the developer, but even in the OS repository, it gives benefits because it does not itself comprises any Windows headers. Thus, a developer will typically pull in fewer or no dependencies involuntarily. This also indicates a considerable decrease in the number of macros that a C++/WinRT developer must take care of. Therefore, C++/WinRT is onward more portable and standards compliant and ahead Microsoft is trying to to make it a cross-compiler and cross-platform library. Moreover, Macros can never mangle C++/WinRT headers. You will have to include different Windows headers yourself. You know that including them without depending on another library is better.
Windows 10 SDK Preview Build 17758 Highlights
The current build Support get_strong and get_weak to create delegates – This update lets a developer use “get_strong” or “get_weak” replacing a raw this pointer. This is useful when creating a delegate pointing to a member function.
Add async cancellation callback – Developers has been consistently demanding the feature. Cancellation callback has the extension of C++/WinRT coroutine support.
The SDK build makes the use of APIs expecting IBuffer parameters more comprehensible – This update offers straight access to the data behind an IBuffer implementation using the same data naming convention used by the C++ standard library containers. This also restricts the collision of metadata names that conventionally starts with an uppercase letter.
Conformance – The update provides a better support for Visual C++ stricter conformance modes and Clang.
The update has Improved code gen – Different changes to decrease code size, provide a better inlining moreover optimize factory caching.
Cut needless recursion: When the command line targets a folder instead of a particular winmd, cppwinrt will not search recursively for “winmd” files. It causes performance issues in the Windows build and can lead to usage errors. These are rigorous to detect when developers inadvertently utilize cppwinrt to consume more winmds than expected. After the improvement, the cppwinrt compiler also now manages duplicates more wisely. The change makes it more flexible to user error and poor-formed winmd files.
This update declares both “WINRT_CanUnloadNow” and “WINRT_GetActivationFactory” in base.h – After the advent of this SDK build, callers are free of declaring them directly. Their signatures have also altered, amounting to a breaking change. The declarations reduce most of the pain of this change. The change was necessary because C++/WinRT no longer depends on the Windows headers. This improvement eliminates the dependency on the types from the Windows headers.
Strengthen smart pointers – After the arrival of Windows Preview SDK Build 17758, event revokers didn’t revoke when move-assigned a new value. Microsoft fixed this error after a proper investigation.
Windows 10 SDK Preview Build 17758 Breaking Changes
In Windows 10 SDK Preview Build 17758, support for non-WinRT interfaces is not enabled by built-in configuration. To enable, just #include <unknwn.h> previous to any C++/WinRT headers.
winrt::get_abi(winrt::hstring) thereon returns void* rather than HSTRING. The code that requires the HSTRING ABI can directly use a static_cast.
winrt::put_abi(winrt::hstring) returns void** in lieu of HSTRING*. The code that requires HSTRING ABI can straightway use a reinterpret_cast.
HRESULT is further projected as winrt::hresult. The code that requires an HRESULT can just 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.
The globally unique identifier is now projected as winrt::guid.. The code that implements APIs with GUID parameters rather uses winrt::guid. But the same is otherwise convertible so long as <unknwn.h> is included initially.
“WINRT_CanUnloadNow” furthermore “WINRT_GetActivationFactory” Signatures has changed. Code does not require to declare these functions at all and alternatively include winrt/base.h to add their declarations.
The winrt::handle constructor is presently explicit. Code assigning a raw handle value requires calling the attach method instead.
winrt::clock::from_FILETIME is now deprecated. Code should bring winrt::clock::from_file_time into use rather.
What’s New in Windows 10 SDK Preview Build 17758
MSIX Support
You should bring MakeAppx tool into use to package your application with MSIX. For starting the installation simply click on the MSIX file.
In Windows Preview SDK Build 17758, you are able to package your applications dev as MSIX! To install the application – just click on the MSIX file. To know more about MSIX, watch the introductory video located here.
You can submit Feedback and comments on the MSIX Community.
MC.EXE
Windows Preview SDK Build 17758 comes up with some consequential changes to the C/C++ ETW code generation of mc.exe –
The -mof parameter has been deprecated in this update. This “.mof'” parameter guides MC.exe to generate ETW code that is supportive for Windows XP and previous. The Support for the – mof parameter will be eliminated in a forthcoming version of mc.exe.
While you will not use the“-mof parameter, the C/C++ header is now compatible with both kernel and user-mode as well. You don’t need to specify “-km” or “-um” on the command line for this. The header will apply the _ETW_KM_ macro to itself check whether it is being compiled for user or kernel-mode. This will call the applicable ETW APIs for each mode.
There is only one difference between “-km” and “-um”. The EventWrite[EventName] macros generated with “-km” have an Activity ID parameter while the EventWrite[EventName] macros don’t.
In SDK Build 17758, the “EventWrite[EventName]” macros pay a role of the default with a view to call either “EventWriteTransfer” (user mode) or “EtwWriteTransfer” (kernel mode). Earlier, the EventWrite[EventName] macros were the default for the same.
The generated header will further support multiple customization macros. For instance, you have the option to set the “MCGEN_EVENTWRITETRANSFER” macro if you want that the generated macros should call anything else than EventWriteTransfer.
“The manifest supports new attributes”.
Event “name”: non-localized event name.
Event “attributes”: additional key-value metadata for an event, for example, 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. If provider traits are applied in the manifest, the EventRegister[ProviderName] macro will itself register them.
MC will further inform an error if a localized message file is losing a string (Earlier MC would doggo generate a corrupt message resource.)
Message Compiler can now generate Unicode (UTF-8 or UTF-16) output with the “-cp utf-8” or “-cp utf-16” parameters.
Windows 10 SDK Preview Build 17758 Known Issues
In the current build, headers are generated with types in the ABI namespace. The execution minimizes conflicts between C++/CX and C++/WinRT clients that need to consume types straight at the ABI layer[1]. With the built-in configuration, types threw out by MIDL are *not* put in the ABI namespace. Despite this has the potential to create conflicts from teams trying to consume ABI types from the headers generated by Windows WinRT MIDL moreover non-Windows WinRT MIDL.
Confirming developers to have a consistent view of the WinRT Application Programming Interface, validation has been included to the generated headers. This also ensures that the ABI prefix is consistent in the middle of the Windows headers and user generated headers. If you confront an error such as:
“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:\(41)”: note: see previous definition of “CHECK_NS_PREFIX_STATE”.
It indicates that certain MIDL generated headers remain inconsistent in the respect to the system generated headers.
There are two ways to fix this:
- Compile your IDL file with the /ns_prefix MIDL command line switch. This will move entire all types to the ABI namespace consistent with the Windows headers. You will, however, need to change the code.
- “Add #define DISABLE_NS_PREFIX_CHECKS” prior to including the Windows headers. This method will suppress the validation.
Windows 10 SDK Preview Build 17758 API Updates, Additions and Removals
When targeting new Application Programming Interfaces, you can write your app to be adaptive to run properly on maximum Windows 10 devices. Kindly have a look at Dynamically detecting features with API contracts for details.
Source – Windows Developer Blog.