upvote

points

by Numerlor8 hours ago |
comments
upvoteby colejohnson668 hours ago|
[-]
Not just that, but on Windows, they're bypassing the actually guaranteed stable Win32 API in favor of linking directly to the lower-level components. Completely destroying any forward compatibility!

https://codeberg.org/ziglang/zig/issues/31131

It's the kind of change that makes me read Zig as not trying to be a serious language. Not that there's anything wrong with that, but the way Zig positions itself is at odds with the completely bizarre takes they do.

reply
upvoteby FacelessJim1 hours ago|
parent|
next
[-]
If you spend some time working on cross platform code you will quickly realize that that choice is actually the right one. The NT API is actually very close in abstraction to Unix and allows for much less ad hoc code to handle windows specifics than using Win32 API (which is an abomination).

The zig windows NT implementations are very well done and I actually use them as reference when dealing with windows IO.

reply
upvoteby dwattttt4 hours ago|
parent|
prev|
next
[-]
From the link:

> > 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 am suddenly less interested in relying on Zig.

reply
upvoteby xydone3 hours ago|
parent|
[-]
Why should you design your software around what a different piece of software could claim of your program?
reply
upvoteby dwattttt3 hours ago|
parent|
[-]
Because you want someone who trusts that different piece of software to use yours.

Zig's decision here means the problem is _yours_ to convince this third party to trust you.

reply
upvoteby pawn191118 minutes ago|
parent|
[-]
The idea/hope is perhaps that the Zig programs will be of better quality than other programs, which will make it hard for the other side (the antivirus) to justify its position in a reasonable way. And in the end the other side will be forced to change its processes.
reply
upvoteby flohofwoe2 hours ago|
parent|
prev|
next
[-]
> Completely destroying any forward compatibility!

Microsoft breaking the ntdll.dll function interface is extremely unlikely, there's too much popular software in the wild depending on it.

reply
upvoteby not_a93 hours ago|
parent|
prev|
[-]
The next choice will be dynamically resolving syscall IDs from NTDLL? Surely that has no issues that could possibly happen.
reply