[mappu]

For most of Wine's life it was sufficient to implement the system library ABI, but recent developments mean they also have to trap the (unstable) syscall ABI with ptrace. You could mimic Binder in userspace the same way, without the kernel module. But even that's not a problem since Binder is upstream and enabled by default in many distro kernels now.

[ronsor]

When did WINE start doing this? I always love a good read on ptrace hacks.

[lights0123]

https://github.com/wine-staging/wine-staging/commit/595f2f98...

A new strategy is used that is much faster: https://www.phoronix.com/news/Syscall-User-Dispatch-Queued

[quotemstr]

> Games avoiding the Windows API and performing system calls directly is an increasingly common occurrence by modern Windows games, seemingly in the name of Digital Rights Management schemes and similar protected modes.

Yuck. Windows system call numbers are not contractual. At all. Microsoft should try harder to kill any code outside ntdll.dll that makes a system call. It's obnoxious for a developer to deliberately use unstable interfaces and then demand indefinite compatibility.

[lxgr]

> demand indefinite compatibility.

Not infinite – long enough for the game to bring in most revenue is enough.

Who cares that it stops running one or two Windows updates later for totally avoidable reasons? Definitely not the publisher. (In fact, isn't it about time for an HD remaster again?)

[quotemstr]

Microsoft cares, though, because if a game stops working when you upgrade Windows, you blame the Windows upgrade, not Microsoft. So now Microsoft has to maintain these legacy system calls even though they never signed up to do that.

[ronsor]

Microsoft does not. This is the one area where they don't compromise: system call numbers regularly change between Windows builds.

[int0x29]

There is now at least one public windows kernel call listed on MSDN: __fastfail

https://learn.microsoft.com/en-us/cpp/intrinsics/fastfail?vi...

[quotemstr]

I'd call that a special ABI feature, not a stable system call. Note that it's a software interrupt, not a regular SYSENTER. But sure. Maybe I'm splitting hairs.

[augusto-moura]

I don't think binder is upstream, nor is the default in many distros. AFAIK support is very limited as not a lot of people use it. In arch it is provided only as a community package (AUR) [1]. This was a major blocker for me when trying to install anbox or waydroid, custom compiled kernel modules is a no-no for me, not because of security issues (which could exist), but because they can break a lot of stuff and fixing kernel modules is not a stroll in the park.

[1]: https://aur.archlinux.org/packages/binder_linux-dkms

[mappu]

It was moved from linux-staging to proper Linux in 2014 [1], and it's included with Debian oldoldstable, oldstable, and stable as well as Ubuntu linux-image packages, as a module binder_linux.ko; just need to modprobe binder.

1. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

2. https://packages.debian.org/search?suite=buster&arch=any&mod...

[ac29]

It is upstream and Arch gives directions for enabling it in the standard kernel: https://wiki.archlinux.org/title/Waydroid#Building_a_kernel

[yjftsjthsd-h]

I'm reasonably confident that it is upstream: https://github.com/torvalds/linux/blob/master/drivers/androi... looks like the most obvious bit, though there are other pieces. (And now I'm curious why waydroid is maintaining their own dkms code separate from that; perhaps it's to better target a range of kernel versions?) I will agree that it's not generally actually built/used by distros.