I _think_ its an API wrapper to make functionality available in older versions of windows, is is only in newer versions of windows? Or maybe other platforms that support UWP? It feels like the readme is written in startup-speak, where I was expecting it to be a little more... developer-y?
UWP was originally "monolithic" and "closed" in several respects: your app had to either adopt all UWP facets (be a "UWP app") or none (be a "Win32 app"), new APIs only shipped with new Windows releases, the implementations were entirely closed source, etc.
In the past few years they've started to take pieces of what used to be UWP and pull them out into separate components. Unlike the monolithic UWP platform, these components can be adopted independently by Win32 apps without having to adopt all the other components at once, their runtimes can be distributed with your app outside of Windows and run at least a few versions back, their implementations are partly or wholly open source, they do planning and design reviews in the open on github, etc.
So far, the components they've done this with have been
* WinUI (a decoupling of the UWP UI framework)
* MSIX (a decoupling of the UWP packaging system)
* C++/WinRT, C#/WinRT and Rust/WinRT (a decoupling of the UWP object system and language bindings)
The "new" Project Reunion is basically an umbrella name for these decoupled UWP components, a declaration of their intent to decouple the rest of UWP in similar fashion, and a new github repository for planning this and designing the future evolution of the Windows developer platform in general. So the repository has issues posted by Microsoft developers about how the UWP app lifecycle and resource formats can be decoupled, for example.
https://docs.microsoft.com/en-us/windows/apps/desktop/modern...
Desktop C++ users should use: "UWP XAML hosting API provided by the Windows 10 SDK (version 1903 and later)."
This was about a month ago.
I hope they do better this time.
Fascinatingly, it seems that Microsoft for their own purposes prefers to use Electron-based applications.
I'm curious if they will manage to reduce that strange state to something more reasonable.
The original goal was to force people to move to UWP, which is mobile friendly, processor architecture independent, etc. But the shift was too hard so nobody did it. If all of the APIs are available everywhere, legacy Win32 apps can continue to evolve, and at the same time, Win32 and UWP apps coming closer together makes an eventual shift over to UWP more practical because it won't require starting from scratch.
Possibly related:
Windows Package Manager Preview
https://devblogs.microsoft.com/commandline/windows-package-m...
https://github.com/microsoft/winget-cli
[1] https://mybuild.microsoft.com
[2] https://github.com/microsoft/ProjectReunion
[3] https://venturebeat.com/2020/05/19/microsofts-project-reunio...