Windows 10: Microsoft Making Win32 APIs More Accessible to More Languages

Brink · Jan 20, 2021

Introduction

Win32 APIs provide powerful functionality that let you get the most out of Windows in your applications. While these APIs are readily accessible to C and C++ developers, other languages like C# and Rust require wrappers or bindings in order to access these APIs. In C#, this is commonly known as platform invoking or P/Invoke.

Historically this has required developers to handcraft the wrappers or bindings, which is error prone and doesnât scale to broad API coverage. In recent years, given the strong demand for calling Win32 APIs from various languages, several community projects have spawned to provide more strongly typed and idiomatic representations of these wrappers and bindings to provide an improved developer experience and spare developers the overhead of creating them themselves. Some notable projects include PInvoke for .NET and winapi-rs for Rust.

The main challenge with these projects is they are manually maintained, which makes broad and sustained API coverage difficult and costly, and their work doesnât really benefit other languages.

As owners of the Windows SDK, we wanted to see where we could provide unique value here, take some of the burden off of the community, and make achieving broad and sustainable API coverage across languages a reality.

The result of this is our win32metadata project and corresponding Win32 language projections now in preview on GitHub!

Win32 Metadata

The goal of the win32metadata project is to provide a complete description of the Win32 API surface in metadata so that it can be projected to any language in an automated way, improving correctness and minimizing maintenance overhead. The output of this project is effectively an ECMA-335 compliant Windows metadata file (winmd) published to Nuget.org containing metadata describing the entire Win32 API surface.

Win32 APIs have existed for a long time, so accurately describing all of them will take some iteration. We will be developing this tooling in the open and welcome community contributions to ensure an accurate representation of the Win32 API surface that will benefit all languages.

For this metadata to enable developers to call Win32 APIs idiomatically from the language of their choice, we need language projections built on top of it. The first such language projection is #/Win32.

C#/Win32

Built in partnership with Andrew Arnott, the owner of the PInvoke project for .NET, C#/Win32 parses the metadata and generates the P/Invoke wrappers required to call the APIs you care about.

Simply add a reference to the Microsoft.Windows.CsWin32 package from NuGet.org and add a file called NativeMethods.txt to the root of your project with a list of Win32 functions you want to call. The file can contain one function per line or even wildcards like BCrypt.* for including entire modules. Once populated, C#/Win32 will generate the P/Invoke wrappers for the functions you request and all of their dependencies.

[IMG width="750px"]https://blogs.windows.com/wp-content/uploads/prod/sites/3/2021/01/CsWin32.gif[/IMG]

You can see in the animation above, after adding CreateFile to NativeMethods.txt and a using statement for the Microsoft.Windows.Sdk namespace, CreateFile can be called via the PInvoke static class. C#/Win32 provides rich Intellisense, strong types for parameters, and also includes the relevant documentation from docs.microsoft.com, all dynamically generated from metadata based on the APIs you request! No additional dependencies are required, broad API coverage is achieved with improved correctness and minimal maintenance overhead, and the APIs are expressed idiomatically as C# developers would expect.

You can learn more about C#/Win32 and try it for yourself by visiting the repo.

C#/Win32 is just an early example of whatâs possible with dynamically created projections of Win32 APIs. We envision projections like this for many languages, all expressing Win32 APIs in whatever idiomatic patterns developers of the language expect. The windows Rust crate is another example.

Rust

The Rust language projection follows in the tradition established by C++/WinRT of building language projections for Windows using standard languages and compilers, providing a natural and idiomatic way for Rust developers to call Windows APIs. The windows crate lets you call any Windows API using code generated on the fly directly from the metadata, enabling you to call the APIs as if they were just another Rust module. It does not attempt to partition Windows APIs by technology, instead providing a single way to call any Windows API regardless of the underlying technology. You can seamlessly make use of APIs based on C-style exports, COM interfaces, or WinRT types.

Other Languages

In addition to C# and Rust, we are also working on a Modern C++ projection in the open on GitHub and welcome community contributions there. These projects are early previews and under active development so are subject to change significantly as we absorb feedback and make progress. We will work with the community to support other languages based on demand, partnering with existing community projects where appropriate.

Under the umbrella of the win32metadata project, we hope to advocate a set of principles that all language projections should follow for the best developer experience while providing flexibility for each projection to do whatâs best for their community.

Conclusion

Making Win32 APIs more accessible to more languages will allow developers to make the most out of Windows regardless of their preferred language. We are excited to engage with the community to expand API coverage and language support and minimize the maintenance overhead of existing projects.

You can view our roadmap, FAQs, and other useful details in our repo.
Click to expand...

Source: Protected: Making Win32 APIs More Accessible to More Languages

:)

Amrita Bhattacharjee · Jan 20, 2021

microsoft photos language

Hi Magda,

I suggest you to follow the steps below and check if it helps.

Type settings in the search box.

Click on time and language.

Click on region and language.

Click on add a language.

Select the particular language and then make it as default by right clicking on the language and click on as default.

Please post back with the updated status to assist you further.

Thank you.

Brink · Jan 20, 2021

Microsoft filling in divide between Win32 apps and new Windows APIs

Many new and sought-after Windows APIs and features such as BackgroundTasks, Notifications, LiveTiles, Share and more, are either not available or not easily callable from non-packaged Win32 applications. This is due to the programming model for UWP APIs that integrate with the system and have a dependency on the following concepts:

Identity – The need for package or application identity to identify the caller, and an identifier to scope data and resources.

Registration – The need for configuration of machine state during application deployment, which is required by the API and indexed by the package or application identity.

For packaged applications, Identity declared in the Appxmanifest.xml, and Registration is handled by the MSIX deployment pipeline based on the information in the AppxManifest.xml. This allows a simplified calling pattern for UWP APIs where the application code just uses an API. Compare this to a typical Win32 API that requires a register-use-unregister pattern for managing a callback.

We’ve heard your feedback, and in response we’re filling in the divide between Win32 apps and new Windows APIs & features so that you can take advantage of these new APIs & features and enhance your applications. As of Windows Build 10.0.19000.0 we’re introducing the following new AppModel concepts to provide your Win32 app with deeper integration into the OS:

Sparse Package registration
Signed MSIX packages can be installed on Windows today but all content referenced in the package’s Appxmanifest.xml must be present inside the package. A ‘Sparse’ Package contains an AppxManifest.xml but unlike a regular/full package, the manifest can reference files outside its package in a predetermined ‘external location’. This allows applications that are not yet able to adopt complete MSIX packaging to gain Identity, configure state (Registration) as required by UWP APIs and then take advantage of these APIs.

Package ‘External Location’
To support a Sparse Package, a package definition now has a new <allowExternalContent> element. This is what allows your package AppxManifest.xml to reference content outside its package, in a specific location on disk. For example, if your existing Win32 app installs content in C:\Program Files\MyWin32App\ , you can create a Sparse Package that declares the <allowExternalContent> element and during app installation or first run of your app, you can register the Sparse Package and declare C:\Program Files\MyWin32App\ as the external location your app will be using. This way you can continue deploying all your other app artifacts in the locations you do today while taking advantage of the Sparse Package.

Win32 type RuntimeBehavior
To help with compatibility of your existing Win32 app when using a Sparse Package, the app can register to have its application process be run like a non-packaged Win32 app as much as possible. This differs from a fully packaged Win32 app in that it is not subject to filesystem + registry virtualization, lifetime management by the system and other runtime attributes of fully packaged applications. The main runtime similarity between such an app and a fully packaged app is the presence of app/package identity in the running process.

Activation via CreateProcess
The activation path for UWP applications today ensures the app has PackageIdentity in its process token. This is used by UWP APIs to identify the caller and refer to later – either to perform a callback or to look up state that was configured during deployment. Because of this requirement, calling CreateProcess() on a UWP exe will fail as the CreateProcess() pipeline was not enlightened about Identity. In order to support Sparse Packages with an External Location, we leverage the classic Win32 application.manifest to provide Identity in CreateProcess() scenarios.

At their core, these features are about providing a foundation for non-packaged Win32 processes to use our latest APIs and features.

*Please note that these are still new and somewhat advanced development features that do not yet have full Visual Studio integration i.e. there are still some gaps in the end to end authoring experience such as having to create a Sparse Package outside of Visual Studio...
Click to expand...

Read more: Identity, Registration and Activation of Non-packaged Win32 Apps - Windows Developer Blog

Tweet

— Twitter API (@user) View on Twitter
Click to expand...

Brink · Jan 20, 2021

Introducing the Storage Access API for Microsoft Edge

Today, we’re excited to announce the “first-look” rollout of the Storage Access API in our Canary and Dev channels. For developers, this API allows them to determine whether their access to browser-based storage is restricted by a user’s privacy settings and to request storage access from users if so. This capability can be used to create graceful fallback experiences in cases when storage access may be restricted by features such as tracking prevention in Microsoft Edge. For users, this API provides greater transparency into and control over the sites that are requesting access to browser-based storage that could be used to track their behaviors across the web. This post outlines what the addition of the Storage Access API means for both developers and users.

Developer Experience

Using the Storage Access API is as easy as updating your code to leverage the following new functions:

hasStorageAccess()

Useful to check if access to cookies and other storage exists in the current context.

Returns a promise with a boolean result indicating if storage access exists or not.

requestStorageAccess()

Requires a user gesture to invoke.

Useful to request access to storage for a single third-party context.

Returns a promise that will resolve if access is either available or granted and reject if unsuccessful.

Note: Since we are still gradually rolling out the Storage Access API, it’s possible that you may not have it enabled by default on your device. If you want to test it early, please enable the “Storage Access API” flag in edge://flags.
The usage of these new functions is best demonstrated with an example.

Example:

A social media site, contoso.social, offers sites the ability for developers to embed social media widgets as third-party content on their sites. One site where these widgets appear is www.contoso.example. To offer the ability for contoso.social users to comment on, save, or share contoso.example content with friends, contoso.social’s embedded content needs access to its own storage such as cookies or localStorage in the context of contoso.example in order to associate these actions with a visitor’s account.

Checking for Access:

contoso.social can use document.hasStorageAccess() to see if access to storage already exists and to provide an alternative user experience such as displaying a request to login or request access if not:

Code:

document.hasStorageAccess().then(access => {
if (access) {
// Show UX with access to storage.
} else {
// Show UX for no access.
}
});
Click to expand...

Requesting Access:

If no storage access is currently present, contoso.social can request access during a user gesture. As an example, the onclick handler of a login button could be tied to a request for storage access (see the “User Experience” section below) using the document.requestStorageAccess() method.

Code:

function onLoginClicked() {
document.requestStorageAccess().then(() => {
// Access granted: Safe to access storage now.
}).catch(e => {
// Access denied
});
}
Click to expand...

Sandboxing

The allow-storage-access-by-user-activation token can be used to enable the usage of the API when embedded content is loaded in a sandboxed iframe. In practice, both the allow-scripts and allow-same-origin tokens will also be required as well to ensure the API can be effectively used.

Code:

<html>
<body>
<iframe sandbox="allow-scripts allow-storage-access-by-user-activation allow-same-origin" src="https://constoso.social/embed.htm"></iframe>
</body>
</html>
Click to expand...

As a developer, we hope you will leverage the Storage Access API to create web-based experiences that will continue to be compatible even as browsers place more restrictions on third-party storage.

User Experience

With the introduction of the Storage Access API, you may notice an “Allow cookies and site data?” prompt like the one below when you interact with third-party content such as social media widgets or embedded videos while browsing:

This indicates that the site whose embedded content you’re interacting with (contoso.social in the example above) currently has its storage restricted by Microsoft Edge’s privacy settings and is requesting your permission to access its storage within the context of the site you’re visiting (https://www.contoso.example in the example above). While several types of sites require storage access for legitimate scenarios such as making sure you’re signed in when you expect to be, allowing this access can allow the site requesting it track your activity on the site you’re currently visiting.

Clicking “Allow” will temporarily allow the requesting site access to its storage on the site you were visiting when the prompt appeared. This allowance will last for a 30-day period after which it will automatically expire. Clicking “Block” will prevent the requesting site from accessing its storage on the site you were visiting when the prompt appeared. If you change your mind, interacting with the third-party content a second time will cause the prompt to be displayed again, giving you the option to revisit your choice.

To give you control over any storage access requests you’ve allowed before they automatically expire, you’ll notice a new “Cookies and site data you’ve temporarily allowed” section at the bottom of the edge://settings/content/cookies page. Here, you can review and revoke the storage access requests you’ve granted in a single list:

Community Involvement

We implemented the Storage Access API upstream so that all Chromium-based browsers could benefit from it. We are also actively participating in standardization discussions that are ongoing in the W3C Privacy Community Group to ensure that the API works uniformly across browsers. If you have any feedback on the functionality or capabilities of the API itself, please feel free to join the standardization discussions by filing an issue on GitHub. If you have any feedback on the Storage Access API as it exists in Microsoft Edge, please send us feedback using in-app feedback tool (Alt + Shift + I).

To close, we’d like to thank our friends at Apple and Mozilla for their early work on the Storage Access API and our friends at Google for helping pave the way for getting the API implemented in Chromium. We’re excited for you to try it out and to hear what you think!

– Brandon Maslen, Senior Software Engineer
– Scott Low, Senior Program Manager
Click to expand...

Source: Introducing the Storage Access API - Microsoft Edge Blog

Tweet

— Twitter API (@user) View on Twitter
Click to expand...

Tweet

— Twitter API (@user) View on Twitter
Click to expand...

Windows 10: Microsoft Making Win32 APIs More Accessible to More Languages

Microsoft Making Win32 APIs More Accessible to More Languages

Microsoft Making Win32 APIs More Accessible to More Languages

Microsoft Making Win32 APIs More Accessible to More Languages

Microsoft Making Win32 APIs More Accessible to More Languages - Similar Threads - Microsoft Making Win32

One more question about the Win32 hive situation?

Making Reinstallation more Seemless

Making web more accessible and inclusive for all with Microsoft Edge

Microsoft Edge DevTools now available to more languages

Microsoft should use more of Vulkan API in Gaming

Make video more clear

Microsoft account makes networking more difficult?

Making Microsoft products more accessible: What to expect in 2017

Microsoft & Facebook create open ecosystem to make AI more accessible