In the frame with the Great MS Bakeoff: Microsoft sets out plans for Windows windows

HWND? AppWindow? Current situation 'not making anyone happy' as company seeks one true way

Microsoft has revealed its plans for the future of the windowing API in Windows, a fundamental piece in desktop development, as part of the Project Reunion effort to untangle the mess caused by UWP (Universal Windows Platform).

Writing code to make a window appear on the screen is the "Hello world" of Windows development. Back in 1985, when Windows 1.0 was released, you did this by calling CreateWindow and getting back an HWND or window handle, an integer that identified the window and allowed further interaction with it.

As Windows evolved, CreateWindow evolved into CreateWindowEx, CreateWindowExA and so on, but the fundamental approach remains in the Win32 API today.

In 2012 Microsoft decided to make a modern and more secure Windows system based on the Windows Runtime, or WinRT, which runs on top of Windows and has its own API. This was the basis of "Metro" applications in Windows 8 and then the Universal Windows Platform (UWP) in Windows 10. The API for creating a window, if you did not do it through XAML statements or some other wrapper, was CoreWindow.

The differences between Win32 windows and CoreWindow windows account for much of the UI inconsistency in Windows 10. The new-style windows as used in the modern Settings app, for example, have a different look and feel from the Win32 Control Panel. Developers have been frustrated too since despite Microsoft's pleas to migrate to UWP, Win32 windows are more powerful in some respects as well as being compatible with Windows 7 and 8.

"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," acknowledged program manager Robert Karman in a new post setting out Microsoft's proposals for windowing in Project Reunion, intended to reunify Windows development.

Karman offered only a "high-level perspective" but said:

• There will be a "high level, easy to use" windowing API for new projects. Karman hints that it might be similar to AppWindow, currently a preview windowing API for UWP, by saying: "If you have worked with AppWindow in UWP, you should be familiar with what we have in mind." However, he also talked about "a migration path from UWP AppWindow API onto the high-level Reunion Windows APIs" so it is not the same thing.
• The new API will include "most of the windowing primitives" from USER32, the Win32 windowing API.
• Code will be able to "freely move from one layer to the other" by getting an AppWindow object from an HWND, or a HWND from an AppWindow, that can be passed to other APIs.
• Since "most of USER32" will be in the Reunion API migrating Win32 applications should be straightforward in most cases, with only "limited code changes for the windowing space".

One interpretation of the above is that CreateWindowEx will still work in Project Reunion, but will create something like an enhanced UWP window, so that some new variant of AppWindow will be an alternative high-level API to the same underlying platform. This would enable current Windows applications to be recompiled for Reunion and achieve the consistency that is currently lacking.

Karman almost spelled this out when he said: "The higher-level APIs will all be built using the lower-level primitives. There will be no 'black box' and completely different stack powering the higher-level APIs like today with the difference between CoreWindow and HWND."

He also promised that Microsoft will not alienate developers with "yet another solution".

A reason to migrate

Karman said that migrating code will be easier for Win32 applications than for UWP applications – frustrating for developers who presumed that by adopting UWP they would have a smoother path to supporting future versions of Windows. That said, migrating UWP applications is intended to be "mostly automatable".

What about compatibility? There is no intention to support current UWP applications on "down-level OS versions", said Karman. As for the new Reunion API, down-level compatibility for applications built for this "is being worked on", said Karman, so he will not commit to details.

Developer Martin Anderson asked what has happened to enhancements that Microsoft promised in the UWP windowing APIs, like "light dismiss windows", "multiple windows on the same thread", "size and position windows", "3D space positioning", "Transparency" and "MDI". This last stands for Multiple Document Interface, a design for document-handling applications which has been deprecated for many years, but still has some use today.

"Some features are no longer relevant, some are being satisfied by access to the lower-level APIs, some are still on the roadmap," said Karman. There was also a warning that in order to deliver the first version faster, Microsoft "might limit the amount of features we include in the first release".

Microsoft's hardest task may be to convince developers not just to stick with Win32, which will be supported for the foreseeable future and runs on older versions of Windows. The key will be to deliver some convincing benefits from migration to the new API, something that hitherto has been largely lacking. ®