Windows 10: Windows 10 SDK Preview Build 17709 now available - July 10

Brink · Jul 10, 2018

Today, we released a new Windows 10 Preview Build of the SDK to be used in conjunction with Windows 10 Insider Preview (Build 17709 or greater). The Preview SDK Build 17709contains bug fixes and under development changes to the API surface area.

The Preview SDK can be downloaded from developer section on Windows Insider.

For feedback and updates to the known issues, please see the developer forum. For new developer feature requests, head over to our Windows Platform UserVoice.

Things to note:

This build works in conjunction with previously released SDKs and Visual Studio 2017. You can install this SDK and still also continue to submit your apps that target Windows 10 build 1803 or earlier to the store.

The Windows SDK will now formally only be supported by Visual Studio 2017 and greater. You can download the Visual Studio 2017 here.

This build of the Windows SDK will install on Windows 10 Insider Preview and supported Windows operating systems.

C++/WinRT Update for build 17709 and beyond:

This update introduces many improvements and fixes for C++/WinRT. Notably, it introduces the ability to build C++/WinRT without any dependency on the Windows SDK. This isn’t particularly interesting to the OS developer, but even in the OS repo it provides benefits because it does not itself include any Windows headers. Thus, a developer will typically pull in fewer or no dependencies inadvertently. This also means a dramatic reduction in the number of macros that a C++/WinRT developer must guard against. Removing the dependency on the Windows headers means that C++/WinRT is more portable and standards compliant and furthers our efforts to make it a cross-compiler and cross-platform library. It also means that the C++/WinRT headers will never be mangled by macros. If you previously relied on C++/WinRT to include various Windows headers, you will now have to include them yourself. It has always been good practice to include any headers you depend on explicitly, and not rely on another library to include them for you.

Highlights

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.

Breaking Changes

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:ut_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.

What’s New:

MSIX Support

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. To understand more about MSIX, watch this introductory video: link

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

MSIX is not currently supported by the App Certification Kit nor the Microsoft Store at this time.

MC.EXE

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.

Known Issues:

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[1]. 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.

API Updates, Additions and Removals

When targeting new APIs, consider writing your app to be adaptive in order to run correctly on the widest number of Windows 10 devices. Please see Dynamically detecting features with API contracts (10 by 10) for more information.

The following APIs have been added to the platform since the release of 17134. The APIs below listed have been removed.
Click to expand...

Source: Windows 10 SDK Preview Build 17709 available now! - Windows Developer Blog

Download: Download Windows Insider Preview SDK

:)

Brink · Jul 10, 2018

Windows 10 SDK Preview Build 17661 now available

Today, we released a new Windows 10 Preview Build of the SDK to be used in conjunction with Windows 10 Insider Preview (Build 17661 or greater). The Preview SDK Build 17661 contains bug fixes and under development changes to the API surface area.

The Preview SDK can be downloaded from developer section on Windows Insider.

For feedback and updates to the known issues, please see the developer forum. For new developer feature requests, head over to our Windows Platform UserVoice.

Things to note:

This build works in conjunction with previously released SDKs and Visual Studio 2017. You can install this SDK and still also continue to submit your apps that target Windows 10 Creators build or earlier to the store.

The Windows SDK will now formally only be supported by Visual Studio 2017 and greater. You can download the Visual Studio 2017 here.

This build of the Windows SDK will install on Windows 10 Insider Preview and supported Windows operating systems.

Known Issues

The contract Windows.System.SystemManagementContract is not included in this release. In order to access the following APIs, please use a previous Windows IoT extension SDK with your project.

This bug will be fixed in a future preview build of the SDK.

The following APIs are affected by this bug:
Click to expand...

Read more: Windows 10 SDK Preview Build 17661 now available! - Windows Developer Blog

Download: Download Windows Insider Preview SDK

Brink · Jul 10, 2018

Windows 10 SDK Preview Build 17035 now available

Today, we released a new Windows 10 Preview Build of the SDK to be used in conjunction with Windows 10 Insider Preview (Build 17035 or greater). The Preview SDK Build 17035 contains bug fixes and under development changes to the API surface area.

The Preview SDK can be downloaded from developer section on Windows Insider.

For feedback and updates to the known issues, please see the developer forum. For new developer feature requests, head over to our Windows Platform UserVoice.

Things to note:

This build works in conjunction with previously released SDKs and Visual Studio 2017. You can install this SDK and still also continue to submit your apps that target Windows 10 Creators build or earlier to the store.

The Windows SDK will now formally only be supported by Visual Studio 2017 and greater. You can download the Visual Studio 2017 here.

Known Issues:

Installation on an operating system that is not a Windows 10 Insider Preview build is not supported and may fail.

What’s New:

C++/WinRT Now Available:
The C++/WinRT headers and cppwinrt compiler (cppwinrt.exe) are now included in the Windows SDK. The compiler comes in handy if you need to consume a third-party WinRT component or if you need to author your own WinRT components with C++/WinRT. The easiest way to get working with it after installing the Windows Insider Preview SDK is to start the Visual Studio Developer Command Prompt and run the compiler in that environment. Authoring support is currently experimental and subject to change. Stay tuned as we will publish more detailed instructions on how to use the compiler in the coming week. The ModernCPP blog has a deeper dive into the CppWinRT compiler. Please give us feedback by creating an issue at: Microsoft/cppwinrt.

Breaking Changes

New MIDL key words.

As a part of the “modernizing IDL” effort, several new keywords are added to the midlrt tool. These new keywords will cause build breaks if they are encountered in IDL files.
The new keywords are:

event

set

get

partial

unsealed

overridable

protected

importwinmd

If any of these keywords are used as an identifier, it will generate a build failure indicating a syntax error.

The error will be similar to:

1 >d:\os\src\onecore\com\combase\unittest\astatestservers\testserver6\idl\remreleasetest.idl(12) : error MIDL2025 : [msg]syntax error [context]: expecting a declarator or * near “)”

To fix this, modify the identifier in error to an “@” prefix in front of the identifier. That will cause MIDL to treat the offending element as an identifier instead of a keyword.
Click to expand...

Read more: Windows 10 SDK Preview Build 17035 now available - Building Apps for Windows

Brink · Jul 10, 2018

Windows 10 SDK Preview Build 17095 now available

Today, we released a new Windows 10 Preview Build of the SDK to be used in conjunction with Windows 10 Insider Preview. The Preview SDK Build 17095 contains bug fixes and under development changes to the API surface area.

The Preview SDK can be downloaded from developer section on Windows Insider.

For feedback and updates to the known issues, please see the developer forum. For new developer feature requests, head over to our Windows Platform UserVoice.

Things to note:

This build is also available in the latest Visual Studio 2017 Preview (https://www.visualstudio.com/vs/preview/)

This build works in conjunction with previously released SDKs and Visual Studio 2017. You can install this SDK and still also continue to submit your apps that target Windows 10 Creators build or earlier to the store.

The Windows SDK will now formally only be supported by Visual Studio 2017 and greater. You can download the Visual Studio 2017 here.

This build of the Windows SDK will install on Windows 10 Insider Preview and supported Windows operating systems.

Known Issues

Cannot deploy to a device: When attempting to deploy to a mobile device, it fails with the following error: DEP0001: Unexpected Error: SmartDeviceException – Class not registered [0x80131500]

To work around this issue:

Go to Administrative Command Prompt

Run REGSVR32 “\Program Files (x86)\Windows Kits\10\bin\10.0.17095.0\x86\SirepClient.dll”

The following tools are not included with this release:

Filtdump.exe
JSConstraintDebug.exe
Regwindmd.exe
Topedit.exe

What’s New:

C++/WinRT Now Available: The C++/WinRT headers and cppwinrt compiler (cppwinrt.exe) are now included in the Windows SDK. The compiler comes in handy if you need to consume a third-party WinRT component or if you need to author your own WinRT components with C++/WinRT. The easiest way to get working with it after installing the Windows Insider Preview SDK is to start the Visual Studio Developer Command Prompt and run the compiler in that environment. Authoring support is currently experimental and subject to change. Stay tuned as we will publish more detailed instructions on how to use the compiler in the coming week.The ModernCPP blog has a deeper dive into the CppWinRT compiler. Please give us feedback by creating an issue at: Microsoft/cppwinrt.

Breaking Changes

New MIDL key words.

As a part of the “modernizing IDL” effort, several new keywords are added to the midlrt tool. These new keywords will cause build breaks if they are encountered in IDL files.

The new keywords are:

event

set

get

partial

unsealed

overridable

protected

importwinmd

If any of these keywords is used as an identifier, it will generate a build failure indicating a syntax error.

The error will be similar to:

1 >d:\os\src\onecore\com\combase\unittest\astatestservers\testserver6\idl\remreleasetest.idl(12) : error MIDL2025 : [msg]syntax error [context]: expecting a declarator or * near “)”

To fix this, modify the identifier in error to an “@” prefix in front of the identifier. That will cause MIDL to treat the offending element as an identifier instead of a keyword.

API Updates and Additions

When targeting new APIs, consider writing your app to be adaptive in order to run correctly on the widest number of Windows 10 devices. Please see Dynamically detecting features with API contracts (10 by 10) for more information.

The following APIs have been added to the platform since the release of 16299.
Click to expand...

Read more: Windows 10 SDK Preview Build 17095 now available - Windows Developer Blog

Windows 10: Windows 10 SDK Preview Build 17709 now available - July 10

Windows 10 SDK Preview Build 17709 now available - July 10

Windows 10 SDK Preview Build 17709 now available - July 10

Windows 10 SDK Preview Build 17709 now available - July 10

Windows 10 SDK Preview Build 17709 now available - July 10 - Similar Threads - SDK Preview Build

Windows 10 SDK Preview Build 20180 now available - July 29

Windows 10 SDK Preview Build 20175 now available - July 22

Windows 10 SDK Preview Build 20170 now available - July 15

Windows 10 SDK Preview Build 20161 now available - July 1

Windows 10 SDK Preview Build 18945 available now - July 30

Windows 10 SDK Preview Build 17723 now available - July 31

Windows 10 SDK Preview Build 17713 now available - July 17

Windows 10 SDK Preview Build 17704 now available - July 3

Windows 10 SDK Preview Build 17061 now available

Users found this page by searching for:

driver msix 0x80131500

msix 0x80131500