General questions

[float34]

Hello!
Couple of questions.
Sorry if they are incorrect/naive, I am trying to understand everything on a higher level and from a Python developer perspective.

1. I feel that there are not enough illustrative materials explaining the architecture of "Project Reunion". My confusion comes from the fact that there are also not much diagrams explaining UWP-Win32 APIs relation. The only one I was able to find is from Windows 8 era, probably not relevant anymore. Having diagrams is crucial for attracting new developers, one picture worth thousand words. You can't understand the next step if the previous step is unclear.
   Maybe I am missing something and there is a folder/resource somewhere with all related images?

2. Looking at https://github.com/microsoft/ProjectReunion/blob/main/docs/images/projectreunion.gif I really don't get why one need to implement another API layer instead of merging Win32 and UWP APIs on the OS level, e.g. by extending Win32 with new UWP APIs.
   This way all new apps will still access Win32 APIs if they need WinUI/packaging/whatever, just "modern" parts of it.
   Are there any obvious reasons to implement it the way it is now? If yes, will it be simplified in the future?

3. What is the computational overhead of using language projections like C++/WinRT (C#/WinRT) compared to "pure" C++/C# calls to Win32? Are there any benchmarks? If not, those measurements needs to be performed as well.

Thank you!

[andrewleader]

Hey Victor, thanks for asking these questions!

1. Agreed that we currently don't have too many docs explaining the architecture (hopefully we'll expand those as we're working on the architecture ourselves). Is there something specific you're trying to understand as an app developer? From the app developer perspective, there shouldn't be any need to worry about the architecture... you simply install a NuGet package into your app and then you can use Reunion APIs directly from your app, regardless if it's C++ or C#, regardless if it's a packaged app or not.
2. The reason we're adding another API layer is that this new Reunion API layer can be shipped "out of box", which means we can support these APIs down-level, and when we ship new APIs, you don't have to wait for the next Windows update to be able to use the APIs. Today, apps have to wait 1-2 years till all their users have updated to the latest version of Windows 10, with shipping APIs outside of the OS itself, we can let you (app developers) use APIs instantly without waiting.
3. I'll ask our WinRT expert!

[Arebusf21]

I understand where Victor is coming from, it's not clear where in the Windows software stack, the Windows App SDK sits!
It's difficult to make a decision on designing a new application, if you cannot visualize the software environment you are developing in.
Most Windows developers are reluctant to "dive in" and use new software because of past experiences, spending many hours hunting down errors and trying to understand software that is not adequately documented. Right now you have some members of the developer community that are lost in the forest and looking for a way out! It would be great for a Reunion architect to take some time out and document at a more detailed level where the SDK software sits in the overall software stack that is the Windows development environment.