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

81–90 of 99 posts

Re: Windows: Prefer the Native API over Win32

#81

Post by wtetzner »

koakuma-chan wrote: post #35
usrnm wrote: post #23

Earlier quoted context omitted.

> 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

Let me narrow down the scope here. I am a Rust developer, developing software that will run on my Linux server. Why would I want to use libc? Why does Rust standard library use libc? Zig, for example, doesn't.

> Why does Rust standard library use libc?

Because that's the stable public interface provided by pretty much every OS except Linux. On Linux, if you don't want to depend on the OS-supplied libc, you can use musl.

Re: Windows: Prefer the Native API over Win32

#82

Post by xfeeefeee »

Dwedit wrote: post #58

The one thing that really benefits from using NT Native API over Win32 is listing files in a directory. You get to use a 64KB buffer to get directory listing results, while Win32 just does the one at a time. 64KB buffer size means fewer system calls. (Reading the MFT is still faster. Yes, you need admin for that)

Oh hey this is exactly why I made node-windows-readdir-fast - especially with the way node works, this makes reading filenames and length and times around 50x faster

https://github.com/xfeeefeee/node-windows-readdir-fast https://www.npmjs.com/package/node-windows-readdir-fast

Windows only of course, but the concept is sound. Was also fun benchmarking to find out that parsing a binary stream was faster than creating a ton of objects through the node api (or json deserialization)

Re: Windows: Prefer the Native API over Win32

#83

Post by accoil »

monocasa wrote: post #15
roelschroeven wrote: post #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 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.

It's a common enough issue with go that they wrote a faq on it too: https://go.dev/doc/faq#virus

Re: Windows: Prefer the Native API over Win32

#84

Post by Narishma »

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.

It's the opposite of that. The Linux syscall is more stable than the (gnu)libc.

Re: Windows: Prefer the Native API over Win32

#85

Post by pjmlp »

rep_lodsb wrote: post #79
pjmlp wrote: post #22

Earlier quoted context omitted.

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.

But is the "proper UNIX way" a good thing? Funny that you would be arguing for that (unless I misunderstood the intention), given your many other posts about how C is a horrible broken unsafe language that should not be used by anyone ever. I tend to agree with that, btw, even if not so much with the "memory safety" hysteria. Should every program, now and in the future, be forced to depend on libc, just because it's…

The problem is the misconception of what libc is.

In traditional UNIX, there is no libc per se, there is the stable OS API set of functions and that's it.

When C was standardised, a subset of the UNIX API became the ISO C standard library, aka libc. When it was proven that wasn't enough for portable C code, the remaining UNIX API surface became POSIX.

Outside UNIX, libc is indeed a thing, because many of those OSes aren't even written in C, just like your language lists example, in those OSes libc ships with C compiler, not the OS per se, as you can check by diving into VMS documentation before it became OpenVMS, or IBM and Unisys systems, where libc is also irrelevant if using PL/I, NEWP, whatever.

Also on Windows, you are not supposed to depend on libc unless you are writing portable C code, there isn't one libc to start with. Just like everyone else, each compiler ships their own C runtime library, and nowadays there is also universal C runtime as well, plenty of libc choices.

If not writing portable C code, you aren't supposed to use memset(), rather FillMemory ().

Same applies to other non-UNIX OSes, you would not be calling memset(), rather the OS API for such service.

Re: Windows: Prefer the Native API over Win32

#86

Post by eps »

blibble wrote: post #36
eps wrote: post #31

Earlier quoted context omitted.

> Microsoft are free to change the Native API at will,... But they won't, because if there is one thing that Microsoft has always been extremely good at and cared for is backward compatibility. And changing Native API will break a ton of existing software, because even though undocumented it is very widely used.

you are confusing the ntdll interface (which is undocumented and subject to change), and win32 (which is stable, mostly) they tell you not to use ntdll, and say they will change it whenever they want and they have in the past (they have had to moderate this policy with "containers", but it's still what they say)

I'm not confusing anything.

Re: Windows: Prefer the Native API over Win32

#87

Post by eps »

dbdoskey wrote: post #62
eps wrote: post #31

Earlier quoted context omitted.

> Microsoft are free to change the Native API at will,... But they won't, because if there is one thing that Microsoft has always been extremely good at and cared for is backward compatibility. And changing Native API will break a ton of existing software, because even though undocumented it is very widely used.

Actually they do change the native API quite a bit. Not in minor releases so much but in major releases

They depricate some methods (very rarely and reasonably) and add new enums or struct versions to existing ones, but never change existing semantics, leave alone method signatures. As I said elsewhere, I invite you to find examples of actually destructive Native API changes.

Re: Windows: Prefer the Native API over Win32

#88

Post by CorrectHorseBat »

TazeTSchnitzel wrote: post #42

Go famously tried to bypass macOS's libc and directly use the underlying syscall ABI, which is unstable, and then a macOS update came out and broke everything, which taught them the error of their ways ( https://github.com/golang/go/issues/17490 ). I wonder if this will happen to Zig too.

The same on OpenBSD

Re: Windows: Prefer the Native API over Win32

#89

Post by Dwedit »

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

NTDLL should be stable since it's well documented, and many functions redirect to Ntoskrnl.exe, and things like kernel level drivers call those functions. Those functions won't change without the drivers breaking.

Then there's "Win32u.dll". These correspond to API calls from User32.dll, Gdi32.dll, etc. This DLL didn't even exist during the Windows 2000-XP era. This stuff is not well documented, and I don't know if this is stable.

Re: Windows: Prefer the Native API over Win32

#90

Post by Dwedit »

delta_p_delta_x wrote: post #24
monocasa wrote: post #18

Earlier quoted context omitted.

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

Only Malware uses the system call numbers directly. Using the system call numbers directly is foolish if they're going to change and break your app. Just import and call a function that will perform the actual SYSENTER (or WOW64 context change).
Post reply on HN