December 2020 - Wine-Bugs - list.winehq.org

[Bug 49421] New: `winetricks -q ffdshow` throws an access violation in usp10.dl (winetricks-test)
by WineHQ Bugzilla Dec. 5, 2020

Dec. 5, 2020

https://bugs.winehq.org/show_bug.cgi?id=49421 Bug ID: 49421 Summary: `winetricks -q ffdshow` throws an access violation in usp10.dl (winetricks-test) Product: Wine Version: 5.7 Hardware: x86 OS: Linux Status: UNCONFIRMED Keywords: download, Installer, regression Severity: normal Priority: P2 Component: gdi32 Assignee: wine-bugs(a)winehq.org Reporter: austinenglish(a)gmail.com CC: julliard(a)winehq.org Regression SHA1: da604dce3493cbd79a201cf0d1885c848c10eac4 Distribution: Gentoo Note: I've only been able to reproduce this when running winetricks-test; I suspect it's related to `winetricks sandbox`, though running that beforehand outside of winetricks-test doesn't reproduce the bug. Marking "UNCONFIRMED" accordingly. This is a regression, introduced by: da604dce3493cbd79a201cf0d1885c848c10eac4 is the first bad commit commit da604dce3493cbd79a201cf0d1885c848c10eac4 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Fri Apr 17 12:39:01 2020 +0200 gdi32: Use Windows paths in add/remove_font_resource(). Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> dlls/gdi32/freetype.c | 152 ++++++++++++++++++++------------------------------ 1 file changed, 60 insertions(+), 92 deletions(-) Running the installer with /silent runs it in quiet mode. It appears to install fine, but during installation, a message box appears showing: Access violation at address 00E2A834 in module 'usp10.dll'. Read of address 00000068. -- 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 30627] New: Appending text to a large richedit is very slow
by wine-bugs＠winehq.org Dec. 5, 2020

Dec. 5, 2020

http://bugs.winehq.org/show_bug.cgi?id=30627 Bug #: 30627 Summary: Appending text to a large richedit is very slow Product: Wine Version: 1.5.3 Platform: x86 OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: richedit AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com Classification: Unclassified Although the pathological case reported in bug 30614 is now fixed, all is not yet well. When repeatedly appending lines, builtin riched20 starts out about 3x slower than native, and at 40k lines, is about 10x slower than native. This is painful for long-running apps that use richedit for verbose logs. (Measured with the attached program and today's git on my i5, appending 1000 lines to an empty richedit control takes builtin hidden: 907 ms builtin visible: 4862 ms native hidden: 368 ms native visible: 4530 ms Appending 1000 lines to a richedit control which already contains 40000 lines takes: builtin hidden: 22169 ms builtin visible: 33002 ms native hidden: 1750 ms native visible: 4807 ms ) Building wine's riched20 with -O1 -fno-inline and profiling with 'perf' shows 62.60% ME_WrapMarkedParagraphs 12.07% ME_PaintContent 9.99% ME_InvalidateMarkedParagraph at 50k lines. Initial inspection seems to show that most of the time in ME_WrapMarkedParagraphs is in the function itself, not in any called functions. Adding trace statements to all callers of ME_WrapMarkedParagraphs, I see one call during EM_EXSETSEL: ME_Repaint Calling ME_WrapMarkedParagraphs and four calls during EM_REPLACESEL: ME_UpdateRepaint Calling ME_WrapMarkedParagraphs ME_UpdateScrollBar Calling ME_WrapMarkedParagraphs ME_Repaint Calling ME_WrapMarkedParagraphs ME_UpdateScrollBar Calling ME_WrapMarkedParagraphs This is the case whether the window is hidden or not. Bug 13355 (which Dylan says is separate, since it's about richedit being slow on a single large call to WM_SETTEXT) suggests in comment 14 ways to remove some redundant calls to ME_WrapMarkedParagraphs, and to let one of them return early. In addition to those ideas, for this bug, it would be useful if ME_WrapMarkedParagraphs (and ME_InvalidateMarkedParagraph) could avoid making a linear scan across all paragraphs. -- 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 3919] Picasa 2 - Timeline feature doesn't show in fullscreen
by WineHQ Bugzilla Dec. 5, 2020

Dec. 5, 2020

https://bugs.winehq.org/show_bug.cgi?id=3919 --- Comment #25 from joaopa <jeremielapuree(a)yahoo.fr> --- Bug still occurs with wine-5.22. -- 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 0

[Bug 41234] New: FreeGate 7.59 does not run on the latest versions of some distros
by wine-bugs＠winehq.org Dec. 5, 2020

Dec. 5, 2020

https://bugs.winehq.org/show_bug.cgi?id=41234 Bug ID: 41234 Summary: FreeGate 7.59 does not run on the latest versions of some distros Product: Wine Version: 1.9.12 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: caminostro3(a)gmail.com Distribution: Fedora Created attachment 55521 --> https://bugs.winehq.org/attachment.cgi?id=55521 Terminal output of wine running freegate 7.59 I tried running Freegate 7.59 (Latest version) on Fedora 23, Linux Mint 17, and Ubuntu 16.04. The first dialogs asking for EULA agreement and some options appear, but the main window does not. The terminal output of running this application with wine 1.9.12 on Fedora 23 is attached. -- 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 45383] New: Xanadu Next: movies not working (avi/MPEG-4 (XviD))
by wine-bugs＠winehq.org Dec. 5, 2020

Dec. 5, 2020

https://bugs.winehq.org/show_bug.cgi?id=45383 Bug ID: 45383 Summary: Xanadu Next: movies not working (avi/MPEG-4 (XviD)) Product: Wine Version: 3.11 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: quartz Assignee: wine-bugs(a)winehq.org Reporter: betaversiondot(a)gmail.com Distribution: Debian Created attachment 61699 --> https://bugs.winehq.org/attachment.cgi?id=61699 Xanadu Next wine-3.11 Black screen instead of movies. -- 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 12

[Bug 46216] New: Lords of the Fallen needs ThreadEnableAlignmentFaultFixup
by wine-bugs＠winehq.org Dec. 5, 2020

Dec. 5, 2020

https://bugs.winehq.org/show_bug.cgi?id=46216 Bug ID: 46216 Summary: Lords of the Fallen needs ThreadEnableAlignmentFaultFixup Product: Wine Version: 3.21 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: andrey.goosev(a)gmail.com Distribution: --- Spamming output after launching: fixme:thread:NtSetInformationThread info class 7 not supported yet wine-3.21-114-g1582ae6b04 -- 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 6

[Bug 26541] New: Dragon Saga doesn't start
by wine-bugs＠winehq.org Dec. 5, 2020

Dec. 5, 2020

http://bugs.winehq.org/show_bug.cgi?id=26541 Summary: Dragon Saga doesn't start Product: Wine Version: 1.3.16 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com Installing DragonSagaInstaller-0.1.29-20110216.msi went fine, but $ cd ~/.wine/drive_c/Program Files/Gravity/Dragon Saga $ wine Release/DragonSaga.EXE fails like this: fixme:ntdll:NtQueryInformationProcess (process=0xffffffff) Unimplemented information class: ProcessDebugFlags Unhandled exception: privileged instruction in 32-bit code (0x0123980c). Backtrace: =>0 0x0123980c in dragonsaga (+0xe4980c) (0x0032fea0) 1 0x7edaa2fc call_process_entry+0xb() in kernel32 (0x0032feb8) 2 0x7edac593 start_process+0x52(peb=0x1) [dlls/kernel32/process.c:1086] in kernel32 -- 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 6

[Bug 28089] New: exception handling code touches stack for exceptions handled by the debugger
by wine-bugs＠winehq.org Dec. 5, 2020

Dec. 5, 2020

http://bugs.winehq.org/show_bug.cgi?id=28089 Summary: exception handling code touches stack for exceptions handled by the debugger Product: Wine Version: unspecified Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll AssignedTo: wine-bugs(a)winehq.org ReportedBy: bernhardloos(a)googlemail.com Created an attachment (id=35971) --> (http://bugs.winehq.org/attachment.cgi?id=35971) a hack to work around the problem Wine places the CONTEXT and EXCEPTION_RECORD structures onto the stack past ESP during the unix signal handler and continues with most of the exception handling code outside of the signal handler. Unfortunately and contrary to windows behavior the debugger gets notified only after this happens. Windows doesn't touch the stack at all, if the exception is handled by the debugger. This makes it very hard to single step trough code which keeps useful data past ESP (securom 8 for example). it's easy to show with this small test: void foo() { char *x = 0, *y = 0, *from = 0, *to = 0; char c; x = &c; y = &c - 500; while (y != x) *y++ = 0x55; c = 0x77; /* single step a few times here */ y = &c - 500; while (y != x) { if (*y != 0x55) if (from) to = y; else from = y; y++; } /* to and from shoudl be NULL */ } -- 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 13

[Bug 43567] New: Vietcong - game crashes during radiocalls
by wine-bugs＠winehq.org Dec. 4, 2020

Dec. 4, 2020

https://bugs.winehq.org/show_bug.cgi?id=43567 Bug ID: 43567 Summary: Vietcong - game crashes during radiocalls Product: Wine Version: 2.14 Hardware: x86-64 URL: http://www.moddb.com/games/vietcong/downloads/vietcong -singleplayer-demo OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: havran.jan(a)email.cz Distribution: ArchLinux Created attachment 58977 --> https://bugs.winehq.org/attachment.cgi?id=58977 Vietcong - terminal log Vietcong crashes when radiocall icon is shown. This bug is also reproduciable on Windows > Vista, but it works on Windows XP. There exists community tool: VCStarter, which fixes this for newer Windows and also for Wine. I have spoke with VCStarter creator and he told me that the game uses some dirty assembler in that part (maybe part of anticheat protection or no-cd crack?). I have doubts if it is really Wine bug, but since this game works on Windows <= XP, it should also work on Wine (with Win XP compatibility). PS: You will not be able tu run this game probably because of bug #9337. As a workaround, you can use VCStarter (version 1.7 only, older versions did not fix the bug) or patch from bug #39057 - all this is described in bug #9337 PPS: While patch from bug #39057 fixes bug #9337 crashing for all Vietcong versions, VCStarter works only with Vietcong 1.60 (so it does not work with Vietcong demo version). -- 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 13

[Bug 50171] New: 32-bit PE entry point no longer called through BaseThreadInitThunk() assembly wrapper when Wine is built with LLVM MinGW
by WineHQ Bugzilla Dec. 4, 2020

Dec. 4, 2020

https://bugs.winehq.org/show_bug.cgi?id=50171 Bug ID: 50171 Summary: 32-bit PE entry point no longer called through BaseThreadInitThunk() assembly wrapper when Wine is built with LLVM MinGW Product: Wine Version: 5.22 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, while investigating bug 28332 I found a regression introduced by https://source.winehq.org/git/wine.git/commitdiff/0c631ebb2354334eaf309bc07… ("kernel32: Build with msvcrt."). With 32-bit kernel32 cross-compiled to PE format, the stack on app entry point is now aligned to 16-byte boundary. This makes the game from bug 28332 "magically" work while the 32-bit non-PE kernel32 causes a crash (expected due to Wine quartz bug). https://bugs.winehq.org/show_bug.cgi?id=28332#c17 The stack alignment from entry point, including selected functions from the call chain up to alloca() caller. --- snip --- EIP | PE ESP | non-PE ESP | comment 0x42D5E3 | 0x31FF60 +00 | 0x31FF44 +00 | entry point main thread 0x42A720 | 0x31FEA0 +C0 | 0x31FE84 +C0 | 0x4200C5 | 0x31FE54 +4C | 0x31FE38 +4C | 0x40D8B7 | 0x31FE4C +08 | 0x31FE30 +08 | 0x40D570 | 0x31FE48 +04 | 0x31FE2C +04 | 0x40D6FF | 0x31FB1C +32C | 0x31FB00 +32C | before alloca(0) 0x40D704 | 0x31FB10 +0C | 0x31FB00 +00 | after alloca(0) --- snip --- It seems in 32-bit PE kernel32.dll, the thread entry point is called through the fastcall "C" version of BaseThreadInitThunk() instead of the fastcall assembly wrapper. 32-bit non-PE kernel32.dll.so works correctly, the thread entry point is called through __fastcall_BaseThreadInitThunk() assembly wrapper. https://source.winehq.org/git/wine.git/blob/bedfb9cae224a369efa4588332a5518… --- snip --- 36 #ifdef __i386__ 37 __ASM_STDCALL_FUNC( __fastcall_BaseThreadInitThunk, 12, 38 "pushl %ebp\n\t" 39 __ASM_CFI(".cfi_adjust_cfa_offset 4\n\t") 40 __ASM_CFI(".cfi_rel_offset %ebp,0\n\t") 41 "movl %esp,%ebp\n\t" 42 __ASM_CFI(".cfi_def_cfa_register %ebp\n\t") 43 "pushl %ebx\n\t" 44 __ASM_CFI(".cfi_rel_offset %ebx,-4\n\t") 45 "movl 8(%ebp),%ebx\n\t" 46 /* deliberately mis-align the stack by 8, Doom 3 needs this */ 47 "pushl 4(%ebp)\n\t" /* Driller expects readable address at this offset */ 48 "pushl 4(%ebp)\n\t" 49 "pushl %ebx\n\t" 50 "call *%edx\n\t" 51 "movl %eax,(%esp)\n\t" 52 "call " __ASM_STDCALL( "RtlExitUserThread", 4 )) 53 #endif 54 55 /*********************************************************************** 56 * BaseThreadInitThunk (KERNEL32.@) 57 */ 58 void __fastcall BaseThreadInitThunk( DWORD unknown, LPTHREAD_START_ROUTINE entry, void *arg ) 59 { 60 RtlExitUserThread( entry( arg ) ); 61 } --- snip --- https://source.winehq.org/git/wine.git/blob/bedfb9cae224a369efa4588332a5518… --- snip --- 185 @ stdcall -fastcall BaseThreadInitThunk(long ptr ptr) --- snip --- cross-toolchain used: LLVM MinGW 20201020 with LLVM stable 11.0.0 https://github.com/mstorsjo/llvm-mingw https://github.com/mstorsjo/llvm-mingw/releases https://github.com/mstorsjo/llvm-mingw/releases/download/20201020/llvm-ming… $ wine --version wine-5.22 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