Discussion: What is Project Reunion? about windowsappsdk HOT 13 CLOSED

Project Reunion will be a set of code you can reference in your app so there’s a single API surface between Win32, packaged, unpackaged, and UWP. Project Reunion will do the versioning & light up & fan-out and deliver functionality for use in your apps.

WinUI and WebView2 are "Project Reunion family" components as they use modern API definitions, work in all those kinds of applications, work across Windows versions, and handle most of the heavy lifting of version agility for you.

Please help us prioritize the support your apps need - especially where your app is UWP but wants more powers like Win32 or where your app is Win32 but wants access to the modern functionality included in UWP.

from windowsappsdk.

That's one way to think about it, yes. There's a bunch of awesome APIs in Windows with a long history of support. Some of those are hard to use safely, others have been replaced with newer better APIs over time. We know your apps need to run on as many versions of Windows as possible, and requiring apps to have the "if win7 { thing } else { newer-thing }" can be error prone.

Ideally there's common core problems we're providing solutions for. Lifecycle, power management, data isolation, notifications, background tasks, windowing, security, identity, and more. Providing a single converged API area that works across Win32, UWP, Desktop, and more helps your app code take advantage of the best support when available.

from windowsappsdk.

Thanks for the responses so far. My goal here is to ensure everyone is at the same level of understanding.

Project Reunion will be a set of code you can reference in your app so there’s a single API surface between Win32, packaged, unpackaged, and UWP. [...]

• By "set of code" are we talking about a library (and perhaps projections for multiple languages) here?

• Sounds like this "set of code" will offer yet another abstraction on top of what we have now, in hopes of hiding some of the gritty details.

  • So using file reading as an example, presumably the "set of code" would:

    • Tap into Win32 CreateFile and/or ReadFile if called from the context of an unpackaged desktop app
    • Tap into WinRT Windows.Storage.FileIO methods if called from the context of a secure AppContainer packaged app
    • etc...

    Is that correct?

• Are there really APIs that differ in packaged and unpackaged scenarios? Or are you referring to APIs that require identity?

• Can you clarify what you mean by "UWP"? There is no canonical definition of UWP, so it's critical the moniker not be used. (For example, UWP doesn't have any APIs of its own. It envelopes existing Win32, COM, and WinRT APIs, yet this repository makes a confusing distinction between Win32 and "UWP" APIs.)

WinUI and WebView2 are "Project Reunion family" components as they use modern API definitions, work in all those kinds of applications, work across Windows versions, and handle most of the heavy lifting of version agility for you.

• Makes sense.

from windowsappsdk.

The FAQ points at the Universal Windows Platform App page and distills the four parts of the application model (deployment, isolation, lifecycle, presentation) as they relate to UWPs. Do note that full trust components are not strictly universal - when an MSIX with one deploys on certain editions the functionality will not be available at runtime. We're keenly aware of this division and what it means when app developers want to target "all Windows endpoints" which may be inclusive of those editions with stricter policies.

One of my personal motivations for Project Reunion is to identify the common places where UWPs rely on runFullTrust to access platform functionality not available to AppContainer. For many of these already proposed in issues - background clipboard access, file verb handlers, app file access prompts - Project Reunion can provide an AppContainer-ready supported approach to those problems, rather than every app inventing or cloning their own mechanism. Ideally this would let those apps remove the runFullTrust part of their MSIX and be completely clean UWPs.

from windowsappsdk.

@jonwis I understand that's what you think UWP means, but you have to load in some historical context here to get closer to the truth. In 2014, UAP/UWP was introduced as a silo holding the Windows Runtime, the UI design language, a new appmodel, identity system, and a bag of store policies. This was part of the grand universal vision. Win32, COM, and .NET were not part of this vision.

Fast forward to 2019, Microsoft recognized the conflation of UI, model, and API surface and started breaking down those couplings, effectively killing the original UWP vision. Microsoft called for us (developers, MVPs, and press) to stop using the UWP terminology, confirmed that vision was dead, and asked that we instead embrace all app incantations as simply Windows Apps. Unfortunately, NDAed/poor communication, combined with downlevel/outlier platforms (e.g. HoloLens), has resulted in a huge darn mess.

My ask is simple: Stop using the term UWP. It doesn't mean what it originally meant in 2016. It's never clear what anyone is referring to when it's used in conversation. And it's commonly misused (e.g. there is no UWP XAML, are no UWP APIs and certainly are no, as you suggest, "UWPs").

from windowsappsdk.

We've added more details about what Project Reunion is, the approach and the roadmap.
https://github.com/microsoft/ProjectReunion/blob/master/docs/README.md

from windowsappsdk.

I would like to know the scope and vision for this project #23

from windowsappsdk.

So would it be right to think of Project Reunion, as a semi-wrapped Win32/COM API set - which can be consumed by apps?

WinRT already being clean and projected, but older APIs being brought up to a similar level?

from windowsappsdk.

That's one way to think about it, yes. There's a bunch of awesome APIs in Windows with a long history of support. Some of those are hard to use safely, others have been replaced with newer better APIs over time. We know your apps need to run on as many versions of Windows as possible, and requiring apps to have the "if win7 { thing } else { newer-thing }" can be error prone.

Ideally there's common core problems we're providing solutions for. Lifecycle, power management, data isolation, notifications, background tasks, windowing, security, identity, and more. Providing a single converged API area that works across Win32, UWP, Desktop, and more helps your app code take advantage of the best support when available.

That sounds brilliant. I think what could be helpful down the line, would be to have documentation with the "best way" to do things, so instead of doing X and Y in MFC, use these Reunion APIs.

from windowsappsdk.

I'm also confused because in "The Journey to One.NET" at 1:24:37 it is stated that .NET Core / 5 will not come to UWP. Does that mean Project Reunion, despite adding a larger Win32 API surface, will not be able to host a .NET 5 runtime? Is this a technical decision or strategy decision?

Frankly this project seems like a dead end if it still doesn't bring 2-year-old C# and .NET features to the platform. It looks like a stopgap effort to try and revive UWP development for one last hurrah ahead of the Windows 10X release, since the Windows team prefers container-ready apps.

If Microsoft wants 10X apps, this Build 2020 should've showcased the best possible tooling for those apps. How does Reunion improve that developer story?

from windowsappsdk.

@jonwis I'm disappointed you decided to invent another definition for UWP. It seems to ignore runFullTrust apps and fails to acknowledge the ambiguity that exists in the community.

from windowsappsdk.

We've added more details about what Project Reunion is, the approach and the roadmap.
https://github.com/microsoft/ProjectReunion/blob/master/docs/README.md

That is a much clearer vision for what this project aims to be and do!

I wonder if Microsoft has been collating feedback from big Windows app developers over the years, to identify pain points or difficult to achieve things with the low level Windows COM,

Companies like Adobe, Autodesk, the Office team, etc - Could that past knowledge be shared to facilitate discussion of what pain points could be wrapped into modern, powerful and flexible APIs?

Then there are elements within Windows, things like the DWM, GDI+, that are core to Windows, but closed off with undisclosed functionality and internal code. Will there be consideration to modernising or creating open implementations of these things, which could become part of Reunion?

from windowsappsdk.

@mdtauk - Thanks! We're still evaluating the balance of what we can move into Project Reunion and what stays in the platform. If there's specific functionality that your app would benefit from, please file a specific issue for it. Definitely "this was hard to use" is one detectoid for something that Project Reunion could help with.

from windowsappsdk.