April 2021 - Wine-Bugs - list.winehq.org

[Bug 50898] New: Improve performance for RGB lookups into color tables conversion
by WineHQ Bugzilla April 23, 2021

April 23, 2021

https://bugs.winehq.org/show_bug.cgi?id=50898 Bug ID: 50898 Summary: Improve performance for RGB lookups into color tables conversion Product: Wine Version: 6.5 Hardware: x86-64 OS: Linux Status: NEW Severity: enhancement Priority: P2 Component: gdi32 Assignee: wine-bugs(a)winehq.org Reporter: gabrielopcode(a)gmail.com Distribution: --- Created attachment 69710 --> https://bugs.winehq.org/attachment.cgi?id=69710 Generate a lookup cache for RGB into color table conversion This improves the performance of color conversion from RGB to palette significantly by generating a lookup cache for 5-bit-per-color RGB values (centered) into the palette, before doing the conversion, for older applications and games. The comments in the patch should describe the algorithm I came up with for large color tables. Note that Windows also quantizes the lookup to 5-bit-per-color already, so it very likely does something similar (but seems to do more caching based on my tests); we have this quantization in wine's code to match Windows, but we don't take advantage of it, so it's wasted. Generating it by looking through the color table for each entry in the lookup cache wouldn't be a good idea if the color table is large. The lookup cache itself is 32768 entries, which turns out to be the equivalent of a 256x128 image. The current algorithm used by wine works like that already: it goes through each pixel in the image, and for each pixel, it looks up every color in the color table, which is extremely slow. Generating the cache like that would mean images have to be at least 256x128 for it to have any benefit, otherwise it would be a performance regression instead, and that's not very reasonable to expect of older applications, and it wouldn't provide much. So, the table generation algorithm is much more efficient than that for large amount of colors in the table. In my synthetic tests generating 4096 tables with various color tables of 256 colors, it turned out to be at least 4x faster, sometimes even 4.5x depending on color table (even a purely random color table), for example a random table taking about 14406ms instead of 62056ms on my CPU. In fact, the algorithm is not far from being constant in terms of amount of colors in the table, taking only 50% more time from 16 colors to 256. So basically increasing the amount of colors from 16 to 256 doesn't make that much difference, since each color usually fills its own part of the lookup cache, which is not filled again (unless distance is shorter due to quantization, but that's only for one generation anyway). In contrast, going through each color in the table for each entry (the original algorithm) would massively increase the amount of time spent (from less than 10 seconds, up to more than a minute, or 6x slower). For a few benchmark examples: a 256-color table with the algorithm takes about 14000ms to do 4096 iterations on my CPU, a 40-color table takes about 12000ms, so it's only 17% slower with this algorithm. The 40 colors seems to be the cutoff on my CPU where the algorithms start to differ in performance, with the straight one being faster at lower amount of colors, presumably due to better cache locality and branch prediction. A fast and easy way to "see this in action" is to download Winamp, then launch it and right-click on the top, click on the "Nullsoft Winamp..." menu item and then go to the Credits tab. Depending on your CPU you can clearly see the FPS difference and/or CPU usage for one core. (Note that it still has some fps drops, this is normal and happens on Windows as well, even when the CPU core is not maxed out, it's inherent in the app) http://web.archive.org/web/20180902190237/http://winamparchive.org/dl/winam… Further improvements would require caching it somehow between calls, but I believe that requires either more fragile changes to gdi32 code, or semi-hacks to deal with a typical applications' expectations, so this should be a good start for now. -- 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 25265] New: Foobar2000 won't watch folders
by wine-bugs＠winehq.org April 23, 2021

April 23, 2021

http://bugs.winehq.org/show_bug.cgi?id=25265 Summary: Foobar2000 won't watch folders Product: Wine Version: 1.3.7 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: lucisandor(a)gmail.com Foobar2000 is a media player with an automatically updated media library. The library updates correctly when updates are triggered manually, but, under Wine, it does not detect changes in folders. Moreover, Foobar2000 provides for such cases a "polling" function, but that is useless too. The most upsetting is that changes in watched folders are not detected even when they were produced by Fooobar2000, e.g., by using the menu option "move file". If I move a file from one watched folder to another, the media library will not be aware of the changes in any of the two locations. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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 19

[Bug 50894] New: Starting rundll32.exe via sysnative fails
by WineHQ Bugzilla April 23, 2021

April 23, 2021

https://bugs.winehq.org/show_bug.cgi?id=50894 Bug ID: 50894 Summary: Starting rundll32.exe via sysnative fails Product: Wine Version: 6.5 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: rpisl(a)seznam.cz Distribution: --- Starting rundll32 via c:\windows\sysnative\rundll32.exe is broken since Wine 6.5. It worked up to Wine 6.4. wine cmd c:\>cd c:\windows\sysnative c:\windows\sysnative>dir ... files listed properly c:\windows\sysnative>rundll32.exe wine: failed to open L"c:\\windows\\sysnative\\rundll32.exe": c0000135 Can't recognize 'rundll32.exe' as an internal or external command, or batch script. Creating unix symlink from sysnative to system32 in wine prefix is a workaround. -- 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 9

[Bug 49671] New: Supreme Commander demo needs CLSID {bc3e0fc6-2e0d-4c45-bc61-d9c328319bd8} xactengine2_4.dll
by WineHQ Bugzilla April 23, 2021

April 23, 2021

https://bugs.winehq.org/show_bug.cgi?id=49671 Bug ID: 49671 Summary: Supreme Commander demo needs CLSID {bc3e0fc6-2e0d-4c45-bc61-d9c328319bd8} xactengine2_4.dll Product: Wine Version: 5.14 Hardware: x86-64 URL: https://download.cnet.com/Supreme-Commander-demo/3000- 7483_4-10637347.html OS: Linux Status: NEW Keywords: download Severity: minor Priority: P2 Component: xactengine Assignee: wine-bugs(a)winehq.org Reporter: andrey.goosev(a)gmail.com Distribution: --- 0024:err:ole:CoGetClassObject class {bc3e0fc6-2e0d-4c45-bc61-d9c328319bd8} not registered 0024:err:ole:CoGetClassObject no class object {bc3e0fc6-2e0d-4c45-bc61-d9c328319bd8} could be created for context 0x1 wine-5.14-132-g1ec8bf9b73 -- 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 49286] New: Melodyne 5 crashes due to unimplimented WS2_32.dll.GetHostNameW
by WineHQ Bugzilla April 23, 2021

April 23, 2021

https://bugs.winehq.org/show_bug.cgi?id=49286 Bug ID: 49286 Summary: Melodyne 5 crashes due to unimplimented WS2_32.dll.GetHostNameW Product: Wine-staging Version: 5.9 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: ToxicBugzilla(a)outlook.com CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- Created attachment 67291 --> https://bugs.winehq.org/attachment.cgi?id=67291 The backtrace. Installed Melodyne 5 trial (https://services.celemony.com/cgi-bin/WebObjects/LicenseApp.woa/wa/demoRegi…) with mfc42, vcrun6, and vcrun2019 installed in a 64 bit prefix due to Melodyne 5 only working in 64 bit now. (installer will crash without it due to missing dll contained, plus Melodyne 5 needs vcrun2019 from my research) Installer works fine, (b47a56f747bf3a477f2a564ee65eb005d40e6ef7 setup.exe) but launching the resulting Melodyne.exe (e9b21aa11efbbc01d76df17ee4e7a421c2186986 [sha1 of Melodyne.exe could vary due to unique installs on every computer? unsure, but setup.exe should stay the same) itself will give this in the terminal: 002c:fixme:winediag:__wine_start_process Wine Staging 5.8 is a testing version containing experimental patches. 002c:fixme:winediag:__wine_start_process Please mention your exact version when filing bug reports on winehq.org. 00c0:fixme:msvcrt:MSVCRT__stdio_common_vsnwprintf_s options 24 not handled 00c0:fixme:msvcrt:MSVCRT__stdio_common_vsnwprintf_s options 24 not handled 00c0:fixme:msvcrt:MSVCRT__stdio_common_vsprintf_s options 24 not handled 00c0:fixme:msvcrt:MSVCRT__stdio_common_vsprintf_s options 24 not handled 00c0:fixme:msvcrt:MSVCRT__stdio_common_vsprintf_s options 24 not handled 00c0:fixme:msvcrt:MSVCRT__stdio_common_vsprintf_s options 24 not handled 00c0:fixme:msvcrt:MSVCRT__stdio_common_vsprintf_s options 24 not handled 00c0:fixme:msvcrt:MSVCRT__stdio_common_vsprintf_s options 24 not handled 00c0:fixme:ole:CoInitializeSecurity (0000000000000000,-1,0000000000000000,0000000000000000,0,3,0000000000000000,0,0000000000000000) - stub! 00c0:fixme:msvcrt:MSVCRT__stdio_common_vsprintf_s options 24 not handled 00c0:fixme:msvcrt:MSVCRT__stdio_common_vsprintf_s options 24 not handled 00c0:fixme:msvcrt:MSVCRT__stdio_common_vsprintf_s options 24 not handled 00c0:fixme:msvcrt:MSVCRT__stdio_common_vsprintf_s options 24 not handled 00c0:fixme:msvcrt:MSVCRT__stdio_common_vsprintf_s options 24 not handled 00c0:fixme:msvcrt:MSVCRT__stdio_common_vsprintf_s options 24 not handled 00c0:fixme:msvcrt:MSVCRT__stdio_common_vsnprintf_s options 24 not handled 00c0:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION wine: Call from 0x7bc8b9ac to unimplemented function WS2_32.dll.GetHostNameW, aborting wine: Unimplemented function WS2_32.dll.GetHostNameW called at address 000000007BC8B9AC (thread 00c0), starting debugger... Due to being unable to find any mention of it anywhere except for Microsoft's website noting of its addition, this is probably a bug in normal Wine & development as well, but I have yet to test due to time constraints. Also, when opening "show details" in the debugger, "00c8:fixme:dbghelp:elf_search_auxv can't find symbol in module" get spammed in the terminal excessively. (62 times) -- 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 32

[Bug 50946] New: BioShock Remastered crashes after choosing difficulty
by WineHQ Bugzilla April 23, 2021

April 23, 2021

https://bugs.winehq.org/show_bug.cgi?id=50946 Bug ID: 50946 Summary: BioShock Remastered crashes after choosing difficulty Product: Wine Version: 6.5 Hardware: x86-64 OS: Linux Status: NEW Keywords: regression Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: andrey.goosev(a)gmail.com CC: julliard(a)winehq.org Regression SHA1: beff5c56cdb02d614a5159de0e5ce1914c8ebc77 Distribution: --- Unhandled exception: page fault on write access to 0x00000000 in 32-bit code (0x7b03dd45). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7b03dd45 ESP:0041df54 EBP:0041dfb8 EFLAGS:00200212( - -- I -A- - ) EAX:0041df60 EBX:e06d7363 ECX:00000000 EDX:0041df80 ESI:0041fed8 EDI:1172bd40 Stack dump: 0x0041df54: 0041dfe4 0000000c f7c6f4a4 c0000005 0x0041df64: 00000000 00000000 7d7d8cd5 00000002 0x0041df74: 00000001 00000000 00000000 00000000 0x0041df84: 00000000 00000000 00000000 00000000 0x0041df94: 00000000 00000000 00000000 00000000 0x0041dfa4: 00000000 00000000 00000000 0041dfd0 Backtrace: =>0 0x7b03dd45 (0x0041dfb8) 1 0x7d790805 (0x0041dff8) 2 0x10ef86d0 EntryPoint+0xffffffff() in bioshockhd (0x0041fee4) 3 0x10f0c968 EntryPoint+0xffffffff() in bioshockhd (0x0041fef4) 4 0x10f7d9fd in bioshockhd (+0x67d9fc) (0x0041ff40) 5 0x7b64ddc0 in kernel32 (+0x2ddbf) (0x0041ff58) 6 0x7bc77e17 (0x0041ff6c) 7 0x7bc7802a (0x0041ffec) 0x7b03dd45: addl $12,%esp -- 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 3

[Bug 50733] New: MUSICUS!: ending videos play are extremely choppy
by WineHQ Bugzilla April 23, 2021

April 23, 2021

https://bugs.winehq.org/show_bug.cgi?id=50733 Bug ID: 50733 Summary: MUSICUS!: ending videos play are extremely choppy Product: Wine Version: 6.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winegstreamer Assignee: wine-bugs(a)winehq.org Reporter: pernegger(a)gmail.com Distribution: --- When testing if 6.3 fixed #50686 I noticed another performance issue / regression: MUSICUS!'s MPEG1 ending videos are extremely choppy in 6.3. They're not very dynamic in the first place, so it's hard to tell what's wrong, but the audio (ending song) is fine, and the video (lyrics) are more or less in sync, so I'd say lots of frames are getting dropped, but I couldn't swear the whole thing isn't running a tad slow, too. 6.0 is *much* better. If I open the video in VLC directly, it is a bit smoother still, but without a direct comparison I wouldn't have noticed. This is on a Ryzen 7 3900X [Ubuntu 18.04.5]. (Then I remembered that I had this issue on my "laptop", too. That's a Surface Go 2 [Ubuntu 20.04], currently. Only it was *much* worse, totally unwatchable, we're talking a new frame every other second, maybe. I chalked it up to the machine being too slow, but maybe not. It's not just MUSICUS!, either, I retrospect one or two other (older) visual novels showed similar symptoms -- I just assumed the videos were crap at the time. Note that this bug is strictly about MUSICUS!, when that test case is fixed, I'll happily go back and test the other stuff, the tangent is just meant to illustrate that hardware performance may play a role in how noticeable it is.) [#50239 has slightly different symptoms, and most importantly, I'm using MUSICUS!'s 64-bit exe.] The regular terminal output has nothing, please advise on how to get suitable debug logs. -- 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 27

[Bug 50275] New: Copy paste bug in conhost/window.c
by WineHQ Bugzilla April 23, 2021

April 23, 2021

https://bugs.winehq.org/show_bug.cgi?id=50275 Bug ID: 50275 Summary: Copy paste bug in conhost/window.c Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: mikrutrafal(a)protonmail.com Distribution: --- https://github.com/wine-mirror/wine/blob/e909986e6ea5ecd49b2b847f321ad89b2a… console->active->win.right is set twice but console->active->win.up or similar is missing -- 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 2

[Bug 43498] New: Built-in comctl32 doesn't show Send To menu in Winamp
by wine-bugs＠winehq.org April 23, 2021

April 23, 2021

https://bugs.winehq.org/show_bug.cgi?id=43498 Bug ID: 43498 Summary: Built-in comctl32 doesn't show Send To menu in Winamp Product: Wine Version: 2.14 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: comctl32 Assignee: wine-bugs(a)winehq.org Reporter: averageradical(a)gmail.com Distribution: --- For background, please see bug #43486. If I install Winamp (`winetricks winamp`), when right clicking an item in the playlist, there is no "Send To" menu. If I install comctl32 v5 (`winetricks comctl32`), the "Send To" menu exists and works properly; however, the Add File and Add Directory buttons crash Winamp (bug #43486). Would it be possible to fix Wine's built-in comctl32 to support Winamp's "Send To" menu? I can build Wine from source and reproduce the problem(s) easily if anybody needs any trace. Thank you. -- 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 8

[Bug 49840] New: chromium fails to load (--no-sandbox is a workaround)
by WineHQ Bugzilla April 23, 2021

April 23, 2021

https://bugs.winehq.org/show_bug.cgi?id=49840 Bug ID: 49840 Summary: chromium fails to load (--no-sandbox is a workaround) Product: Wine Version: 5.16 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: dark.shadow4(a)web.de Distribution: --- Linking old version of chromium, since the newer versions have issues with d3d as well. Download: https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.h… As noted, the sandbox errors and no page loads. The latest working wine version is wine-staging-5.4. This could either be a syscall issue again, since the patchset was changed a lot during integration into Wine - or maybe it's an unrelated regression. -- 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 24