Live data from Hacker News

Windows: Prefer the Native API over Win32

codeberg.org

11–20 of 99 posts

Re: Windows: Prefer the Native API over Win32

#11

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.

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.

Re: Windows: Prefer the Native API over Win32

#12
> > Won't this get flagged by anti-virus scanners as suspicious?

> Unfortunately, yes. We consider this a problem for the anti-virus scanners to solve.

I don't think the anti-virus scanners consider Zig important enough, or even know about. They will not be the ones experiencing problems. Having executables quarantined and similar problems will fall on Zig developers and users of their software. That seems like a major drawback for using Zig.

Re: Windows: Prefer the Native API over Win32

#13
post #9

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]. [1] https://news.ycombinator.com/item?id=44611692

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

Re: Windows: Prefer the Native API over Win32

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

Re: Windows: Prefer the Native API over Win32

#15

> > Won't this get flagged by anti-virus scanners as suspicious? > Unfortunately, yes. We consider this a problem for the anti-virus scanners to solve. I don't think the anti-virus scanners consider Zig important enough, or even know about. They will not be the ones experiencing problems. Having executables quarantined and similar problems will fall on Zig developers and users of their software. That seems like a maj…

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.

Re: Windows: Prefer the Native API over Win32

#17

> > Won't this get flagged by anti-virus scanners as suspicious? > Unfortunately, yes. We consider this a problem for the anti-virus scanners to solve. I don't think the anti-virus scanners consider Zig important enough, or even know about. They will not be the ones experiencing problems. Having executables quarantined and similar problems will fall on Zig developers and users of their software. That seems like a maj…

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.

Re: Windows: Prefer the Native API over Win32

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

Re: Windows: Prefer the Native API over Win32

#19

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.

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

Re: Windows: Prefer the Native API over Win32

#20

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.

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.

More like everyone else, Linux kernel is the exception here.
Post reply on HN