Windows 10 SDK Preview Build 17763 Details

Windows 10 SDK Preview Build 17763 approaches to Windows 10 Build 17763 and later with bug fixes and under development improvements to the API surface area. The update includes changes in C++/WinRT, the introduction of MSIX Support, MC.EXE and multiple other features.

You can download Windows 10 SDK Preview Build 17763 from the developer segment of Windows Insider. This update works in conjunction with earlier sent SDKs and Visual Studio 2017. You can receive this SDK and submit your apps that target Windows 10 v1803 or previous to the Microsoft store.

Windows 10 SDK Preview Build 17763 Changes and Improvements Details

Important Things

• The Windows Software Developer’s Kit will now officially only be supported by Visual Studio 2017 and later.
• You can get the ISO image of the SDK here – https://go.microsoft.com/fwlink/?prd=11966&pver=1.0&plcid=0x409&clcid=0x409&ar=Flight&sar=Sdsurl&o1=17763.

C++/WinRT Update for build 17709 and greater

Windows 10 SDK Preview Build 17763 update comes up with manifold improvements and fixes for C++/WinRT. Most important, it provides the ability to build C++/WinRT without having any dependency on the Windows SDK. This is beneficial for OS repo in addition to the OS developer because it doesn’t itself include any Windows headers. Thus, a developer will generally pull in less number of or no dependencies inadvertently. Removal of dependence also leads to a dramatic reduction in the number of macros that a C++/WinRT developer must guard against. This indicates that C++/WinRT is more portable and standards compliant. Furthermore, Macros will no longer mangle C++/WinRT headers. If you earlier relied on C++/WinRT to add multiple Windows headers then you will now have to follow this on your own.

Windows 10 SDK Preview Build 17763  Highlights

• Windows 10 SDK Preview Build 17763 permits a developer use “get_strong” or “get_weak” replacing a raw this pointer when they create a delegate pointing to a member function.
• Microsoft has added a cancellation callback in this build. This is the most repeatedly demanded feature for C++/WinRT coroutine support.
• However, maximum APIs have a choice for collections or arrays, sufficient APIs rely on IBuffer that it should be simpler to use this type of API from C++. This build gives you straight access to the data behind an IBuffer implementation. This is using the same data naming convention used by the C++ standard library containers. The new method also cast colliding aside with metadata names that conventionally start with an uppercase letter.
• The current build has tuned up support for Clang and Visual C++ stricter conformance modes.
• You will find several improvements to decrease code size, increase inlining, and optimize factory caching.
• In case, command referring to a folder in lieu of a particular “winmd”, “cppwinrt” then it will not search recursively for winmd files. This causes performance mess in the OS build and can throw usage errors that are hard to detect. This occurs when developers inadvertently originate cppwinrt to involve more winmds than expected. The cppwinrt compiler also now manages duplicates with more wisdom. For this, it makes more resilient to user error and bad-formed winmd files.
• The callers don’t require to declare them directly. Their signatures have also altered, amounting to a breaking change. The declarations lessen most of the pain of this change. Since C++/WinRT no longer depends on the Windows headers and this change removes the dependency so the alteration was important.

Windows 10 SDK Preview Build 17763 Breaking Changes

• In the current build, the support for non-WinRT interfaces is turned off as default. To change the status and enable, just #include <unknwn.h> against any C++/WinRT headers.
• winrt::get_abi(winrt::hstring) will further return void* rather than of HSTRING. The code that needs the HSTRING ABI can simply use a static_cast.
• winrt::put_abi(winrt::hstring) will further return void**in lieu of HSTRING*. The code that requires the HSTRING ABI can only use a reinterpret_cast.
• HRESULT will be projected as winrt::hresult. The code that requires an HRESULT can merely use static_cast when you want either type checking or support type traits. Alternatively, it is convertible so long as <unknwn.h> is added first.
• Globally Unique Identifier will be projected further as winrt::guid. The code that implements APIs with GUID parameters must use “winrt::guid” rather, but it is otherwise convertible while <unknwn.h> is included at the outset.
• In the present build, the “WINRT_CanUnloadNow” and “WINRT_GetActivationFactory” signature has changed. The code must not require to declare these functions at any cost rather include winrt/base.h to for declarations.
• The winrt::handle constructor is onward explicit. The code that assigns a raw handle value necessarily call the attach method instead.
• winrt::clock::from_FILETIME is already deprecated. Code should use winrt::clock::from_file_time rather.

What’s New in Windows 10 SDK Preview Build 17763

MSIX Support

After receiving Windows 10 SDK Build 17763, you can package your applications as MSIX. You are able to run these applications on any device having build 17682 or greater.

You will need to bring “MakeAppx tool” into use to package your application with MSIX. To install just click on the MSIX file. To know more about MSIX, follow this introductory video: link

Feedback and comments are welcome on our MSIX community: http://aka.ms/MSIXCommunity

MSIX is not presently supported by the ACK nor the Microsoft Store at this time.

MC.EXE

Microsoft strikes up some important changes to the C/C++ ETW code generation of Message Compiler –

The “-mof” parameter has been deprecated. This parameter directs MC.exe to produce ETW code that is compatible with the Windows XP version and previous. Support for the -mof parameter will be eradicated in a coming version of mc.exe.

While the -mof parameter is not utilized, the generated C/C++ header is now supporting with both kernel furthermore user-mode. It doesn’t care for whether -km or -um was specified on the command line. The header will use the “_ETW_KM_ macro” to itself decide whether it is being compiled for either kernel or user-mode. It will call the suitable ETW APIs for each and every mode.

There is only one difference between “-km” and “-um”. This is “EventWrite[EventName]” macros generated with -km have an Activity ID parameter while the “EventWrite[EventName]” macros generated with -um do not.

“EventWrite[EventName]” macros will straightaway be default to calling either “EventWriteTransfer” (user mode) or “EtwWriteTransfer” (kernel mode). Earlier, “EventWrite[EventName]” macros was workin as the default.

The header at present supports multiple customization macros. For instance, you are able to use the “MCGEN_EVENTWRITETRANSFER” macro if you require the generated macros to call 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, filename, line number, component name, function name.

Event “tags” – 28-bit value accompanied by user-defined semantics (per-event).

Field “tags” – 28-bit value along with user-defined semantics (per-field – valid on either “data” or “struct” elements).

You are able to currently define provider traits in the manifest (for example, provider group). When you apply the provider traits, then “EventRegister[ProviderName]” macro will itself register them.

MC will now inform about an error in the situation of localized message file missing a string.

MC is now capable of generating Unicode output with the -cp utf-8 or -cp utf-16 parameters.

Windows 10 SDK Preview Build 17763 Known Issues

In the present build, SDK headers are generated using types within the ABI namespace. The process casts conflicts between C++/CX and C++/WinRT clients aside which need to consume types directly at the ABI layer. With the built-in configuration, types thrown by MIDL are *not* put in the ABI namespace, however, this has the capability to create conflicts. This occurs between the teams with the intention to involve ABI types from Windows WinRT MIDL and non-Windows WinRT MIDL generated headers.

The SDK build has added validation to the generated headers to make sure that developers have a persistent view of the WinRT API surface. This also confirms that the ABI prefix is consistent between the Windows and user generated headers. In the situation you encounter an error, for example, –

“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 something in your MIDL generated headers are not consistent with the system generated headers.

There are two ways to fix this:

1st preference: Compile your IDL file along with the “/prefix MIDL” command line switch. This will enforce all your types to be shifted to the ABI namespace consistent with the Windows headers. This may require code changes in your code however.

Alternative preference – Add “#define DISABLE_NS_PREFIX_CHECKS” ahead of including the Windows headers. This will suppress the validation.

Windows App Certification Kit

When examining your application with the WACK, the test may crash if it includes 2 or more TargetDeviceFamily entries in the Package.appxmanifestfile. For instance –

<TargetDeviceFamily Name="Windows.Universal"
MinVersion="10.0.0.0"
MaxVersionTested="10.0.0.0"/>
<TargetDeviceFamily Name="Windows.Desktop"
MinVersion="10.0.0.0"
MaxVersionTested="10.0.0.0"/>

You can solve the problem by removing one of the TargetDeviceFamily entries.

Windows 10 SDK Preview Build 17763 API Updates, Additions and Removals

When targeting new APIs, think about writing your app to be adaptive so that it may support the widest number of Windows 10 devices. Kindly check Dynamically detecting features with API contracts for additional details.

Source – Windows Developer blog.