Announcement: Proposed approach for windowing in Project Reunion

[rkarman]

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.

• Started out by calling CreateWindowEx and got an HWND, but now you want to go into CompactOverlay? No problem, get an AppWindow object for your HWND and use the high-level scenario APIs!
• Started out by creating an AppWindow, but now you want to tailor your experience beyond what the high-level API allows you to? No problem, get the HWND for your AppWindow and pass it to the lower-layer APIs.

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

1. We will provide a global windowing currency across Win32 and UWP.
2. Win32 apps shall be able to recompile to Reunion with only limited code changes for the windowing space.
3. The windowing API for new projects, whether they be Win32 or UWP, will be a high-level, easy to use, API that follows
   modern development principles and patterns.
4. We will provide a migration path from UWP AppWindow API onto the high-level Reunion Windowing APIs that is mostly automatable.
5. Developers shall have access to the full spectrum of windowing APIs (both high- and low-level) with as few restrictions as possible. Ex. there may be a need to avoid certain window messages, events, or calling patterns when mixing between APIs of different "levels".

Non-Goals / Negative Goals

• It is not our goal to bring the current versions of UWP AppWindow and ApplicationView APIs to down-level OS versions past where they were introduced.

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.

[MarkIngramUK]

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).

[sylveon]

New APIs making use of LocalAlloc have been added as recently as Windows 8. LocalAlloc being present in UWP also hurts no one and makes porting old code easier, so it's a positive.

However I agree that we could drop some APIs like SetWindowLong (which is 1:1 replaced by SetWindowLongPtr)

[riverar]

Questions:

• What is a "windowing currency"? (Please use plain English in all outward facing comms.)

• What do you want from us? I presume this thread will just fill up with random complaints and feature requests. Is that what you want? Do you have any questions you need answers to?

[MarkIngramUK]

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.

[smj389]

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.

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.

[dpaulino]

Win32 apps shall be able to recompile to Reunion with only limited code changes for the windowing space.

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

[smj389]

Win32 apps shall be able to recompile to Reunion with only limited code changes for the windowing space.

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

We will provide a migration path from UWP AppWindow API onto the high-level Reunion Windowing APIs that is mostly automatable.

[rkarman]

Great questions Rafael! I'll try to address them as best I can.

• What is a "windowing currency"? (Please use plain English in all outward facing comms.)

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.

• What do you want from us? I presume this thread will just fill up with random complaints and feature requests. Is that what you want? Do you have any questions you need answers to?

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):

• Do you think this we are taking the right approach for this space? If not - what are we missing?
• Do you believe that a full layer of APIs is truly needed? (Or do you perhaps think one part or the other of the layers are not needed (I don't want to put words in anyone's mouths, so I'm being vague here)
• Does bringing a lot of the user32 APIs to UWP mean that you are more likely to adopt UWP for future projects?
• Does having access to a high-level windowing construct from the platform itself (AppWindow) add value to your existing Win32 app(s)? (this may be hard to answer until we share more of the feature details)