> breaking from the legacy is hard for the sake of backwards compatibility
Generally yes, but in case of Windows the hard part of the problem is already solved. I think it was just the wrong priorities. Specifically, Windows SDK could do following things to enable new styles/controls/behavior:
1. Require new apps to call an API to switch to new stuff, like InitCommonControlsEx
2. Require new apps to include an XML manifest with some flag or version number, like they did with high DPI support
3. A nuclear option β implement new userland, write new apps against that one; NT kernel supports multiple subsystems at the same time, Win32 is one of them.
isn't all of this what they tried with UWP and WinRT ? It utterly failed. People want their useful win32 apps. Those are the only reason I boot on that OS once in a while.
UWP/WinRT was close to the nuclear option. I think the main reason it failed is their app store. They should have allowed to publish these new apps with SetupSomething.exe and I think developers would eventually switch.
A good example of that option is the way they did Linux support in WSL1. Not exactly a new subsystem but technically pretty close. They could do something like that only with GUI, and not based on Linux.
BTW, I still use WSL1 every day. Too bad itβs deprecated, WSL2 is VM based, borderline useless for me.
> breaking from the legacy is hard for the sake of backwards compatibility
Generally yes, but in case of Windows the hard part of the problem is already solved. I think it was just the wrong priorities. Specifically, Windows SDK could do following things to enable new styles/controls/behavior:
1. Require new apps to call an API to switch to new stuff, like InitCommonControlsEx
2. Require new apps to include an XML manifest with some flag or version number, like they did with high DPI support
3. A nuclear option β implement new userland, write new apps against that one; NT kernel supports multiple subsystems at the same time, Win32 is one of them.