Windows 10: Microsoft explains what is Project Reunion to fix Win32 and UWP apps

Brink · Jun 15, 2020

What is Project Reunion?

Project Reunion is a set of libraries, frameworks, components, and tools that you can use in your apps to access powerful Windows platform functionality from all kinds of apps on many versions of Windows. Project Reunion combines the powers of Win32 native applications alongside modern API usage techniques, so your apps light up everywhere your users are.

Your app can use the parts of Project Reunion that are most interesting to you without having to rewrite it into a new app model or deployment system. Project Reunion provides a single consistent API surface for both new and existing functionality that automatically adapts to your preferred app model and deployment mechanism. Project Reunion helps you move towards a modern API and app style without requiring you to make a hard choice to rewrite it or re-implement it across versions of Windows.

This repo contains the Project Reunion components that are common for all applications. Look for the "Project Reunion Family" badge in other repos showing that their code is using Project Reunion techniques and tooling. Your own components can be part of the "Project Reunion Family" by following the same principles and practices as Project Reunion itself â support all forms of apps with a single API surface and meet developers where they are with the tools they need to build great apps on Windows.

Using Project Reunion will be as simple as adding a reference to our NuGet packages in your build.

What Project Reunion Brings

Project Reunion functionality comes in three main categories â new APIs, converged APIs, and API subsets. Your apps can pick up each different level of functionality at your own pace.

New APIs

Whenever possible, new Windows functionality will be delivered as part of the Project Reunion Family. APIs and functionality delivered as "New" are identity-, packaging-, and isolation- transparent to your application. New functionality will share a common interface for you to use whether your app is MSIX, MSI, setup.exe, Desktop Bridge, or AppContainer.

Some of the APIs and functionality listed will come over time; they are listed as examples of the category rather than fully supported on day 1.

These APIs are self-consistent and solve specific application problems or help you build additional functionality into your application. Potential categories of APIs here might be:

Application data storage and management to keep your data in one place and the user's system tidy

Cloud app support for identity and connectivity management to use the power of Azure

Packaging and system integration so Windows understands what your app is doing

App-to-app inter-process communication helpers so your apps can work with other app easily

Privacy-aware resource access APIs for camera, microphone, location, and more

You'll start using these APIs by adding a reference to the Project Reunion NuGet package and then adding uses of the APIs in your app code. Use as much or as little of Project Reunion as helps your application. New Project Reunion APIs will be available on all supported versions of Windows and for all apps. Where certain APIs behave differently (such as due to identity, isolation, or lifecycle differences) your app can detect it with clear "TheType.IsSupported" checks.

Converged APIs

Project Reunion provides API surfaces that bridge the gap between Win32 and UWP/AppContainer functionality already within the platform. Authors of shared code (like frameworks) can use a single method and avoid their own "if (AppContainer) { x } else { y }" checks.

Project Reunion APIs provide "polyfill" implementations of APIs when necessary so your app can run on more versions of Windows without additional "is this Windows 10 Creator's Release?" checks.

Converged API documentation also includes ways to find uses of the "un converged" code in your project, along with guidance on how to move from common code patterns to the new Project Reunion converged APIs. Examples of converged APIs include:

Window Content Frame abstraction over Win32 and UWP windowing

Application lifecycle behaviors like start, logoff, restart manager integration, restart-for-update

Startup and Background Task support to reduce your app's power and performance footprint

Application resource management for strings, images, display resolutions, and locales

Advanced clipboard access

Once your app adds a reference to the Project Reunion codebase your app can start migrating blocks of functionality to using these fully-supported converged APIs. You can move as much of your application to Project Reunion functionality as necessary, keeping your existing application style and behaviors. Whenever possible these APIs will be similar to their existing Windows SDK namespaced APIs, easing the transition to Project Reunion for your existing code. For existing "flat C" Win32 APIs, an equivalent converged API will be added and then projected to your language and runtime. If you prefer a "flat C" style â or the APIs you want already have a "flat C" expression â we're working on building out a projection of those APIs for you.

As your app migrates to Project Reunion functionality it'll be easier to move between deployment and isolation technologies. Project Reunion handles the brokering of resource access from a low integrity-level (low-IL) or AppContainer process so your app can reference user resources while respecting user choice & privacy controls.

Subset API Family

Project Reunion helps you stay within the set of APIs that Windows supports on all editions and all endpoints. Like the Windows Kit API partitions, Project Reunion defines a subset of supported Windows Platform APIs that work across all versions of Windows. If your code targets this subset - and uses Project Reunion New + Project Reunion Converged functionality whenever possible - it'll work everywhere Windows works, without needing additional support work.

Project Reunion Subset APIs for your apps also let you start using Project Reunion's functionality with minimal changes to your existing code by using an updated and streamlined set of headers and implementations. Feature areas supported by the Project Reunion Subset include subsets of:

Windowing, Input, Messaging, GDI, and GUI subsystem functionality

Filesystem and storage access

Networking

Printing

Process, threading, memory management, basic application services

DirectX, D3D, DirectML

Migrate your app to the Project Reunion Subset API set by first removing all references to Windows Kit headers (windows.h, kernel32.lib, user32.lib, winsock.h, etc) and then adding references to the core Project Reunion Subset header and import libraries.

While many existing Windows Kit APIs are part of the Project Reunion Subset, you may have some minimal changes to make to your application's code or behavior. Recompile & relink your application then ship it with our support packages.

Is this "subset" model interesting for you and your apps? This feature of Project Reunion is still in planning for a future release. Let us know by filing an issue with the "subset" tag on it and list the APIs and functionality you'd like to see.

Project Reunion Family Components

Available Now

These components are available for you to use now and adhere to the "Project Reunion Family Promise" that they have a single API for use in all kinds of applications.

WinUI 3 for XAML helps you build fluent UX for all kinds of applications with the power of XAML. This component {link to repo} is part of the Project Reunion Family of functionality, building on the identity + packaging + deployment transparent ideas that Project Reunion supports for your app as well.

C++/WinRT, RUST/WinRT, and C#/WinRT provide language-native projections of Windows, Project Reunion, and your own custom types defined in metadata. Consume APIs from the Windows Kit, produce them for use by other supported projections, and create your own new language projections.

MSIX-Core lets you package your application for distribution to Windows Desktop machines via the store or your own delivery pipeline. MSIX-Core lets you use the reuse parts of the MSIX packaging story on older versions of Windows.

Coming Soon

While we think these are interesting for applications, you tell us! Part of working in the open is that we learn together about the needs of application developers. Below are a set of functionality that seems interesting to make available through a Converged or New model, but you tell us! Some are linked to an issue thread proposing the functionality. +1 the ones you like, comment on the detailed design & direction, and help us shape where we're going.

Edge/Chromium backed WebView2 brings the ease of authoring your app in HTML+JS once and reusing it on all platforms. WebView2's use of Project Reunion technologies like WinUI3 as a hosting frame lets you run modern web-based UX on all editions of Windows.

Modern Lifecycle helpers help your app be power-sensitive and reactive to changes in the runtime system's power management and user state. They also help your app restart after the user reboots, register your app so it can be restarted, and reduce update-related reboots.

Startup Tasks make your app come alive as the user logs in to reconnect, start working while not over-using resources, or be ready for fast use. User choice and power management features let you reduce your impact on the critical logon path.

Update Scan Integration help keep your app up to date automatically while running at the same time as other system maintenance tasks are happening.

Access to user resources even from AppContainer and isolated applications. Your AppContainer apps can access powerful Win32 technologies like the clipboard, inter-process communication, and the Windows Shell Namespace with user consent through brokering.

Modern Resource Tooling so you can use the power of ResX/ResW in your Win32 applications instead of MUI.

Future Direction

We aim to grow Project Reunion to provide a modern, simple, and accessible version of much of the power of the Windows Application Platform. Working in the open with our development community ensures we're doing the right things first to solve problems your apps are facing on current and future versions of Windows.

Some functionality will be delivered first as Project Reunion components. As we think about evolving the platform it's important to make sure new functionality & features are available to our developer community just as soon as they're ready to go. Where there's newer in-platform functionality to use Project Reunion will help you adopt that as soon as it's widely available, without you having to retarget or rewrite â the same Project Reunion API surface will continue to work.

As your app uses more Project Reunion functionality it'll be ready for additional targets such as packaging, identity, AppContainer, and other future Windows Editions. Depending on Project Reunion APIs means we take on the work to keep these APIs working as Windows evolves forward. Staying within the Project Reunion API surface ensures your app can address the widest range of Windows editions and releases while using up-to-date functionality.

How we are doing this

Working in the open

Project Reunion relies on the power of open-source and the features of GitHub to deliver code to you as fast as we can dream it up. You should feel free to fork, create pull requests, open issues, propose resolutions to issues. You can see and influence all our features via the issue tracker. You should expect that we listen and provide constructive feedback.

Build & Artifacts

Code within the Project Reunion GitHub repo builds on a CI/CD loop and produces freshly built DLLs and metadata on each pull request. The output includes a NuGet package containing metadata for Project Reunion and a ready-to-deliver MSIX for inclusion in your application as a redistributable or as a package reference. Add a reference to the Project Reunion package and start building. To help deploy your apps we'll include both a Framework Package MSIX as well as instructions on how to deploy that MSIX from your existing installer.

Versioning

Project Reunion will use strongly-typed metadata-based API definitions on which your apps can take a long-term dependency following our published support lifecycle. We'll use SemVer 2 to clearly identify breaking API shape levels that let those APIs evolve forward towards new functionality while not compromising existing apps. Project Reunion helps keep apps up to date through Framework Packages that are updated with non-breaking changes as appropriate.

Extending APIs

Some of what Project Reunion provides is access to functionality that is inside Windows, but for which there is no public API. We're working on the details, but our plan is to deliver a secondary package of code that provides a public API over those previously unexposed components. While those components will be implemented as closed-source they'll come with a metadata-based publicly callable & supported API surface and be included in the Project Reunion framework packages for use by apps.

Brokering

UWPs (AppContainer, Low-IL) processes are meant to protect both the user and the application itself from other applications. Access to user & system resources is limited to the supported set of brokers for those resources. Project Reunion also includes a main package that runs at the user's integrity level (medium-IL, sometimes called "full trust") and can provide user-approved access to resources previously unavailable to AppContainer and low-IL processes.

This pattern is available to AppContainer apps today as a "full trust component" - Project Reunion aims to provide a common pattern & platform for these custom components.

What Project Reunion isn't

Project Reunion isn't a new application model or platform from Windows. There won't be a "new Project Reunion App" template for Visual Studio, VSCode, or other development environments.

You'll still have full access to the Windows SDK and associated kits. Over time the features that Project Reunion provides will grow beyond just merging the existing Win32 and UWP models and provide additional functionality for all apps to use.

Project Reunion isn't a new packaging or isolation model for applications. There won't be required changes to your application in order to access Project Reunion functionality other than using the new functionality itself. If the APIs you use need identity or packaging these requirements will be indicated.

Project Reunion isn't a new security or privacy model for applications. Your app's existing security, privacy, reliability, and identity stories continue to work with Project Reunion. There may be places that Project Reunion helps your app be more aware of customer security or privacy concerns. Project Reunion helps you use modern security & privacy functionality that evolves alongside your application's needs.

Project Reunion isn't a way to run your app in the cloud. Using Project Reunion technology will help get your app on modern API families that are cloud ready. Key components like modern lifecycle and state isolation help get your app ready to run wherever your customers are.

More Documentation

High level overview - Why we're doing this.

Roadmap - Where we're going. We're following a roadmap that gets us to building a first version of Project Reunion exploring some basic common features. You can help by filing issues for features you'd like to see!

Contributor guide - How to contribute to Project Reunion.

FAQ - frequently asked questions about Project Reunion.

Click to expand...

Source: https://github.com/microsoft/Project...docs/README.md

:)

Brink · Jun 15, 2020

Microsoft wants to close the UWP and Win32 divide with Windows Apps

Is Microsoft's UWP going away? Is the Microsoft Store on its way out? Microsoft Corporate VP Kevin Gallo explains the latest twists in Microsoft's long and winding Windows developer platform strategy.

For months, many pundits, partners and customers have wondered aloud whether Microsoft's Universal Windows Platform (UWP) has a future. Officially, the story is UWP is alive and well. But the Win32 platform lives on and seems to be back on Microsoft's radar screen. So what's the real story?

I had a chance this week in Seattle to ask Kevin Gallo, Corporate Vice President of the Windows Developer Platform, for his take on what's going on with the Windows developer platform.

When Microsoft launched UWP in 2015, officials promised that the platform would provide apps with better performance and security because they'd be distributable and updatable from the Microsoft Store. Developers would be able to use a common set of programming interfaces across Windows 10, Windows Phone, HoloLens and more, officials said, when selling the UWP vision. The downside: UWP apps would work on Windows 10-based devices only. Developers would have to do work to get their apps to be UWP/Store-ready. And Win32 apps wouldn't get UWP features like touch and inking.

Arguably, Gallo told me, "we shouldn't have gone that way," meaning creating this schism. But Microsoft execs -- including Gallo -- continue to maintain that UWP is not dead.

Over the past year or so, Microsoft has been trying to undo some of the effects of what Gallo called the "massive divide" between Win32 and UWP by adding "modern desktop" elements to Win32 apps.

"By the time we are done, everything will just be called 'Windows apps,'" Gallo told me. "We're not quite there yet." But the ultimate idea is to make "every platform feature available to every developer."
Click to expand...

Read more:

Microsoft wants to close the UWP, Win32 divide with 'Windows Apps' | ZDNet

Microsoft Confirms UWP is Not the Future of Windows Apps - Thurrott.com

Brink · Jun 15, 2020

Microsoft wants to close the UWP and Win32 divide with Windows Apps

Is Microsoft's UWP going away? Is the Microsoft Store on its way out? Microsoft Corporate VP Kevin Gallo explains the latest twists in Microsoft's long and winding Windows developer platform strategy.

For months, many pundits, partners and customers have wondered aloud whether Microsoft's Universal Windows Platform (UWP) has a future. Officially, the story is UWP is alive and well. But the Win32 platform lives on and seems to be back on Microsoft's radar screen. So what's the real story?

I had a chance this week in Seattle to ask Kevin Gallo, Corporate Vice President of the Windows Developer Platform, for his take on what's going on with the Windows developer platform.

When Microsoft launched UWP in 2015, officials promised that the platform would provide apps with better performance and security because they'd be distributable and updatable from the Microsoft Store. Developers would be able to use a common set of programming interfaces across Windows 10, Windows Phone, HoloLens and more, officials said, when selling the UWP vision. The downside: UWP apps would work on Windows 10-based devices only. Developers would have to do work to get their apps to be UWP/Store-ready. And Win32 apps wouldn't get UWP features like touch and inking.

Arguably, Gallo told me, "we shouldn't have gone that way," meaning creating this schism. But Microsoft execs -- including Gallo -- continue to maintain that UWP is not dead.

Over the past year or so, Microsoft has been trying to undo some of the effects of what Gallo called the "massive divide" between Win32 and UWP by adding "modern desktop" elements to Win32 apps.

"By the time we are done, everything will just be called 'Windows apps,'" Gallo told me. "We're not quite there yet." But the ultimate idea is to make "every platform feature available to every developer."
Click to expand...

Read more:

Microsoft wants to close the UWP, Win32 divide with 'Windows Apps' | ZDNet

Microsoft Confirms UWP is Not the Future of Windows Apps - Thurrott.com

FordGT90Concept · Jun 15, 2020

Microsoft Adds Ability to Block Win32 Apps from Install on Windows 10

I think Microsoft is aiming more for a 60/40 ecosystem where the majority of users are on UWP, because that's all they need, and the rest are professionals and power users that sparingly use UWP. I don't think Microsoft expects to eliminate Win32 any time soon simply because the performance differences make it impractical. Case in point: compare the UWP versions of Office programs to the Win32 version of Office. The former is good when you're mobile, the latter is good when you're stationary. The capabilities of the latter far exceed the former.

Windows 10: Microsoft explains what is Project Reunion to fix Win32 and UWP apps

Microsoft explains what is Project Reunion to fix Win32 and UWP apps

Microsoft explains what is Project Reunion to fix Win32 and UWP apps

Microsoft explains what is Project Reunion to fix Win32 and UWP apps

Microsoft explains what is Project Reunion to fix Win32 and UWP apps - Similar Threads - Microsoft explains Project

Microsoft announces release of Project Reunion 0.5

Windows 10 could see big changes with Project Reunion

Microsoft wants to unify UWP and Win32 with Project Reunion

Microsoft is unifying Win32 and Windows 10 UWP development

Differentiate UWP apps from win32/64 software.

Win32 apps in the Microsoft Store?

Win32 & UWP apps missing on start menu, taskbar and search on roaming profiles

Microsoft wants to close the UWP and Win32 divide with Windows Apps

WiFi Direct Windows10 UWP Win32

Users found this page by searching for:

UWP relink