[jcelerier]

> Qt cannot provide "perfect" ABI compatibility even if they wanted to because of C++

That does not really matter in practice though. I ship a Qt app as AppImage, it works fine from CentOS 7 to the very latest ArchLinux. I just ship libc++ along with it - which is the same that I have to do in Windows anyways.

[badsectoracula]

Of course it matters in practice since we're talking about dynamic linking that applications can link against the OS-provided libraries so that they can keep gaining new features and bug fixes.

A trivial example on Windows would be how Win32 applications get to use the Win+; emoji popup even if they were made before Windows even got that feature, or how even classic VB applications can be made to run in HiDPI mode by ticking a shortcut checkbox despite being written decades before HiDPI was even a thing (assuming they use twip instead of pixel coordinates at least).

Or on Linux, how some old games made for it need their bundled SDL removed so that the games can use the system-provided version because the old version tried to use OSS or whatever was common at the time the game as written and the new version can use ALSA or even Pulse that didn't even exist in older times. And i remember reading on twitter about some distros planning to provide the SDL1-to-SDL2 wrapper as an option instead of the real SDL1 because it provides better compatibility with some modern window managers... and Wayland (that SDL1 doesn't support at all but the API doesn't really make a difference and could work perfectly fine with Wayland).

> which is the same that I have to do in Windows anyways.

Windows comes with WAY more functionality out of the box so that applications do not have to rely as much in their own libraries and can rely on the OS to provide and keep functionality up to date. Of course applications can ignore that, but they just do not get those new features and fixes.

The recent Visual C++ runtimes not being part of Windows is a baffling and really stupid decision though. I am certain it has more to do with internal politics and feuds between WinDiv and DevDiv than something practical.

[jcelerier]

> A trivial example on Windows would be how Win32 applications get to use the Win+; emoji popup even if they were made before Windows even got that feature, or how even classic VB applications can be made to run in HiDPI mode by ticking a shortcut checkbox despite being written decades before HiDPI was even a thing (assuming they use twip instead of pixel coordinates at least).

eh, I really really disagree with this. In my experience more often than not this kind of changes breaks the app in various ways. What if the app was using that shortcut for something else ? Now it's broken and can't be used anymore. Likewise for the hidpi thing that windows does, it's terrible - running the app at original resolution and applying a 2x nearest neighbor filter to the whole window would be better than that mess of "crisp" text with upscaled pixmaps that were never made for this resolution.

> Or on Linux, how some old games made for it need their bundled SDL removed so that the games can use the system-provided version because the old version tried to use OSS or whatever was common at the time the game as written and the new version can use ALSA or even Pulse that didn't even exist in older times. And i remember reading on twitter about some distros planning to provide the SDL1-to-SDL2 wrapper as an option instead of the real SDL1 because it provides better compatibility with some modern window managers... and Wayland (that SDL1 doesn't support at all but the API doesn't really make a difference and could work perfectly fine with Wayland).

I strongly believe that for old games / software it's better to use a VM / emulator for hardware of that game's era.

[badsectoracula]

> eh, I really really disagree with this. In my experience more often than not this kind of changes breaks the app in various ways.

What did break?

> What if the app was using that shortcut for something else ? Now it's broken and can't be used anymore.

Win+; is very unlikely to be used by anything and it is handled by the window proc of the EDIT window class, meaning that other stuff (e.g. accelerators, which are used to implement shortcuts) get to take first dibs. So if an application was using that shortcut it wouldn't reach the EDIT window proc anyway. It isn't any different than an application replacing the right click menu of a text field - the applications that do not do that (ie. most applications) get the new entries introduced in (IIRC) Vista about Unicode characters, etc and the (few) applications that replace it just do not get these options but their menus keep working.

> Likewise for the hidpi thing that windows does, it's terrible - running the app at original resolution and applying a 2x nearest neighbor filter to the whole window would be better than that mess of "crisp" text with upscaled pixmaps that were never made for this resolution.

Note that this is what Windows does by default, what i describe is something you can do manually.

But personally i disagree, i'd rather have crisp text (which is what the majority of a window contains) and a few upscaled bitmaps than lowres everything.

> I strongly believe that for old games / software it's better to use a VM / emulator for hardware of that game's era.

I play a ton of old games and i completely disagree with this. VMs pretty much never work properly and have all tons of issues. Emulators are very slow. And above all, running games on modern hardware allows for higher resolution and maxing out graphics that was often impossible in original hardware (e.g. forcing 32bit color, antialiasing, anisotropic filtering, etc). Not to mention the potential for mods that improve parts of the game which would be impossible on original hardware.