[Bug 48291] Detroit: Become Human crashes on launch

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=48291

--- Comment #42 from Zebediah Figura <z.figura12 at gmail.com> ---
(In reply to qsniyg from comment #41)
> (In reply to Zebediah Figura from comment #40)
> > Ultimately, if we really want to pursue making direct syscalls work (and I
> > still wince that the idea isn't immediately thrown out as absurd)
> 
> IIRC there are a few DRM and anticheat systems that use syscalls directly,
> apparently RDR2 does as well
> (https://github.com/ValveSoftware/Proton/issues/3291#issuecomment-562993403).
> While I agree that this is crazy, I don't know if there's any other way.
> That being said, I don't believe wine necessarily needs to switch internally
> to using syscalls instead of IPC, "only" support syscalls as well, so the
> performance or compatibility impact for any application not using syscalls
> directly (i.e. nearly all of them) shouldn't be affected.

Yes, it's more of a matter of establishing a fence, past which we can say, "if
you want your application to work on Wine, then *don't do this*." But I know
that's not a hugely productive thing to do in practice :-/

> >I think we'll need to start talking to the Linux kernel about giving us a custom interface that makes it easy and performant.
> 
> Is there an issue with seccomp? I've used it in the past, and while at the
> time it didn't support what I was looking for (passing fds, although the one
> who posted the patch was interested in pursuing this at the time), it was
> quite easy to use and as far as I could tell, there wasn't much overhead
> either.

Partly as stated above, but moreover, some applications (and Red Dead
Redemption 2 is one) make the excellent choice of hardcoding syscall numbers,
which obviously then coincide with Linux syscalls. Solving this in a
non-generic fashion isn't pretty and probably isn't sustainable either; solving
it in a generic fashion would mean trapping *every* syscall before using
heuristics to determine whose it is, which is of course a big performance
problem. The fact that seccomp can't be removed once applied rules out the
approach of turning it off whenever we exit PE code, and even if we could that
would require a syscall at every transition.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.