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

[Bug 44691] New: EA origin install error 3:0
by wine-bugs＠winehq.org April 23, 2021

April 23, 2021

https://bugs.winehq.org/show_bug.cgi?id=44691 Bug ID: 44691 Summary: EA origin install error 3:0 Product: Wine Version: 3.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: maxi.cass11(a)gmail.com Distribution: --- Hi, I have tried to install origin with wine 3.3 on a clean wine Prefix on my computer but with the full version I get an error 3:0 I think it's a permission issue because when you want to look on the Origin folder it have a locker on it. And this is the permission of the files: drwxrwxr-x 7 amosar amosar 4096 Mar 9 00:40 . drwxrwxr-x 6 amosar amosar 4096 Mar 9 00:39 .. drwxrwxr-x 4 amosar amosar 4096 Mar 9 00:39 Common Files drwxrwxr-x 2 amosar amosar 4096 Mar 9 00:39 Internet Explorer dr-xr-xr-x 2 amosar amosar 4096 Mar 9 00:40 Origin drwxrwxr-x 2 amosar amosar 4096 Mar 9 00:39 Windows Media Player drwxrwxr-x 3 amosar amosar 4096 Mar 9 00:39 Windows NT -- 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 21

[Bug 41468] New: Supreme Commander Forged Alliance needs CLSID ' {343e68e6-8f82-4a8d-a2da-6e9a944b378c}' xactengine2_9.dll
by wine-bugs＠winehq.org April 23, 2021

April 23, 2021

https://bugs.winehq.org/show_bug.cgi?id=41468 Bug ID: 41468 Summary: Supreme Commander Forged Alliance needs CLSID '{343e68e6-8f82-4a8d-a2da-6e9a944b378c}' xactengine2_9.dll Product: Wine Version: 1.9.20 Hardware: x86-64 OS: Linux Status: NEW Severity: minor Priority: P2 Component: xactengine Assignee: wine-bugs(a)winehq.org Reporter: andrey.goosev(a)gmail.com CC: aeikum(a)codeweavers.com Distribution: --- err:ole:CoGetClassObject class {343e68e6-8f82-4a8d-a2da-6e9a944b378c} not registered err:ole:CoGetClassObject no class object {343e68e6-8f82-4a8d-a2da-6e9a944b378c} could be created for context 0x1 wine-1.9.20-92-g1dedd90 -- 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 7

[Bug 34398] New: Daedalic games don't display anything with winemac.drv
by wine-bugs＠winehq.org April 23, 2021

April 23, 2021

http://bugs.winehq.org/show_bug.cgi?id=34398 Bug #: 34398 Summary: Daedalic games don't display anything with winemac.drv Product: Wine Version: 1.7.1 Platform: x86 OS/Version: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: winemac.drv AssignedTo: wine-bugs(a)winehq.org ReportedBy: thanoulas(a)gmail.com Classification: Unclassified Created attachment 45793 --> http://bugs.winehq.org/attachment.cgi?id=45793 err+all,fixme+all With winemac driver The games "Chains of Satinav" and "Memoria" show a black display when using the winemac driver. They both work fine when using the x11 driver. I've attached a log -- 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 27

[Bug 50892] New: WINE 6.3: opentrack-wrapper-wine segfaults with message "Got unexpected trap 14 during process initialization".
by WineHQ Bugzilla April 23, 2021

April 23, 2021

https://bugs.winehq.org/show_bug.cgi?id=50892 Bug ID: 50892 Summary: WINE 6.3: opentrack-wrapper-wine segfaults with message "Got unexpected trap 14 during process initialization". Product: Wine Version: 6.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: xeno(a)x-s.com.pl Distribution: --- As per Summary opentrack-wrapper-wine.exe.so process (opentrack trackir and freetrack protocols wrapper) crashes just after launch. If started from console with env WINEPREFIX=<my_wine_prefix_path> wine /usr/lib64/opentrack/opentrack-wrapper-wine.exe.so it crashes spitting out message: 00fc:err:seh:segv_handler_early Got unexpected trap 14 during process initialization Once wine is downgraded to 5.x (here tested with 5.18 and 5.22) wrapper process starts just fine and stays on until headtracking is stopped. Tested with opentrack 2.3.12 and 2.3.13, wine 6.3. Steps to reproduce: start opentrack select pointtracker as input, accela as filter wine as output configure wine output plugin and point it to wine prefix where app that uses headtracking is installed start headtracking start app/game from Expected result: - opentrack-wrapper-wine.exe.so stays in the list of active processes - headtracking works in games/apps running in wine. Actual results: - opentrack-wrapper-wine.exe.so process appears for a brief moment then instantly closes - headtracking works in opentrack preview window but not in a apps running in wine. OpenTrack is fa opensource project obtainable from github: https://github.com/opentrack/opentrack I can provide rough but working Fedora x86_64 rpm if needed. -- 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 5

[Bug 48486] New: cmd WCMD_ReadAndParseLine contains non-null terminated strings, causing garbage output in trace logs
by WineHQ Bugzilla April 23, 2021

April 23, 2021

https://bugs.winehq.org/show_bug.cgi?id=48486 Bug ID: 48486 Summary: cmd WCMD_ReadAndParseLine contains non-null terminated strings, causing garbage output in trace logs Product: Wine Version: 5.0-rc6 Hardware: x86 OS: Linux Status: NEW Severity: trivial Priority: P2 Component: cmd Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, as it says. It's already PE but various strings have not been converted yet. The function in the summary is the one most offending/annoying in trace logs. There are other occurrences as well. Example download: https://github.com/git-for-windows/git/releases/download/v2.25.0.windows.1/… --- snip --- ... 006a:Call KERNEL32.MultiByteToWideChar(000001b5,00000000,00bd7a78 "\t\t(a)IF NOT EXIST bin\\rebase.exe @(\n\t\t\t(a)IF NOT EXIST bin @MKDIR bin\n\t\t\t(a)COPY usr\\bin\\rebase.exe bin\\rebase.exe\n\t\t)\n\t\t(a)IF NOT EXIST bin\\msys-2.0.dll @(\n\t\t\t(a)COPY usr\\bin\\msys-2.0.dll bin\\msys-2.0.dll\n\t\t)\n\t\t(a)bin\\rebase.exe -b 0x64000000 usr\\bin\\msys-2.0.dll\n"...,00000021,00be5238,00002000) ret=00401a09 006a:Ret KERNEL32.MultiByteToWideChar() retval=00000021 ret=00401a09 006a:Call KERNEL32.HeapFree(00110000,00000000,00bd7a78) ret=00401a22 006a:Ret KERNEL32.HeapFree() retval=00000001 ret=00401a22 006a:Call msvcrt.wcschr(00be523c L"@IF NOT EXIST bin\\rebase.exe @(",00000025) ret=004137f3 006a:Ret msvcrt.wcschr() retval=00000000 ret=004137f3 006a:Call KERNEL32.CompareStringW(00000400,00001001,00be523e L"IF NOT EXIST bin\\rebase.exe @(",00000003,0041b706 L"remforifelse\4357\444d\525f\6165\4164\646e\6150\7372\4c65\6e69e\6f4e\6320\6d6f\616d\646e\6e20\726f\6820\6e61\6c64\2065\7573\7070\696c\6465\necho.echo:echo/\764f\7265\6c66\776f\6420\7465\6365\6574\2064\6e69\6320\6d6f\616d\646e\ndo/I",00000003) ret=00411489 006a:Ret KERNEL32.CompareStringW() retval=00000001 ret=00411489 006a:Call KERNEL32.CompareStringW(00000400,00001001,00be523e L"IF NOT EXIST bin\\rebase.exe @(",00000003,0041b70c L"forifelse\4357\444d\525f\6165\4164\646e\6150\7372\4c65\6e69e\6f4e\6320\6d6f\616d\646e\6e20\726f\6820\6e61\6c64\2065\7573\7070\696c\6465\necho.echo:echo/\764f\7265\6c66\776f\6420\7465\6365\6574\2064\6e69\6320\6d6f\616d\646e\ndo/I",00000003) ret=004115c0 006a:Ret KERNEL32.CompareStringW() retval=00000003 ret=004115c0 006a:Call KERNEL32.CompareStringW(00000400,00001001,00be523e L"IF NOT EXIST bin\\rebase.exe @(",00000002,0041b712 L"ifelse\4357\444d\525f\6165\4164\646e\6150\7372\4c65\6e69e\6f4e\6320\6d6f\616d\646e\6e20\726f\6820\6e61\6c64\2065\7573\7070\696c\6465\necho.echo:echo/\764f\7265\6c66\776f\6420\7465\6365\6574\2064\6e69\6320\6d6f\616d\646e\ndo/I",00000002) ret=004115fa 006a:Ret KERNEL32.CompareStringW() retval=00000002 ret=004115fa ... --- snip --- Wine source: https://source.winehq.org/git/wine.git/blob/02f3a133b64ed1f979309e1399738ea… $ sha1sum Git-2.25.0-32-bit.exe 7dc64019c089d4a9a3700ee7140a7af9a5416199 Git-2.25.0-32-bit.exe $ du -sh Git-2.25.0-32-bit.exe 45M Git-2.25.0-32-bit.exe $ wine --version wine-5.0-rc6 Regards -- 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 50801] New: Wine Mono crashes on macOS
by WineHQ Bugzilla April 23, 2021

April 23, 2021

https://bugs.winehq.org/show_bug.cgi?id=50801 Bug ID: 50801 Summary: Wine Mono crashes on macOS Product: Wine Version: 6.4 Hardware: x86-64 OS: Mac OS X Status: NEW Severity: normal Priority: P2 Component: mscoree Assignee: wine-bugs(a)winehq.org Reporter: madewokherd(a)gmail.com Running the csc.exe shipped with Wine Mono on macOS 11.2.1 crashes with: 0024:err:virtual:virtual_setup_exception stack overflow 1456 bytes in thread 0024 addr 0x7bc2bd61 stack 0x130a50 (0x130000-0x131000-0x230000) >From a +relay,+seh log, trimmed by thread: 0024:Call msvcrt.memcpy(0022dec0,02950f35,00000010) ret=1801013e1 0024:Ret msvcrt.memcpy() retval=0022dec0 ret=1801013e1 0024:trace:seh:dispatch_exception code=c0000005 flags=0 addr=0000000002951170 ip=0000000002951170 tid=0024 0024:trace:seh:dispatch_exception info[0]=0000000000000001 0034:Call KERNEL32.HeapFree(00020000,00000000,000b96f0) ret=68765c83 0024:trace:seh:dispatch_exception info[1]=0000000000000498 0024:warn:seh:dispatch_exception EXCEPTION_ACCESS_VIOLATION exception (code=c0000005) raised 0024:trace:seh:dispatch_exception rax=0000000000000498 rbx=0000000000000000 rcx=0000000000000001 rdx=0000000000000010 0024:trace:seh:dispatch_exception rsi=0000000000000010 rdi=0000000000a24dd0 rbp=000000000022e2c0 rsp=000000000022e270 0024:trace:seh:dispatch_exception r8=000000000022e5f0 r9=0000000002950f00 r10=000000000000000a r11=0000000002950f64 0024:trace:seh:dispatch_exception r12=0000000000a32e88 r13=000000000022e928 r14=000000000022e5f0 r15=0000000000000000 0024:trace:seh:call_vectored_handlers calling handler at 00000001801038F0 code=c0000005 flags=0 I haven't been able to get winedbg working well enough to give me any real information, but that memcpy call is from the end of mono_breakpoint_clean_code. I also got this from WINE_MONO_VERBOSE=1: Method (wrapper alloc) object object:AllocSmall (intptr,intptr) emitted at 0000000002951110 to 000000000295123b (code length 299) [csc.exe] So we're crashing on access to JIT-compiled code. There's probably a way to tell from the +seh log whether that's on execute access, but I'm just going to assume it is. -- 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 44755] New: reg.exe: does not provide /reg: 64 switch in 64-bit wineprefix
by wine-bugs＠winehq.org April 23, 2021

April 23, 2021

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 28995] New: Unable to use named pipes with ">" character in the name
by wine-bugs＠winehq.org April 23, 2021

April 23, 2021

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 17823] New: A crash when installing Rhino 4.0 trial version
by wine-bugs＠winehq.org April 23, 2021

April 23, 2021

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 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