[qq66]

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

[tredre3]

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 pretty clear that they're doing it because it's a more fun challenge. As a low-level developer myself, I agree that using the lowest-level API possible is fun, especially if it's poorly documented and you have to try to try to preemptively mitigate breakage! But this is no mentality to have when you're writing a language ecosystem...

[josephcsible]

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

[thrwyexecbrain]

The Zig maintainers clearly think that keeping up with the undocumented native API is less headache than using the documented but notoriously inelegant win32 API.

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.

[renox]

It may gives them less headache but if the part about the antivirus flagging the exécutable as suspicious it may give the users headaches..

[slopinthebag]

lately it feels like zig is attempting to speed run irrelevance. which is a shame.

[gjsman-1000]

I don't know, everyone here seems plenty okay to tolerate worse levels of instability from Linux binaries. :)

[slopinthebag]

im too much of a mac user to understand what this references :p

[gjsman-1000]

Take a random Linux binary which does anything non-trivial (has a GUI, does system monitoring, etc.), try running it on a different distribution from 3 years earlier without a packaging system, and tell me how it goes.

[CorrectHorseBat]

What confuses me the most is the kernel goes actually to great lengths not to break userspace, but if you rely on anything else than the kernel stuff breaks all the time, and distributions never update a released version to a newer kernel but just patch old kernels for years. So why do the kernel developers even bother?

[lelanthran]

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.

[gjsman-1000]

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