December 2019 - Wine-Bugs - list.winehq.org

[Bug 48291] Detroit: Become Human crashes on launch

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=48291 --- Comment #43 from qsniyg <qsniyg(a)mail.com> --- (In reply to Zebediah Figura from comment #42) > Partly as stated above Ah my apologies, for some reason I forgot to ctrl+f before asking haha > 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. 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.

Dec. 31, 2019

[Bug 40779] Error in Copy/Past to Registration bar of PDF Eraser

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=40779 --- Comment #11 from Vincent Povirk <madewokherd(a)gmail.com> --- It may be possible to test the original bug with an archived version, like this one: https://web.archive.org/web/20160405113259/https://www.pdferaser.net/down/p… I haven't gotten very far with it, but at least it doesn't fail in the same way. -- 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.

Dec. 31, 2019

[Bug 40779] Error in Copy/Past to Registration bar of PDF Eraser

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=40779 --- Comment #10 from Vincent Povirk <madewokherd(a)gmail.com> --- I don't think we can run the current version. It seems to have trouble with this method: converting method string W9sL8qMZ2gvL5ALRQZ.ECXxAIAI190mcxNI82:A2fd5lmlNX (int) * Assertion at /home/meh/work/wine-mono/mono/mono/metadata/metadata.c:1081, condition `index < meta->heap_blob.size' not met Looking at it more closely, the method is obfuscated by using a switch instruction to branch between parts of the IL. It also violates an important rule of IL code: For each IL instruction, the stack should be the same depth regardless of the path taken to reach that instruction. There are obvious loops involving the switch instruction where the stack depth would be changed. I don't think it's possible for Mono's JIT to execute code like this given the approach it currently takes. It might be possible for an interpreter, but I don't think it's possible to use the interpreter in Mono selectively, or to run Windows programs in a fully interpreted mode. -- 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.

Dec. 31, 2019

[Bug 40779] Error in Copy/Past to Registration bar of PDF Eraser

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=40779 Vincent Povirk <madewokherd(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- URL| |http://www.pdferaser.net/ Keywords| |download, obfuscation -- 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.

Dec. 31, 2019

[Bug 48291] Detroit: Become Human crashes on launch

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=48291 --- Comment #42 from Zebediah Figura <z.figura12(a)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.

Dec. 31, 2019

[Bug 48291] Detroit: Become Human crashes on launch

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=48291 qsniyg <qsniyg(a)mail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |qsniyg(a)mail.com --- Comment #41 from qsniyg <qsniyg(a)mail.com> --- (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. >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. -- 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.

Dec. 31, 2019

[Bug 40779] Error in Copy/Past to Registration bar of PDF Eraser

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=40779 --- Comment #9 from Vincent Povirk <madewokherd(a)gmail.com> --- In my own testing it fails with: Unknown heap type: #GUlD Unknown heap type: #Blop * Assertion at /home/meh/work/wine-mono/mono/mono/metadata/metadata.c:1081, condition `index < meta->heap_blob.size' not met I'm guessing Mono is having trouble reading the heap tables from the exe. Not sure why this might've worked before. It could have been a change to pdferaser. -- 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.

Dec. 31, 2019

[Bug 40779] Error in Copy/Past to Registration bar of PDF Eraser

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=40779 --- Comment #8 from Vincent Povirk <madewokherd(a)gmail.com> --- ClipboardAvailableFormats was an internal function used by Mono's winforms implementation. We're now using .NET Core winforms which does this differently, so a retest would be worthwhile. -- 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.

Dec. 31, 2019

[Bug 47872] gdiplus:font fails in Japanese locale on Windows 10

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=47872 --- Comment #5 from Vincent Povirk <madewokherd(a)gmail.com> --- Can someone with a failing setup test this patch? https://testbot.winehq.org/JobDetails.pl?Key=62692 (The patch or test .exe can be downloaded from links in the "File name" column.) -- 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.

Dec. 31, 2019

[Bug 21017] Adobe Premiere Pro CS4 won't start

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=21017 --- Comment #39 from Luke Short <ekultails(a)gmail.com> --- I am still encountering the same issues mentioned previously using Wine 5.0rc2. Wine 3.8 was the last version where we were able to get this to 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.

Dec. 31, 2019