Do they still have tons of high-DPI bugs where some apps work with it and some get all garbled?

Well to be fair HiDPI issues are application issues as opposed to core Windows issues.

It's first and foremost a bad DPI independence API design, largely due to a terrible backwards compatibility of an even more terrible legacy stack. It is fixed somewhat in their modern stacks, such as WPF and UWP, but the vast majority of Windows software is not written with these frameworks.

While it is understandable why the legacy baggage is there and cannot be removed, the end result is a big mess, still to this day. Most (but still not all) first party software is OK to good. Third party software (not apps from the store) is a mess, usually either blurry, tiny or downright broken. Windows ecosystem being Windows ecosystem, there are many alternative to almost everything, and some software is improving. But it is still a big mess.

Apple's transition was a lot smoother due to vertical integration, a much smaller software library, more dedicated software developer base (or rather, much more willing to be early adopters of new APIs) and most importantly, a much better designed API without a 20-30 year old baggage.

It should be interesting to see people's reaction to the software, after jumping ship for macOS to Windows on these fantastic displays. I couldn't stand the mess after a week with Windows 10 on my MBP. (But I do use Windows 10 regularly on my desktop, on a "normal" display.)

> a much better designed API without a 20-30 year old baggage.

Apple's API dates back to the 1980s, just like Windows'. If you want to nitpick, Windows was developed in the early-mid 1980s while Next was developed in the mid-late 1980s.

I mostly meant the software support baggage, but yes, indeed, so many of the Next concepts are still true today in Cocoa API design.

I have a number of mac apps that don't scale. Biggest offender, although also on windows, is steam. I don't know what it is about game developers but they just can't seem to manage ui scaling.

As most new apps start to be built on UWP that issue will go away.

Also, I am not sure what DPI issues you're facing but I have run W10 on my rMBP for quite some time and it's been thoroughly pleasant. Perhaps your issues are fuzzy text due to mixed DPI, multi monitor setup?

UWP apps have a lot of limitations compared to WPF/Win32 apps. As I understand it, UWP apps can't record audio in the background or act as a Bluetooth accessory, to give two examples.

So, even if a developer is willing to invest the time to rewrite an app to use UWP, the app will lose a lot of functionality. Microsoft has again poorly architected their APIs.

Unlike macOS, where there's no penalty to adopting the latest APIs. It's not as if, to use the Touch Bar, you have to give up access to other capabilities, like recording audio in the background.

More information: https://kartick-log.blogspot.in/2016/08/how-powerful-is-uwp-...

I mean, you can just use WPF + the desktop bridge in these cases. There's still some work for the desktop bridge to catch up, but it's perfectly feasible (aside from, you know, feeling like a traditional Windows desktop app vs a "Modern" one without a lot of work styling WPF controls).

I am not using UWP apps. Most of the software I use on Windows are either MFC or Windows Forms. These can also be DPI aware and render correctly, but they require proactive developer support, which is not something that is happening in the Windows developer world right now. Either software is abandonware (but still works), or issues are open and remain open or are simply closed with "won't fix" status. Most developers see this as a non-issue or very low priority. I mean, even Chrome does not support high DPI from what I remember. It looked terrible.

Linux world is in the same boat. It's even worse there, because a lot of the toolkits don't support high DPI modes or are buggy, and developers there are even less interested or have the know-how to fix issues.

With the emergence of cheaper 4K monitors, perhaps we'll see a change to the better, who knows.

Multi-monitor support is another issue entirely.

What's funny is that supporting high DPI on a winforms app isn't even hard. Even if you size all your widgets in pixels, if you just do a little playing with the scaling options and just try out the ui on high DPI, it seems to work pretty well except for the old icons. I forgot what the setting is called, but theres a (non-defaukt) scaling option or two that seemed to "just work" as it were.

The harder part is to consistently fix everything that uses the old win2000 8pt default font instead of a modern one.

UWP is dead imo. Microsoft is ignoring the signs that can tell it to accept it gracefully. There is not one uwp app that I use. They are just not reliable. A splash screen will show up, and then disappear. The app won't launch. You open the fb messenger app and then switch desktops to work. 2 hours later the messenger is nowhere to be found. It just disappears. No error no notification. Nothing. First I thought it's fb incompetence. But this happens with the built in photos app. The built in mail app. Even shell elements (start menu, notification shade) are buggy. Windows 10 is a great os as long as you avoid any interaction with uwp stuff.

Also, it's not just scaling. Often even if an application scales somewhat correctly, often some elements don't, because it's using some open source that draws something in a terrible manner. Or, assets look blurry because of "16x16 is all you really need" mentality. This used to happen on OS X in the first months, but very quickly and uniformly, developers just fixed their custom code and assets. Not so with Windows developers, sadly.

Microsoft took ages to fix first-party applications that shipped with the OS: https://www.thurrott.com/windows/windows-10/83964/microsoft-....

Microsoft's inability to execute is mind-boggling.

It's not. Win10 doesn't even have a proper HiDPI installation dialog.

Why was the transition to HiDPI so much less painful on macOS, then?

Because Apple designed the core OS to handle it much better, and make it easier to support for developers. (which was years in the making, far before the launch of rMBP.)

While I agree that the OS X APIs were superior at the time, it is important to remember that Windows was and still is an enterprise OS, first and foremost, and this is a big mess. So this slowed progress a lot. Modern Windows UI frameworks are good too, but they are used very seldom, or if used, often used incorrectly. Since high DPI displays have been rare and expensive, I think also developers have very little awareness of the problems, and much less will to work on it. Linux is in the same boat.

How many apps from the 90s do you know that still work on macOS?

Sure, but their hi-DPI approach was much more backwards compatible capable than Microsoft's. Having apps still work, but be tiny and unreadable or haveing their UI exploded all over the place isn't a great exampe of backwards compatibility.

Yes, backwards compatibility is great. But it does not come without a cost.

Not it was easier because they also control the hardware and defined HiDPI to be always exactly 200%, compared to various scaling factors that windows needs to support.