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 Leopard <yurnerolinux(a)yandex.com> 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.

Dec. 31, 2019

[Bug 48291] Detroit: Become Human crashes on launch

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=48291 --- Comment #48 from qsniyg <qsniyg(a)mail.com> --- (In reply to Zebediah Figura from comment #47) > 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. If seccomp is used, ntdll uses syscalls, as (afaics) that's how windows works: https://j00ru.vexillium.org/syscalls/nt/64/ . IPC isn't used. If seccomp is not used, IPC is used, and it doesn't matter that it uses linux syscalls because syscalls aren't being trapped :) > 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. Sorry, I'm not very good at explaining, so let me use code instead. For the example you gave, let's say at user_kernel_shared/file.c, there's this function: NTSTATUS Internal_NtReadFile(Internal_HANDLE ihandle, ...) { ... fread(buffer, 1, length, get_fp_from_ihandle(ihandle)); ... return STATUS_SUCCESS; } Then in wineserver: void handle_NtReadFile_syscall(struct seccomp_data data, struct seccomp_notif_resp* resp) { ... Internal_HANDLE ihandle = get_ihandle_from_handle(data.args[0]); resp->val = Internal_NtReadFile(ihandle, ...); ... } And ntdll: NTSTATUS WINAPI NtReadFile(HANDLE hFile, ...) { if (use_syscalls) { // perform syscall } else { return Internal_NtReadFile(get_ihandle_from_handle(hFile), ...); } } Obviously this is all pseudocode, but that would be the general idea. In some cases, less code would be able to be shared (e.g. when IPC would be needed, as that code would only apply to ntdll), but it would help reduce some code duplication. -- 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 #47 from Zebediah Figura <z.figura12(a)gmail.com> --- (In reply to qsniyg from comment #46) > (In reply to Zebediah Figura from comment #45) > > You'd need to do IPC without syscalls, which strikes me as pretty much > > impossible. > > Unless you're speaking about another part of wine, IPC would only be used if > seccomp cannot be used, which means it shouldn't matter if it uses syscalls > or not. The existing implementation could theoretically even be kept, if > duplication of code doesn't matter. 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) > (In reply to Zebediah Figura from comment #45) > > 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. > > That's a good point. In _theory_ (part of) the implementation for syscalls > could reside somewhere else in the wine source code, and both wineserver and > the userspace dlls could access it, so it wouldn't change anything > performance-wise if using IPC. This would obviously increase the complexity > of both the userspace dlls and wineserver, but I guess it could be a > compromise, if it could be properly pulled off. 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.

Dec. 31, 2019

[Bug 48291] Detroit: Become Human crashes on launch

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=48291 --- Comment #46 from qsniyg <qsniyg(a)mail.com> --- (In reply to Zebediah Figura from comment #45) > You'd need to do IPC without syscalls, which strikes me as pretty much > impossible. Unless you're speaking about another part of wine, IPC would only be used if seccomp cannot be used, which means it shouldn't matter if it uses syscalls or not. The existing implementation could theoretically even be kept, if duplication of code doesn't matter. > 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. That's a good point. In _theory_ (part of) the implementation for syscalls could reside somewhere else in the wine source code, and both wineserver and the userspace dlls could access it, so it wouldn't change anything performance-wise if using IPC. This would obviously increase the complexity of both the userspace dlls and wineserver, but I guess it could be a compromise, if it could be properly pulled off. -- 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 18490] Multiple games fail to set pixel format on D3D device context created on desktop window (Empire: Total War, Napoleon: Total War, Utopia City)

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=18490 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |qsniyg(a)mail.com --- Comment #63 from Zebediah Figura <z.figura12(a)gmail.com> --- *** Bug 46774 has been marked as a duplicate of this bug. *** -- 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 46774] DDS compression tools crash, possibly due to creating a DirectX context without a window

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=46774 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE CC| |z.figura12(a)gmail.com Status|UNCONFIRMED |RESOLVED --- Comment #4 from Zebediah Figura <z.figura12(a)gmail.com> --- Based on the attached patch, this is a duplicate of already fixed bug 18490. *** This bug has been marked as a duplicate of bug 18490 *** -- 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 #45 from Zebediah Figura <z.figura12(a)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.

Dec. 31, 2019

[Bug 40779] PDF Eraser 1.5 (.NET 4.0 app): Paste of license data from clipboard fails with Wine-Mono

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=40779 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |focht(a)gmx.net Summary|Error in Copy/Past to |PDF Eraser 1.5 (.NET 4.0 |Registration bar of PDF |app): Paste of license data |Eraser |from clipboard fails with | |Wine-Mono Keywords|obfuscation | --- Comment #13 from Anastasius Focht <focht(a)gmx.net> --- Hello Vincent, the original .NET app from the Internet archive snapshot isn't obfuscated. Removing keyword and refining summary to mention the app version and Wine-Mono. --- snip --- // Assembly PDFEraser, Version=1.5.0.4, Culture=neutral, PublicKeyToken=null // MVID: EAAFA3CC-D975-44C6-AD37-E6562A0E3D3D // Assembly references: // mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 // System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 // System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 // System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a // itextsharp, Version=4.1.2.0, Culture=neutral, PublicKeyToken=8354ae6d2174ddca // Module references: // PDFtoXPD.dll // PDFtoX.dll [assembly: CompilationRelaxations(8)] [assembly: RuntimeCompatibility(WrapNonExceptionThrows = true)] [assembly: Debuggable(DebuggableAttribute.DebuggingModes.Default | DebuggableAttribute.DebuggingModes.DisableOptimizations | DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints | DebuggableAttribute.DebuggingModes.EnableEditAndContinue)] [assembly: AssemblyTitle("PDF Eraser")] [assembly: AssemblyDescription("Erase Content from PDF")] [assembly: AssemblyConfiguration("")] [assembly: AssemblyCompany("PDF Eraser")] [assembly: AssemblyProduct("PDF Eraser")] [assembly: AssemblyCopyright("Copyright @ PDFEraser.net")] [assembly: AssemblyTrademark("PDF Eraser")] [assembly: ComVisible(false)] [assembly: Guid("0e71f314-420c-4e64-bcf8-7c840aca210f")] [assembly: AssemblyFileVersion("1.5.0.4")] [assembly: TargetFramework(".NETFramework,Version=v4.0", FrameworkDisplayName = ".NET Framework 4")] [assembly: AssemblyVersion("1.5.0.4")] --- snip --- Regards -- 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 #44 from qsniyg <qsniyg(a)mail.com> --- 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? -- 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/ |https://web.archive.org/web | |/20160405113259/https://www | |.pdferaser.net/down/pdferas | |er.exe Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #12 from Vincent Povirk <madewokherd(a)gmail.com> --- Looks like my troubles were caused by a bug in master, fixed it here: https://github.com/madewokherd/winforms/commit/b386ad7ca14c6eecdb6d731bcf42… Pasting into registration box works, resolving fixed. -- 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