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.

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

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

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.

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.

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.

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

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

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.

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

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?

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

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

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

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.