Alternatives to Windows APIs in Universal Windows Platform (UWP) apps

Learn which features of the Windows API can be used in a Universal Windows Platform (UWP) app and which APIs to use as alternatives for those that cannot.

App installation

None of the existing app installation APIs are supported in a UWP app. Here’s some alternatives to the app installation APIs:

Devices

A subset of the device APIs is supported in a UWP app.

For device APIs that cannot be used in a UWP app, here are some alternatives.

Feature	Alternative
Bluetooth	Windows.Devices.Bluetooth
Device enumeration (Function Discovery, PnP-X, WSD)	Windows.Devices.Enumeration
FAX	none
Location API	Windows.Devices.Geolocation
Print	Windows.Graphics.Printing
3D Printing	Windows.Graphics.Printing3D
Sensors	Windows.Devices.Sensors
Serial and parallel ports	Windows.Devices.SerialCommunication
SMS	Windows.Devices.Sms
UPnP	Windows.Devices.Enumeration.Pnp
Windows Portable Devices	Windows.Devices.Portable
WSD	Windows.Devices.Enumeration
Battery	Windows.Devices.Power Windows.System.Power

Graphics

Subsets of these graphics APIs are at least partially supported in a UWP app:

Here are some alternatives:

Multimedia

Subsets of these multimedia APIs are at least partially supported in a UWP app:

• Core audio
• Media Playback
• Media Foundation
• Windows Audio Session API (WASAPI)

For more information on API that are available for UWP apps, see Audio, video, and camera

Networking

Subsets of these networking APIs are at least partially supported in a UWP app:

• DHCP
• Mobile Broadband
• RPC
• Windows Sockets (Winsock)
• Windows Web Services

Here’s some alternatives to networking APIs that cannot be used in a UWP app.

Feature	Alternative
BITS	Windows.Networking.BackgroundTransfer
EAP	none
Firewall	none
HTTP Server	none
IP Helper	Windows.Networking.Connectivity
NDF	none
NLM	Windows.Networking.Connectivity
P2P	none
QOS	Windows.Networking.Sockets
RAS	none
SNMP	none
TAPI	none
WinHTTP	Windows.Web.Http
WinINet	Windows.Web.Http
Winsock	Windows.Networking.Sockets

Printing and documents

A subset of the printing and documents APIs is supported in a UWP app.

When designing a UWP app, you’ll want to provide the best printing experience:

Security

None of the existing security APIs are supported in a UWP app. Here’s some alternatives to the security APIs:

Storage

Subsets of these storage APIs are at least partially supported in a UWP app:

• Directory create, delete, and enumerate
• File mapping

Here’s some alternatives to Win32 storage APIs that cannot be used in a UWP app.

Feature	Alternative
File copy, move, and replace	Windows.Storage.StorageFile
Directory create, delete, and enumerate	Windows.Storage.StorageFolder
IMAPI	none
Management (mount points, format, quotas)	none
Oplocks	none
Search	Windows.Storage.Search
USN journal	none

System

Subsets of these system APIs are at least partially supported in a UWP app:

• Heap API, thread local storage (TLS)
• Last error
• Synchronization

Here’s some alternatives to system APIs that cannot be used in a UWP app.

Feature	Alternative
Console	Create a UWP Console App
Current directory	none
Fibers	none
Memory manager	Heap API
Named pipes	Interprocess Communications
Power	Windows.Devices.Power Windows.System.Power Windows.System.Power.Diagnostics
Registry	Windows.Storage.ApplicationDataContainer Windows.Storage.ApplicationDataContainerSettings
Thread pool	Windows.System.Threading
Threads	Windows.System.Threading

User interface

Subsets of these user interface APIs are at least partially supported in a UWP app:

• National Language Support (NLS)
• Strsafe functions
• Text Services Framework (TSF)
• UI automation
• Windows Animation Manager

Here’s some alternatives to user interface APIs that cannot be used in a UWP app.

.NET Networking APIs for UWP Apps

This post was written by Sidharth Nabar, Program Manager on the Windows networking team.

At Build 2015, we announced that .NET Core 5 is the new version of .NET for developers writing Universal Windows Platform (UWP) apps. The set of networking APIs available for developers in .NET Core 5 is an evolution from the set that was available for Windows Store app developers in Windows 8.1 (API reference on MSDN). As was highlighted at Build, porting your apps to .NET Core and UWP enables you to target a wide variety of devices including Xbox, Windows Phone, Windows and HoloLens with the same codebase. Of course, you can still use all the .NET networking APIs that you used in Windows 8.1 Store apps (no API surface has been removed/deprecated), and more.

Although most of the networking API surface in .NET Core is the same as previous .NET Framework versions, the underlying implementation for some of these APIs has undergone a significant change as we move from the .NET Framework to .NET Core. We have also taken this opportunity to modernize the implementation of our networking APIs and make it more suitable to run in the context of Store apps on Windows. In this post, we outline all the .NET networking APIs available to UWP developers and provide some insights into the implementation underneath the APIs.

Note that all the APIs and changes discussed in this post are applicable only to .NET Core for UWP apps, and not to .NET Framework 4.6. We are also investing in networking API improvements in .NET Core for server platforms (through ASP.NET 5), but we will cover those in a separate blog post. Similarly, this post does not cover networking APIs outside of .NET APIs that are available to Windows apps developers.

What’s New

These are the new APIs and features that we have added into .NET Core 5 for UWP app developers.

System.Net.Sockets

With Windows 10 and .NET Core 5, System.Net.Sockets has been added into the API surface for UWP app developers. This was a highly requested API for Windows Store apps (it was already available for Windows Phone Silverlight apps) and includes types such as System.Net.Sockets.Socket and System.Net.Sockets.SocketAsyncEventArgs , which are used by developers for asynchronous socket communication. The current API surface of System.Net.Sockets in .NET Core is based on that of Phone 8.1 Silverlight and continues to support most of the types, properties and methods (some APIs that are considered obsolete have been removed). Moving forward, we plan to expand the API surface to support more types from this namespace – please see the Looking ahead section below.

The implementation underneath the System.Net.Sockets API has been significantly changed to eliminate dependencies on APIs that are not part of .NET Core, as well as to use the same underlying threading APIs as other WinRT APIs. Our goal is to ensure functional parity between the previous implementation and the new .NET Core version. Please send us your feedback on GitHub if you see any differences in behavior or performance as you port your Sockets code to UWP.

System.Net.Http gets HTTP/2

Developers writing UWP apps on Windows 10 and .NET Core 5 will get HTTP/2 support in System.Net.Http.HttpClient . HTTP/2 is the latest version of the HTTP protocol and provides much lower latency in web access by minimizing the number of connections and round-trip messages. Adding this support into the HttpClient API means that server responses come back much faster, leading to an app that feels more fluid at the same network speed. And the best part is – this feature on by default, so there is zero code change required to leverage this. For more details on how HTTP/2 provides faster web access to apps, see this talk from Build 2015. The talk also features a simple photo downloading app that shows approximately 200% improvement in latency upon switching to HTTP/2 (demo video).

The following code snippet shows how to query the HTTP version preference on the client as well as the actual HTTP version being used for the connection:

Notes:

Setting the Request.Version property to 2.0 is not supported on other .NET platforms and will throw a System.ArgumentException when trying to send such a request. The default version on .NET platforms other than UWP is 1.1.

The Request.Version property represents the client API preference to use HTTP/2. The actual HTTP version used will depend on the client OS, server and intermediate proxies. HTTP/2 is a negotiated protocol that will automatically fall back to HTTP 1.1 if the server or intermediaries do not support HTTP/2.

What’s Changed

In this section, we review some APIs that were already available to Windows Store developers but have undergone significant change in underlying implementation. Understanding this change may help you as a developer to gain insight into changes you may see in your code as you port it from a Windows 8.1 Store app to Windows 10 UWP.

System.Net.Http

In Windows 8.1, the implementation of HttpClient was based on a managed HTTP stack comprising of types such as System.Net.HttpWebRequest and System.Net.ServicePointManager . In .NET Core for UWP apps, this has been replaced by a completely new, lightweight wrapper on top of native Windows OS HTTP components such as Windows.Web.Http , which is based on WinINet. This allows us to leverage all the latest features (e.g. HTTP/2) from the OS and we are able to provide these new features much faster to .NET developers than we previously could. It also helps lower the memory consumption of .NET apps running on Windows 10, thereby giving the user a more fluid experience running multiple apps simultaneously. The available set of APIs from System.Net.Http documented here remains unchanged.

The new implementation has been tested to ensure functional parity with the previous Windows 8.1 implementation so that you, the developer, do not see any differences in API behavior as you port your HTTP client code to UWP. However, if you do see any issues/bugs, please file a bug on GitHub.

System.Net.Requests

This library contains types related to System.Net.HttpWebRequest and System.Net.HttpWebResponse classes that allow developers to implement the client role of the HTTP protocol. The API surface for .NET Core 5 is the same as that available for Windows 8.1 apps and is very limited compared to the surface in the .NET Framework. This is intentional and we highly encourage switching to the HttpClient API instead – that is where our energy and innovation will be focused going forward. Other parts of .NET Core 5 such as Windows Communication Foundation (WCF) have already migrated to HttpClient in their .NET Core implementation as well, as outlined here.

This library is provided purely for backward compatibility and to unblock usage of .NET libraries that use these older APIs. For .NET Core, the implementation of HttpWebRequest is actually based on HttpClient (reversing the dependency order from .NET Framework). As mentioned above, the reason for this is to avoid usage of the managed .NET HTTP stack in a UWP app context and move towards HttpClient as a single HTTP client role API for .NET developers.

What’s the same

Other types from System.Net and System.Net.NetworkInformation namespaces that were supported for Windows 8.1 Store apps will continue to be supported for UWP apps. There have been some minor additions to this API surface, but no major changes in implementation.

Looking Ahead

In this post, we discussed the initial version of the set of .NET networking APIs that will be available to Windows 10 UWP app developers. We will continue to build on this set and add more API surface to ensure that developers can write rich, full-featured UWP apps using .NET.

To ensure that we prioritize and focus on the right APIs, we need feedback from you – please send us feedback on which APIs are missing in .NET Core and are blocking you from delivering the best possible experience to your users in a UWP app. Please create or vote on an idea on Windows platform missing APIs uservoice or file an issue in GitHub. We look forward to working with you to deliver awesome apps to the entire breadth of Windows devices.

Networking API Improvements in Windows 10

In today’s cloud-first, mobile-first technology world, most Store apps have at least some integration with web services or other devices on a network. These include apps that fetch online weather content, news or sports scores, media or podcast downloaders and even peer-to-peer games, chat or VoIP apps. These apps are built using a wide variety of networking APIs that are a part of the Universal Windows Platform.

In Windows 10, our networking team has invested significant effort in improving these APIs in terms of their speed and memory performance as well as the capabilities and flexibility they provide to you, the developer. In this blog post, we’ll discuss some of the key improvements we have made in this area, and illustrate how to leverage these in your own apps.

Networking APIs in Universal Windows Platform

The Universal Windows Platform (UWP) contains a large set of networking APIs that are targeted at diverse scenarios – from querying the connectivity status of the device and connecting to peer devices, to communicating with REST web services and downloading large media files in the background. In this blog post, we’ll focus on the following subset of networking APIs:

1. Windows.Networking.Sockets – Typically used in P2P chat, VoIP and VPN apps
2. System.Net.Sockets – .NET version of Sockets API widely used in cross-platform libraries and apps
3. WinSock – Widely used in cross-platform libraries such as OpenSSL or multiplayer game libraries
4. Windows.Web.Http and System.Net.Http – Used to communicate with REST web services
5. Windows.Networking.BackgroundTransfer – Used for uploading or downloading data even when app is not in the foreground
6. Windows.Data.Json – Used to serialize/deserialize JSON content served by webservices

These APIs represent different layers in networking from Sockets at the lowest layer, HTTP building on top of it and finally, Background Transfer and JSON that add more value building on top of HTTP.

New in Windows 10

In Windows 10, the above-mentioned APIs have been enhanced for greater performance and for providing more flexibility to developers. We discussed all of these improvements in detail in this video for BUILD 2015.

1. Socket Broker: Allows apps to listen on Sockets even when the app is not in the foreground
2. Batched Sends: A new optimization in the Sockets API implementation can make sending data up to 4x faster.
3. HTTP/2: HTTP APIs now support the new, faster version of HTTP protocol for UWP apps. This makes REST webservice downloads and uploads up to 3x faster.
4. Post-processing in Background Transfer: UWP apps can now handle the completion of their background downloads/uploads in a background task even before the app is launched the next time.

Due to time constraints, we couldn’t cover all of the new features we’re adding to Windows 10 in the video. Here are a few more:

System.Net.Sockets and Winsock for UWP Apps

With Windows 10, System.Net.Sockets and Winsock have been added into the API surface for UWP app developers. These were both highly requested API s for Windows Store apps (they were already available for Windows Phone Silverlight apps). WinSock is also supported for Windows 8.1 apps with the latest updates to Visual Studio 2014.

The current API surface of both Winsock and System.Net.Sockets for UWP apps is based on that of Phone 8.1 Silverlight and continues to support most of the types, properties and methods (some APIs that are considered obsolete have been removed).

Client certificate support for StreamSocket class

Windows.Networking.StreamSocket class supports using SSL/TLS to authenticate the server the app is talking to. In certain cases, the app also needs to authenticate itself to the server using a TLS client certificate. Starting in Windows 10, you can provide a client certificate on the StreamSocket.Control object (this must be set before the TLS handshake is started). If the server requests the client certificate, Windows will respond with the certificate provided.

Here is a code snippet showing how to implement this:

[code lang=”csharp”]
var socket = new StreamSocket();
Windows.Security.Cryptography.Certificates.Certificate

certificate = await GetClientCert();
socket.Control.ClientCertificate = certificate;

await socket.ConnectAsync(destination, SocketProtectionLevel.Tls12);
[/code]

Handling null values and better debugging experience for JSON

One of the key developer requests we had for our Windows.Data.Json API in Windows 8.1 was to enable better handling of null values. Starting with Windows 10, we have added new, intuitive APIs to serialize and deserialize null values to and from JSON strings. Here is an example of how you can handle null value in JSON strings in Windows 10 UWP apps:

Serializing an object to JSON (Stringify):

[code lang=”csharp”]
jsonObjectNetworking apis in windows = JsonValue.CreateNullValue();
var outputString = jsonObject.Stringify();
[/code]

Deserializing a JSON string (Parse):

[code lang=”csharp”]
IJsonValue myJsonValue = jsonObject.GetNamedValue(key);

if (myJsonValue.ValueType == JsonValueType.Null)
<
Phone = null;
>
else
<
var myValue = myJsonValue.GetString();
>
[/code]

The new JsonValueType.Null enumeration value enables handling of null values with the same programming patterns that developers use today for integers, strings or Boolean values.

Richer debugging experience in Visual Studio for JSON

The next addition to Windows.Data.Json API is an improved debugging experience with Visual Studio. In Windows 8.1, developers stepping through their code while debugging would only see the type of a JsonObject or JsonArray instance but not its contents. This makes it harder for developers to debug their parsing logic and ensure that their objects have been correctly populated. Starting in Windows 10, you can now inspect the internal contents of JsonObject and JsonArray types. Here’s an example with a JsonArray object:

Improved SD card support for Background Transfer

In Windows 8.1, the Windows.Networking.BackgroundTransfer API supported downloading data on a removable storage (e.g. SD Card). The design was to download the content in the internal temporary cached storage first and then move the file to the destination. As a result, the size of the file which can be downloaded was constrained by the amount of internal storage available.

In Windows 10, this implementation has been changed to check whether the download is happening in a different drive than where the application is installed and use that location for the temporary cache. This will alleviate the problem of not being able to download large content (content which is greater in size than the available internal storage) on SD card.

Related Content

The entire set of networking APIs in UWP is too large to cover here. You can watch the following videos from Build 2015 for more info on other APIs in the networking area:

Looking Ahead

With Windows 10, we have evolved our networking APIs from Windows 8.1 to provide better performance and capabilities to you, the developer. Further, since these APIs are a part of UWP, you can use them to build apps for the entire range of Windows devices. With upcoming releases, we will continue to improve the performance of our networking APIs as well as add features that enable developers to build awesome, differentiated experiences on Windows. We look forward to hearing your feedback on which networking APIs are currently missing from UWP and are highest priority for you to deliver your app on Windows. You can file an idea on UserVoice or join the Windows Insiders program and submit feedback through the forums.