Earlier quoted context omitted.
The article you linked to is talking about a new feature, per-thread DPI awareness, which is something that macOS has never had—NSHighResolutionCapable is per-app (in the Info.plist) and always has been. It seems strange, then, to claim that this feature is needed for HiDPI to not be "broken". Rather, the problem here is that legacy APIs, which Windows has a lot of, are not HiDPI capable, and attempts to retrofit the…
The article is also talking about non-client area scaling which is not a per thread issue. Also, it gives the example of the print dialog in Notepad not scaling. That's a first party app! Sure, Carbon doesn't scale. It was effectively deprecated almost ten years ago when it wasn't ported to 64-bit. Apple rapidly rewrote its first-party apps and they've been scalable for years. Basic first party apps in Windows 10 don…
It's talking about that and the per thread DPI issue. And again, it seems to be backwards compatibility that's the issue. Note that you have to opt in to the non-client-area scaling with a special API.
> Also, it gives the example of the print dialog in Notepad not scaling. That's a first party app!
Are you sure notepad.exe can be even changed? It's a tiny wrapper around a comctl32.dll TEXT control. The Print dialog is pure comdlg32.dll, and I'm sure there are backwards compatibility reasons why that cannot be changed.
Wine has to fairly precisely duplicate notepad.exe, so I suspect there is some backwards compatibility reason why it has to be the way it is.
Remember that Win32 is totally based on using exact pixel coordinates for everything. There are a lot fewer apps hardcoding pixel measurements of things in the Apple world (and coordinates in classic Win32 are in integers, not CGFloats as in Core Graphics/Cocoa). Microsoft can't even change the Windows 95 default style of buttons without opt-in without breaking apps!
> Apple rapidly rewrote its first-party apps
Not iTunes! It is still Carbon.