March 2021 - Wine-bugs - list.winehq.org

[Bug 28995] New: Unable to use named pipes with ">" character in the name
by wine-bugs＠winehq.org 24 Apr '21

24 Apr '21

http://bugs.winehq.org/show_bug.cgi?id=28995 Bug #: 28995 Summary: Unable to use named pipes with ">" character in the name Product: Wine Version: 1.3.32 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: valentyn.pavliuchenko(a)gmail.com Classification: Unclassified I have an app (Avid VENUE software) that uses pipes to work. The app fails to launch because of pipe name contains a character ">". MSDN says: The pipename part of the name can include any character other than a backslash, including numbers and special characters. The entire pipe name string can be up to 256 characters long. Pipe names are not case sensitive. App logs show the following: 23.957 CreateFile error '\\.\PIPE\D-Show Pipe GUI->DM': Invalid name. Changing ">" to "_" by direct editing executable files makes problem disappear. -- 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 18

[Bug 44755] New: reg.exe: does not provide /reg: 64 switch in 64-bit wineprefix
by wine-bugs＠winehq.org 24 Apr '21

24 Apr '21

https://bugs.winehq.org/show_bug.cgi?id=44755 Bug ID: 44755 Summary: reg.exe: does not provide /reg:64 switch in 64-bit wineprefix Product: Wine Version: 3.4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: registry Assignee: wine-bugs(a)winehq.org Reporter: wine(a)marco-rebhan.de Distribution: --- In a 64-bit prefix, the reg.exe command line switches /reg:32 and /reg:64 should be available to enable/disable registry redirection. A command like `wine reg import /reg:64 test.reg` should be perfectly valid, to prevent the imported keys from going somewhere in Wow6432Node, but instead it gives the following error: reg: Invalid syntax. Type "REG IMPORT /?" for help. As far as I could figure out, there is no workaround other than manually importing the keys in the regedit GUI (calling regedit from the command line with the registry file as an argument doesn't work), which makes importing keys correctly not automatable. Using wine-3.4 staging -- 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 17823] New: A crash when installing Rhino 4.0 trial version
by wine-bugs＠winehq.org 24 Apr '21

24 Apr '21

http://bugs.winehq.org/show_bug.cgi?id=17823 Summary: A crash when installing Rhino 4.0 trial version Product: Wine Version: 1.1.17 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P3 Component: msi AssignedTo: wine-bugs(a)winehq.org ReportedBy: andrej(a)podzimek.org Created an attachment (id=20083) --> (http://bugs.winehq.org/attachment.cgi?id=20083) Output from the installer When installing a trial version of Rhino 4.0 obtained from here http://download.rhino3d.com/eval/?p=25, the installer reports successful completion. However, the terminal output shows a crash. Presumably, Rhino crashes when run after the installation. A small part of the GUI is displayed, but remains unresponsive. A dialog window for error-reporting pops up. -- 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 44

[Bug 25265] New: Foobar2000 won't watch folders
by wine-bugs＠winehq.org 24 Apr '21

24 Apr '21

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 50898] New: Improve performance for RGB lookups into color tables conversion
by WineHQ Bugzilla 24 Apr '21

24 Apr '21

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 50894] New: Starting rundll32.exe via sysnative fails
by WineHQ Bugzilla 24 Apr '21

24 Apr '21

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 24 Apr '21

24 Apr '21

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 24 Apr '21

24 Apr '21

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 50275] New: Copy paste bug in conhost/window.c
by WineHQ Bugzilla 24 Apr '21

24 Apr '21

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 50733] New: MUSICUS!: ending videos play are extremely choppy
by WineHQ Bugzilla 24 Apr '21

24 Apr '21

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