4 ms·

For people not familiar with Windows development, another name for the NT native API is "the API that pretty much every document on Windows programming tells yo

For people not familiar with Windows development, another name for the NT native API is "the API that pretty much every document on Windows programming tells you not to use". It's like coding to the Linux syscall interface instead of libc.

nullpoint420 9mo ago
Yeah, I know go has had issues because they subvert libc themselves in similar fashion. I wonder how this will turn out.
- LoganDark 9mo ago
  I think they had to revert back to libc on macOS/iOS because those have syscall interfaces that truly are not stable (and golang found that out the hard way). I wonder if they had to do the same on BSDs because of syscall filtering.
  - samus 9mo ago
    Indeed, OpenBSD recently added hardening measures and started restricting the generic syscall interface to libc.
- wrs 9mo ago
  Go backed out of their strategy on MacOS and started using libc (libsystem?), because when Apple says something is internal and may change without notice, they really mean it. It may be a better risk with Microsoft, but it’s still a risk.
- lelanthran 9mo ago
  Same way it turned out for Go: they had to walk it back.
HexDecOctBin 9mo ago
Linux syscall interface is actually stable and can easily be targeted. It’s BSDs (and Mac OS) that force everyone to link to only libc.
- pjmlp 9mo ago
  More like everyone else, Linux kernel is the exception here.
kvemkon 9mo ago
> It's like ... Considering the level of the API. But it is total opposite comparing a bit deeper. Linux has a famous rule "WE DO NOT BREAK USERSPACE!" e.g. [1]. [1] https://news.ycombinator.com/item?id=44611692 https://news.ycombinator.com/item?id=44611692
- dunder_cat 9mo ago
  One thing that is amusing about the prevalence of advanced anti-cheat in Windows gaming is it's actually causing said API/ABIs to undergo ossification. A good data point is the invention of Syscall User Dispatch^1 on Linux which would allow a program to basically install a syscall handler when they originate from various regions of memory. I do not know how usable this is in practice, admittedly -- but I think the fact it was contributed at all speaks to the growing need. ^1 https://docs.kernel.org/admin-guide/syscall-user-dispatch.html https://docs.kernel.org/admin-guide/syscall-user-dispatch.ht...
koakuma-chan 9mo ago
> It's like coding to the Linux syscall interface instead of libc. The right thing to do? I don't see why I would want to use libc.
- delta_p_delta_x 9mo ago
  On Windows, the stability guarantees are opposite to that of Linux. The kernel ABI is not guaranteed to be stable, whereas the Win32 ABI is. And frankly, the Windows way is better. On Linux, the 'ABI' for nearly all user-mode programs is not the kernel's ABI but rather glibc's (plus the variety of third-party libraries, because Win32 has a massive surface area and is an all-in-one API). Now, glibc's ABI constantly changes, so linking against a newer glibc (almost certainly the 'host' glibc, because it is almost impossible to supply a different 'target' glibc without Docker) will result in a program that doesn't run on older glibc. So much for Torvalds' 'don't break userspace'. Not so for a program compiled for 'newer' Win32; all that matters are API compatibilities. If one only uses old-hat interfaces that are documented to be present on Windows 2000, one can write and compile one's code on Windows 11, and the executable will run on the former with no issues. And vice versa, actually.
  - monocasa 9mo ago
    A lot of the native API is considered stable these days. The actual signals aren't, but the wrappers in ntdll are.
  - samus 9mo ago
    The Win32 ABI is also just a wrapper on the native API, which is only stable in practice, but not officially according to any Microsoft documentation. Glibc is userspace seen from the perspective of the Linux kernel.
    - delta_p_delta_x 9mo ago
      It doesn't really matter if it's 'just a wrapper', because said wrapper provides an ABI. Even if the underlying Native API changes, the interface the wrapper presents to other compiled binaries won't. The latter will contain caller/callee register setup, type layouts, function arguments and more for that wrapper. Cygwin is also 'just a wrapper' for the Native API and Win32, and look how drastically it changes the ABI of applications.
pjmlp 9mo ago
Except unlike Linux syscall interface and like almost every other OS out there, ABI compatibility is an accident, not a guarantee.
eps 9mo ago
"Every document" notwithstanding, Native API is very widely used in practice and generally considered stable. If in doubt, try and find examples of its breakage, semantic changes, etc.
samus 9mo ago
With the crucial difference that Linux places high value on syscall interface binary compatibility, while the NT native API is not guaranteed to be stable in any way. A bit more comparable is OpenBSD where applications are very much expected to only use libc wrappers, which threw a wrench into the works for the Go runtime.
Narishma 9mo ago
> It's like coding to the Linux syscall interface instead of libc. It's the opposite of that. The Linux syscall is more stable than the (gnu)libc.
josephcsible 9mo ago
> It's like coding to the Linux syscall interface instead of libc. Which is perfectly fine to do and guaranteed to work forever because of Linus's policy that kernel updates aren't allowed to break userspace programs.

nullpoint420 9mo ago

Yeah, I know go has had issues because they subvert libc themselves in similar fashion. I wonder how this will turn out.

LoganDark 9mo ago
I think they had to revert back to libc on macOS/iOS because those have syscall interfaces that truly are not stable (and golang found that out the hard way). I wonder if they had to do the same on BSDs because of syscall filtering.
- samus 9mo ago
  Indeed, OpenBSD recently added hardening measures and started restricting the generic syscall interface to libc.
wrs 9mo ago
Go backed out of their strategy on MacOS and started using libc (libsystem?), because when Apple says something is internal and may change without notice, they really mean it. It may be a better risk with Microsoft, but it’s still a risk.
lelanthran 9mo ago
Same way it turned out for Go: they had to walk it back.

HexDecOctBin 9mo ago

Linux syscall interface is actually stable and can easily be targeted. It’s BSDs (and Mac OS) that force everyone to link to only libc.

pjmlp 9mo ago
More like everyone else, Linux kernel is the exception here.

kvemkon 9mo ago

> It's like ... Considering the level of the API. But it is total opposite comparing a bit deeper. Linux has a famous rule "WE DO NOT BREAK USERSPACE!" e.g. [1]. [1] https://news.ycombinator.com/item?id=44611692 https://news.ycombinator.com/item?id=44611692

dunder_cat 9mo ago
One thing that is amusing about the prevalence of advanced anti-cheat in Windows gaming is it's actually causing said API/ABIs to undergo ossification. A good data point is the invention of Syscall User Dispatch^1 on Linux which would allow a program to basically install a syscall handler when they originate from various regions of memory. I do not know how usable this is in practice, admittedly -- but I think the fact it was contributed at all speaks to the growing need. ^1 https://docs.kernel.org/admin-guide/syscall-user-dispatch.html https://docs.kernel.org/admin-guide/syscall-user-dispatch.ht...

koakuma-chan 9mo ago

> It's like coding to the Linux syscall interface instead of libc. The right thing to do? I don't see why I would want to use libc.

delta_p_delta_x 9mo ago
On Windows, the stability guarantees are opposite to that of Linux. The kernel ABI is not guaranteed to be stable, whereas the Win32 ABI is. And frankly, the Windows way is better. On Linux, the 'ABI' for nearly all user-mode programs is not the kernel's ABI but rather glibc's (plus the variety of third-party libraries, because Win32 has a massive surface area and is an all-in-one API). Now, glibc's ABI constantly changes, so linking against a newer glibc (almost certainly the 'host' glibc, because it is almost impossible to supply a different 'target' glibc without Docker) will result in a program that doesn't run on older glibc. So much for Torvalds' 'don't break userspace'. Not so for a program compiled for 'newer' Win32; all that matters are API compatibilities. If one only uses old-hat interfaces that are documented to be present on Windows 2000, one can write and compile one's code on Windows 11, and the executable will run on the former with no issues. And vice versa, actually.
- monocasa 9mo ago
  A lot of the native API is considered stable these days. The actual signals aren't, but the wrappers in ntdll are.
- samus 9mo ago
  The Win32 ABI is also just a wrapper on the native API, which is only stable in practice, but not officially according to any Microsoft documentation. Glibc is userspace seen from the perspective of the Linux kernel.
  - delta_p_delta_x 9mo ago
    It doesn't really matter if it's 'just a wrapper', because said wrapper provides an ABI. Even if the underlying Native API changes, the interface the wrapper presents to other compiled binaries won't. The latter will contain caller/callee register setup, type layouts, function arguments and more for that wrapper. Cygwin is also 'just a wrapper' for the Native API and Win32, and look how drastically it changes the ABI of applications.

pjmlp 9mo ago

Except unlike Linux syscall interface and like almost every other OS out there, ABI compatibility is an accident, not a guarantee.

eps 9mo ago

"Every document" notwithstanding, Native API is very widely used in practice and generally considered stable. If in doubt, try and find examples of its breakage, semantic changes, etc.

samus 9mo ago

With the crucial difference that Linux places high value on syscall interface binary compatibility, while the NT native API is not guaranteed to be stable in any way. A bit more comparable is OpenBSD where applications are very much expected to only use libc wrappers, which threw a wrench into the works for the Go runtime.

Narishma 9mo ago

> It's like coding to the Linux syscall interface instead of libc. It's the opposite of that. The Linux syscall is more stable than the (gnu)libc.

josephcsible 9mo ago

> It's like coding to the Linux syscall interface instead of libc. Which is perfectly fine to do and guaranteed to work forever because of Linus's policy that kernel updates aren't allowed to break userspace programs.