https://bugs.winehq.org/show_bug.cgi?id=48291 Alexandr Oleynikov <sashok.olen(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sashok.olen(a)gmail.com --- Comment #1 from Alexandr Oleynikov <sashok.olen(a)gmail.com> --- Created attachment 65991 --> https://bugs.winehq.org/attachment.cgi?id=65991 +relay,+seh +relay,+seh could be useful too i guess -- 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.

https://bugs.winehq.org/show_bug.cgi?id=48291 Alexandr Oleynikov <sashok.olen(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Hardware|x86 |x86-64 -- 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.

https://bugs.winehq.org/show_bug.cgi?id=48291 Paul Gofman <gofmanp(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gofmanp(a)gmail.com --- Comment #3 from Paul Gofman <gofmanp(a)gmail.com> --- (In reply to Alexandr Oleynikov from comment #2) The initial crash is likely because it could not find mfc140.dll which it loaded through LoadLibrary(), which you probably fixed with native vcrun2015. Could you please give any details and log how it does not launch now? -- 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.

https://bugs.winehq.org/show_bug.cgi?id=48291 --- Comment #5 from Paul Gofman <gofmanp(a)gmail.com> --- The minimum system requirements I could find involve Windows 10, and the main thread exits right after GetVersionInfo(), so I wonder if setting Win version to 10 in winecfg change anything? -- 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.

https://bugs.winehq.org/show_bug.cgi?id=48291 --- Comment #7 from Alexandr Oleynikov <sashok.olen(a)gmail.com> --- And there are also reports online that it works just fine on Windows 7 after installing vcrun2015. -- 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.

https://bugs.winehq.org/show_bug.cgi?id=48291 --- Comment #9 from Alexandr Oleynikov <sashok.olen(a)gmail.com> --- Oh, but the first log I attached to this issue was made without installing vcrun2015. Should have made it more clear sorry. I'll make another clean one but this time with version set to 7. Should note that I will still need to install native dotnet as EGS launcher just doesn't install without it, however, I didn't notice the game itself loading it? -- 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.

https://bugs.winehq.org/show_bug.cgi?id=48291 --- Comment #11 from Paul Gofman <gofmanp(a)gmail.com> --- It is all OK if you mention all these details. Your log did not have a line about Wine staging, which makes me think that maybe something got mixed up or the log was not recorded from the very beginning. On a clean prefix (with that workarounds needed to install the game applied and vcrun2015 for MFC), could you please make sure that you are starting the game with debug channels before any other processes were started for your Wine prefix? If you are using some wrapper to start Wine, can you please not and start it from the command line so we are sure this is a full log. And record the log with: WINEDEBUG=warn+all,+relay,+seh,+loaddll,+module,+process -- 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.

https://bugs.winehq.org/show_bug.cgi?id=48291 --- Comment #13 from Alexandr Oleynikov <sashok.olen(a)gmail.com> --- Yep, of course. So sorry for not providing all information from the start, and that I forgot to leave the wine version in the logs when I trimmed it to when the game itself starts. If you don't mind, I'll use TKG PKGBUILD to build wine, but of course I will disable absolutely every patchset that is applied to these by default to eliminate interference from other patches. -- 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.

https://bugs.winehq.org/show_bug.cgi?id=48291 --- Comment #15 from Alexandr Oleynikov <sashok.olen(a)gmail.com> --- Oh, my existing prefix only has vcrun2015 and native dotnet for EGS installation, and nothing extra was used when creating previous logs except for usage of Esync and DXVK, but just in case I'll remove that and leave only vcrun and dotnet. In that case, here is a WINEDEBUG=warn+all,+relay,+seh,+loaddll,+module,+process log made with Wine Staging 4.21 from Arch Linux repositories made in that prefix. And I made sure that the version is set to Windows 7. I let it run for some time to make sure the issue was fully recorded and then terminated the app with wineserver -k. It's too large for WineHQ so here's a link to google drive: https://drive.google.com/open?id=1fxeL8BAcfAjW4mxUwuo6Obv6fwduRY__ Hopefully this will be more helpful :) -- 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.

https://bugs.winehq.org/show_bug.cgi?id=48291 Leopard <yurnerolinux(a)yandex.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |yurnerolinux(a)yandex.com --- Comment #17 from Leopard <yurnerolinux(a)yandex.com> --- Game has a free demo available that can be used for testing purposes. https://www.epicgames.com/store/product/detroit-become-human/demo -- 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.

https://bugs.winehq.org/show_bug.cgi?id=48291 --- Comment #19 from Alexandr Oleynikov <sashok.olen(a)gmail.com> --- I can confirm that the Demo works. However, the full game still crashes, now even with native vcrun. -- 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.

https://bugs.winehq.org/show_bug.cgi?id=48291 --- Comment #21 from Leopard <yurnerolinux(a)yandex.com> --- Sorry for my previous comment , demo of the game indeed works with vcrun2015. However performance is really bad , even in the intro videos and main menu. My specs are not the issue btw ; i7 7700HQ 8 threads and gtx 1050 4gb with 440 driver. -- 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.

https://bugs.winehq.org/show_bug.cgi?id=48291 --- Comment #23 from Alexandr Oleynikov <sashok.olen(a)gmail.com> --- Thanks so much! And that error message you've experienced (Something Went Wrong...) is caused by DRM and happens not due to your patch but due to changing wine version too many times. Unrelated, but compared to Windows, the performance in this game under Wine is just horrendous. I'm talking about actual slideshow vs buttery smooth picture on Windows. And this even with Esync or Fsync enabled. So, should I open a different another bug report about it needing mfc140.dll? I actually tried running it in a prefix with just that dll and without actual vcrun2015 installed and it worked. -- 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.

https://bugs.winehq.org/show_bug.cgi?id=48291 --- Comment #25 from Paul Gofman <gofmanp(a)gmail.com> --- Created attachment 66094 --> https://bugs.winehq.org/attachment.cgi?id=66094 Don't use fast_wait_cv in conditional variable waits Attached patch fixes the terrible performance issue for me (both on demo and full game). I did not test performance in details but that impossibly slow poerformance is gone with this patch. I didn't yet fully analyzed what exactly is wrong with the fast_wait_cv() for this case, I suppose it was helping in some other cases, I didn't yet analyse what exactly is specifics here. To summarize, the following is covered by the previous and this patch: 1. The game requires x64 syscalls emulation (supported in the previously attached patch using seccomp). Unfortunately seccomp is Linux specific, it won't work on Mac. The emulation of syscalls might be useful for some other DRMs. 2. The game requires processor features to be set more accurately. Somehow some features are currently set for AMD CPUs only, while Intel can have the same. The previous patch addresses that. 3. User shared data area has NumberOfPhysicalPages not filled in 4. Performance issue (use of fast_wait_cv). The issues 1-3 are in the previous patch. I suggest to make this bug about issue 1 (x64 syscalls emulation). The other 3 needs separate bugs to be created. -- 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.

https://bugs.winehq.org/show_bug.cgi?id=48291 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com --- Comment #27 from Zebediah Figura <z.figura12(a)gmail.com> --- (In reply to Paul Gofman from comment #26) Nice find! On 64-bit machines, we actually have 8 bits to work with, which means we could manually align the address upward, at least for condition variables and SRW locks. Note also that address waits are hashed, so we don't need to use the server path for those even if they're unaligned. -- 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.

https://bugs.winehq.org/show_bug.cgi?id=48291 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch -- 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.

https://bugs.winehq.org/show_bug.cgi?id=48291 Paul Gofman <gofmanp(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #66111|0 |1 is obsolete| | --- Comment #30 from Paul Gofman <gofmanp(a)gmail.com> --- Created attachment 66112 --> https://bugs.winehq.org/attachment.cgi?id=66112 Handle unaligned addresses in for condition variables. Fixed a bug in the previous patch. -- 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.

https://bugs.winehq.org/show_bug.cgi?id=48291 --- Comment #32 from Alexandr Oleynikov &lt;sashok.olen(a)gmail.com&gt; --- By using last patch + installing native vcrun2019, performance is now more or less on par with Windows <3 -- 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.

https://bugs.winehq.org/show_bug.cgi?id=48291 --- Comment #34 from Zebediah Figura &lt;z.figura12(a)gmail.com&gt; --- Created attachment 66132 --> https://bugs.winehq.org/attachment.cgi?id=66132 alternate patch for futex alignment Can you please test the attached patch also? It should be functionally identical to Paul's latest patch for condition variables, but is written a bit differently. (From a structural perspective I prefer leaving use_futexes() as it is, and I think I also prefer restricting the alignment logic to the futex path.) -- 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.

https://bugs.winehq.org/show_bug.cgi?id=48291 David Torok &lt;dt(a)zeroitlab.com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dt(a)zeroitlab.com --- Comment #36 from David Torok &lt;dt(a)zeroitlab.com&gt; --- Created attachment 66143 --> https://bugs.winehq.org/attachment.cgi?id=66143 seccomp filter to trap based on the program counter value @Paul Gofman : Thank you for your work on x64 syscall emulation! I would like to discuss your approach a bit further to hopefully generalize this idea. I see you incremented the syscall numbers in the nt syscall thunks and subtracted accordingly before the dispatcher. My understanding is that this will not work in cases where the application looks up the NT build (from the PEB for instance) and uses a syscall number based on the build information. (Examples include Red Dead Redemption 2, similar issue: https://bugs.winehq.org/show_bug.cgi?id=47198 ) Assuming that my thinking is correct, we would need to set the syscall numbers accordingly in wine, which results in conflicts with linux syscall numbers. I've been thinking about ways to go about this, and thought we could rewrite the seccomp filter to trap only on virtual addresses outside of glibc. (see the attachment) What are your thoughts, would that work well for us? -- 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.

https://bugs.winehq.org/show_bug.cgi?id=48291 --- Comment #38 from Paul Gofman &lt;gofmanp(a)gmail.com&gt; --- I have split off Bug #48386, Bug #48387 from this bug (p. 2, 3 from Comment #25). This bug is about p. 1, that is, syscall emulation. There is currently no bug record for unaligned use of futexes (performance issue here), not sure if we need it. -- 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.

https://bugs.winehq.org/show_bug.cgi?id=48291 --- Comment #39 from Zebediah Figura &lt;z.figura12(a)gmail.com&gt; --- (In reply to Paul Gofman from comment #38) It's probably ideal, so we have something to link the patch to. I've filed bug 48389. -- 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.

https://bugs.winehq.org/show_bug.cgi?id=48291 qsniyg &lt;qsniyg(a)mail.com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |qsniyg(a)mail.com --- Comment #41 from qsniyg &lt;qsniyg(a)mail.com&gt; --- (In reply to Zebediah Figura from comment #40) 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. 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. -- 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.

https://bugs.winehq.org/show_bug.cgi?id=48291 --- Comment #43 from qsniyg &lt;qsniyg(a)mail.com&gt; --- (In reply to Zebediah Figura from comment #42) Ah my apologies, for some reason I forgot to ctrl+f before asking haha Right, for some reason it eluded me that seccomp would also affect wine's syscalls haha. Turning it off and on would also likely incur a performance cost as well. I guess an experiment could be to replace all IPC with syscalls (possibly through an inline function or macro, so as to allow an IPC fallback without a ton of #ifdefs), so the PE'd process would never actually run any posix functions. It would be interesting to see what the performance implications are. Obviously quite a few components of wine would have to be rewritten to allow for this (shell32 comes to mind). If I have time, I'll try taking a crack at this myself, but I think this will have to be more than just a one person job, as quite a lot of code would have to be rewritten for this. -- 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.

https://bugs.winehq.org/show_bug.cgi?id=48291 --- Comment #45 from Zebediah Figura &lt;z.figura12(a)gmail.com&gt; --- (In reply to qsniyg from comment #44) 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.

https://bugs.winehq.org/show_bug.cgi?id=48291 --- Comment #47 from Zebediah Figura &lt;z.figura12(a)gmail.com&gt; --- (In reply to qsniyg from comment #46) You proposed that the implementation of ntdll be moved to wineserver. That's a separate process; how exactly are you proposing we communicate with it? We currently do so via sockets; that's IPC and requires system calls. (In reply to qsniyg from comment #46) I'm not sure what you're even proposing here. ntdll runs in a given client process, wineserver runs in a different process. One of these has to execute, say, an NtReadFile() call and the underlying read() call that this probably implies. Making the wineserver do that incurs a lot of overhead no matter how it's done—it inheres just from counting the extra context switches and scheduling. -- 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.

https://bugs.winehq.org/show_bug.cgi?id=48291 Leopard &lt;yurnerolinux(a)yandex.com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- CC|yurnerolinux(a)yandex.com | -- 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.

https://bugs.winehq.org/show_bug.cgi?id=48291 --- Comment #50 from qsniyg &lt;qsniyg(a)mail.com&gt; --- (In reply to Zebediah Figura from comment #49) This is why I wrote that it would be an experiment to see the performance impact. However seccomp - unlike ptrace - does not stop the process when it traps a syscall (it will pause the thread calling it obviously, but that's to be expected). Seccomp's performance overhead per-syscall is also apparently quite minimal according to various sources, so I'm not sure if the performance impact would be very significant. There's actually also the possibility that it will be faster, as it doesn't encode/decode anything, neither does it use sockets. If seccomp is disabled, I'm not sure if there's anything that can be done (other than ptrace, which is probably out of the question for performance reasons). That being said, I've been investigating this further, and I don't think it's possible for the moment, because of a few syscalls that must be performed in the client application, such as memory allocation. One possible solution would be to have a ptrace-like extension for seccomp, where the response would include a syscall to execute on the tracee. -- 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.

https://bugs.winehq.org/show_bug.cgi?id=48291 Zebediah Figura &lt;z.figura12(a)gmail.com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Staged patchset| |https://github.com/wine-sta | |ging/wine-staging/tree/mast | |er/patches/ntdll-Syscall_Em | |ulation Component|-unknown |ntdll Summary|Detroit: Become Human |Detroit: Become Human |crashes on launch |crashes on launch (direct | |use of x86_64 SYSCALL | |instruction) Status|UNCONFIRMED |STAGED Ever confirmed|0 |1 Blocks| |48386, 48387 -- 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.

https://bugs.winehq.org/show_bug.cgi?id=48291 Brendan Shanks &lt;bshanks(a)codeweavers.com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bshanks(a)codeweavers.com --- Comment #52 from Brendan Shanks &lt;bshanks(a)codeweavers.com&gt; --- I've been working on supporting Red Dead Redemption 2, and now have a hack-y solution to handle its syscallls using seccomp. RDR2 and the Rockstar Launcher use direct syscalls (with Windows syscall numbers) for some isolated uses. The launcher calls NtCreateFile/NtWriteFile. RDR2 calls NtQueryInformationProcess/NtQuerySystemInformation/NtGetContextThread for anti-debug checks, and sometimes NtCreateFile/NtReadFile/NtClose. Major/minor/build numbers are pulled from the PEB and used to branch to code that sets the right number and does the syscall. I started out by trapping the specific syscall numbers in BPF, and then having the SIGSYS handler decide whether to execute the native syscall or have Wine handle it. This did work for the anti-debug calls, but had numerous problems: - The arguments of some calls make it obvious whether they're meant for Linux or Windows, like R10/ProcessHandle of NtQueryInformationProcess often being -1. Most calls (like the file I/O calls) are not that easy. - Once enabled, seccomp applies to the current thread, any threads that thread creates, and any child processes it spawns. Of course those spawned processes will not have a SIGSYS handler defined, and terminate when they execute a trapped syscall. I'm not sure how common it is for Wine to spawn non-Wine processes (I do remember seeing a recent patch that spawned 'ping'), but it's still not a great thing to break. I even had this problem with Wine itself, server_init_process() calls setsockopt(/NtQuerySystemInformation) and was crashing. My workaround was to call install_bpf() at the top of __wine_process_init(). - Windows system call numbers changing based on the version are problematic with every approach, but especially when they're hardcoded in the BPF program (can't be changed after it's enabled). What I'm using now is to have BPF filter on the instruction pointer, since the game and launcher both load at 0x14000000. It's working well in this case, but clearly a hack. My latest WIP branch is at <https://github.com/mrpippy/wine/tree/rdr2-2> for anyone curious. There's a patch there (and I'll attach here) which adds symbols for Wine's syscall numbers, I think it could belong in the winebuild-Fake_Dlls staging patchset. -- 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.

https://bugs.winehq.org/show_bug.cgi?id=48291 --- Comment #54 from Zebediah Figura &lt;z.figura12(a)gmail.com&gt; --- (In reply to Brendan Shanks from comment #53) I'm not sure this patch makes sense by itself, and I'm not happy about including any of the other patches in Staging. What does deserve examination is how this can be made to work in (upstream) Wine, if indeed it can. Determining whether a syscall comes from PE or Unix code will probably become easier as time goes on and the boundary between PE and Unix becomes clearer. However, will the SIGSYS handler be fast enough, or will it cause a noticeable slowdown? My suspicion is the latter, but that's just armchair analysis. If not, I imagine we're going to need to introduce support in the kernel in order to make this work. -- 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.

https://bugs.winehq.org/show_bug.cgi?id=48291 --- Comment #55 from Brendan Shanks &lt;bshanks(a)codeweavers.com&gt; --- Something that may be useful in the future: I wrote a script to parse j00ru's Windows syscall tables and generate version-specific Windows->Wine syscall number conversion functions. https://github.com/mrpippy/wine/commit/6846ade935a493cf6620630f7c556140ebd2… -- 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.

https://bugs.winehq.org/show_bug.cgi?id=48291 GloriousEggroll(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |GloriousEggroll(a)gmail.com --- Comment #56 from GloriousEggroll(a)gmail.com --- Created attachment 68650 --> https://bugs.winehq.org/attachment.cgi?id=68650 rdr2 5.20 patches (not working) Is there any hope of getting rdr2 working on upstream wine any time soon? I've tried porting over the win7->10 update patches and syscall patches to upstream, but sadly it still fails. Attached is the current patchset I'm applying to 5.21-staging. RDR2.exe just silently runs then fails in the background. -- 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.

https://bugs.winehq.org/show_bug.cgi?id=48291 Ker noa &lt;blue-t(a)web.de&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |blue-t(a)web.de -- 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.

https://bugs.winehq.org/show_bug.cgi?id=48291 --- Comment #58 from Andrey Gusev &lt;andrey.goosev(a)gmail.com&gt; --- RDR 2 with vanilla 8.2-110-g4d0d7e49b9b worked normally. API in game was set to Vulkan by default. -- 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.