February 2023 - Wine-bugs - list.winehq.org

[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 53706] New: NtDeviceIoControlFile() is quite slow when called with and invalid handle
by WineHQ Bugzilla 27 Mar '23

27 Mar '23

https://bugs.winehq.org/show_bug.cgi?id=53706 Bug ID: 53706 Summary: NtDeviceIoControlFile() is quite slow when called with and invalid handle Product: Wine Version: 7.17 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: metalcaedes(a)gmail.com Distribution: --- Created attachment 73130 --> https://bugs.winehq.org/attachment.cgi?id=73130 Call DeviceIoControl() with an invalid handle a lot and measure how long it takes I'm running some nonpublic proprietary application that I don't have the source code for in Wine (I attached a simple testprogram though). I noticed severe performance problems (compared with native Windows) and profiling it in perf (is there a better way?) showed a lot of useless memory addresses and also NtDeviceIoControlFile(). I figured out that the application calls DeviceIoControl() *a lot*, and after hooking that function and replacing it with a stub that basically just returns FALSE the application's performance was a lot better (good enough for my purposes). Being the curious type, I added some logging to my stub and realized that the handle that gets passed is 0xFFFFFFFF (INVALID_HANDLE_VALUE) - even on Windows! Specifically, I saw: hDevice: 0xFFFFFFFF code: 0x80010021 inBufSize: 4 outBufSize: 4 overlapped: 0x0 Reimplementing DeviceIoControl() (based on Wine Source) in my (former) stub and adding some time measurements showed that in this specific case (calling it with an invalid handle) the called NtDeviceIoControlFile() often takes around 4 microseconds on Wine (sometimes even over 20!) while it only takes around 0.5 microseconds on Windows 10 (even though that PC is a bit slower). So it takes 8-40 times as long in Wine. Looking into Wine's NtDeviceIoControlFile() implementation, this is probably the case because it calls into wineserver, via `server_ioctl_file()`. So I *think* that this could be relatively easily fixed by checking if the handle is INVALID_HANDLE_VALUE first thing in NtDeviceIoControlFile(), and if that's the case call `SetLastError( ERROR_INVALID_HANDLE );` and `return FALSE;` (Windows returns FALSE and sets that error code). I'm not 100% sure about this though, because I don't know if there are any cases of calling `NtDeviceIoControlFile()` where INVALID_HANDLE_VALUE is OK - if there are, the early-out-check would probably have to take the `code` argument into account (as far as I can tell it specifies the operation that NtDeviceIoControlFile() executes). I attached a simple test program that just calls DeviceIoControl() a lot (with the parameters I've seen in the real program I have issues with) and measures how long that takes. On my Windows machine (i7-4771, Win10) one call takes about 0.48-0.5 microseconds. On my Linux machine (Ryzen 5950X, Kernel 5.15, wine 7.17) one call takes about 4 microseconds on average, though many calls took longer. -- 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 53821] New: winbase.h: ReOpenFile declaration missing (and not available in any other header)
by WineHQ Bugzilla 27 Mar '23

27 Mar '23

https://bugs.winehq.org/show_bug.cgi?id=53821 Bug ID: 53821 Summary: winbase.h: ReOpenFile declaration missing (and not available in any other header) Product: Wine Version: 7.19 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: contact(a)ivanchev.net Distribution: --- A declaration for ReOpenFile should be imported with winbase.h (https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-reop…) but is currently missing. In fact, no header in Wine declares that function. -- 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 53832] New: wbemprox: where-clause seems to be case-sensitive
by WineHQ Bugzilla 27 Mar '23

27 Mar '23

https://bugs.winehq.org/show_bug.cgi?id=53832 Bug ID: 53832 Summary: wbemprox: where-clause seems to be case-sensitive Product: Wine Version: 7.19 Hardware: x86-64 URL: https://github.com/PowerShell/PowerShell/releases/down load/v7.0.3/PowerShell-7.0.3-win-x64.msi OS: Linux Status: NEW Keywords: dotnet, download Severity: normal Priority: P2 Component: wmi&wbemprox Assignee: wine-bugs(a)winehq.org Reporter: xerox.xerox2000x(a)gmail.com Distribution: Debian Created attachment 73364 --> https://bugs.winehq.org/attachment.cgi?id=73364 script to reproduce the problem prerequisite: winetricks dotnet48 The attached script shows the problem: on windows one can either use 'c:' or 'C:' in the following query: $searcher = [wmisearcher]'Select freespace From win32_logicaldisk where deviceid="c:"' $searcher.scope.path = "\\.\root\cimv2" $searcher.get() On wine only the upper-case 'C:' yields any results. Steps to reproduce: download attached script and do 'wine pwsh -f aaa.ps1' Results on wine: Lower case c: gives: Upper case c: gives: __GENUS : 2 __CLASS : Win32_LogicalDisk __RELPATH : __PROPERTY_COUNT : 1 __DERIVATION : {} __SERVER : __NAMESPACE : __PATH : FreeSpace : 5817585664 PSComputerName : Results on windows: Z:\> .\aaa.ps1 Lower case c: gives: __GENUS : 2 __CLASS : Win32_LogicalDisk __SUPERCLASS : __DYNASTY : __RELPATH : __PROPERTY_COUNT : 1 __DERIVATION : {} __SERVER : __NAMESPACE : __PATH : FreeSpace : 23573446656 PSComputerName : Upper case c: gives: __GENUS : 2 __CLASS : Win32_LogicalDisk __SUPERCLASS : __DYNASTY : __RELPATH : __PROPERTY_COUNT : 1 __DERIVATION : {} __SERVER : __NAMESPACE : __PATH : FreeSpace : 23573446656 PSComputerName : -- 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

[Bug 49285] New: PNotesPortable crashes inside kernel32
by WineHQ Bugzilla 27 Mar '23

27 Mar '23

https://bugs.winehq.org/show_bug.cgi?id=49285 Bug ID: 49285 Summary: PNotesPortable crashes inside kernel32 Product: Wine Version: 5.9 Hardware: x86 URL: https://download3.portableapps.com/portableapps/PNotes Portable/PNotesPortable_9.3.0.paf.exe?20190321 OS: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: xerox.xerox2000x(a)gmail.com Distribution: Debian Yet another one: Hi, a user tested some portable apps on forum: https://forum.winehq.org/viewtopic.php?f=2&t=33957 When you right-click on the taskbar icon, and then choose "Exit" it crashes. 00c4:Call KERNEL32.WritePrivateProfileStructW(00494d5c L"hotkeys",0031c6f4 L"10001",00000000,00000040,004f0310 L"Z:\\media\\louis\\aqqa\\PNotesPortable\\Data\\settings\\Note s.ini") ret=0043456f 00c4:trace:seh:raise_exception code=c0000005 flags=0 addr=0x7b64e9f5 ip=7b64e9f5 tid=00c4 -->crash So looks like it crashes inside WritePrivateProfileStructW ?? sha1sum PNotesPortable_9.3.0.paf.exe 2df27f55e3b43c889a5e7c68684e8acbaef9498f PNotesPortable_9.3.0.paf.exe -- 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 47375] New: Photoshop C 2018 crashes on unimplemented function msvcr120.dll.? _Schedule@_StructuredTaskCollection@details@Concurrency@@QEAAXPEAV_UnrealizedChore@23@@Z
by wine-bugs＠winehq.org 27 Mar '23

27 Mar '23

https://bugs.winehq.org/show_bug.cgi?id=47375 Bug ID: 47375 Summary: Photoshop C 2018 crashes on unimplemented function msvcr120.dll.?_Schedule(a)_StructuredTaskCollection@deta ils(a)Concurrency@@QEAAXPEAV_UnrealizedChore(a)23@@Z Product: Wine Version: 4.10 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msvcrt Assignee: wine-bugs(a)winehq.org Reporter: winepala(a)tradermail.info Distribution: --- Created attachment 64711 --> https://bugs.winehq.org/attachment.cgi?id=64711 wine output Photoshop CC 2018 crashes on an unimplemented function after using the Color Range tool to make a selection. wine: Call from 0x7b4560f6 to unimplemented function msvcr120.dll.?_Schedule(a)_StructuredTaskCollection@details(a)Concurrency@@QEAAXPEAV_UnrealizedChore(a)23@@Z, aborting -- 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 11

[Bug 50948] New: taskmgr show wrong memory usage unit (GB => MB)
by WineHQ Bugzilla 27 Mar '23

27 Mar '23

https://bugs.winehq.org/show_bug.cgi?id=50948 Bug ID: 50948 Summary: taskmgr show wrong memory usage unit (GB => MB) Product: Wine Version: 6.5 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: limstash.w(a)gmail.com Distribution: --- Created attachment 69771 --> https://bugs.winehq.org/attachment.cgi?id=69771 Screenshot Task manage performance page show wrong memory usage unit, should be GB instead of MB. Step to reproduce: 1. wine taskmgr 2. switch to the performance page $ wine --version wine-6.5 -- 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 13