Comment by krastanov

I remember when the shader caching done for a popular game in linux made that game run better than the windows version

What I wonder about is if MS wants to keep people on windows, what methods they can use to do that. For simple desktop stuff I don't think they have many options to lock in other developers (and their audiences) to windows unless they want do so themselves (putting aside web based or not PC-desktop).

Bleeding edge gaming and multiplayer anti-cheat is one area where I think having a big company owning the OS probably helps them stay ahead, as that structure probably lets them work with hardware designers to get the capabilities in use (i.e. in new versions of DirectX) and available to software developers first. There's generally a lag in adoption for new features within Vulkan and then usage downstream in wine/proton to get compatibility parity with windows, then the games themselves being able to run feature/performance parity. It'd be interesting to see what cooperation would be needed to have the linux gaming stack equal at the point new features are released, and with the least amount of manual hacks or command line tweaking required for the users. As discussed a few weeks back, tough anti-cheat for linux seems like a paradox with the current methods.

Why would Microsoft ever do that?

WSL is already there for the folks that want to play with Linux.

Inb4 Windows 40k and to run the "kernel" you need to sacrifice 1000 a day

Anything Direct Draw related will be mapped into OpenGL under Unix giving you decent speeds. On Windows it will be a crawling slideshow because from Windows 8 and up it will use a really dog slow software mode with no acceleration at all, worse than plain VESA. Yes, you can reuse WineD3D DLL's on Windows and run these game in a fast way, but not by default, it's a Win32 port of some Wine libraries.

It certainly runs 16-bit Windows games better than Windows 11, which can't run them at all. Not that there are a ton of those, but it's still pretty neat that they work.

Not just ancient games!

https://arstechnica.com/gaming/2025/06/games-run-faster-on-s...

Wine is also the reason why Windows software has more longevity on Mac than Mac software. Like, 32-bit didn't get deprecated in Wine.

I don't know what the official policy is, but glibc uses versioned symbols and certainly provides enough ABI backward-compatibility that the Python package ecosystem is able to define a "manylinux" target for prebuilt binaries (against an older version of glibc, natch) that continues to work even as glibc is updated.

Sorry I am not sure if 2.12 is a a recent release or older, I made up this number up

If the application is built against 2.12 it may link against symbols which are versioned 2.12 and may not work against 2.11 - the opposite (building against 2.11 and running on 2.12) will work

>If true (I don't think it is), that is a hard showstopper for most companies that want to develop for Linux.

Not really a show stopper, vendors just do what vendors do and bundle all their dependencies in. Similar to windows when you use anything outside of the win32 API.

The only problem with this approach is that glibc cannot have multiple versions running at once. We have “fixed” this with process namespaces and hence containers/flatpak where you can bundle everything including your own glibc.

Naturally the downside is that each app bundles their own libraries.

MUSL is a better libc for companies making proprietary binaries. They can either statically link it, or provide a .so with the musl version they want their programs to use & dynamically link that.

Plenty of operating systems work like this. Just not highly commercial ones because proprietary software is the norm on those.

From a bit of research it looks like FreeBSD for example only provides a stable ABI within minor versions and I imagine if you build something for FreeBSD 14 it won’t work on 13.

Stable ABI literally only benefits software where the user doesn’t have the source. Any operating system which assumes you have the source will not prioritize it.

(Edit: actually thinking harder MacOS/iOS is actually much worse on binary compatibility, as for example Intel binaries will stop working entirely due to M-cpu transition - Apple just hits developers with a stick to rebuild their apps)

what about mac os?

that 10 year old binary should run, unless it links against a library that no longer exists.

for example here is a 20 year old binary of the game mirrormagic that runs just fine on my modern fedora machine:

    ~/Downloads/mirrormagic-2.0.2> ldd mirrormagic
        linux-gate.so.1 (0xf7f38000)
        libX11.so.6 => /lib/libX11.so.6 (0xf7db5000)
        libm.so.6 => /lib/libm.so.6 (0xf7cd0000)
        libc.so.6 => /lib/libc.so.6 (0xf7ad5000)
        libxcb.so.1 => /lib/libxcb.so.1 (0xf7aa9000)
        /lib/ld-linux.so.2 (0xf7f3b000)
        libXau.so.6 => /lib/libXau.so.6 (0xf7aa4000)
    ~/Downloads/mirrormagic-2.0.2> ls -la mirrormagic
    -rwxr-xr-x. 1 em-bee em-bee 203633 Jun  7  2003 mirrormagic

ok, there are some issues: the sound is not working, and the resolution does not scale. but there are no issues with linked libraries.