Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Windows: Prefer the Native API over Win32

codeberg.org

Post reply on HN
Print view View original

21–30 of 99 posts

Re: Windows: Prefer the Native API over Win32

#21

Post by monocasa »

delta_p_delta_x wrote: post #11
koakuma-chan wrote: post #10

Earlier quoted context omitted.

> 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.

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 c…

A lot of the native API is considered stable these days. The actual signals aren't, but the wrappers in ntdll are.

Re: Windows: Prefer the Native API over Win32

#22

Post by pjmlp »

koakuma-chan wrote: post #10
pseudohadamard wrote: post #2

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 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.

Nope, in UNIX proper syscalls and libc overlap, that is how C and UNIX eventually evolved side by side, in a way one could argue UNIX is C's runtime, and hence why most C deployments also expect some level of compatibility with UNIX/POSIX.

Linux is the exception offering its guts to userspace with guarantees of stability.

Re: Windows: Prefer the Native API over Win32

#23

Post by usrnm »

koakuma-chan wrote: post #10
pseudohadamard wrote: post #2

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 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.

> I don't see why I would want to use libc

To make your code portable? Linux-only software is even worse than Windows-only

Re: Windows: Prefer the Native API over Win32

#24

Post by delta_p_delta_x »

monocasa wrote: post #18
cmovq wrote: post #14

Is there an official stance on whether ntdll is stable? Obviously they're not going to change things arbitrarily since applications depend on it, but I'm wondering if there is a guarantee like the linux syscall interface or how you can run a win32 application compiled in 2004 on Win11.

It's partially stable. Basically any thing documented on msdn in the API docs is considered stable. Such as: https://learn.microsoft.com/en-us/windows/win32/api/winternl...

Indeed. Anything documented has a function wrapper. `NtCreateFile` is a function wrapper for the syscall number, so any user-mode code that has `NtCreateFile` instead of directly loading the syscall number 0x55 will be stable. The latter might not. In fact, it is not; the number has increased by 3 since Windows XP[1].

One could probably produce some sort of function pointer loader library with these tables, but at that point... Why not just use the documented APIs?

[1]: https://github.com/j00ru/windows-syscalls/blob/8a6806ac91486...

Re: Windows: Prefer the Native API over Win32

#25

Post by monocasa »

anfragment wrote: post #17
monocasa wrote: post #15

Earlier quoted context omitted.

Yeah, I had this problem when shipping go binaries on Windows. Antivirus vendors really do not care that your program regularly shows up as a false positive due to their crappy heuristics, even if you have millions of users.

Have you tried code-signing with an EV certificate? If so, did it help? Asking for a friend.

Statistically notable improvement, but it didn't help a whole lot.

Re: Windows: Prefer the Native API over Win32

#26

Post by cmovq »

monocasa wrote: post #18
cmovq wrote: post #14

Is there an official stance on whether ntdll is stable? Obviously they're not going to change things arbitrarily since applications depend on it, but I'm wondering if there is a guarantee like the linux syscall interface or how you can run a win32 application compiled in 2004 on Win11.

It's partially stable. Basically any thing documented on msdn in the API docs is considered stable. Such as: https://learn.microsoft.com/en-us/windows/win32/api/winternl...

Interesting, some functions explicitly mention:

> [NtQuerySystemTime may be altered or unavailable in future versions of Windows. Applications should use the GetSystemTimeAsFileTime function.] [0]

So it does seem like a bad idea for a standard library.

[0]: https://learn.microsoft.com/en-us/windows/win32/api/winternl...

Re: Windows: Prefer the Native API over Win32

#27

Post by dblohm7 »

This is a terrible idea! _Maybe_, _maybe_ using only the documented APIs with only the documented parameters.

Unfortunately it makes too many false assumptions about interoperability between Win32 and the underlying native API that aren't true.

For example (and the Go runtime does this, much to my chagrin), querying the OS version via the native API always gives you "accurate" version information without needing to link a manifest into your application. Unfortunately that lack of manifest will still cause many Win32 APIs above the native layer to drop into a compatibility mode, creating a fundamental inconsistency between what the application thinks the OS capabilities are versus which Win32 subsystem behaviours the OS thinks it should be offering.

Re: Windows: Prefer the Native API over Win32

#28

Post by boje »

Honestly, this sounds like a future headache that would otherwise go unnoticed unless the programmer is dealing with porting or binding over source code meant for older Windows systems to Zig (or supporting older systems in general). Eventually it might result in a bunch of people typing out blogposts venting their frustrations, and the creation of tutorials and shims for hooking to Win32 instead of the Zig standard library with varying results. Which is fine, I suppose. Legacy compiler targets are a thing.

This is already a problem with Linux binaries for systems that don't have a recent enough Glibc (unless the binaries themselves don't link to it and do syscalls directly).

Re: Windows: Prefer the Native API over Win32

#29

Post by cmovq »

>> Microsoft are free to change the Native API at will, and you will be left holding both pieces when things break.

> [...] the worst case scenario is really mild: A new version of windows comes out, breaking ntdll compatibility. Zig project adds a fix to the std lib. Application developer recompiles their zig project from source, and ships an update to their users.

That assumes the application developer will continue to maintain it until the end of time.

Also "the fix" would mean developers wanting to support earlier Windows versions would need to use an older std library? Or is the library going to have runtime checks to see what Windows build its running on?

Re: Windows: Prefer the Native API over Win32

#30

Post by nvme0n1p1 »

bob1029 wrote: post #16

Why not use both DLLs? Prefer win32 wherever possible and use the lower level APIs only if absolutely necessary. Benchmark after you have figured this out. Performance is probably not a thing at this level of abstraction.

What makes you think they haven't benchmarked?

Here's one fun example from following development on Zulip: advapi.dll loads bcrypt.dll, which loads bcryptprimitives.dll. bcryptprimitives.dll runs an internal test suite every time it's loaded into any process. So if you can avoid loading advapi.dll, your process will start faster.

Post reply on HN