[Bug 48291] Detroit: Become Human crashes on launch

WineHQ Bugzilla wine-bugs at winehq.org
Tue Dec 31 16:05:34 CST 2019


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

--- Comment #45 from Zebediah Figura <z.figura12 at gmail.com> ---
(In reply to qsniyg from comment #44)
> After doing a little more thinking and investigation, here are my thoughts:
> 
>  * A seccomp-based solution could indeed work, if no linux syscalls are sent.
>    * The implementation of ntdll would have to be moved to wineserver,
> shell32 would have to be partly rewritten to use windows functions, etc.
>    * From what I've read, the overhead is pretty small. Although I haven't
> tried this yet, in theory a big BPF tree (where apparently most of the
> performance overhead currently lies) shouldn't be needed if all syscalls are
> trapped.
>  * Differences in syscall numbers could be handled through a LUT present in
> both wineserver and userspace, based on the Windows version selected.
>  * Since seccomp can be turned off in userspace, support for it cannot be
> hardcoded through #ifdefs, it has to instead be able to detect support at
> runtime.
>  * Obviously IPC has to be supported as well, but the current solution will
> have to be rewritten if duplication of code is to be avoided. For most
> cases, this shouldn't be much of an issue, but how about cases where memory
> has to be written (e.g. NtOpenFile returning a handle)? Would
> write_process_memory be a valid option? It would be a pretty terrible option
> performance-wise (and possibly compatibility-wise as well) if the ptrace
> path has to be used. The alternative would be to write a custom struct for
> every syscall, which would quite obviously be a chore.
> 
> Any thoughts on this?

You'd need to do IPC without syscalls, which strikes me as pretty much
impossible.

shell32 I think is mostly almost there, it's only using environment variables
and Unix file I/O that we can access from Win32 code. It just hasn't been done
yet. Unfortunately it's more than just ntdll and shell32, it's everything that
needs to access an external library, or do e.g. unix ioctls.

Not to mention that relying on IPC for everything that could involve a system
call would be enormously expensive. The degree to which we do already is bad
enough.

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



More information about the wine-bugs mailing list