In the frame with the Great MS Bakeoff: Microsoft sets out plans for Windows windows
- Reference: 1598972828
- News link: https://www.theregister.co.uk/2020/09/01/microsoft_windows_windowing_api_project_reunion/
- Source link:
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.
[1]
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 [2]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 [3]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".
Project Reunion: Microsoft's attempt to tear down all those barriers it's built for Windows developers over the years [4]READ MORE
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 [5]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. ®
Get our [6]Tech Resources
[1] https://regmedia.co.uk/2020/09/01/reunion.png
[2] https://github.com/microsoft/ProjectReunion/issues/157
[3] https://docs.microsoft.com/en-us/uwp/api/windows.ui.windowmanagement.appwindow?view=winrt-19041
[4] https://www.theregister.com/2020/05/19/project_reunion_microsoft/
[5] https://github.com/microsoft/ProjectReunion/issues/157#issuecomment-682259993
[6] https://whitepapers.theregister.com/
I think this is a great idea and about time they focused on core tech rather than just piling layers on top. Microsoft should "improve" it by deprecating a number of "modern" Metro wrappers and focus on the standard winapi. Just add extensions to it. Kind of like how Motif (Xm) added extensions on top of XIntrinsics (Xt).
The WndProc stuff was not actually too bad for using C (i.e a single callback with a "type" id). It also made wrapping it in objects i.e for C++ fairly easy.
if they feel they must get away from C style architecture and onto C++, I really do hope they bring smart pointers in. I am sick of being carelessly handed a raw pointer that has no real consistent lifespan guarantees. If they are not skilled / disciplined enough to do this with C++ and have to migrate to Rust, then... well I guess people will stick with the old winapi due to legacy requirements and nothing will be achieved.
> Kind of like how Motif (Xm) added extensions on top of XIntrinsics (Xt).
[1]30 years ago.
[1] https://en.wikipedia.org/wiki/Motif_(software)
Are you suggesting that new stuff is always better?
> Are you suggesting that new stuff is always better?
The answer is context-dependent. Why don't you ask Microsoft?
On a related train of thought: Ask any UNIX/Linux UI programmer: Is Gtk+ or QT better than Motif? Do they still qualify as new in 2020?
I mean,
a) Motif is a GUI toolkit while Xt is a set of tools for making a GUI toolkit (with Athena as the reference barebones GUI toolkit that shipped with X11), so it's not really comparable. Motif doesn't extend Xt, it sits on top of it.
and
b) Nobody since has used Xt. Gtk doesn't use it. Qt doesn't use it.
I am going to have to be careful with my wording so not to confuse. Or better yet...
Notice how Athena widgets (Xaw) and Motif widgets can interact and exist together on the same Window? This is the benefit of having a common underlying base (Xt).
This is what I meant. That way legacy "widgets" still work and nothing is lost. No-one is tied into a constant treadmill of re-engineering.
Gtk+ and Qt are not good examples of what "good" GUIs should do. They are fairly inefficient, especially over remote connections. Microsoft's RDP needs to be a little bit more mindful of this kind of stuff. Linux dropped the ball a little with X11 and VNC is not really comparable in performance.
Gtk+ and Qt are not good examples of what "good" GUIs should do.
Uh-huh. Right. That's why all current UNIX/Linux software that uses a GUI is written in one of these two. Including that mono (.NET) monstrosity for Linux (written in Gtk+).
I've migrated...
...right the fuck off the infinite Microsoft treadmill of fail.
They still don't get it do they?
Nobody is going to port old code to a shiny new framework just because there's a new API - no matter how much nicer it is. That's simply not the reason anybody writes code. And for as long as Windows supports running win32 apps, people will keep win32 code around, and keep writing new apps in it to reach a wider audience than anything new.
There's 25+ years of Win32 code out there in the wild. Half the developers have probably died, retired, or changed career. Half the source code probably no longer exists. Just as with COBOL, there'll be Win32 code out there running that people don't even know about and that probably hasn't been looked at since Y2k was a thing. There'll be code propping up businesses large and small all over the world who's in-house developers and external vendors have long since disappeared.
Microsoft will never be able to rid itself of Win32 by trying to tempt developers to use something new. The only way they'll do it is to put their foot down and stop supporting it whilst making sure there's a clear and definite stable alternative - something that Microsoft are pretty much incapable of.
I really think that Microsoft need to accept the fact that they're a 'boring' business software vendor - not a hip and trendy brand. They got the corporate world hooked on Windows, Office and VS etc, and that means they're stuck with them for the long term.
Two different windows are a problem ... so add a third!
Adding a third method to create windows is probably the single worst solution to the problem they could have come up with.
The correct solution would have been to have one API call the other, so it always boils down to the same code path.
Failure to think
Code written awhile ago and is still actively used is not likely to be rewritten to use a new API just because the API exists as it is generally a waste of time. The only way to force users and devs to stop using Win32 is to stop supporting it and removing it from Bloatware at some point in time. But there is a lot of elderly, useful business code that would have to be rewritten; the howls of anguish would be loud. As far as consumer code, I am not sure how much would be affected but there will be some howling from them also.
The only other alternative is to create an API that is so superior to the current APIs that when the next major revision done to the elderly code will be rewritten to use the new API. I do not think this scenario is very likely to happen as I do not think any new API will be that much better than its predecessor to warrant a rewrite.
The Rejects of Redmond are stuck, either support Win32 for the foreseeable future or alienate your customers; pick your poison.
Most of User32?
So, is this going to emulate a Win32 message cycle? I won't believe it until I see it, and if it doesn't, then porting most Win32 apps of any complexity is not going to be straightforward at all.
This seems appropriate...
https://xkcd.com/927/