The difference really doesn't have to do with backward compatibility (which Windows does to arguably an even greater extent than Linux) but with where the stable interface boundary is. Windows puts the boundary in ntdll, Linux puts it at syscalls.

Well, the stable kernel interface matters on Linux because the user space doesn't give a damn about backwards compatibility. You might be fine if you only rely on the system libc. But every other library that you don't ship with your binary is essentially out to break your stuff. These libraries may even differ between distributions even though they have the same version numbers just because they were built using different build configurations. This is why things like the Steam Runtime exist.

> But every other library that you don't ship with your binary is essentially out to break your stuff.

There are many more lower level libraries that provide binary backwards compatibility: libasound, libX11, libGL, ...

Sure you're not going to be able to assume that /usr/lib/libpng.so.1 will provide the functionality that you want but that isn't any different from png1.dll some program installed in system32.

It's funny that you mention libpng. That is one of those libraries that is developed so conservatively that I'd actually trust it to provide the features a binary that I ship relies on. I rarely (if ever) needed the more obscure things like 16 bit per channels or ICC profiles.

That has nothing to do with kernel space vs user space and everything to do with different projects having different attitudes. The comparison is to the case where Linux instead ships a special "linuxso.so" that all processes and libraries need to (dynamically) link against in order to get a stable interface.

That attitude that is so prevalent in Linux user space is what this thread was getting at. This is why the syscall interface being maintained as a stable interface is so important on Linux compared to other operaring systems.

Backward compatibly is important. It's a weird Linuxism to assert that it's the kernel that has to provide the compatibility interface. There's no reason the ring zero transition has to be the stable part.

The real reason Linux's ABI boundary is the kernel is just that the kernel and glibc are sperate and frequently-antagonistic projects. Linux ships the org chart.

Even if they were the same project it wouldn't matter, because the promise is that your completely statically-linked binary will continue to work without recompilation on tomorrow's kernel if it works on today's.

Otherwise stated as "Linux suppirts completly statically linked binaries". Apart from asthetics, I don't see the limitation of not supporting static linking to lib c.

Huh? What you should care about is whether your program can run on future systems. Whether you call your program static or not is irrelevant.

It's relevant because if your program is statically linked then it doesn't matter whether or not future changes at the kernel boundary are made backwards-compatible by compensating changes in libc (as is possible if you release them together), because your statically-linked binary can't pick up those libc changes.

What? That makes no sense. The question here was why static linking is relevant to the point about whether or not having libc release together with the kernel means you could move the compatibility line to the libc interface, and I was answering that question.

Forbidding static linking libc is fine if you do that from the beginning. Linux didn't, so - whether or not you approve - there's statically linked binaries out there that must be supported. It's not about calling users stupid, or a discussion about what users should or shouldn't do - it's a discussion about what the kernel can do, today, given the backwards compatibility constraint and the reality on the ground. (Personally I am completely in favour of dynamic linking, but that's not the point).

> What? That makes no sense. The question here was why static linking is relevant

No it is not.

1. ninkendo asked how syscalls worked

2. detaro replies that NT software uses ntdll and never do raw syscalls

3. alxlaz non-sequiturs that "the kernel community is big on interface stability and compatibility"

4. quotemstr points out that backwards compatibility does not in any way, shape or form require a stable kernel ABI, that's just a weird linuxism (because it ships as a kernel alone rather than a system)

5. you apparently decide to bring the entire thing on an irrelevant tangent completely missing the point

I wasn't responding to ninkendo, detaro or alxlaz. I was responding precisely to quotemstr's:

The real reason Linux's ABI boundary is the kernel is just that the kernel and glibc are sperate [projects]

...by pointing out the very real issue that even if they were the same project today, they'd still have to maintain compatibility at the system call layer, because that ship has sailed.

To be more precise, then, the Linux kernel is the ABI boundary because during Linux's fluid and formative period, the kernel and libc were separate projects. I agree that it's mostly epoxied in place now, modulo my lkml libsyscall proposal from a while ago.

But Windows has excellent back-compatibility!