3 ms·

Win32 is the most stable abi on the Linux desktop.

by Asmod4n 15d ago

rfgplk 15d ago
Dead wrong. Win32 (externally) only seems stable, but internally it changes between Windows releases. Win7 syscalls are completely different from Win11 syscalls, meaning if I want to release a binary _without relying_ on Win32 I need to provide full syscall mappings _for each and every Windows version_. This doesn't happen on Linux.
- david-gpu 15d ago
  >> Win32 is the most stable abi on the Linux desktop. > Dead wrong [...] if I want to release a binary _without relying_ on Win32 Then you are not using the Win32 ABI, are you?
- aseipp 15d ago
  > only seems stable, but internally it changes That's literally the definition of it being stable. Programs written against an interface keep working despite the implementation changing. The Linux kernel also constantly changes internally but programs written against syscalls keep working, so it is stable; that fact doesn't stop being a fact just because I dislike perf_event_open(2) or whatever. This is all very basic and easy to understand.
- usernameak 15d ago
  Those are not a part of the API contract in case with NT kernel, though, unlike Linux. Also, there are OS-provided shims in ntdll.dll (which, by the way, isn't a part of Win32 platform API, but a part of the NT kernel interface).
preg_match 14d ago
Correct, most of Linux user land targets API stability, not ABI stability. Windows targets ABI stability because applications are typically distributed as binary blobs. Most applications on Linux are open-source and built per each distro, so it’s a non-issue, just recompile. This doesn’t work for proprietary software that’s distributed as blobs and rarely updated, like say, video games. But that’s a minority of stuff on Linux. But not on windows. Realistically, on Linux applications target specific API versions of frameworks. Like Qt 6, or GTK 3, or whatever. Then everything is compiled or dynamically linked at a per-distro level. The ABI compat can bite specifically when distros enforce strict dynamic linking. But then containerization technologies come in. And there is a difference between API and ABI stability. For example, adding SSO to std::string in C++ broke ABI, not API. If you recompile it’s fine, everything works. If you don’t then it doesn’t.
- Asmod4n 14d ago
  Sadly glibc made the choice for everyone that you have to recompile constantly to keep your app working. That’s one of the biggest issues keeping Linux small on the desktop since nearly no commercial oriented company works that way. But it looks like we will soon be able to „virtualize“ the dynamic loader so glibc has no say in this matter anymore.

Win32 is the most stable abi on the Linux desktop.

by Asmod4n 15d ago

Win32 is the most stable abi on the Linux desktop.

Dead wrong. Win32 (externally) only seems stable, but internally it changes between Windows releases. Win7 syscalls are completely different from Win11 syscalls, meaning if I want to release a binary _without relying_ on Win32 I need to provide full syscall mappings _for each and every Windows version_. This doesn't happen on Linux.

david-gpu 15d ago
>> Win32 is the most stable abi on the Linux desktop. > Dead wrong [...] if I want to release a binary _without relying_ on Win32 Then you are not using the Win32 ABI, are you?
aseipp 15d ago
> only seems stable, but internally it changes That's literally the definition of it being stable. Programs written against an interface keep working despite the implementation changing. The Linux kernel also constantly changes internally but programs written against syscalls keep working, so it is stable; that fact doesn't stop being a fact just because I dislike perf_event_open(2) or whatever. This is all very basic and easy to understand.
usernameak 15d ago
Those are not a part of the API contract in case with NT kernel, though, unlike Linux. Also, there are OS-provided shims in ntdll.dll (which, by the way, isn't a part of Win32 platform API, but a part of the NT kernel interface).

preg_match 14d ago

Correct, most of Linux user land targets API stability, not ABI stability. Windows targets ABI stability because applications are typically distributed as binary blobs. Most applications on Linux are open-source and built per each distro, so it’s a non-issue, just recompile. This doesn’t work for proprietary software that’s distributed as blobs and rarely updated, like say, video games. But that’s a minority of stuff on Linux. But not on windows. Realistically, on Linux applications target specific API versions of frameworks. Like Qt 6, or GTK 3, or whatever. Then everything is compiled or dynamically linked at a per-distro level. The ABI compat can bite specifically when distros enforce strict dynamic linking. But then containerization technologies come in. And there is a difference between API and ABI stability. For example, adding SSO to std::string in C++ broke ABI, not API. If you recompile it’s fine, everything works. If you don’t then it doesn’t.

Asmod4n 14d ago
Sadly glibc made the choice for everyone that you have to recompile constantly to keep your app working. That’s one of the biggest issues keeping Linux small on the desktop since nearly no commercial oriented company works that way. But it looks like we will soon be able to „virtualize“ the dynamic loader so glibc has no say in this matter anymore.