June 2023 - Wine-bugs - list.winehq.org

[Bug 55055] New: Japanese IME fails to clear composition string when deleting the only remaining character
by WineHQ Bugzilla 23 Jun '23

23 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=55055 Bug ID: 55055 Summary: Japanese IME fails to clear composition string when deleting the only remaining character Product: Wine Version: 8.10 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: imm32 Assignee: wine-bugs(a)winehq.org Reporter: achurch+wine(a)achurch.org Distribution: --- Created attachment 74617 --> https://bugs.winehq.org/attachment.cgi?id=74617 PoC patch Environment: Linux, LANG=ja_JP.UTF-8, ATOK X3 (XIM) Since Wine 8.9 (and possibly 8.8, but not in 8.7), if XIM input results in a composition string being reduced to zero length, the previous composition string remains displayed until further input. For example, using Japanese: 1) Press 'A' -> composition string "あ" -> program displays "あ" 2) Press backspace -> composition string empty -> program still displays "あ" 3) Press 'I' -> composition string "I" -> program displays "い" In step 2, the program should no longer display a composition string, but the "あ" from step 1 remains displayed until further input in step 3 (at which point the displayed composition string is correct again). I first observed this in Final Fantasy XIV, but it reproduces in Notepad as well. Changing dlls/imm32/ime.c:ImeToAsciiEx() to send WM_IME_ENDCOMPOSITION when compstr->dwCompStrLen is zero (see attached patch) seems to fix the bug without any side effects in FFXIV and Notepad, but I have no idea what other effects this might have, or if there needs to be some sort of deeper state tracking for a proper fix. -- 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 55088] New: Program crashes when Common Dialog File open function is called
by WineHQ Bugzilla 23 Jun '23

23 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=55088 Bug ID: 55088 Summary: Program crashes when Common Dialog File open function is called Product: Wine Version: 6.0.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: comdlg32 Assignee: wine-bugs(a)winehq.org Reporter: schicktmireurescheisse(a)gmail.com Distribution: --- Created attachment 74644 --> https://bugs.winehq.org/attachment.cgi?id=74644 This is the contents of the error message when the program crashes. When the open file button (the blue button with the folder icon in the upper left corner) of "Entgenderer" is clicked, the software instantly crashes. The program does not get as far to display the open file common dialog. Actually, the program is expected to show the file open dialog in order to enable the user to select a text file. The program was written by me. It is a 16 Bit NE binary (therefore, it actually does not use the comdlg32 DLL, but probably its predecessor - but this category fitted best). The sample program can be retrieved via the link https://github.com/Waldwatz/Wine-reveals-the-truth/releases/ and then the Entgenderer2.zip file has to be downloaded. The terminal output after the program has crashed is: wine: Unhandled page fault on read access to FFFFFFFF at address 00003FD6 (thread 0104), starting debugger... -- 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 55051] New: Build regression in wine 8.10 using clang on aarch64 (error in backend: Invalid register name "x18")
by WineHQ Bugzilla 23 Jun '23

23 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=55051 Bug ID: 55051 Summary: Build regression in wine 8.10 using clang on aarch64 (error in backend: Invalid register name "x18") Product: Wine Version: 8.10 Hardware: aarch64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msvcrt Assignee: wine-bugs(a)winehq.org Reporter: pierrick.bouvier(a)linaro.org Distribution: --- When compiling wine for aarch64, a build regression appeared in Wine 8.10 when using clang (any version). This is only present when performing make install, which compiles some DLL. Error is that register x18 is used, and clang reports it as an hard error. gcc reports a warning but does not produce an error (warning: call-clobbered register used for global register variable). --- Reproduction steps (from linux-aarch64, debian bookworm): # download llvm-mingw and add to PATH $ ./configure CC="clang" --without-x --without-freetype --prefix=/usr $ make # works $ make install # fails clang -c -o dlls/msvcr110/onexit.o ... fatal error: error in backend: Invalid register name "x18". ... 3. Running pass 'Function Pass Manager' on module 'dlls/msvcrt/onexit.c'. 4. Running pass 'AArch64 Instruction Selection' on function '@_register_onexit_function' --- Bisect pointed this commit: https://github.com/wine-mirror/wine/commit/56cfbf6b860b46768eeae60eef7dfe0a… include: Only enable the non-inline NtCurrentTeb() on the Unix side. This previous commit introduced register x18 for TEB on arm64 (but commit above makes it active): https://github.com/wine-mirror/wine/commit/7f088b0b1387a3b54c438b839046afad… This previous bug already discussed this topic (https://bugs.winehq.org/show_bug.cgi?id=38780) but I'm not sure what the conclusion would be. --- Compiling with CLAGS=-ffixed-x18 silences clang, but I'm not sure it's the right thing to do. gcc works only because it's a warning and not an error. -- 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 6

[Bug 55027] New: Microsoft Office: IME result string may get doubled when edit is done
by WineHQ Bugzilla 23 Jun '23

23 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=55027 Bug ID: 55027 Summary: Microsoft Office: IME result string may get doubled when edit is done Product: Wine Version: 8.9 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs(a)winehq.org Reporter: firelzrd(a)gmail.com Distribution: --- Created attachment 74582 --> https://bugs.winehq.org/attachment.cgi?id=74582 Bad and Good cases in Excel 2003 The recent (v8.x) IMM32 progress is so remarkable that CJK users may finally think of replacing Windows for using Microsoft Office. However, in Microsoft Office apps (confirmed in 2003) having done editing IME preedit text by hitting Enter key may actually put the result text doubled (see in the attached video). My analysis showed that when: WM_IME_COMPOSITION which has GCS_RESULTREADSTR & GCS_RESULTSTR flags on is sent to complete the edit, and result text is sent, Only in case the problem occurs, right after that: WM_IME_COMPOSITION which has GCS_COMPSTR & GCS_COMPATTR & GCS_RESULTSTR flags on is sent. This behavior indicates that xic_preedit_done() and xim_set_result_string() which I found in xim.c are called sometimes in a wrong order. A: XICCallback preedit_done is called xic_preedit_done is called B: keyboard.c:X11DRV_KeyEvent xim_set_result_string is called A is supposed to be called first, and then B should follow. in the good case A happens, then B happens. in the bad case B happens, then A happens. So I think this problem occurs because XIC callback and X11DRV_KeyEvent are called asynchronously. I think the solution may be: * In xim_set_result_string(), check if XIC preedit context exists, and if so, ppostpone the sending of WM_IME_COMPOSITION until next xic_preedit_done() is called or * Ignore xic_preedit_done() if xim_set_result_string() was called very recently Let me hear what you guys think. 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.

1 14

[Bug 55047] New: d3d test_cursor_clipping() fails
by WineHQ Bugzilla 23 Jun '23

23 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=55047 Bug ID: 55047 Summary: d3d test_cursor_clipping() fails Product: Wine Version: 7.21 Hardware: x86-64 OS: Linux Status: NEW Keywords: regression, testcase Severity: normal Priority: P2 Component: win32u Assignee: wine-bugs(a)winehq.org Reporter: z.figura12(a)gmail.com CC: rbernon(a)codeweavers.com Regression SHA1: af902c188ebaf7d6dda3b628409d8c390ab410d5 Distribution: --- I can observe this on two different machines, with at least ddraw and d3d8 tests. It happens regardless of whether the virtual desktop is used. The failure looks like this: ddraw:ddraw1: ddraw1.c:14352: Test failed: SetDis.layMode failed, hr 0x80004001 d3d8:device: device.c:10815: Test failed: Adapter 0: Expect clip rect (0,0)-(640,480), got (1,1)-(639,479). It's not quite consistent, though. One machine can reproduce the ddraw1 failure pretty consistently, enough for me to be able to bisect, but the other seems to fail only intermittently. As a result I can't be 100% sure of the bisect result, but it seems to make sense. -- 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 55026] New: Expose save_period as a configurable option via winecfg
by WineHQ Bugzilla 23 Jun '23

23 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=55026 Bug ID: 55026 Summary: Expose save_period as a configurable option via winecfg Product: Wine Version: 8.10 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: wineserver Assignee: wine-bugs(a)winehq.org Reporter: aros(a)gmx.com Distribution: --- Wine dumps registry files to the disk every 30 seconds which might not be good for users of SSD/NVMe disks considering it involves completely rewriting them since they are text files, not binary databases as the real Windows registry is where updates are local and small. E.g after installing Microsoft Office the system.reg file can easily blow up to tens of megabytes and it's not that funny having this file being rewritten so often. Would be nice to have this option exposed via winecfg. -- 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 19

[Bug 55123] New: widl crashes when uuid is missing
by WineHQ Bugzilla 23 Jun '23

23 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=55123 Bug ID: 55123 Summary: widl crashes when uuid is missing Product: Wine Version: 8.10 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: tools Assignee: wine-bugs(a)winehq.org Reporter: dark.shadow4(a)web.de Distribution: --- Created attachment 74678 --> https://bugs.winehq.org/attachment.cgi?id=74678 Minimal Sample See attached sample -- 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 1

[Bug 55122] New: oleaut32:vartest - test_VarParseNumFromStrFr() fails on Windows 11
by WineHQ Bugzilla 23 Jun '23

23 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=55122 Bug ID: 55122 Summary: oleaut32:vartest - test_VarParseNumFromStrFr() fails on Windows 11 Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: oleaut32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com oleaut32:vartest - test_VarParseNumFromStrFr() fails on Windows 11: vartest.c:1999: Test failed: 1: Call succeeded, hres = 00000000 vartest.c:2012: Test failed: 1: returned 80020005 vartest.c:2049: Test failed: 1: returned 80020005 vartest.c:2121: Test failed: 1: Call succeeded, hres = 00000000 vartest.c:2135: Test failed: 1: returned 80020005 See https://test.winehq.org/data/patterns.html#oleaut32:vartest Where 80020005 == DISP_E_TYPEMISMATCH -- 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 1

[Bug 55121] New: wintrust:asn - test_encodeSPCPEImage() fails on Windows 11
by WineHQ Bugzilla 23 Jun '23

23 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=55121 Bug ID: 55121 Summary: wintrust:asn - test_encodeSPCPEImage() fails on Windows 11 Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: wintrust Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com wintrust:asn - test_encodeSPCPEImage() fails on Windows 11: asn.c:385: Test failed: CryptEncodeObjectEx failed: c0000005 asn.c:398: Test failed: CryptEncodeObjectEx failed: c0000005 asn.c:563: Test failed: CryptEncodeObjectEx failed: c0000005 asn.c:673: Test failed: CryptEncodeObjectEx failed: c0000005 asn.c:696: Test failed: CryptEncodeObjectEx failed: c0000005 asn.c:709: Test failed: CryptEncodeObjectEx failed: c0000005 See https://test.winehq.org/data/patterns.html#wintrust:asn Where c0000005 == STATUS_ACCESS_VIOLATION -- 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 1

[Bug 53431] New: widl generates enum forward declarations in typedefs which are not valid in C++
by WineHQ Bugzilla 23 Jun '23

23 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=53431 Bug ID: 53431 Summary: widl generates enum forward declarations in typedefs which are not valid in C++ Product: Wine Version: 7.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: tools Assignee: wine-bugs(a)winehq.org Reporter: gfw.kra(a)gmail.com Distribution: --- Hi everyone, I recently discovered an issue with C++ code in headers compiled from winrt idl's using widl. It does not compile when included, when tried using mingw g++ v12.1.0. There’s seems to be issue with how enum typedefs are translated within namespaces. Example: When tried to include windows.media.speechsynthesis.h compiled from windows.media.speechsynthesis.idl in cpp file, the following output is received (compiler output shows headers from mingw, but these look the same when compiled using widl in wine). ``` /usr/x86_64-w64-mingw32/include/windows.foundation.h:90:26: error: use of enum ‘PropertyType’ without previous declaration 90 | typedef enum PropertyType PropertyType; | ^~~~~~~~~~~~ /usr/x86_64-w64-mingw32/include/windows.foundation.h:164:18: error: using typedef-name ‘ABI::Windows::Foundation::PropertyType’ after ‘enum’ 164 | enum PropertyType { | ^~~~~~~~~~~~ /usr/x86_64-w64-mingw32/include/windows.foundation.h:90:39: note: ‘ABI::Windows::Foundation::PropertyType’ has a previous declaration here 90 | typedef enum PropertyType PropertyType; | ^~~~~~~~~~~~ /usr/x86_64-w64-mingw32/include/windows.media.speechsynthesis.h:218:30: error: use of enum ‘VoiceGender’ without previous declaration 218 | typedef enum VoiceGender VoiceGender; | ^~~~~~~~~~~ /usr/x86_64-w64-mingw32/include/windows.media.speechsynthesis.h:476:22: error: using typedef-name ‘ABI::Windows::Media::SpeechSynthesis::VoiceGender’ after ‘enum’ 476 | enum VoiceGender { | ^~~~~~~~~~~ /usr/x86_64-w64-mingw32/include/windows.media.speechsynthesis.h:218:42: note: ‘ABI::Windows::Media::SpeechSynthesis::VoiceGender’ has a previous declaration here 218 | typedef enum VoiceGender VoiceGender; | ^~~~~~~~~~~ /usr/x86_64-w64-mingw32/include/windows.media.speechsynthesis.h:822:30: error: using typedef-name ‘ABI::Windows::Media::SpeechSynthesis::VoiceGender’ after ‘enum’ 822 | enum VoiceGender *value) = 0; | ^~~~~~~~~~~ /usr/x86_64-w64-mingw32/include/windows.media.speechsynthesis.h:218:42: note: ‘ABI::Windows::Media::SpeechSynthesis::VoiceGender’ has a previous declaration here 218 | typedef enum VoiceGender VoiceGender; ``` windows.media.speechsynthesis.idl has typedef of enum VoiceGender, which is defined later. ``` namespace Windows { namespace Foundation { interface IClosable; } namespace Media { namespace SpeechSynthesis { typedef enum VoiceGender VoiceGender; ``` This is translated to following: ``` #ifdef __cplusplus namespace ABI { namespace Windows { namespace Media { namespace SpeechSynthesis { typedef enum VoiceGender VoiceGender; } } } } #else /* __cplusplus */ typedef enum __x_ABI_CWindows_CMedia_CSpeechSynthesis_CVoiceGender __x_ABI_CWindows_CMedia_CSpeechSynthesis_CVoiceGender; #endif /* __cplusplus */ ``` This typedef is not valid in C++. According to the standard, enum cannot be forward declared using typedef. This could be replaced with just simple enum declaration, but it would need to have type specifier (that goes for definition as well). Best 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 1