-
Notifications
You must be signed in to change notification settings - Fork 305
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question: What kinds of APIs are out of scope for Reunion? #23
Comments
To add to @mdtauk, here are example issues of mine I created on the WinUI repo: UWP: microsoft/microsoft-ui-xaml#1888 Based on my current understanding of this project, it appears to me these issues above could be a good fit for this repository. I'm not sure about an issue like https://github.com/microsoft/microsoft-ui-xaml/issues/2186 (which targets UWP but for the "reunion's" sake could also be expanded to Win32). Edit: In the Build Focus Group Evolving the Windows App Platform we were told that this repo is also the place to pick for creating UWP app model related issues. |
Reunion certainly will be looking at Windowing APIs and models. Are there other examples of APIs you think might be outside the scope? |
@stevewri lemme try. here are some:
|
Project Reunion can't change fundamental Windows behaviors like processes, threads, memory management, handles, tokens, security boundaries, networking, sockets, shell windowing behaviors, user identity, etc. What we can change are behaviors that are specific to your apps. The FAQ covers what some of these areas are: https://github.com/microsoft/ProjectReunion/blob/master/docs/faq.md#what-kinds-of-apis-are-out-of-scope |
I know these are early days for this project, but it may be helpful if there were some kind of guidance as to what asks are beyond the scope or ability for this project.
One example has been with WinUI. There were certain asks around Windowing APIs and Models, which were OS dependant, and not within the control of the WinUI team/project.
If there were no bounds to this project, you could theoretically reduce Windows to a backend kernel and driver model - and everything from Shell to Apps being moved to this repo and open-sourced.
The text was updated successfully, but these errors were encountered: