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

91–99 of 99 posts

Re: Windows: Prefer the Native API over Win32

#91

Post by monocasa »

Dwedit wrote: post #90
delta_p_delta_x wrote: post #24

Earlier quoted context omitted.

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

Unfortunately, that's not the case. Wine for instance has to keep up to date to maintain compatibility with some applications.

https://gitlab.winehq.org/wine/wine/-/releases/wine-11.0

> NT system calls use the same syscall numbering as recent Windows, to support applications that hardcode syscall numbers.

Re: Windows: Prefer the Native API over Win32

#92

Post by monocasa »

Dwedit wrote: post #89
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...

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

Sure, I rarely see people refer to the win32k stubs in win32u as part of the native api, despite the Nt prefixes.

Re: Windows: Prefer the Native API over Win32

#93

Post by josephcsible »

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…

Antivirus is going to flag you no matter what if you're not a big-name developer with an expensive certificate. Even a "hello world" GUI program done with MSVC and Win32 gets called the Wacatac Trojan without one. We shouldn't let their incompetence dictate how our software works.

Re: Windows: Prefer the Native API over Win32

#94

Post by josephcsible »

tredre3 wrote: post #55
qq66 wrote: post #33

> Comparing the comprehensive Win32 API reference against the incidentally documented Native APIs, its clear which one Microsoft would prefer you use. The native API is treated as an implementation detail, whilst core parts of Windows' backwards compatibility strategy are implemented in Windows subsystem. > A general-purpose programming language and toolchain for maintaining robust, optimal, and reusable software. Zi…

They defer all very real issues caused by their approach as being problems for others to solve (wine, antiviruses, users, even microsoft). That's such a weird level of hubris. I think the only place where avoiding win32 is desirable is to write drivers, but zig already has support for some level of bare-metal development and I'm sure a package can provide shims to all ntdll utilities for that use-case. I think it's p…

Don't Wine and Microsoft already need to support the native API forever since so many AAA games use it?

Re: Windows: Prefer the Native API over Win32

#95

Post by josephcsible »

cmovq wrote: post #29

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

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

If it's still relevant after the developer abandons it, someone else will probably fork it.

Re: Windows: Prefer the Native API over Win32

#96

Post by josephcsible »

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.

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.

Re: Windows: Prefer the Native API over Win32

#97

Post by josephcsible »

lelanthran wrote: post #66
delta_p_delta_x wrote: post #46

Earlier quoted context omitted.

Is there a source for this? My Google- and GitHub-fu turns up nothing.

He might be talking about cipher test that respected cryptography libs do on initialisation to verify integrity. Skipping those seem like a really bad idea.

> Skipping those seem like a really bad idea.

Why? Is there any realistic scenario where your cryptography libs worked correctly yesterday but the exact same ones will be buggy today? What would be wrong with them just running once per build instead?

Re: Windows: Prefer the Native API over Win32

#98

Post by josephcsible »

lelanthran wrote: post #65
nvme0n1p1 wrote: post #30

Earlier quoted context omitted.

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.

Are you talking about the cipher tests that are run when any cipher library is loaded? There's a reason they do that and it's not for shits and giggles. You could find yourself with broken ciphers and not know it. Skipping the cipher (or hash - not sure now) tests seem like a good way to get exploited.

> Skipping the cipher (or hash - not sure now) tests seem like a good way to get exploited.

Can you explain how? That doesn't seem plausible.

Re: Windows: Prefer the Native API over Win32

#99

Post by jojomodding »

For comparison, in Rust they track down the differences in which flags are ignored in a certain kind of `fcntl` syscall across all the architectures that have this C function, which includes Solaris, Mac OS, the BSDs, Linux, ... This is so that this is correctly handled in Miri, which can then be used to run the test-suite of the OS-specific parts of the standard library, and observe if this uses unsupported features in some way. This ensures that the standard library relies on documented features and not on whatever happens to work right now.

See for example this PR comment: https://github.com/rust-lang/miri/pull/4840#discussion_r2836...

Post reply on HN