It's the other way around, isn't it? They're not going to reimplement the Win32 API on top of WinUI, but WinUI uses Win32 in part for its implementation on some platforms (that platform being classic desktop Windows).
Is not WinUI the extraction of the UI part of the UWP stack? Yes namespaces break, but concepts and controls are from the same linage. UWP is more than the UI. It has also sandboxing and deployment.
So essentially, it is not a new UI. Just a new version of an old one.
(consider e.g. WinForms was also ported from .NET Framework to .NET Core. That is also not counted here ;))
> Is not WinUI the extraction of the UI part of the UWP stack? Yes namespaces break, but concepts and controls are from the same linage. UWP is more than the UI. It has also sandboxing and deployment.
The UWP has everything except a GUI.
> So essentially, it is not a UI.
fixed itl
> (consider e.g. WinForms was also ported from .NET Framework to .NET Core. That is also not counted here ;))
So everyday a new framework. How many days will pass until UWP will be obsolete ?
Actually, I think they made this specifically because win32 is here to stay. UWP is officially dead and you can upload win32 to the Microsoft Store, now. This paves the way for some parts of the UWP dream (works on high dpi, supports touch, fancy graphics without needing custom assets) in win32.
Between this, MSIX, containerization, etc the fat app landscape could be pretty good. Too bad all my vendors who are still releasing fat apps will never modernize and all the new vendors are web-only.
They say that the VM and the remote desktop connection are "optimized" but also that UWP/Modern apps will be faster and better for battery life, so it doesn't sound like a great future for win32.
The value of Windows is in the Win32 API, due to the existing investment into software. If you have existing code base, you want to keep it running with minimal ongoing investments.
For a case study of interest for newer APIs, see also Windows RT.
Windows RT failed, because it had no applications, except for MS Office.
So Win32 was there, ISVs just were not allowed to recompile their apps for the ARM target. They were expected to port them to Modern API. Which of course, they didn't.
> UWP is the future of Windows APIs, Win32 is mostly frozen since WIndows XP.
Frozen is usually a good thing.
> Microsoft is just making UWP similar to what Google is making with AndroidX, detaching the technology from the OS version.
... and from users also. Will they get a lawsuit from Google for copying their UI as they got from Apple ? I think not because the UI is so bad that they will be ashamed to go to court with something like this.
Frozen is good because it means you can develop reliable software that will continue to work in the future without running on a constant treadmill of useless updates.
The API is frozen, not the features and bug fixes. New APIs can be introduced (and are introduced) and bug fixes and features are added. As a very simple example, see how you can enter emojis in any unicode-aware Win32 input box application with Win+; even though this functionality was introduced in (IIRC) Windows 10 Fall Creators Update.
It is because even they come via XAML Islands, or UWP/COM interop, at the end of the day it is still UWP/COM that is going forward.
Looking forward how Windows will look like now that it was officially communicated that Windows 10X is also coming to desktops and laptps, with its sandbox model for 100% of all userspace.
All that is irrelevant, the point is that having a frozen API doesn't mean that the API's implementation is also frozen. You can still get new features on a frozen API as well as new APIs alongside it.
> What else did you want them to do? Continue adding features to long deprecated APIs?
Yes. It isn't like deprecating APIs is forced on them by some otherworldly power, they decide to do that and they can also decide to not do that. They are in full control of their technology, they can do whatever they want.
