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.
> 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].
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.
"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.
Yeah, I know go has had issues because they subvert libc themselves in similar fashion. I wonder how this will turn out.
Except unlike Linux syscall interface and like almost every other OS out there, ABI compatibility is an accident, not a guarantee.
> 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.
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.