August 2018 - Wine-Bugs - list.winehq.org

[Bug 33943] Battle.net client dropdowns do not appear until you hover its options

by wine-bugs＠winehq.org

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

Aug. 28, 2018

[Bug 43638] Yermom demoscene demo crashes on start up

by wine-bugs＠winehq.org

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

Aug. 28, 2018

[Bug 43564] Prey Demo texture/lighting issues

by wine-bugs＠winehq.org

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

Aug. 28, 2018

[Bug 45689] Quik 7: Combobox is not populated properly

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=45689 Nikolay Sivov <bunglehead(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |78236592df22e152c6be3b43871 | |a3e1faeb41df0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Nikolay Sivov <bunglehead(a)gmail.com> --- This should be fixed now, 78236592df22e152c6be3b43871a3e1faeb41df0. Please test. -- 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.

Aug. 28, 2018

[Bug 43030] LINE: Window border stays on top of other windows

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=43030 aufa.nabil.amiri(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aufa.nabil.amiri(a)gmail.com --- Comment #9 from aufa.nabil.amiri(a)gmail.com --- problem persist with wine 3.14, using the newest Line version ( 5.9.2.1763 ).. anyway, why is this bug still have unconfirmed status ? -- 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.

Aug. 28, 2018

[Bug 37355] Multiple software protection schemes need ntoskrnl ' MmMapLockedPagesSpecifyCache' implementation (Tages Protection v5.x, BattleEye's 'bedaisy.sys')

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=37355 --- Comment #21 from Richard Yao <ryao(a)gentoo.org> --- To improve on my previous comment, this probably should be implemented as a wine server service. Upon being asked to do it, the requesting “kernel process” could block on recvmsg with the wineserver. Then the wineserver could attach ptrace to the target process and then: 1. Insert the information needed to service the request. 2. Save the registers to a predefined region. 3. Change the instruction pointer to jump into the interrupt handler. Before finally letting the process continue: Then the interrupt handler could do the messy stuff that I described previously, send the file descriptor to the wineserver with sendmsg and resume execution. Now, the wineserver can simply send the file descriptor to the “kernel process”. This makes it easier to handle concurrent usage of this API. Specifically, calls to the API could be serialized would make implementation easier. There would be more to it than this (especially when the function is called to map invalid or already shared memory), but this should be doable as long as the goal is to simulate a “mmap” that lets you map already existent regions of memory that pre-existing regions. Another idea that could also work would be if the wineserver kept file descriptors for all memory regions mapped into child processes. Then when shared memory is desired, it could just call dup on the file descriptor, call lseek on the duplicated file descriptor, send it to the child to mmap and then close the duplicate on its end. The child could close it too after mmap’ing it. This would also require keeping track of where everything is mapped with reference counters, but it would easier to be convinced of correctness and there would be no issue from having to do memcopy() and worry about whether this is on memory already shared across multiple processes. You would have to worry about running out of file-descriptors unless you do a hack where you let child processes hold onto the file descriptors for the wineserver until it needs it to bypass the system limit on the maximum number of file descriptors open by a 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.

Aug. 28, 2018

[Bug 37355] Multiple software protection schemes need ntoskrnl ' MmMapLockedPagesSpecifyCache' implementation (Tages Protection v5.x, BattleEye's 'bedaisy.sys')

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=37355 Richard Yao <ryao(a)gentoo.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ryao(a)gentoo.org --- Comment #20 from Richard Yao <ryao(a)gentoo.org> --- > The problem is that there is no way to properly implement this on Linux > since there is no way to simply map the memory of a different process if you > are not inside the kernel. Since wine is no kernel module it can only use > memory of different processes, when they explicitly create it as shared > memory block. Sadly you can not declare a memory block as shared after it > was allocated, so this does not help implementing this command. Are you sure? The way that I see it, if we can insert code into the other process in advance that we can trigger forassistance, this is doable. 1. Our “kernel” process somehow pings the other process. Then it attaches ptrace, saves the registers and request information to a predetermined place in memory and changes the instruction pointer to jump into an pseudo-interrupt handler. It resumes that process and then blocks on hearing back from the other process. 2. The other process’ pseudo-interrupt handler will create an anonymous file, either by making a file and unlinking it or by using O_TMPFILE. The file will be set to the size of the memory region being mapped via ftruncate(). This is then mapped into the address space using mmap(). The memory in the existing region is then copied. The handler now does mmap() the anonymous file into the correct position while calling unmap() on the previous mapping. Finally, it sends the file descriptor to the “kernel” process (via the wine server, a named pipe, whatever). 3. The “kernel” process the calls mmap() on the file descriptor. We have now mapped the region into the process. I am not well versed in wine’s architecture, but this would achieve shared memory. The caveat being that you are not sharing the existing pages, but making new ones. If multiple processes are sharing the same pages, then we would need help from the wine server in keeping track of who has what mapped where and triggering the interrupt handlers in all processes that are sharing memory that is being mapped somewhere to remap it using a new copy. They also all would need to be paused. This definitively becomes more complicated than that when you consider other corner cases, like what happens if we have a race where multiple “kernel threads” try to do this at the same time, but the general idea ought to work. Also, I said to use an anonymous file rather than POSIX shared memory to avoid having to keep track of the shared memory objects, but I suppose that if the wineserver is tracking things for the case of multiple processes sharing the same memory having this call done on that memory, then it could also keep track of shared memory objects so that processes using them will be told to properly free them should the mapping disappear so that we don’t risk leaking memory with long running processes. -- 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.

Aug. 28, 2018

[Bug 42631] Mouse drift, jump or don' t react to small slow movements in Unity-engine games and Fallout 4 ( partly fixed in Unity games, have walkaround in Fallout4 )

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=42631 --- Comment #55 from tim110011(a)163.com --- Tested 7 Days to Die on wine-staging-3.14 with "Fix sub pixel raw motion v2": It seems mouse movement is fixed. I am using a normal mouse, anyone test this patch with a high dpi mouse? -- 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.

Aug. 28, 2018

[Bug 45372] Resident Evil 7 requires mfplat.dll.MFCreateMFByteStreamOnStream to be implemented

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=45372 --- Comment #4 from Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- I've updated the staging patchset, can you please try again? -- 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.

Aug. 28, 2018

[Bug 45715] Just Dance 2017: Unimplemented function mfplat.dll.MFCreateMemoryBuffer

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=45715 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |leslie_alistair(a)hotmail.com Status|UNCONFIRMED |STAGED Staged patchset| |https://github.com/wine-sta | |ging/wine-staging/tree/mast | |er/patches/mfplat-MFCreateM | |emoryBuffer Ever confirmed|0 |1 -- 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.

Aug. 28, 2018