3 ms·

> In Linux, you can make system calls directly... > In Windows, you do not make system calls directly, Instead, you dynamically link to libraries that make the

> In Linux, you can make system calls directly... > In Windows, you do not make system calls directly, Instead, you dynamically link to libraries that make the system calls for you. Isn't the actual problem the glibc shared library since the Linux syscall interface is stable? (as promised by "don't break user space") - e.g. I would expect that I can take a 20 years old Linux binary which only does syscalls and run that on a modern Linux, is that assumption wrong? ABI stability for Windows system DLLs is also only one aspect, historically Microsoft has put a ton of effort into preserving backward compatibility for popular applications even if they depend on bugs in Windows that had been fixed in later Windows versions. I expect that Windows is full of application specific hacks under the hood to make specific old applications work. E.g. just using WINE as the desktop Linux API won't be enough, you'll also have to extend the "don't break user space" promise from the kernel to the desktop runtime environment, even if it means "bug-by-bug-compatibility" with older versions.

maccard 2y ago
> Isn't the actual problem glibc since the Linux syscall interface is stable? Yes > I would expect that I can take a 20 years old Linux binary which only does syscalls and run that on a modern Linux, is that assumption wrong? You’re right. But those apps are simple enough that we could probably compile them quicker than they actually run. > I expect that Windows is full of application specific hacks under the hood to make specific old applications work. Yes [0]! > just using WINE as the desktop Linux API won't be enough, you'll also have to extend the "don't break user space" promise from the kernel to the desktop runtime environment Yes, but. Windows is the user space and kernel for the most part. So the windows back compat extends to both the desktop runtime and the kernel. You might argue it’s a false equivalence, and you’re technically correct. But that doesn’t change the fact that my application doesn’t work on Linux but it does on windows. [0] https://news.ycombinator.com/item?id=35203390 https://news.ycombinator.com/item?id=35203390
- flohofwoe 2y ago
  I'm not trying to defend Linux btw, and I appreciate Microsoft's approach to backward compatibility (some of the Windows games I play regularly hail from the late 90s). Just wanted to point out that ABI stability alone probably isn't the reason why Windows is so backward compatible, there's most likely a lot of 'boring' QA and maintenance work going on under the hood to make it work. Also FWIW some of the early D3D9 games I worked on no longer run on out of the box on Windows (mostly because of problems related to switching into fullscreen), I guess those games were not popular enough to justify a backward compatibility workaround in modern Windows versions ;)
  - maccard 2y ago
    Again, you’re technically correct but I don’t think it matters. Windows gives (in practice) DE, user space, and kernel stability, and various Linux distributions don’t. If you care about changing the Linux ecosystem to provide that stability it matters, but if you want to run an old application it doesn’t.
IshKebab 2y ago
Yeah the direct syscall interface isn't a problem because it's so stable. The problem is almost entirely glibc. If GCC simply had a flag --glibc-version=2.14 or whatever then 99% of the problems would be solved. I tend to just compile on a really old distro to work around this. Tbf you need to do the same thing on Mac, it just isn't so much of an issue because Macs are easier to update. The other side of the problem is that the whole Linux ecosystem is actively hostile to bundling dependencies and binary distribution in general, so it's not a surprise that it sucks so much.

maccard 2y ago

> Isn't the actual problem glibc since the Linux syscall interface is stable? Yes > I would expect that I can take a 20 years old Linux binary which only does syscalls and run that on a modern Linux, is that assumption wrong? You’re right. But those apps are simple enough that we could probably compile them quicker than they actually run. > I expect that Windows is full of application specific hacks under the hood to make specific old applications work. Yes [0]! > just using WINE as the desktop Linux API won't be enough, you'll also have to extend the "don't break user space" promise from the kernel to the desktop runtime environment Yes, but. Windows is the user space and kernel for the most part. So the windows back compat extends to both the desktop runtime and the kernel. You might argue it’s a false equivalence, and you’re technically correct. But that doesn’t change the fact that my application doesn’t work on Linux but it does on windows. [0] https://news.ycombinator.com/item?id=35203390 https://news.ycombinator.com/item?id=35203390

flohofwoe 2y ago
I'm not trying to defend Linux btw, and I appreciate Microsoft's approach to backward compatibility (some of the Windows games I play regularly hail from the late 90s). Just wanted to point out that ABI stability alone probably isn't the reason why Windows is so backward compatible, there's most likely a lot of 'boring' QA and maintenance work going on under the hood to make it work. Also FWIW some of the early D3D9 games I worked on no longer run on out of the box on Windows (mostly because of problems related to switching into fullscreen), I guess those games were not popular enough to justify a backward compatibility workaround in modern Windows versions ;)
- maccard 2y ago
  Again, you’re technically correct but I don’t think it matters. Windows gives (in practice) DE, user space, and kernel stability, and various Linux distributions don’t. If you care about changing the Linux ecosystem to provide that stability it matters, but if you want to run an old application it doesn’t.

IshKebab 2y ago

Yeah the direct syscall interface isn't a problem because it's so stable. The problem is almost entirely glibc. If GCC simply had a flag --glibc-version=2.14 or whatever then 99% of the problems would be solved. I tend to just compile on a really old distro to work around this. Tbf you need to do the same thing on Mac, it just isn't so much of an issue because Macs are easier to update. The other side of the problem is that the whole Linux ecosystem is actively hostile to bundling dependencies and binary distribution in general, so it's not a surprise that it sucks so much.