61–70 of 99 posts
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.
Yeah, I know go has had issues because they subvert libc themselves in similar fashion. I wonder how this will turn out.
>> 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…
> 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.
> 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…
This might very well be a good idea. Microsoft is not going to change a vital piece of their OS just on a whim. I would wager that even if they wanted to, they would not be able to do so that easily. A large organization maintaining a large software with a billion users just does not move that fast.
Earlier quoted context omitted.
Zig is proposing the opposite problem: future versions of windows wont run even trivial zig programs from today. I can tell you that old Linux binaries run just fine on current distros. Looking at how many times you repeated your misunderstanding in this thread it's clear that, not only do you not understand the solution, you don't understand the problem either.
> I can tell you that old Linux binaries run just fine on current distros. Simple: I don't believe you. Grab this copy of Firefox from 2022, https://www.firefox.com/en-US/firefox/96.0/releasenotes/ , and run it on a modern distribution in 2026. If you fail, my point is made.
Why specifically FF? Software without TLS does run just fine 5 years later on 5 year newer distros.
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.
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.
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.
Is there a source for this? My Google- and GitHub-fu turns up nothing.
Skipping those seem like a really bad idea.
Earlier quoted context omitted.
Zig is proposing the opposite problem: future versions of windows wont run even trivial zig programs from today. I can tell you that old Linux binaries run just fine on current distros. Looking at how many times you repeated your misunderstanding in this thread it's clear that, not only do you not understand the solution, you don't understand the problem either.
> I can tell you that old Linux binaries run just fine on current distros. Simple: I don't believe you. Grab this copy of Firefox from 2022, https://www.firefox.com/en-US/firefox/96.0/releasenotes/ , and run it on a modern distribution in 2026. If you fail, my point is made.
The page didn't include a download link, so I found it here: https://ftp.mozilla.org/pub/firefox/releases/96.0/linux-x86_...
And yes, it runs perfectly fine on Debian 13.
Earlier quoted context omitted.
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…
The Win32 ABI is also just a wrapper on the native API, which is only stable in practice, but not officially according to any Microsoft documentation. Glibc is userspace seen from the perspective of the Linux kernel.
Cygwin is also 'just a wrapper' for the Native API and Win32, and look how drastically it changes the ABI of applications.
Earlier quoted context omitted.
> I can tell you that old Linux binaries run just fine on current distros. Simple: I don't believe you. Grab this copy of Firefox from 2022, https://www.firefox.com/en-US/firefox/96.0/releasenotes/ , and run it on a modern distribution in 2026. If you fail, my point is made.
Does Debian Stable count? The page didn't include a download link, so I found it here: https://ftp.mozilla.org/pub/firefox/releases/96.0/linux-x86_... And yes, it runs perfectly fine on Debian 13.
You aren't going to convince him because he doesn't know what the problem is.
Fool's errand. Apps built with this will have to be maintained forever (vs the apps from Win 9x which still work in Windows 11).
Putting it on app developers to account for infinite forward compatibility is not at all reasonable.
The best outcome would be if many Zig apps become popular enough that Windows is forced to maintain backward compatibility for ntdll. The API is clearly superior to win32 as many other developers have discovered and discussed before. It’d be nice to force MS to take low lever programming seriously instead of chasing AI slop.