51–60 of 99 posts
Earlier quoted context omitted.
lately it feels like zig is attempting to speed run irrelevance. which is a shame.
I don't know, everyone here seems plenty okay to tolerate worse levels of instability from Linux binaries. :)
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.
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.
Earlier quoted context omitted.
I don't know, everyone here seems plenty okay to tolerate worse levels of instability from Linux binaries. :)
im too much of a mac user to understand what this references :p
Earlier quoted context omitted.
Yeah, I know go has had issues because they subvert libc themselves in similar fashion. I wonder how this will turn out.
I think they had to revert back to libc on macOS/iOS because those have syscall interfaces that truly are not stable (and golang found that out the hard way). I wonder if they had to do the same on BSDs because of syscall filtering.
> 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…
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...
Earlier quoted context omitted.
> 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.
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…
Glibc is userspace seen from the perspective of the Linux kernel.
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.
(Reading the MFT is still faster. Yes, you need admin for that)
Earlier quoted context omitted.
im too much of a mac user to understand what this references :p
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.
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.
Earlier quoted context omitted.
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.
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.
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.