Windows 10: Windows 10 SDK Preview Build 17754 now available - September 11

Brink · Sep 11, 2018

Today, we released a new Windows 10 Preview Build of the SDK to be used in conjunction with Windows 10 Insider Preview (Build 17754 or greater). The Preview SDK Build 17754contains 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 builds and supported Windows operating systems.

In order to assist with script access to the SDK, the ISO will also be able to be accessed through the following URL: https://go.microsoft.com/fwlink/?prd...dsurl&o1=17754 once the static URL is published.

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 that you will now have to include them yourself. It has always been good practice to always 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:*Tongueut_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: 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 for more information.

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

In addition, please note the following removal since build 17744:
Click to expand...

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

Download: Download Windows Insider Preview SDK

Tweet

— Twitter API (@user) View on Twiiter

:)

JGToy · Sep 11, 2018

Windows 10 SDK Preview Build 17035 now available

Read more: Windows 10 SDK Preview Build 17035 now available - Building Apps for Windows
Click to expand...

Picking it up!
Thanks Brink.

Brink · Sep 11, 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 · Sep 11, 2018

Windows 10 SDK Preview Build 14965 Released

Today, we released a new Windows 10 Anniversary SDK Preview to be used in conjunction with Windows 10 Insider Preview (Build 14965 or greater). The Preview SDK is a pre-release and cannot be used in a production environment. Please only install the SDK on your test machine. The Preview SDK Build 14965 contains bug fixes and under development changes to the API surface area. If you are working on an application that you need to submit to the store, you should not install the preview.

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

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

Things to note:

The SDK will require Visual Studio 2017 Preview. You can download the Visual Studio 2017 Release Candidate here.

What’s New

This Windows SDK includes updates and additions to the Windows namespace. See section API Updates and Additions below for the list.

Debugging Tools for Windows has been updated with a few new features, including JavaScript scripting and extensibility. See the blogpost at https://blogs.msdn.microsoft.com/win...extensibility/ for more information.

Known Issues Windows SDK

Wrong GenXBF.DLL
If you installed a previous Windows SDK flight, either version 14951 or 14931, you may have an incorrect GenXBF.dll installed. Please follow the following steps after installing the Windows 10 SDK Preview build 14965.

Exit Visual Studio

Open an Administrative command prompt

Type the following: DEL “c:\Program Files (x86)\Windows Kits\10\bin\x86\genxbf.dll”
DEL “c:\Program Files (x86)\Windows Kits\10\bin\x64\genxbf.dll”

Run Control Panel

Select Uninstall a Program

Highlight Windows Software Development Kit – Windows 10.0.14965.1000

Click Change

Select Repair

Click Next

Windows SDK setup will restore the missing GenXBF.dlls with the appropriate version.

Visual Studio 2017 fails with HRESULT: 0x80041FE2 when trying to create C++ UWP apps targeting build 14965 SDK

This is a known problem. Here are steps to address this issue in your project file:

Close the project

Open up the project file in notepad or your favorite editor

Add the following to the project file:

[table][tr][td]1[/td] [td]<PropertyGroup><DoBundleInstallationChecks>false</DoBundleInstallationChecks></PropertyGroup>[/td] [/tr] [/table]

Reopen the project in Visual Studio

Known Issues Microsoft Emulator

Microsoft Emulator Preview for Windows 10 Mobile (10.0.14965.0) crashes when launching
Impact:
Please note that there is a bug impacting the usage of hardware accelerated graphics in the latest release of the Mobile Emulator. Follow the instructions below to temporarily disable hardware accelerated graphics in the emulator and use the emulator with software rendered graphics (WARP).

NOTE: The following registry setting will impact any and all Microsoft Emulators installed on your machine. You will need to remove this registry setting in order to re-enable hardware accelerated graphics in the emulator.

Create the following registry subkey if it doesn’t exist: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Xde\10.0

Right click the 10.0 folder, point to New, and then click DWORD Value.

Type DisableRemoteFx, and then press Enter.

Double-click DisableRemoteFx, enter 1 in the Value data box, select the Decimal option, and then click OK.

Click to expand...

Read more: Windows 10 SDK Preview Build 14965 Released | Building Apps for Windows

Windows 10: Windows 10 SDK Preview Build 17754 now available - September 11

Windows 10 SDK Preview Build 17754 now available - September 11

Windows 10 SDK Preview Build 17754 now available - September 11

Windows 10 SDK Preview Build 17754 now available - September 11

Windows 10 SDK Preview Build 17754 now available - September 11 - Similar Threads - SDK Preview Build

Windows 10 SDK Preview Build 20226 now available - September 30

Windows 10 SDK Preview Build 20215 now available - September 16

Windows 10 SDK Preview Build 20211 now available - September 10

Windows 10 SDK Preview Build 20206 now available - September 2

Windows 10 SDK Preview Build 18980 available now - September 17

Windows 10 SDK Preview Build 18975 available now - September 10

Windows 10 SDK Preview Build 18970 available now - September 3

Windows 10 SDK Preview Build 17763 now available - September 25

Windows 10 SDK Preview Build 17749 now available - September 4