Announcement: Proposed approach for windowing in Project Reunion #370
Replies: 92 comments 88 replies
-
|
Is there a plan for handling the pain (for Microsoft) of eternal backwards compatibility? As developers opt-in to Reunion it would be good to embrace the idea of deprecating functions in future versions, in order to provide the best APIs possible. Though I appreciate you probably don't want to think about past v1 release, I just wanted to point out how bonkers it is that Win32 still has support for 16-bit APIs (and even in UWP e.g. LocalAlloc and co). |
Beta Was this translation helpful? Give feedback.
-
|
New APIs making use of However I agree that we could drop some APIs like |
Beta Was this translation helpful? Give feedback.
-
|
Questions:
|
Beta Was this translation helpful? Give feedback.
-
|
I'm just advocating for allowing old APIs to be removed, or updated, and for new APIs to be added. I guess if Reunion is shipped with the app, that would be reasonably trivial to achieve. |
Beta Was this translation helpful? Give feedback.
-
|
Please don't do this. It's good for App developers but when you write or use libraries a stable API and ABI is necessary. Shipping WinUI bundled with your App instead of the OS does not change anything on this problem. |
Beta Was this translation helpful? Give feedback.
-
As Raymond Chen keeps reminding us, source compatibility is important to adoption. There is code out there that started with Win16 and is probably still with us today. |
Beta Was this translation helpful? Give feedback.
-
Regarding this goal, I noticed that Win32 was explicitly mentioned. For clarify, can someone confirm if UWP will also recompile to Reunion with limited code changes for the windows space? I apologize if the question doesn't makes sense, I'm still wrapping my head around Project Reunion |
Beta Was this translation helpful? Give feedback.
-
We will provide a migration path from UWP AppWindow API onto the high-level Reunion Windowing APIs that is mostly automatable. |
Beta Was this translation helpful? Give feedback.
-
|
Great questions Rafael! I'll try to address them as best I can.
The object/construct you use to reference a window. In Win32 this is HWND, for UWP it is CoreWindow, ApplicationView and AppWindow depending on what APIs you are using. We want to make sure you can reference a window in the same way across the different app models, and also make sure that as a developer you don't have to think differently about a window based on what API created them.
I know that this announcement is light on technical details that may be needed in order for you to give deep and meaningful feedback on how this approach for windowing will work, benefit, or impact each of you and your specific app needs. But in general I want to bring windowing to top of mind of the community in order to set the stage for the specs that will start to show up for this space in the near future. A couple of questions I want you to think about and try to answer as we continue the conversation (some of it on this post, some of it on new posts about specific features):
|
Beta Was this translation helpful? Give feedback.
-
|
I have a question based on something that has nagged at me in a different situation. It might not arise in Project Reunion. It is about Abstraction-Layer InterferenceIt is a bit about leaking abstractions. Here is my example case. There are two questions. This has to do with stateful entities and what happens (or is prevented) when one operates with a sharing of the other. I am willing to be told that this is a naive question and that the runtime/Reunion does not allow such abstraction-breaking interferences. But I have to ask. |
Beta Was this translation helpful? Give feedback.
-
We are thinking hard about this one. As I wrote above we are targeting "most" of the windowing primitives, not all. This is intentional - we will weigh app compatibility and usage against "cleaner platform" and potential tradeoffs of not bringing an API forward. As part of the next steps we will be sharing what we believe are a good "first set" to bring forward and have a communication with you to align and adjust as needed. |
Beta Was this translation helpful? Give feedback.
-
|
From an appearance standpoint, my hope is that I can still use the best of what CoreWindow offers, but with the flexibility of some Win32 window features. For example, the most asked for things for UWP CoreWindow has been things like custom window geometry and real transparency. Easy Acrylic is still amazing so we don't want to lose that, so imagine being able to combine Acrylic with custom geometry without needing to write a custom graphics pipeline. |
Beta Was this translation helpful? Give feedback.
-
|
Am I right in thinking that the initial version of this, when it is added to Reunion, will take us all back to the current windowing offered by Windows? Are there plans and thoughts for adding new innovation to windows and windowing? There was talk at Build 2018 I think, about actual new modern windowing concepts there were to come to UWP. And how far back will these innovations be supported, Windows 10 Threshold / Windows 8.1 / Windows 7?
|
Beta Was this translation helpful? Give feedback.
-
@rkarman
|
Beta Was this translation helpful? Give feedback.
-
|
Agree with the first dot-point. The forced overlay of UWP actually prevents certain kinds of apps from being developed that utilize screen edges (top and bottom) for functionality, like camera panning. We see the problem with UWP's current approach in Minecraft and No Man's Sky where the task bar and title bar sometimes pop up in front of the window without permission. There has been some discussion of complete overlay suspension in UWP but we still haven't heard anything about a solution. |
Beta Was this translation helpful? Give feedback.
-
|
No Man's Sky on PC is not UWP... |
Beta Was this translation helpful? Give feedback.
-
|
Was I thinking of Astroneer. |
Beta Was this translation helpful? Give feedback.
-
|
Being able to handle more than one window from the same thread / message loop is key in Win32 and is really missing in UWP (unless I missed an API). |
Beta Was this translation helpful? Give feedback.
-
|
"message loop is key in Win32 and is really missing in UWP" - what does this mean? Instead of the legacy Win32 message loop, UWP has a more modern style of subscribing to events - application events, window events and input events. The classic message loop has never been required AFAICT. |
Beta Was this translation helpful? Give feedback.
-
|
Read as "more than one window from the same thread [...] is key in Win32 and is really missing in UWP" |
Beta Was this translation helpful? Give feedback.
-
I always found the UWP windowing options to be more complicated than I would have liked. I would never have called them "easy". Making them ever "easier" in the future would be great. The explanation of laying of APIs isn't clear. It sounds like all APIs will be available everywhere and does not explain how they will be layered. How does microsoft/microsoft-ui-xaml-specs#71 relate to this? |
Beta Was this translation helpful? Give feedback.
-
AppWindow allows that, but ContentDialog can only be opened once per thread at a time. Which means if you use that you're forced to use threads anyways. Worse even, XAML islands in a thread currently leaks if I just exit the thread after the window is closed, so I had to implement my own thread pool to keep the message loop running once the window is closed (because the Windows thread pool doesn't do that) to allow the cleanup to be performed correctly. Fun times. |
Beta Was this translation helpful? Give feedback.
-
|
Answering some questions under my current knowledge of the current Plan of Record about WinUI. Q: Will WinUI run on a) Xbox, b) HoloLens, c) Surface Hub, d) Azure Cloud, e) Windows 10X? Q: Will WinUI continue to support a security sandbox execution model? Q: Given WinUI code is no longer compiled to native code as is the case for UWP, what will be in place from day 1 to prevent reverse engineering IL byte code back to source code? Q: What will the performance penalty be in comparison to UWP, for C# WinUI given .Net Native is no longer in the mix? Q: Will WinUI continue to support the Appx container? Q: Will F# development be supported for WinUI? Q: What will Microsoft's position be with respect to UWP apps currently in the store. Is there an end of life point planned? Q: Why is the UWP binary XAML specification still undocumented? It too was clearly designed to prevent easy snooping and has yet to be documented for that reason. I have also read some comments about some functionalities (APIs) that are not available for external developers. |
Beta Was this translation helpful? Give feedback.
-
|
"UWP is a reliable platform for making Windows apps," reliable, but hobbled, without modern .net support and without Steam distribution, it's a dead platform. |
Beta Was this translation helpful? Give feedback.
-
|
@marb2000 , thank you very much for answering all the questions. I appreciate the candor. I am disappointed in key aspects of where this is going. It's simply not feasible for many companies to be publishing their source code through means of fully reversible IL byte code. Becoming automatically Open Source is not the objective for a lot of us when we publish something into the Store. Obfuscation has many issues that I care not to revisit, nor is obfuscation any sort of answer here. Looks like I'll be dusting off my C++ in a big way for anything I'll be releasing with WinUI. I also expect Microsoft to publish nothing of significance with managed code. Prove us wrong that you, Microsoft, considers WinUI + Managed a non starter for your customer facing products. That's the message you're already putting out with respect to UWP, by re-writing just about everything that was decent as a Microsoft UWP app. It's not a stretch to see that WinUI will be less performant than UWP in many ways. Given everything you have described @marb2000, I really do have to wonder who WinUI is intended to attract? My only answer would be WPF developers that could not make the switch to UWP because of all its limitations. Eventually, WinUI winds up with the same UI capabilities as UWP, in addition to all of the Win32 API surface. Given the promises made when UWP was first put forward, over all, it's a pretty big step backwards if that's the goal, and at UWPs expense. I can call into Win32 from UWP today if I distribute outside the Microsoft store. The future is gloomier than I imagined. The world keeps getting stranger. The mess gets bigger. Sorry if that sounds dreary or dire. |
Beta Was this translation helpful? Give feedback.
-
|
I invite you to check out the following page: https://github.com/dotnet/runtimelab/tree/feature/NativeAOT. This NuGet package currently in development can transform .NET IL into precompiled binary programs just like you are requesting today. As long as you don’t use NativeAOT emits a different, product-specific form of reflection metadata that is not visible to ILSpy or similar programs. While this can in theory be used to locate certain product routines for reverse engineering, if you’re that concerned you can disable reflection and emit no metadata whatsoever, but this comes at a compatibility penalty. Hope this helps! |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the heads up @wjk. I've been playing with this and IL2CPP. This WIP is a long way from being applicable to where UWP is at today. IL2CPP is somewhat closer to the under the hood contortions the .Net Native compiler performs. Sad to see .Net Native become an orphan ... as the expression goes, success has many fathers, but failure is an orphan. |
Beta Was this translation helpful? Give feedback.
-
|
One last note before I leave this alone for awhile, @marb2000 , one of your colleagues did manage to paint a less gloomy UWP picture. I need to dial back my pessimism a tad. 2020 was not a good year to be an optimist. |
Beta Was this translation helpful? Give feedback.
-
|
Glad that @ryandemopoulos bring more clarity. 2020 wasn't a good year, I hope 2021 will be brighter and full of hope. |
Beta Was this translation helpful? Give feedback.
-
|
"Glad that @ryandemopoulos bring more clarity." I guess he hadn't see the June Community Call at this point in time. @Noemata You now know better I'm sure, than to imagine that UWP was going to get a fair treatment. It's all about Win32 now. |
Beta Was this translation helpful? Give feedback.
-
It's Win32 and XAML. |
Beta Was this translation helpful? Give feedback.
-
|
@andrewleader , I appreciate the intent with the retort. My view, civil conversation is a nice to have, freedom of speech is a must. So if @llothar wants to throw a couple scurrilous remarks, as long as its not particularly vicious or obscene then say what you must. I can take it. Besides, we all have the occasional bad day and lapse in judgement. |
Beta Was this translation helpful? Give feedback.
-
Well put, but quite an unpopular opinion these days. |
Beta Was this translation helpful? Give feedback.
-
|
I think "Freedom of Speech" as enshrined in the US Bill of Rights is not the same as "Freedom to Speak Everywhere." Nothing compels nongovernmental actors to provide a carte blanche pulpit. I, for one, am quite happy with the Code of Conduct on Microsoft code-in-the open GitHub projects, and will honor it. In particular, I celebrate the notion of having people know that they are safe from aggressive behavior here, and are free to speak within the community constraints. |
Beta Was this translation helpful? Give feedback.
-
|
How about VB.NET? |
Beta Was this translation helpful? Give feedback.
-
|
VB should be compatible to reference projections from CsWinRT. |
Beta Was this translation helpful? Give feedback.
-
|
But clean VB.NET project language will not be there, only C# and C++? |
Beta Was this translation helpful? Give feedback.
-
|
For consuming, there's no difference. For authorizing, it may not be supported if additional source is added to the project. |
Beta Was this translation helpful? Give feedback.
-
|
noted. Thank you |
Beta Was this translation helpful? Give feedback.
-
|
Sorry if this has already been discussed or implemented, but what it the proposed threading model for the new windowing system? Will all the windows use the same thread, or will they use different threads (like CoreApplicationView currently)? Both cases have some potential caveats that I'd like to raise here. The case of the same thread would be simpler to use, but how will we access the properties of the currently relevant window, such as the DPI? If an object is in the visual tree, then it is connected to the window via its parents so there ought to be a way of accessing the window properties easily in that case. But what about outside of the visual tree, or before a control is added to the visual tree? Will be have to pass around a reference to the window as needed? It is essential that support for different windows on different displays with different DPIs is maintained. If not that would be a deal-breaker for me. There are also some more subtle APIs that would need addressing, for example what if you load a BitmapImage in code and choose the option where you provide a view pixel size for the decode width/height. How will the BitmapImage know what DPI to use when converting this to physical display pixels (which it does automatically before decoding)? The case of different threads is more complicated as it requires the developer to put locks around shared objects such as app settings etc. This is painful but once done it's not too bad. However, the main problem I have is how to safely close the window. At the moment (UWP), you get a consolidated event, and then it's up to you to call Window.Close() at the appropriate time (except for the main view which you can't close). However, it would be nice if there was some guidance or build-in support for dealing with this problem. The reason why this is difficult is what if you have ongoing async operations such as this pseudocode. If you close the window while the write is still pending then presumably the stream will not be disposed because the await will never return, so the file will remain locked until the stream is garbage collected, which could be a while (note I haven't tested this fully but it's my assumption). Even worse, I've been using the async lock pattern to do this like load/save state that is shared between windows like so. Note the lock is released on dispose. If the window is closed before this has completed, the lock will be held forever I think. At the moment I just wait for 20 seconds after the consolidated event before closing the window, but this doesn't seem ideal. Some guidance or better built-in mitigations should be appreciated. Another approach I suppose is not the close the window, but reuse it when the user opens a new view (this is what I do for the main view). However, if this is a bit wasteful of memory. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the reply. I'm not sure I understood your comment that detecting the correct DPI is irrelevant for threading because there are many APIs such as the BitmapImage one I mentioned that rely on being to implicitly work out the DPI by using a static method like DisplayInformation.GetForCurrentView without having a reference to the XAML tree (if you use it before adding it to the visual tree). I'm not sure that MVVM says anything about threading in general. But maybe what you are saying is if I were to move the view-independent part of the function to its own function, then I could use ConfigureAwait(false) within that function, which would mean that the function could continue on a background thread even if the view thread shut down. That might be a useful approach. |
Beta Was this translation helpful? Give feedback.
-
|
@benstevens48 if you have multiple windows, each window could be on different monitors with different DPIs. There would be no way to do this from a static if the two windows are on the same thread |
Beta Was this translation helpful? Give feedback.
-
|
@dotMorten - yeah, that was my point, that the one-thread-per-window and one-thread-for-all-windows models each have their drawbacks. But it sounds like the XamlRoot solution will allow the one-thread-for-all-windows model to work correctly with different DPIs (excepting a few APIs that get the DPI implicitly from a static method) since the controls in the visual tree can get the DPI propagated from the XamlRoot, which is presumably associated with the window. |
Beta Was this translation helpful? Give feedback.
-
This was what I spec'ed, @JesseCol was the dev that implemented it. Jesse, if you are in these GitHub lands, can you double check it, please? |
Beta Was this translation helpful? Give feedback.
-
|
@marb2000 - Thanks for the confirmation. I wasn't saying it didn't work, I just wanted to check that it had been considered! I imagine that when it comes to the one-thread-for-all-windows model there are a few APIs that will need calling out in the docs to avoid such as the BitmapImage one I mentioned (specifically BitmapImage.DecodePixelType = Logical, used before insertion into the visual tree). |
Beta Was this translation helpful? Give feedback.
-
|
Does this new Windowing API have anything in store for real-time/fullscreen applications/games? Like:
Getting a surface to render on, putting it on a desired monitor and switching between apps/windows/modes doesn't need to be a rocket science. |
Beta Was this translation helpful? Give feedback.
-
|
@pjmlp Just looked over #14 - it's really really sad MS is doing this, but yeah, not unexpected. It seems win2d will be ported to WinUI3, but there's no timeframe - #756 (reply in thread) |
Beta Was this translation helpful? Give feedback.
-
|
It looks like MS has some other ideas and some of my concerns are probably addressed in their new GDK https://docs.microsoft.com/en-gb/gaming/gdk/ But looking at the docs and the GDKs contents it is still unclear to me what they are really trying to do. At least it it appears that they've scrapped the UWP app model for game consoles and replaced it with Win32 and new C++ exceptionless APIs, which actually is a quite an achievement :)))) (the Reunion Project for the XBox platform???) and it will be possible to develop and publish OpenGL/Vulkan games on Windows store. But if the GDK is any good for non Windows store titles is not quite clear. Maybe not. And what about the App lifecycle management on desktop? IMO the docs are a mess. Hopefully this GDK will be store agnostic. |
Beta Was this translation helpful? Give feedback.
-
|
The UWP model was anyway just for Indies, AAA titles always used a Win 32 like application model. If anything this just confirmed I should rewrite the few UWP apps I still have back into Win32. |
Beta Was this translation helpful? Give feedback.
-
|
@pjmlp I am so sure about that, this doesn't look like anything Win32 to me: It's a bit strange to find this which once was behind an NDA wall in an MS repo. There was UWP for self publishing and XDK for the real stuff. I am not aware of any other options. |
Beta Was this translation helpful? Give feedback.
-
|
That is the deprecated ERA application model, based on WinRT and C++/CX. |
Beta Was this translation helpful? Give feedback.
-
|
UWP has easy to use windowing APIs however the problem with that is some stuff is in one class while others. I understand why this was done like this however I would like to see a single wrapper for all of them and it could work in both Win32 and UWP apps so you can reuse the same code for window/title bar customizations. |
Beta Was this translation helpful? Give feedback.
-
|
Reunion should provide a single titlebar/caption buttons/frame to all kinds of apps using it, and have them work with the same API. That would include non-WinUI apps, with the titlebar extended or not. |
Beta Was this translation helpful? Give feedback.
-
|
Hi everyone. I had a great chat about windowing at discord, and thanks to @mdta i am here now.
So now, some ideas around TabVieW and "windowing":
Excuse the long post, my poor english and my "rustyness". |
Beta Was this translation helpful? Give feedback.
-
|
Classic style apps, would do this in MDI, which is not really a thing in WinUI. WPF has docking panels which could present a side by side UI. I think some thought should go on how existing applications, which make use of MDI, should rethink their UI through samples and possibly blog posts/documentation. Content Dialog is not flexible enough for this, but some kind of "attached" window that moves along with it's parent window could be useful here. It may require WinUI adding new controls, or Reunion enabling new types of windowing modes. Eitherway, a modern solution is needed, especially with the fact that MDI windows in Windows 10, still have an odd mix of Windows Vista Basic Theme styling, within a Windows 10 Win32 style window. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you. The idea is not to create a classic MDI app, because we don´t want the windows to be "inprisioned" in the main one, but I understand you and agree a modern solution is needed. |
Beta Was this translation helpful? Give feedback.
-
|
@rkarman |
Beta Was this translation helpful? Give feedback.
-
|
Funniest thing is, exactly this flickering was fixed, since Windows 3, for plain Win32 windows in version 1703. |
Beta Was this translation helpful? Give feedback.
-
|
@tringi You are probably talking about the ones that use GDI, those are more or less fine. Everything that uses DirectX to draw shows the issue (WPF included). |
Beta Was this translation helpful? Give feedback.
-
|
@Torquerrr Yes. What I meant is, that this flickering is result of naïve approach of implementing the operation in multiple steps, where each one triggers repaint. |
Beta Was this translation helpful? Give feedback.
-
|
Excuse me for meddling in the thread, but where to report a bug in UWP AppWindow? Are Reunion devs maintaining it too, or there is dedicated team for UWP? The bug is that when you close AppWindow, main window sometimes consolidates too. |
Beta Was this translation helpful? Give feedback.
-
@andrewleader I think the expectation is that after Reunion 1.0, Reunion will be taking over responsibilities for UWP app's windowing, even if its not the current priority. :) |
Beta Was this translation helpful? Give feedback.
-
The problem with the Feedback Hub is that no one uses it, even developers. It is the place where old and sick bugs quietly live out their lives. As far as I understand, it is only intended so that technical support can send angry users there when nothing can be done. I have used it and know that sometimes weeks and months pass from the moment when user opens a ticket to the moment it becomes visible in the Partner Center. It just makes no sense to create anything there. |
Beta Was this translation helpful? Give feedback.
-
|
I more than 100% agree. I'm sure MS meant well with Feedback Hub, but the reality is exactly as you say. |
Beta Was this translation helpful? Give feedback.
-
|
@omikhailov |
Beta Was this translation helpful? Give feedback.
-
@ecovio1 You can try reaching Panos Panay in Twitter directly, or maybe even Scott Hanselman. |
Beta Was this translation helpful? Give feedback.
-
|
Will Project Reunion update most common controls to be double buffered by default, so that they're all flicker free? List/Treeview can have double buffering enabled, however all controls should have double buffering enabled by default. Flickering has never looked good, and when there's flickering in a GDI app right next to a UWP app in 2021 it looks terrible. |
Beta Was this translation helpful? Give feedback.
-
|
The List/Treeviews are not individual controls anymore. Thats the new design model. They are just rendering instructions in a buffer that is the size of the toplevel window. So there is neither a meaning to double buffering nor individual control. But the sad thing is that resize window flickering still exist. There are multiple open issue tickets about that, |
Beta Was this translation helpful? Give feedback.
-
|
@rkarman as we approach v1 and the Windowing api is available, is it worth closing off this discussion (it's been stagnant since June) and starting a new discussion focusing on what the team is planning for the next iteration? |
Beta Was this translation helpful? Give feedback.
-
|
Yes. This topic will be closed with the 1.0 Stable release, and we'll open a new to discuss plans and feedback for the next iteration. |
Beta Was this translation helpful? Give feedback.
-
|
I have been playing with the Windowing APIs from preview3 and got some thoughts: The good:
The bad:
|
Beta Was this translation helpful? Give feedback.
-
|
There is |
Beta Was this translation helpful? Give feedback.
-
I know, but in the same way in WinForms one can get the Handle with Window.Handle, why shouldn't it be as easy with WinUI? |
Beta Was this translation helpful? Give feedback.
-
|
Because it seems it should be acceptable for us to write boilerplate code that wasn't a thing in Forms/WPF, or the Microsoft's competing platforms, for whatever reason. I really don't get this distortion field that finds it natural and expects us to buy into it,. after the whole bunch of rewrites started on Windows 8, rebooted on each Windows version afterwards. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your feedback here @martibravo ! I've asked the dev team to take a look at the bug you filed, and we're discussing the other features in the team and will log requests in Productboard to bring into planning for coming releases. Yes, there are integration work to be done between WinUI and the windowing platform to help make life even easier for you as app developers. We're working on this together with the WinUI team and plans will be communicated through the WinUI roadmap over time. |
Beta Was this translation helpful? Give feedback.
and others
-
Windowing in Reunion
We are excited to share some news with you today around the future of windowing for Windows developers. We have been listening to your feedback and concerns for this space over the years and we believe the approach we have chosen will address these in a positive way. This area has a lot of history (some of the features you use today, such as sizing and positioning windows, has been around since the first version of Win32) and a lot of investment in the developer community (your multi-windowed apps, your customized title bars, your customized dialogs and tool windows to create unique experiences, etc.) - we want to acknowledge and honor that as we go forward.
This post will outline our approach from a high-level perspective, our guiding principles, and our goals for the windowing space for Project Reunion. We are eager to get your feedback here, and we are open and ready to adjust our plans based on what you tell us. Nothing is set in stone - we are starting this journey here today, together with you.
A unified windowing space
In the past we have had two very different ways of "doing windowing" for Win32 and UWP - one very powerful but complex to work with even for basic windowing scenarios; one very limited in capabilities but easy to achieve the basics with.
For UWP we have been in a constant state of "catching up" on core functionality, and never being able to. While for Win32 we have been in a state of non-innovation, leaving developers behind because we have focused on bringing new features only to UWP where we can guarantee that guardrails are in place.
We heard you - this situation is not making anyone happy and moving between the two worlds is hard.
With Project Reunion we are taking a bold stance - we want all Windows developers to have the power of Win32 windowing at their disposal, but we also want to provide easy to adopt APIs that can provide consistent experiences across apps, as well as easy to use APIs that lower the bar of entry for new developers.
We also want the windowing model to be fundamentally the same, so that we create a familiar way of working for developers regardless if you chose UWP or Win32 as your application model.
Our approach in order to achieve this? A layered set of APIs.
Layers of APIs
We acknowledge that if you started with CreateWindowEx and used HWNDs for your app, you want to be able to continue to do so going forward. A re-write of your main window proc is just not going to be feasible. Therefore, we are bringing most of the windowing primitives from USER32 to Reunion. This gives you access to powerful APIs when you need them.
We also acknowledge that some things are really hard to do, or to get right for all situations, with the USER32 APIs, so we bring you AppWindow - a high-level windowing API surface that gives you access to a modern Windowing Model with an easier to use surface for areas where we have gotten a lot of feedback in the past, or where we want to help drive innovation, consistency in experience, or make it easier to adopt new features.
How is this different from the old Win32 vs UWP situation?
First, all these APIs are accessible to you regardless of process model - both UWP and Win32 have access to all the layers of the APIs. There might be some behavioral differences when calling the low-level APIs due to the security context of your app and whether it is running in a container or not. For example, the fact that we give you access to
lower level APIs from UWP does not mean we give you access to other processes or their windows, you’ll only be able to modify your own windows - the security context for UWP is not changed.
Secondly, we are giving you the ability to freely move from one layer to the other regardless of where you started from.
Existing apps and their adoption to Reunion
For Win32 we touched on the approach already, by moving most of USER32 to Reunion we hope that you will have a straight-forward and easy path to adopt Reunion. Note that we are not saying that everything in USER32 will be available in Reunion and that there will be no work needed to move your Win32 app to Reunion - there will be parts of USER32 that will not being carried forward, but we will try to keep this to a minimum and limit the apps impacted.
For UWP the story is a little bit more nuanced. UWP have multiple windowing currencies, each with different limitations and life-time management. We are not going to preserve them all and move them to Reunion. As we mentioned earlier we are unifying the windowing model, this means changes to UWP that will require work. We are working through the details of the migration story for UWP depending on where you start from (CoreWindow, ApplicationView, AppWindow), and will start sharing that with you over the coming months. Our aim is to make it easy to migrate most UWP projects to Reunion for the windowing space, and we will do everything we can to help you come with us on the Project Reunion journey. If you have worked with AppWindow in UWP, you should be familiar with what we have in mind.
More details please!
We know that this post is light on technical details and completely lacks API shape information. This is intentional. We first wanted to share our approach for this space with you, to allow you to give feedback on this and influence it. As we align on the approach and start to move forward on the details, we want to design the APIs in the open together with you, not hand down a ready-made solution that we've designed in a vacuum. We hope you agree that this is the right approach, and we look forward to work out the details together with you for the initial release and for many years to come as Reunion grows.
Starting the journey together with you
Over the coming months, we will create functional and API specs here on GitHub and we are looking forward to a great partnership with the community. As a first step of this partnership we'd like to share our guiding principles and high-level goals for the windowing area as these will help inform everyone where we're coming from and what we're aiming for.
Guiding principles for Reunion windowing
We will support developers "where they are" – we will aim to support existing Win32 app developers with limited rewrite
of their existing code; we will aim to support existing UWP developers with an easy transition from AppWindow and
ApplicationView to Reunion windowing APIs.
We will design our new APIs with existing developers in mind, such that we do not leave existing Windows developers
behind or alienate them with "yet another solution"; for developers new to the Windows ecosystem we will strive to have
a low barrier of entry.
We will provide a full stack of APIs – powerful low-level primitives, targeted at expert developers that allow them to
innovate and create experiences beyond our own roadmap and imagination; high-level scenario APIs that allow for any
developer to light up our new features and take advantage of new form factors at a low cost.
Goals
modern development principles and patterns.
Non-Goals / Negative Goals
Open Source
It is our goal to provide as much of the windowing stack for Project Reunion as Open Source as possible. We will listen to your feedback on what you need in this space and adapt as we move forward.
Beta Was this translation helpful? Give feedback.
All reactions