News for hackers. Stuff that matters.
Re:Wine 11.0 by mschuster91 on Sunday January 18, 2026 @06:22PM (#46673245)
> NT system calls use the same syscall numbering as recent Windows, to support applications that hardcode syscall numbers.

Other than antivirus software and maybe MAYBE kernel-level "anticheat" slop - who in their right mind does straight syscalls to the kernel?

Re:Wine 11.0 by userbinator on Sunday January 18, 2026 @08:08PM (#46673921)
Does it matter? The closer they get to being indistinguishable from Windows, the better.
Re:Wine 11.0 by mschuster91 on Sunday January 18, 2026 @09:25PM (#46674401)
The problem is, Windows syscalls change around a lot. Keeping up with that is Sisyphean.
Re:Wine 11.0 by embedding-shape on Monday January 19, 2026 @07:54AM (#46678438)
Wine, from the first moment I saw it decades ago, seems to be all about doing the sisyphean tasks no one else wants to be doing. I'm still in awe how they managed to get Wine to where it is today, so if someone can do it, it's the wine devs :)
Re:Wine 11.0 by StrauXX on Sunday January 18, 2026 @06:32PM (#46673316)
Some programming language compilers generate asm that does call systemcalls directly. Go for example.
Re:Wine 11.0 by teraflop on Sunday January 18, 2026 @06:47PM (#46673404)
Go does hardcode system call numbers on Linux, but it doesn't on Windows. Instead it follows the normal Windows convention of calling the userspace wrappers from kernel32.dll and similar libraries.

https://cs.opensource.google/go/go/+/refs/tags/go1.25.6:src/...

Unlike on Linux, the low-level syscall numbers on the NT kernel are highly unstable across releases, so programs that try to call them directly will generally only work on a very specific kernel version.

Re:Wine 11.0 by nasretdinov on Monday January 19, 2026 @07:40AM (#46678334)
I wonder if due to C slowly fading away things like syscall ABI, kernel numbers, etc, will start getting more stable, not just on Windows but on macOS too
Re:Wine 11.0 by mschuster91 on Monday January 19, 2026 @09:13AM (#46679174)
There still needs to be a cause for working directly with the kernel interface instead of going via the userland interfaces (libc on Linux, kernel32/user32 on Windows, macOS frameworks) to justify the required effort, and the use cases are basically only DRM, malware, malware detectors and anti-cheat.
Re:Wine 11.0 by tux3 on Sunday January 18, 2026 @06:43PM (#46673387)
Userland DRMs do all sort of nonsense. Kernel anticheats wouldn't use the syscalls, they're already able to call the kernel routines they want directly.
Re:Wine 11.0 by kachapopopow on Sunday January 18, 2026 @07:22PM (#46673631)
anti tamper, drm, library call obfuscation and they all do it wrong, really wrong.
Re:Wine 11.0 by wat10000 on Sunday January 18, 2026 @09:56PM (#46674583)
I'd argue that anyone who willingly attempts to program these infernal beasts is not entirely in their right mind to begin with.
Re:Wine 11.0 by realusername on Monday January 19, 2026 @01:35AM (#46675658)
This change was motivated to improve anticheat support indeed.
Re:Wine 11.0 by yshui on Monday January 19, 2026 @10:00AM (#46679744)
If you think directly calling Windows syscall is crazy, some applications parse binary code from ntdll.dll to figure out what the syscall numbers actually are, since they change across different Windows versions :)