wine-bugs July 2021

wine-bugs@winehq.org

1 participants
5258 discussions

[Bug 230] winemaker: Extract more information from the source files
by WineHQ Bugzilla 22 Jul '21

22 Jul '21

https://bugs.winehq.org/show_bug.cgi?id=230 jeremiahpwilson(a)yahoo.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremiahpwilson(a)yahoo.com --- Comment #20 from jeremiahpwilson(a)yahoo.com --- Is this still an issue with Wine 6.13? -- 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 124] Review of Wine Server Protocol
by WineHQ Bugzilla 22 Jul '21

22 Jul '21

https://bugs.winehq.org/show_bug.cgi?id=124 jeremiahpwilson(a)yahoo.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremiahpwilson(a)yahoo.com --- Comment #25 from jeremiahpwilson(a)yahoo.com --- Is this bug still relevant with Wine 6.13? -- 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 52] PrgWin95: Problems with access to the root window. Need LockWindowUpdate().
by WineHQ Bugzilla 22 Jul '21

22 Jul '21

https://bugs.winehq.org/show_bug.cgi?id=52 jeremiahpwilson(a)yahoo.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremiahpwilson(a)yahoo.com --- Comment #43 from jeremiahpwilson(a)yahoo.com --- Can this bug be closed? -- 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 51494] New: Dead Rising 3 makes system unresponsive after launch
by WineHQ Bugzilla 21 Jul '21

21 Jul '21

https://bugs.winehq.org/show_bug.cgi?id=51494 Bug ID: 51494 Summary: Dead Rising 3 makes system unresponsive after launch Product: Wine Version: 6.13 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: andrey.goosev(a)gmail.com Distribution: --- Created attachment 70334 --> https://bugs.winehq.org/attachment.cgi?id=70334 +d3d11 On first loading screen CPU & GPU fans become crazy. 0180:err:ntdll:RtlpWaitForCriticalSection section 000000014192CEE8 "?" wait timed out in thread 0180, blocked by 0178, retrying (60 sec) Before launch strongly recommend prepare wineserver -k command. -- 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 51371] New: Too many fonts slows down kernel32:heap! (caused by gdi32)
by WineHQ Bugzilla 21 Jul '21

21 Jul '21

https://bugs.winehq.org/show_bug.cgi?id=51371 Bug ID: 51371 Summary: Too many fonts slows down kernel32:heap! (caused by gdi32) Product: Wine Version: 6.10 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: gdi32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- In fact having too many fonts slows down the startup of any process that loads gdi32 (or user32), which is to say essentially every process. This hits kernel32:heap quite hard because it starts many subprocesses for its tests. Here's a list of the worst hit tests: Base Full set of fonts (see bug 51367) kernel32:heap <1s 13s comctl32:status <1s 13s reg.exe:add 3s 17s regedit.exe:regedit 14s 54s shell32:shlexec 13s 29s But it's not just these tests being impacted, it's every one of the 720 test units, resulting in a full WineTest run taking an extra 9 minutes (on my box, more on the TestBot's debiant2). The reason for the slowdown seems similar to the dwrite:font case (bug 51367) but on the gdi32 side. In particular each process issues quite a lot of these messages (OPENTYPE_PLATFORM_MAC case iirc) which may or may not be related: 0034:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1. -- 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 51367] New: Major dwrite:analyzer, dwrite:layout and dwrite:font slowdown when adding (CJK) fonts
by WineHQ Bugzilla 21 Jul '21

21 Jul '21

https://bugs.winehq.org/show_bug.cgi?id=51367 Bug ID: 51367 Summary: Major dwrite:analyzer, dwrite:layout and dwrite:font slowdown when adding (CJK) fonts Product: Wine Version: 6.10 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: dwrite Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- Created attachment 70223 --> https://bugs.winehq.org/attachment.cgi?id=70223 Command and fonts for Debian's locales Adding fonts causes major slowdowns in dwrite:analyzer, dwrite:layout and dwrite:font when running in Wine. On my test VM I get the following run times: Base Full set dwrite:analyzer <1s 50s dwrite:layout ~1s 46s dwrite:font ~2s 85s On the TestBot's debiant2 VM dwrite:font actually runs in about 118 seconds with the full set of fonts; which is why it times out about 6% of the time: https://test.winehq.org/data/patterns.html#dwrite:font The base set of font packages is: fonts-dejavu-core fonts-freefont-ttf fonts-liberation fonts-quicksand The problem is that the base set produces unreadable text when running in a Chinese, Japanese or Korean locale: all translated strings are replaced with a set of black squares (surprisingly ar_MA, he_IL, hi_HI are ok). That does not seem to impact the test results but it does not feel right either. At a minimum if Debian says a given set of fonts are needed for a locale we should test the said locale with that set of fonts. So the full set of fonts was created by installing the font packages for all of Debian's locale task packages and this is what debiant2 has. See apt_wine_locales() in wt-install-dev [1]. For reference I attached the corresponding set of packages. The run time increase is not concentrated in one specific test_xxx() function that would iterate over all the fonts. All test_xxx() functions take longer to run. Even the test_CreateFontFromLOGFONT() run time increased to ~17s (iirc). Yet it does not look like it's doing all that much. To speed things up I modified dwrite:font to use multiple threads using the same approach as d3d10core:d3d10core. However even with 8 threads that only gained about 4 seconds out of 118s: each individual test function just took longer. Is that because of lots of global locking? Or because each test adds/removes fonts forcing all the other threads to do many rescans? Are all fonts reloaded and analyzed despite most fonts not having changed? [1] https://github.com/fgouget/wt-daily/blob/master/wt-install-dev#L556 -- 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 24688] New: RTL and encoding problem with Ihulan
by wine-bugs＠winehq.org 21 Jul '21

21 Jul '21

http://bugs.winehq.org/show_bug.cgi?id=24688 Summary: RTL and encoding problem with Ihulan Product: Wine Version: 1.3.4 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: sh.yaron(a)gmail.com Ihulan (www.oniton.com) is a Hebrew greetings apps, there's also an English version called U.R.Celeb (http://urceleb.oniton.com/). The Hebrew installation (http://www.oniton.com/uploads/secure/Ihulan453.exe) has several issues: 1. The text is Gibberish. 2. On the terms of service (2nd page) the text is in Hebrew but selectingthe mixes its order, also the header (in read) are split in the middle by LRM for some reason... 3. The window is not RTL although I'm not sure it should be... This also demonstrates some of the typical problems with Hebrew. Kind regards, Yaron Shahrabani -- 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 34

[Bug 45620] New: Dishonored 2 Demo crashes at launch
by wine-bugs＠winehq.org 20 Jul '21

20 Jul '21

https://bugs.winehq.org/show_bug.cgi?id=45620 Bug ID: 45620 Summary: Dishonored 2 Demo crashes at launch Product: Wine Version: 3.13 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: andrey.goosev(a)gmail.com Distribution: --- Created attachment 62050 --> https://bugs.winehq.org/attachment.cgi?id=62050 +d3d11,+dxgi Crashes at launch, probably due to warn:d3d11:d3d_device_inner_QueryInterface {6543dbb6-1b48-42f5-ab82-e97ec74326f6} not implemented, returning E_NOINTERFACE. -- 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 3

[Bug 37370] New: Doom3 CD version installer prompts are different compared to WinXP
by wine-bugs＠winehq.org 20 Jul '21

20 Jul '21

https://bugs.winehq.org/show_bug.cgi?id=37370 Bug ID: 37370 Summary: Doom3 CD version installer prompts are different compared to WinXP Product: Wine Version: 1.7.28 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: msi Assignee: wine-bugs(a)winehq.org Reporter: wylda(a)volny.cz Created attachment 49696 --> https://bugs.winehq.org/attachment.cgi?id=49696 Wine 1.7.28 vs WinXP This is true nitpick ;) As the attachement show, wine says redundant "Error" in the message block pop up and also button "Retry" vs. "OK". If this is considered as crazy nitpicking, there are other problems to which this bug can be converted to (i won't open new bugs yet until this one fixed and because possible duplicates may exists). "Remember list" unrelated to this bug report: * Cancel does not work under wine. WinXP asks you "Are you sure?" Yes/No. Yes button=exit. * Progress bar is always 100%. WinXP moves as the CD are changed. * When Setup.exe is run under Wow64, it immediately exits with some error code. Under 64bit Win8.1 Setup normally asks you for the serial number as usual. * Missing background images during the installation * Extra minimize button, which is not present on attached WinXP screenshot, makes wine dead. When clicked, popup window is hidden and you can't restore it back. As it is fullscreen, you can't click anywhere, nor Alt-Tab to get it back. Killing wine 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.

2 11

[Bug 28795] New: ExeInfoPE: PE protection schemes that abuse %gs won't run (breaks glibc TLS selector)
by wine-bugs＠winehq.org 20 Jul '21

20 Jul '21

http://bugs.winehq.org/show_bug.cgi?id=28795 Bug #: 28795 Summary: ExeInfoPE: PE protection schemes that abuse %gs won't run (breaks glibc TLS selector) Product: Wine Version: 1.3.30 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Classification: Unclassified Hello, newer versions of "ExeInfoPE" (>0.0.2.3) which coin their own PE protection scheme don't run anymore. There is still bug 26701 though the app crashes now earlier. With tracing enabled: --- snip --- ... 0024:Call KERNEL32.VirtualProtect(00400000,00001000,00000004,0032fe40) ret=05bd0336 0024:Ret KERNEL32.VirtualProtect() retval=00000001 ret=05bd0336 0024:Call KERNEL32.VirtualProtect(00400000,00001000,00000002,0032fe40) ret=05bd034b 0024:Ret KERNEL32.VirtualProtect() retval=00000001 ret=05bd034b 0024:trace:seh:raise_exception code=c0000005 flags=0 addr=0xb74a916a ip=b74a916a tid=0024 0024:trace:seh:raise_exception info[0]=00000000 0024:trace:seh:raise_exception info[1]=ffffffff 0024:trace:seh:raise_exception eax=7bc9d7a7 ebx=b75e0ff4 ecx=0032fdcc edx=7bc9d7a7 esi=0032fc74 edi=ffffffc8 0024:trace:seh:raise_exception ebp=0032fc48 esp=0032f6bc cs=0073 ds=007b es=007b fs=0033 gs=0002 flags=00010246 0024:trace:seh:call_vectored_handlers calling handler at 0x7e16e0bd code=c0000005 flags=0 0024:trace:seh:call_vectored_handlers handler at 0x7e16e0bd returned 0 0024:trace:seh:call_stack_handlers calling handler at 0x7bc90f61 code=c0000005 flags=0 0024:Call KERNEL32.UnhandledExceptionFilter(0032f194) ret=7bc90f9b wine: Unhandled page fault on read access to 0xffffffff at address 0xb74a916a (thread 0024), starting debugger... 0024:trace:seh:start_debugger Starting debugger "winedbg --auto 35 52" 0024:Ret KERNEL32.UnhandledExceptionFilter() retval=00000000 ret=7bc90f9b 0024:trace:seh:call_stack_handlers handler at 0x7bc90f61 returned 1 Unhandled exception: page fault on read access to 0xffffffff in 32-bit code (0xb74a916a). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:0002 EIP:b74a916a ESP:0032f6bc EBP:0032fc48 EFLAGS:00010246( R- -- I Z- -P- ) EAX:7bc9d7a7 EBX:b75e0ff4 ECX:0032fdcc EDX:7bc9d7a7 ESI:0032fc74 EDI:ffffffc8 Stack dump: 0x0032f6bc: 0032fc7c 7bc9d82e 0032fc58 b74a992c 0x0032f6cc: 0032fc7c 7bc9d82d 00000001 00000000 0x0032f6dc: 0032fc8c 7bc9d82d 00000001 00000001 0x0032f6ec: 7bc9d82d 00000000 00000000 00000001 0x0032f6fc: 7bc9d82d 00000000 00000000 00000000 0x0032f70c: 00000000 00000000 00000000 00000000 Backtrace: =>0 0xb74a916a _IO_vfprintf+0x3a() in libc.so.6 (0x0032fc48) 1 0xb74cbdbb vsnprintf+0xca() in libc.so.6 (0x0032fc74) 2 0x7bc350f9 NTDLL_dbg_vprintf+0x56() in ntdll (0x0032fd90) 3 0xb761ab63 wine_dbg_printf+0x2e() in libwine.so.1 (0x0032fdc0) 4 0x7bc640e5 relay_call+0x113() in ntdll (0x0032fe10) 5 0x7b8224ad in kernel32 (+0x124ac) (0x0032fe60) 6 0x004075cd in exeinfope (+0x75cc) (0x0032fe60) 7 0x7b85de44 call_process_entry+0xb() in kernel32 (0x0032fe78) 8 0x7b85df8a start_process+0x143() in kernel32 (0x0032fec8) 9 0x7bc7a244 call_thread_func+0xb() in ntdll (0x0032fed8) 10 0x7bc7a282 call_thread_entry_point+0x33() in ntdll (0x0032ffb8) 11 0x7bc51ebc start_process+0x25() in ntdll (0x0032ffe8) 12 0xb761edb5 wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) 0xb74a916a _IO_vfprintf+0x3a in libc.so.6: movl %gs:0x00000000,%ecx --- snip --- The protection scheme fiddles with %gs selector value which breaks TLS pointer access through %gs:0 (Wine uses %fs) or the stack protector scheme that Userland libs and Wine are built with (glibc provided __stack_chk_guard at %gs:0x14). My gcc 4.6.1 x86 host toolchain has -fstack-protector enabled by default hence Wine gets the stack canary code in the binaries. The Glibc here (Xubuntu 11.10) has stack smashing protection enabled by default. Even if Wine is built with "-fno-stack-protector" the app would still break glibc %gs TLS code. This is just a "collector" bug for apps that run into this issue. WONTFIX obviously, there is no reliable way to know when to repair/restore %gs value (and restarting faulting instruction). Regards -- 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 9

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-bugs July 2021