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.

Why should you design your software around what a different piece of software could claim of your program?

Because you want someone who trusts that different piece of software to use yours.

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

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.

But the trust as a service (TaaS) platform could decide tomorrow that you are not trustworthy because, I don't know, it matched a pattern in a piece of ransomware which is actually a pattern you can produce by allocating 3 pages of memory in one call. Should you as a language now put compile time guarantees that 3 pages cannot be allocated?

This is obviously a ridiculous example, but what I'm aiming to say is, if a piece of software is matching something as untrustworthy when it's not, you shouldn't chase it down to force the little guy who's maxing good will software to fix it because the big bully thinks they are evil and deserve to get quarantined

Sure. But the heuristic the TaaS world is using isn't something as absurd as "allocates 3 pages", it's "uses undocumented system APIs". We're also not arguing in the abstract that "they might make a stupid determination in the future", they're making this determination now.

I'm not a fan of the the security industry's practices, but I can't say they're making a malicious/stupid choice here.

Yeah, I get that, I'm just unconvinced that using lower level, less documented APIs, which are not necessarily meant to be the way users interact with the system, is a good heuristic for malware detection.

I'm ignoring the fact that very few people in the world need an antivirus (other than maybe elderly/less technologically knowledgeable people, but even then I'm not sure they can be fully protected)

The next choice will be dynamically resolving syscall IDs from NTDLL? Surely that has no issues that could possibly happen.

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

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.

It's a shame really that Microsoft wont officially bless ntdll because it's a much more sensible API generally speaking. Like why the hell did they throw away the return value and make everyone do the insane BOOL ret = Win32Function(); if(!ret) { DWORD err=GetLastError(); } dance?

Not every function returnds a boolean. It is probably easier to write HANDLE file = CreateFile(...) than to send in a pointer to HANDLE. Also, this is exactly the same as what libc does with syscalls on Linux etc.