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

Zig clearly doesn't actually care that much about building robust and reusable software if they're going to forgo Microsoft's decades-long backwards compatibility functionality for the dubious gains of using bare-metal APIs.

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

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

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

The ~only good thing that programmers have achieved in the past ~60 years has been Windows stability.

Create a popular programming language, and then make programs written in it not run on newer Windowses is just something else. I so hate this.

Was "robust, optimal and reusable" always "run an older Windows on your newer Windows to run Zig software"?

I'm really struggling to see the pros of this:

> Performance - using the native API bypasses the standard Windows API, thus removing a software layer, speeding things up.

But the article cites no bemchmarks

> Power - some capabilities are not provided by the standard Windows API, but are available with the native API.

Makes sense when you are doing something that needs that power, but that makes more sense as an exception to prefering win32 than a general reason to prefer native.

> Dependencies - using the native API removes dependencies on subsystem DLLs, creating potentially smaller, leaner executables.

Linking win32 is a miniscule cost. (unless you have a benchmark to show me...)

> Flexibility - in the early stages of Windows boot, native applications (those dependent on NtDll.dll only) can execute, while others cannot.

Is Zig being used for such applications? If so, why are the calls that the document says will be kept on win32 not an issue?

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.

Anyone who has some experience with native apis knows that a standard library should never rely on unstable apis. Ntdll is not "stable" as in Microsoft can change it at any time since they expect anyone to use kernel32. It's questionable that they referenced a random book on this top claiming that ntdll is more performant than kernel32 which is doubtful. There are some specific cases where this is true (the ntfs stuff), but, in general, it's not, at least not in a significant matter. A standard library should never do this, it might break binaries for no reason, other than making a cool blog post. I, as a developer, can choose to use ntfs, but a standard library should never.

https://news.ycombinator.com/item?id=25997506 https://github.com/golang/go/issues/68678

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

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.

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.

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

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

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)

Yikes. Are they going to rename the language to "cyg" also? Does not inspire confidence.

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.

Don’t know about windows programming to give opinion but by the sentiment here maybe they should give dev to choose bashed on some comptime flag or sth and maintain two versions

For me this is too much. I wish Zig all the best, but decisions like this make me want to jump off this sinking ship.

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.

> While this can happen, we have not (yet) been affected by any changes in the Win32 -> Native layers.

Frankly this is dumb. Zig hasn't been around long enough to have even seen any changes, so using this as a reason is just plain dumb.

The view that, if windows ever changes, the code must be recompiled is a naive view one would expect from a child, not from a group of experienced devs.

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.

> 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

With the crucial difference that Linux places high value on syscall interface binary compatibility, while the NT native API is not guaranteed to be stable in any way.

A bit more comparable is OpenBSD where applications are very much expected to only use libc wrappers, which threw a wrench into the works for the Go runtime.

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

"Every document" notwithstanding, Native API is very widely used in practice and generally considered stable.

If in doubt, try and find examples of its breakage, semantic changes, etc.

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

Yeah, I know go has had issues because they subvert libc themselves in similar fashion. I wonder how this will turn out.

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

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