June 2022 - Wine-bugs - list.winehq.org

[Bug 52972] New: wineusb.sys: add_usb_device erroneously releases critical section on failure path
by WineHQ Bugzilla 27 Mar '23

27 Mar '23

https://bugs.winehq.org/show_bug.cgi?id=52972 Bug ID: 52972 Summary: wineusb.sys: add_usb_device erroneously releases critical section on failure path Product: Wine Version: 7.8 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: usb Assignee: wine-bugs(a)winehq.org Reporter: jinoh.kang.kr(a)gmail.com CC: z.figura12(a)gmail.com Distribution: --- In wineusb.sys, add_usb_device() erroneously calls "LeaveCriticalSection(&wineusb_cb);" without first having entered the critical section. -- 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.

1 4

[Bug 53051] New: Kvaser software crashes on unimplemented function ntoskrnl.exe.ExNotifyCallback
by WineHQ Bugzilla 27 Mar '23

27 Mar '23

https://bugs.winehq.org/show_bug.cgi?id=53051 Bug ID: 53051 Summary: Kvaser software crashes on unimplemented function ntoskrnl.exe.ExNotifyCallback Product: Wine Version: 7.9 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: ntoskrnl Assignee: wine-bugs(a)winehq.org Reporter: alexhenrie24(a)gmail.com Distribution: --- Created attachment 72447 --> https://bugs.winehq.org/attachment.cgi?id=72447 Console output Steps to reproduce: 1. Install Kvaser Drivers for Windows 2. Run `wine 'C:\Program Files\Kvaser\Drivers\kcanconf.exe'` A crash dialog appears, but after closing it the Kvaser Device Guide does open. $ sha256sum kvaser_drivers_setup.exe 7519aa9b919ab88a830b2818e03d1311fbc2a0ed569722b0e7170fa5ef11839d -- 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.

1 6

[Bug 48600] New: Bloomberg Terminal - crashes post installation, cannot run
by WineHQ Bugzilla 27 Mar '23

27 Mar '23

https://bugs.winehq.org/show_bug.cgi?id=48600 Bug ID: 48600 Summary: Bloomberg Terminal - crashes post installation, cannot run Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: fusion Assignee: wine-bugs(a)winehq.org Reporter: knez(a)mailbox.org Distribution: --- Created attachment 66437 --> https://bugs.winehq.org/attachment.cgi?id=66437 Bloomberg terminal - crashes post installation Bloomberg Terminal - Client Software for Windows. Download location: https://www.bloomberg.com/professional/support/software-updates/ (https://bdn-ak-ssl.bloomberg.com/software/trv/sotrtLite01072020.exe) Bloomberg Terminal – New Installation (Terminal Software Only). OS: Ubuntu 16.04. Bloomberg terminal is a Windows-only financial professional software. The installation was run under Wine and no problems are reported. On execution of the installed file "wintrv.exe" the attached error appears. Further use of the software fails. -- 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.

1 6

[Bug 40444] New: Find doesn't jump to a found item in WinSCP
by wine-bugs＠winehq.org 27 Mar '23

27 Mar '23

https://bugs.winehq.org/show_bug.cgi?id=40444 Bug ID: 40444 Summary: Find doesn't jump to a found item in WinSCP Product: Wine Version: 1.9.7 Hardware: x86 URL: http://winscp.net/download/winscp577.zip OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: t.artem(a)mailcity.com Distribution: Red Hat This bug is very easy to reproduce. Run WinSCP and open a session to any host. Open any long enough file (text/html/whatever), hit Find (Ctrl + F) and try to find something at least on the second page of the open document. The cursor will jump, however the screen will remain on the first page. In order to really jump to this position, you have to close the Find dialog (e.g. hit "Escape") and press "Up" and "Down" which is terribly inconvenient. -- 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.

2 26

[Bug 52975] New: VTFEdit fails to start: err:module:LdrInitializeThunk "MSVCP80.dll" failed to initialize, aborting
by WineHQ Bugzilla 27 Mar '23

27 Mar '23

https://bugs.winehq.org/show_bug.cgi?id=52975 Bug ID: 52975 Summary: VTFEdit fails to start: err:module:LdrInitializeThunk "MSVCP80.dll" failed to initialize, aborting Product: Wine Version: 7.8 Hardware: x86-64 URL: https://web.archive.org/web/20191223154323/http://neme sis.thewavelength.net/files/files/vtfedit133.exe OS: Linux Status: NEW Keywords: download, patch Severity: normal Priority: P2 Component: msvcrt Assignee: wine-bugs(a)winehq.org Reporter: xerox.xerox2000x(a)gmail.com Distribution: --- Created attachment 72344 --> https://bugs.winehq.org/attachment.cgi?id=72344 patch Hi, someone reported on userforum troubles with this program: https://forum.winehq.org/viewtopic.php?f=2&t=36504 (The program is apparently from https://nemstools.github.io/pages/VTFLib-Download.html and already archived on Web archive) Fails to start: 0184:err:module:LdrInitializeThunk "MSVCP80.dll" failed to initialize, aborting Attached patch that fixes the 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.

1 4

[Bug 53003] New: XM6 TypeG: some MIDI note-on messages aren't sent to MIDI devices (MIDI running status isn't supported in the MIDI mapper)
by WineHQ Bugzilla 27 Mar '23

27 Mar '23

https://bugs.winehq.org/show_bug.cgi?id=53003 Bug ID: 53003 Summary: XM6 TypeG: some MIDI note-on messages aren't sent to MIDI devices (MIDI running status isn't supported in the MIDI mapper) Product: Wine Version: 7.8 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winmm&mci Assignee: wine-bugs(a)winehq.org Reporter: sagawa.aki+winebugs(a)gmail.com Distribution: Ubuntu Created attachment 72371 --> https://bugs.winehq.org/attachment.cgi?id=72371 minimal reproducible example XM6 TypeG[1] is a SHARP X68000 Emulator. When I use STed2[2] inside XM6 TypeG, some MIDI note-on messages aren't sent to MIDI devices (e.g. Timidity++). @honda_ken, an original reporter on Twitter, tweeted XM6 TypeG sounds strange on Wine. He also informed me that Wine outputs the following message on his console: 0338:fixme:midi:modData ooch 3c 0338:fixme:midi:modData ooch 403e 0338:fixme:midi:modData ooch 3e 0338:fixme:midi:modData ooch 4040 0338:fixme:midi:modData ooch 40 0338:fixme:midi:modData ooch 4041 0338:fixme:midi:modData ooch 41 0338:fixme:midi:modData ooch 4043 0338:fixme:midi:modData ooch 43 I setup XM6 TypeG environment on my PC and I can reproduce the issue. Preparing the environment is a bit difficult, I wrote a minimal reproducible example (shortmsg.c). Steps to reproduce: 1. Compile the source code. % i686-w64-mingw32-gcc -o shortmsg.exe shortmsg.c -lwinmm 2. Setup your favorite MIDI device, e.g. Timidity++. % timidity -iA & 3. Run the executable (argument -1 means we use the MIDI mapper). % wine shortmsg.exe -1 Expected result: We can hear the piano voice, C, D, E and F. Actual result: We can hear the piano voice, only C. [1] http://retropc.net/pi/xm6/index.html [2] http://retropc.net/x68000/software/sound/rc/sted2/ -- 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.

1 7

[Bug 52841] New: leverless arcade controller SOCD cleaning regression
by WineHQ Bugzilla 27 Mar '23

27 Mar '23

https://bugs.winehq.org/show_bug.cgi?id=52841 Bug ID: 52841 Summary: leverless arcade controller SOCD cleaning regression Product: Wine Version: 7.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: namtsui(a)gmail.com Distribution: --- Created attachment 72236 --> https://bugs.winehq.org/attachment.cgi?id=72236 fix downstream bug: https://github.com/ValveSoftware/Proton/issues/5527 There is a regression in wine SDL. I tested wine 7.0 using Linux 5.17.2. I think this is the commit to blame: https://github.com/wine-mirror/wine/commit/9cf1e8353cf05af1009e3e5d40b62f0e… See the file: wine-7.0/dlls/winebus.sys/bus_sdl.c https://github.com/wine-mirror/wine/blob/6d4ec1255acceec7152ed98764ee29991a… Leverless arcade controllers have all-buttons. One such controller is the hitbox controller from the company hitbox. It has four directional buttons mapped to DPAD. It has simultaneous opposite cardinal direction (SOCD) cleaning. If you hold down + up, it should output up. If you hold left + right, it should output nothing at all (neutral). I added print statements. See the attached fix. In clip 1, I demonstrate SDL2 events when down and up are held simultaneously during a jump for a while: hold down (DOWN press event) hold up (DOWN release event. UP press event.) hold both for a while release all (UP release event. DOWN release event.) [1] https://clips.twitch.tv/PlausibleSparklingButterJonCarnage-1nJQjUmS_kATb5Y6 In clip 2 the actual bug is shown. hold down (DOWN press event) press up (DOWN release event. UP press event.) steps 1 to 2 were demonstrated in clip 1. release up (DOWN press event. UP release event.) keep holding down [2] https://clips.twitch.tv/FunnyPlayfulClintmullinsArgieB8-p3pUOVQuS-eA8oqi The UP release event at the end in step 3 causes the axis to be reset to 0. This ignores the DOWN press event immediately preceding it. Clip 3 shows after the proposed fix is applied. [3] https://clips.twitch.tv/RacyNeighborlyCookiePeteZaroll-2wwLnflwjAa3ZlFz -- 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.

1 10

[Bug 52686] New: DateAdd not implemented
by WineHQ Bugzilla 27 Mar '23

27 Mar '23

https://bugs.winehq.org/show_bug.cgi?id=52686 Bug ID: 52686 Summary: DateAdd not implemented Product: Wine Version: 5.0 Hardware: x86-64 OS: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: vbscript Assignee: wine-bugs(a)winehq.org Reporter: sergey.bychkow(a)gmail.com Created attachment 72024 --> https://bugs.winehq.org/attachment.cgi?id=72024 Sample script A call to DateAdd function breaks VBScript. Sample (testdateadd.vbs): 1> aDateFrom = Now 2> MsgBox "Now: " & aDateFrom 3> aDateFrom = DateAdd("h", 1, aDateFrom) 4> MsgBox "+1h: " & aDateFrom $ wine wscript testdateadd.vbs Line 2 shows MsgBox, but line 4 does not execute. Errors (error.log): 0009:fixme:variant:get_date_format ignoring flags 10 0009:fixme:vbscript:Global_DateAdd 0009:fixme:wscript:ActiveScriptSite_OnScriptError () -- 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.

1 6

[Bug 52534] New: ListView: multi select never sends LVN_ODSTATECHANGED
by WineHQ Bugzilla 27 Mar '23

27 Mar '23

https://bugs.winehq.org/show_bug.cgi?id=52534 Bug ID: 52534 Summary: ListView: multi select never sends LVN_ODSTATECHANGED Product: Wine Version: 7.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: comctl32 Assignee: wine-bugs(a)winehq.org Reporter: winehq-bugs(a)angelohaller.com Distribution: --- When using a ListView in virtual mode (LVS_OWNERDATA) and selecting multiple rows (holding down shift and selecting) the message code LVN_ODSTATECHANGED is never sent. Looking through the wine source, there is definitely code present sending LVN_ODSTATECHANGED, this however never reaches the application and hence is a bug. Running the same application in Windows 7 will however send the LVN_ODSTATECHANGED code. This seems to be true for ALL programs using LVS_OWNERDATA and supporting multi select. This is an issue that arose working on https://github.com/libui-ng/libui-ng/pull/73 A nicer example to reproduce would be from the `Windows classic samples`. I forked the official Microsoft repo to add some debug printing: 1. Clone https://github.com/szanni/Windows-classic-samples 2. Change to directory Samples/Win7Samples/winui/controls/common/vlistvw 3. Build VListVw (I cross compile via `x86_64-w64-mingw32-gcc VListVw.c -lcomctl32` but using the vcproj should work too?) or use the test binary a.exe (linked at the bottom) 4. Run the resulting .exe 5. Select a cell (should print `LVN_ITEMCHANGED`) 6. Hold down `shift` and select a cell a few rows down below. On Windows 7 step 6. triggers the message `LVN_ODSTATECHANGED` to be emitted (as can be seen in the debug print statements). wine however never sends this message. This is contrary to the documentation provided in https://docs.microsoft.com/en-us/windows/win32/controls/lvn-itemchanged#rem… and behavior developers rely on. Test binary: https://github.com/szanni/Windows-classic-samples/blob/main/Samples/Win7Sam… -- 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.

1 8

[Bug 53005] New: quartz:systemclock Fails after timeGetTime() wraps
by WineHQ Bugzilla 27 Mar '23

27 Mar '23

https://bugs.winehq.org/show_bug.cgi?id=53005 Bug ID: 53005 Summary: quartz:systemclock Fails after timeGetTime() wraps Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: quartz Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- Created attachment 72373 --> https://bugs.winehq.org/attachment.cgi?id=72373 Use GetTickCount64() instead of timeGetTime() in quartz:systemclock quartz:systemclock fails on fg-deb64: systemclock.c:186: Test failed: Got timestamps 43062836670000, 113163710000, 43062836670000. https://test.winehq.org/data/patterns.html#quartz:systemclock The issue is that timeGetTime() wrapped after 49.71 days (2^32 milliseconds) of uptime, causing it to no longer match the values returned by IReferenceClock_GetTime(). The test started using timeGetTime() in the commit below: commit bf5b35f19b841e6352c32ca7c6671d9172636871 Author: Zebediah Figura <zfigura(a)codeweavers.com> AuthorDate: Thu Oct 21 12:41:11 2021 -0500 quartz: Use the performance counter for the system clock. Native probably uses timeGetTime() as a source. That doesn't actually match the performance counter on Windows, but it does on Wine, and accessing the counter directly is slightly more efficient anyway. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51684 Signed-off-by: Zebediah Figura <zfigura(a)codeweavers.com> Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> The commit made two changes: GetTickCount*() -> timeGetTime() in the test GetTickCount64() -> QueryPerformanceCounter() in SystemClockImpl_GetTime() Before this commit the test was failing on Windows because the GetTickCount*() values and SystemClockImpl_GetTime() were a bit out of sync. So while switching to GetTickCount64() in the test fixes the issue in Wine and does not seem to cause failures on Windows it's not clear that this is correct either. It would also be nice to see what happens to this test on Windows after 49.7 days of uptime. -- 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.

1 6