Windows 10 SDK

The Windows 10 SDK (10.0.19041.0) for Windows 10, version 2004 provides the latest headers, libraries, metadata, and tools for building Windows 10 apps.

Use this SDK to build Universal Windows Platform (UWP) and Win32 applications for Windows 10, version 20H2 and previous Windows releases.

Windows 10, version 20H2 is a scoped set of features for select performance improvements and quality enhancements. Developers should be aware of this release, but no action is necessary at this time.

A new Windows SDK will not be issued to accompany this version of Windows because this release doesn’t introduce new APIs. That means there’s no need to modify your project files or target a new version of Windows, and you should continue to use the Windows 10 SDK for Windows 10, version 2004. When setting the target version for your Windows app, Windows 10 build 19041 is still the most recent target version.

Getting started

You can get the Windows 10 SDK in two ways: install it from this page by selecting the download link or by selecting “Windows 10 SDK (10.0.19041.0)” in the optional components of the Visual Studio 2019 Installer.

Before you install this SDK:

System requirements

The Windows SDK has the following minimum system requirements:

Supported operating systems

• Universal Windows Platform (UWP) app development
  • Windows 10 version 1507 or higher: Home, Professional, Education, and Enterprise (LTSB and S are not supported)
  • Windows Server 2019, Windows Server 2016 and Windows Server 2012 R2 (Command line only)

• Win32 app development
  • Windows 10 version 1507 or higher
  • Windows Server 2019, Windows Server 2016, and Windows Server 2012 R2 (Command line only)
  • Windows 8.1
  • Windows 7 SP1

(Not all tools are supported on earlier operating systems)

Hardware requirements

• 1.6 GHz or faster processor
• 1 GB of RAM
• 4 GB of available hard disk space

Additional SDK requirements

Installation on Windows 8.1 and earlier operating systems requires KB2999226. To install through Windows Update, make sure you install the latest recommended updates and patches from Microsoft Update before you install the Windows SDK.

What’s new

The Windows 10 SDK for Windows 10, version 2004 offers exciting new APIs and updated tools for developing your Windows applications. Learn more about the new features in Windows 10, version 2004.

To see the new APIs introduced with Windows 10, version 2004, see: What’s new in Windows 10 for developers, build 19041.

Removal of api-ms-win-net-isolation-l1-1-0.lib

In this release api-ms-win-net-isolation-l1-1-0.lib has been removed from the Windows SDK. Apps that were linking against api-ms-win-net-isolation-l1-1-0.lib can switch t OneCoreUAP.lib as a replacement.

Removal of irprops.lib

In this release irprops.lib has been removed from the Windows SDK. Apps that were linking against irprops.lib can switch to bthprops.lib as a drop-in replacement.

Removal of wuapicommon.h and wuapicommon.idl

In this release we have moved ENUM tagServerSelection from wuapicommon.h to wupai.h and removed the header. If you would like to use the ENUM tagServerSelection, you will need to include wuapi.h or wuapi.idl.

Windows 10 WinRT API Pack

The Windows 10 WinRT API Pack lets you add the latest Windows Runtime APIs support to your .NET Framework 4.5+ and .NET Core 3.0+ libraries and apps. To access the Windows 10 WinRT API Pack, see the Microsoft.Windows.SDK.Contracts nuget package.

Universal C Runtime (UCRT)

The printf family of functions now conforms with the IEEE 754 rounding rules when printing exactly representable floating-point numbers and will honor the rounding mode requested via calls to fesetround. Legacy behavior is available when linking with legacy_stdio_float_rounding.obj.

Tools

Windows App Certification Kit

In this release of the Windows SDK, several new APIs were added to the Supported APIs list in the App Certification Kit and Windows Store. If there are APIs in the supported list that appear greyed out or disabled in Visual Studio, you can make a small change to your source file, to access them. For more details, see this known issue.

In addition to adding APIs, the following changes have been made to the tests:

Updated tests:

• ValidateContentUriRules will be informational only. Test failures will be presented as warnings.

Removed tests

• WebView WinRT access test for web app
• PackageSizeCheck test for UWP apps
• SupportedApi test for Desktop Bridge apps
• AppContainerCheck test from BinScope for UWP apps
• ServiceWorker check for all app types

New tests

• High-DPI test. A new test for Desktop Bridge apps checks if the app uses DPI aware feature and warns if not specified. This test will encourage you to make your app per-monitor DPI aware. For details on DPI see High DPI Desktop Application Development on Windows.

Message Compiler (mc.exe)

Updates include:

• Now detects the Unicode byte order mark (BOM) in .mc files. If the .mc file starts with a UTF-8 BOM, it will be read as a UTF-8 file. Otherwise, if it starts with a UTF-16LE BOM, it will be read as a UTF-16LE file. If the -u parameter was specified, it will be read as a UTF-16LE file. Otherwise, it will be read using the current code page (CP_ACP).
• Now avoids one-definition-rule (ODR) problems in MC-generated C/C++ ETW helpers caused by conflicting configuration macros (e.g. when two .cpp files with conflicting definitions of MCGEN_EVENTWRITETRANSFER are linked into the same binary, the MC-generated ETW helpers will now respect the definition of MCGEN_EVENTWRITETRANSFER in each .cpp file instead of arbitrarily picking one or the other).

Windows Trace Preprocessor (tracewpp.exe)

Updates include:

• Now supports Unicode input (.ini, .tpl, and source code) files. Input files starting with a UTF-8 or UTF-16 byte order mark (BOM) will be read as Unicode. Input files that do not start with a BOM will be read using the current code page (CP_ACP). For backwards-compatibility, if the -UnicodeIgnore command-line parameter is specified, files starting with a UTF-16 BOM will be treated as empty.
• Now supports Unicode output (.tmh) files. By default, output files will be encoded using the current code page (CP_ACP). Use command-line parameters -cp:UTF-8 or -cp:UTF-16 to generate Unicode output files.
• Behavior change: tracewpp now converts all input text to Unicode, performs processing in Unicode, and converts output text to the specified output encoding. Earlier versions of tracewpp avoided Unicode conversions and performed text processing assuming a single-byte character set. This may lead to behavior changes in cases where the input files do not conform to the current code page. In cases where this is a problem, consider converting the input files to UTF-8 (with BOM) and/or using the -cp:UTF-8 command-line parameter to avoid encoding ambiguity.

TraceLoggingProvider.h

Updates include:

• Now avoids one-definition-rule (ODR) problems caused by conflicting configuration macros (e.g. when two .cpp files with conflicting definitions of TLG_EVENT_WRITE_TRANSFER are linked into the same binary, the TraceLoggingProvider.h helpers will now respect the definition of TLG_EVENT_WRITE_TRANSFER in each .cpp file instead of arbitrarily picking one or the other).
• In C++ code, the TraceLoggingWrite macro has been updated to enable better code sharing between similar events using variadic templates.

Signing your apps with Device Guard Signing

We are making it easier for you to sign your app. Device Guard signing is a Device Guard feature that is available in Microsoft Store for Business and Education. Signing allows enterprises to guarantee every app comes from a trusted source. Our goal is to make signing your MSIX package easier. See the documentation about Device Guard Signing.

Samples

Windows 10 app samples are now available through GitHub. You can browse the code on GitHub, clone a personal copy of the repository from Git, or download a zipped archive of all the samples. We welcome feedback, so feel free to open an issue within the repository if you have a problem or question. These samples are designed to run on desktop, mobile, and future devices that support the Universal Windows Platform (UWP).

Previous SDK versions

Previously released SDKs and emulators, including update details, can be found on the archive page.

API Light Up

When you use new APIs, consider writing your app to be adaptive so that it runs correctly on the widest array of Windows 10 devices. An adapative app «lights up» with new features wherever the devices and Windows version supports them, but otherwise offers only the functionality available on the detected platform version. For implementation details, see the Version adaptive code article.

Release notes & Known Issues

The Windows 10 SDK, Version 2004 SDK servicing update (released 12/16/2020) contains the following fixes. If you encounter these issues, we recommend that you update your version of the SDK as soon as possible to avoid them:

• Resolved unpredictable and hard to diagnose crashes when linking both umbrella libraries and native OS libraries (for example, onecoreuap.lib and kernel32.lib)
• Resolved issue that prevented AppVerifier from working
• Resolved issue that caused WACK to fail with “Task failed to enable HighVersionLie”

For known issues, see the winapi-sdk Q&A.

For new developer feature requests, submit through the Feedback Hub app under the category “Developer Platform/API.”

More resources

Downloads and tools

Get the latest editions of Visual Studio and Windows 10 development tools.

SDK archive

Find previous releases of the Window SDK and other tools.

Windows blog

Stay in touch with the latest SDK flights by subscribing to our blog.

Windows lifecycle fact sheet

Find the key dates for Windows release updates and end of support.

Calling Windows 10 APIs From a Desktop Application

In today’s post, we’re covering how PC software can leverage the rich functionality of Windows 10. This is valuable background for the post, “Adding UWP Features to your Existing PC Software,” which goes into even more detail on the topic.

So here’s a question that generates a lot of confusion. Can PC software written in WPF, WinForms or MFC access the Windows 10 APIs used by the Universal Windows Platform (UWP)?

The answer is yes. There are some exceptions to this rule (and we’ll go over how to find them), but in general you can access the Windows 10 APIs. Or put a different way, there are no secret APIs being kept away from Windows developers.

How to access the Windows 10 APIs from WPF

You can access the Windows 10 APIs from a pre-existing WPF project. To do so, go to your Solution Explorer window and …

1. Right click on References. Select “Add Reference…” from the context menu. On the left of the Reference Manager, choose Browse and find the following file: C:Program Files (x86)Windows Kits10UnionMetadatawinmd. Add it to your project as a reference. Note: You will need to change the filter to “All Files”.

1. Right click on References. Select “Add Reference…” from the context menu. On the left of the Reference Manager, go to Browse and find the directory “C:Program Files (x86)Reference AssembliesMicrosoftFramework.NETCorev4.5”. Add System.Runtime.WindowsRuntime.dll to your project.

Let’s say I want to make my WPF application location aware by calling on the Geolocator class in the Windows 10 Windows.Devices.Geolocation API. I can now do this and even use the asynchronous pattern common in UWP. Classes and methods I commonly think of as UWP code are now interweaved with classes and methods from WPF. In the example show below, I take my latitude and longitude from Geolocator and display it in a WPF MessageBox.

private async void Button_Click(object sender, RoutedEventArgs e)
<
var locator = new Windows.Devices.Geolocation.Geolocator();
var location = await locator.GetGeopositionAsync();
var position = location.Coordinate.Point.Position;
var latlong = string.Format(«lat:<0>, long:<1>«, position.Latitude, position.Longitude);
var result = MessageBox.Show(latlong);
>

How do I know which APIs are available?

As mentioned above, there are exceptions to the rule that Windows 10 APIs are accessible from PC software. The first big exception concerns XAML UI APIs. The XAML framework in UWP is different from the one in WPF and you really don’t want to be mixing them up, anyways.

The second set of APIs that you can’t use are ones that depend on an app’s package identity. UWP apps have package identities while PC software does not. Package identity information can be found in the app manifest file.

How do you determine which Windows 10 APIs require a package identity and which do not? The easiest way is to refer to this MSDN topic.

Unlocking even more APIs

There’s actually a way to provide PC software with a package identity. The Desktop Bridge lets you package PC software for deployment in the Windows Store. As part of this process, you create an app manifest file for it, effectively giving it a package identity.

If you package your PC software for the Windows Store using Desktop Bridge, then most of the APIs you couldn’t previously use, because they require a package identity, will be available to you. APIs that depend on CoreWindow will still be a problem. However, once you have a desktop bridge package, you can add a UWP component (that runs in a separate app container process), and call literally any UWP API from there.

A quicker way to get at those Windows 10 APIs

But say you don’t want to deploy to the Windows Store at the moment and just want to use some of those Windows 10 APIs. How do you get to them from your app?

There’s a NuGet package for that. It’s called UwpDesktop and is written by Vladimir Postel and Lucian Wischik. If you want to examine the source code, it is maintained on GitHub.

For demonstration purposes, let’s build a console app based on a 2012 article by Scott Hanselman on using WinRT APIs (partly to show how much easier it is to do today). After creating a new desktop console application, insert the original code from 2012 into the Main method in Program.cs.

static void Main(string[] args)
<
LightSensor light = LightSensor.GetDefault();
if (light != null)
<
uint minReportInterval = light.MinimumReportInterval;
uint reportInterval = minReportInterval > 16 ? minReportInterval : 16;
light.ReportInterval = reportInterval;

light.ReadingChanged += (s, a) =>
<
Console.WriteLine(String.Format(«There was light! <0>«, a.Reading.IlluminanceInLux));
>;
>

while (Console.ReadLine() != «q»)

This code sadly will not compile because .NET 4.5 doesn’t know what the LightSensor class is, as shown below.

Here’s how we fix that. Install the UWPDesktop package to your project using the NuGet Package Manager.

Back in Program.cs, add the following using directive to the top of the file:

Next … well, actually that’s all it took. The app works now (assuming you have a light sensor attached to your computer).

And that’s the quick way to go about using Windows 10 APIs in a managed app.

How to access the Windows 10 APIs from C++

Calling Window 10 APIs isn’t just for managed code. You’ve also always been able to call them from C++ native apps.

Start by creating a new C++ Win32 application project. Alternatively, open a pre-existing C++ windows application project. Right click on your project and select Properties to bring up the configuration window. There are just four steps required to configure your application to make Windows 10 API calls.

• Select the Configuration Properties > C/C++ > General node in the left pane. Set the Consume Windows Runtime Extension property to Yes.

• In the same window, edit the Additional #using Directories property, adding the following entries:
  • C:Program Files (x86)Microsoft Visual Studio 14.0VCvcpackages;
  • C:Program Files (x86)Windows Kits10UnionMetadata;
  • C:Program Files (x86)Windows Kits10ReferencesWindows.Foundation.UniversalApiContract1.0.0.0;
  • C:Program Files (x86)Windows Kits10ReferencesWindows.Foundation.FoundationContract1.0.0.0;

• Select the Configuration Properties > C/C++ > Code Generation node in the left pane. Set the Enable Minimal Rebuild property to No.

• Last of all, select the Configuration Properties > General node and pick your Target Windows 10 version. Click OK to save your configuration settings.

Now you can start calling Windows APIs. Let’s finish off this app with something easy – calling the Launcher API from the C++ menubar.

Add the following using directives to the top of your project’s main CPP file:

using namespace std;
using namespace Platform;
using namespace Windows::Foundation;
using namespace Windows::System;
Include the header ROApi.h in your stdafx.h file.
// C RunTime Header Files
#include
#include
#include
#include

// TODO: reference additional headers your program requires here
#include «ROApi.h»
Initialize Windows::Foundation in your program’s entry point.
int APIENTRY wWinMain(_In_ HINSTANCE hInstance,
_In_opt_ HINSTANCE hPrevInstance,
_In_ LPWSTR lpCmdLine,
_In_ int nCmdShow)
<
UNREFERENCED_PARAMETER(hPrevInstance);
UNREFERENCED_PARAMETER(lpCmdLine);

// TODO: Place code here.
Windows::Foundation::Initialize();
>

Initialize Windows::Foundation in your program’s entry point.

int APIENTRY wWinMain(_In_ HINSTANCE hInstance,
_In_opt_ HINSTANCE hPrevInstance,
_In_ LPWSTR lpCmdLine,
_In_ int nCmdShow)
<
UNREFERENCED_PARAMETER(hPrevInstance);
UNREFERENCED_PARAMETER(lpCmdLine);

// TODO: Place code here.
Windows::Foundation::Initialize();
>

By default the Help menu only has one entry for About, so you will need to add a new button. Define the button in your Resource.h file:

#define IDM_SETTINGS 106

Then edit the *.rc file to add a new button for settings, in order to launch the Windows 10 Settings app.

IDC_HELLOWORLDWIN32TOUWP MENU
BEGIN
POPUP «&File»
BEGIN
MENUITEM «E&xit», IDM_EXIT
END
POPUP «&Help»
BEGIN
// add settings item to help menu around Line 47
MENUITEM «&Settings …», IDM_SETTINGS
MENUITEM «&About …», IDM_ABOUT

Finally, override the callbacks for the menubar buttons to make them call the Windows 10 Launcher instead of whatever they are supposed to do.

LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
<
switch (message)
<
case WM_COMMAND:
<
int wmId = LOWORD(wParam);
// Parse the menu selections:
switch (wmId)
<
case IDM_SETTINGS:
Launcher::LaunchUriAsync(ref new Uri(L»ms-settings://»));
break;
case IDM_ABOUT:
Launcher::LaunchUriAsync(ref new Uri(L»https://blogs.windows.com/buildingapps//»));
break;
case IDM_EXIT:
DestroyWindow(hWnd);
break;
default:
return DefWindowProc(hWnd, message, wParam, lParam);
>
>
break;
>
>

Clicking on Help > Settings will bring up the Windows 10 Settings app, while clicking on Help > About will bring you to this blog (one of my favorite places)!

Let’s go one level deeper. There are many C++ applications and games out there that use alternative build tools and alternative build processes. Many of them continue to target older versions of Windows because this is what their customers are using. How can these application developers gradually move over to the Windows 10 APIs without abandoning their Windows 7 clients?

Reusing the same steps above for building a Windows executable, one could build a DLL to encapsulate any Windows 10 calls one might need, isolating them from the rest of the application. Let’s call this new DLL UWPFeatures.dll.

void Game::UpdateTile(int score, int hiScore)
<
HINSTANCE hinstLib;
UPDATETILE UpdateTileProc;
BOOL fFreeResult;

hinstLib = LoadLibrary(TEXT(«UWPFeatures.dll»));
if (NULL != hinstLib)
<
UpdateTileProc = (UPDATETILE)GetProcAddress(hinstLib, «UpdateTile»);
if (NULL != UpdateTileProc)
<
(UpdateTileProc)(score, hiScore);
>
fFreeResult = FreeLibrary(hinstLib);
>
>

Then in the original application, method calls should check to see if the UWPFeatures.dll is packaged with the application (which will be true for Windows 10 installs). If it is present, it can be loaded dynamically and called. If it isn’t present, then the original call is made instead. This provides a quick pattern for not only accessing the Windows 10 APIs from pre-existing C++ games and applications, but also for doing it in a way that doesn’t require heavy reworking of the current base code.

Wrapping up

It has sometimes been claimed that Windows 10 has secret APIs that are only accessible through UWP apps. In this post, we demonstrated that this is not the case and also went over some of the ins and outs of using Windows 10 APIs in both managed and native desktop apps. You will find links below to even more reference materials on the subject.

Did you find this post helpful? Please let us know in the comments below—and also let us know if there’s anything else you’d like us to dig into for you about this topic.

Want to go a step further? Be sure to come back next week for our next blog, where we go into more detail about adding a UWP feature to your existing PC software with the Desktop Bridge.