Thanks to a lot of compatibility work, Windows 10 will run applications built for almost any version of Windows, despite significant changes to the operating system’s internals. A five-year effort started in 2003 just to document all the internal system calls, interfaces, libraries and services in Windows led to the much-misunderstood MinWin — not a new OS, but a new demarcation line inside the operating system for truly low-level functionality like the kernel and the basics of the file system, network connectivity, drivers and other core system services.

That demarcation made it easier to develop the OS without breaking dependencies for applications that run on Windows (or for parts of Windows itself). Since them, Windows has had new SDKs, new APIs and new application models like UWP, and plenty of confusion about what the future of Windows applications was supposed to look like — none of this helped by the continually changing terms used to describe them (Metro, ‘modern’, WinRT, Windows Runtime, Store, UWP).

SEE: Windows 10: A cheat sheet (TechRepublic)

Some new Windows features like the Share charm, geolocation or built-in machine learning were only available to apps built using the newer Windows Runtime APIs; so you can share a web page from the Edge browser to OneNote for Windows or the Mail app, but you need the OneNote web clipper extension or the Office Outlook Desktop Integration app to send the page to OneNote desktop or Outlook.

Other controls and APIs stayed in the Win32 APIs and SDK. Some of the feature gap was simply that it took time to redevelop APIs for a new application platform, and many APIs are now available in both Win32 and Windows Runtime namespaces.

Some of it was by design, for greater security, battery life and user control: running in a sandbox, limiting what files and folders could be accessed, stopping code from running in the background and enforcing full, one-click uninstall. And some were older APIs that still worked but weren’t brought to the new platform because they’re deprecated.

The new Windows app platform’s benefits for users meant more work and complexity for developers, even with multiple initiatives like the Project Centennial desktop bridge to repackage Win32 apps for the Store and .NET moving to decouple APIs and releases from releases of new versions of Windows. The new MSIX installer gives Win32 apps an app management model that’s more like UWP, with managed updates that users don’t have to do manually and a cleaner uninstall experience. MSIX also lets developers run a UWP process alongside a desktop app to get access to APIs like becoming a share target — which is how Outlook can show up as one of the applications you can share to from Edge.

Developers can call many Windows Runtime APIs in Windows Forms and Win32 desktop apps, like adding toast notifications that show up in the Action Centre, or using the built-in 3D printer support. If they want to use UWP interface controls like maps and ink, or the new Fluent design, inside Win32 applications, they can do that in Windows 10 1903 and later with XAML Islands.

Decoupling the XAML-driven user interface of UWP apps from UWP with XAML Islands turned into the much more ambitious approach of WinUI: the UI components and controls in Windows are now being separated from the Windows SDK and from Windows 10 itself. As Windows Developer Platform CVP Kevin Gallo explained at Build 2020, Microsoft is going through the API calls, including private APIs, “untangling them and in some cases lifting entire subsystems out” so that they work in more places.

WinUI 3.0 is an open-source project that will include versions of the Windows 10 user interface controls that will work on Windows 7, Windows 8.1, macOS and Linux, plus the WebAssembly controls from the Uno Platform — so a WinUI interface will work in a browser, on iOS and Android, on Windows, Mac and Linux. The app code would have to change, or run as a PWA or in Electron, of course, so developers building a cross-platform app would use the new Chromium Edge WebView control or use the new C++ React Native implementation and WinUI to build JavaScript applications to run on Windows 10 and macOS, but WinUI will work with Win32 apps built in C++ if that’s what developers want to build.

Having started by decoupling the UI controls, Microsoft is now working on bringing the same pick-and-mix approach to the broad set of Windows APIs. Developers writing Win32 apps can use the languages and runtimes they want (C++, C#, Rust, .NET 5 and .NET Standard 2), the APIs they want, whether they’re old or new functionality, without having to switch to the UWP app model or rewrite the code for different versions of Windows.

Project Reunion: the roadmap

Project Reunion currently includes WinUI, the new Edge WebView control and MSIX along with the C++/WinRT, RUST/WinRT, and C#/WinRT projects that let C++, Rust and C# developers use WinRT APIs in their apps. Over time it’s going to include more libraries, frameworks, components and tools (from Microsoft and third parties) that developers can use to write apps, and new controls are going to be released individually, not as part of a new SDK targeting a specific version of Windows. Theoretically, any language and runtime that can handle the COM objects used for software components in Windows will work with Project Reunion.

The platform scope isn’t quite as wide as WinUI: Project Reunion will let developers create apps for Windows 10 as far back as 1709 and 1803 and, in some cases, Windows 8.1. Using MSIX Core means apps can be packaged for those older versions of Windows, but they don’t have to be distributed through the Microsoft Store.

New Windows APIs will be Reunion APIs ‘whenever possible’. That will include APIs for things like storing the data for an application, identity and cloud connectivity, app packaging, communications between apps and access to camera, microphone, location and other resources where users want to be able to choose what apps can use them for privacy reasons.

There will also be APIs to make it easier to use Win32 and UWP functionality in the same application by handling application tasks like startup tasks, handling reboots and logging off, power management and clipboard access.

In future, Project Reunion will also cover the really basic functionality in every version of Windows: process, thread and memory management, windowing, graphics, input, file system and storage access, networking, printing and DirectX (and GPU-powered machine learning with DirectML). Typically those change slightly from one version of Windows to another; use the Project Reunion subset APIs, and developers can code against them once and have it work on all versions.

SEE: What to do if you’re still running Windows 7 (free PDF) (TechRepublic)

Some of what Project Reunion will let developers use is Windows functionality that doesn’t yet have a public API; Microsoft hasn’t talked about what those previously unexposed components might be.

With new releases of Windows coming every six months rather than every three to five years, tying Windows user interface and code components so tightly to a new release didn’t make sense any more. And ever since Windows 8 was announced, developers have been grumbling about having to change to building UWP apps to take advantage of new Windows features when there are vast numbers of Win32 desktop apps still in use and still in development.

Microsoft itself quickly abandoned the idea of recreating Office in UWP apps; the one success there is the UWP version of OneNote, and that team is busy merging the codebase on its UWP and Win32 desktop applications. Indeed, Project Reunion might be designed to help developers just like the OneNote team, who have to deal with a wide range of platforms and app models.

What Project Reunion isn’t is also important: it’s not a new app model or a new class of APIs, or the basis of a new OS like Windows 10X. It’s just a way of letting developers use all the Windows APIs and features in their app, whatever language they write it in, whatever app model they use. It’s going to take quite a few more years to deliver all of this, but it should mean that this time, when developers tweak their applications for the latest Windows options, they don’t have to give up on any of the old features they were already using to get the latest ones.

Developers will still be choosing between Win32 and UWP application models for a while, and Gallo spent a while explaining how to think about the differences now.

“I start with UWP unless I need deep OS integration. The UWP container keeps my apps safer and keeps me from doing what the user doesn’t want me to do by accident and if they get malware or something like that, I’m in a container that adds higher protection. If I want a huge amount of OS integration or [I’m building] a system utility, I start from Win32. It depends on what you’re building and what features you need. But over time those decisions will just go away.”

One of the continuing strengths of Windows is how many different application platforms it supports: you can run .NET, Java and web apps side by side with React Native and Electron apps, alongside UWP, Windows Forms and desktop Win32 apps. As far as possible, Project Reunion will remove some unnecessary divides, so in the long term applications can just be Windows applications and use any Windows features, old or new.