November 2022 - Wine-bugs - list.winehq.org

[Bug 53828] New: LINUX RUNNING FOXPRO 6.0 DDE to MSFT WORD97 FAILURE
by WineHQ Bugzilla 01 Nov '22

01 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=53828 Bug ID: 53828 Summary: LINUX RUNNING FOXPRO 6.0 DDE to MSFT WORD97 FAILURE Product: Wine Version: 5.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: ookay1980(a)yahoo.com.hk Distribution: --- Created attachment 73358 --> https://bugs.winehq.org/attachment.cgi?id=73358 backtrace dump after WINE abend Under LINUX MINT 20.2 (LOCALE is set to BIG5 Hong Kong) I run MSFT Visual Fox Pro 6.0 and MSFT OFFICE 97 Pro SR2 (Chinese Hong Kong version) The VFP program tried to DDE to WORD97 and run a MACRO to open a DOCUMENT. When I run it in normal WINDOWS ME and WINDOWS XP, it will switch to WORD97 and ran the MACRO to display the WORD DOCUMENT smoothly and automatically. When I run it in LINUX MINT 20.2 and WINE 5.0 It does not switch to WORD97. I have to manually switch to WORD97. The Macro seem to run OK as it displayed the DOC and allowed me to edit the DOC. However, after a few more CLICKs on the WORD screen, WINE abended (the backtrace.txt is saved and attached) Normally when I run OFC97 under WINE without the VFP DDE stuff, it works fine with only some minor issues. It seem to also have some DDE registration issue. -- 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 47990] New: Wine64: Candidate of CJK input method is invisible on macOS Catalina.
by WineHQ Bugzilla 01 Nov '22

01 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=47990 Bug ID: 47990 Summary: Wine64: Candidate of CJK input method is invisible on macOS Catalina. Product: Wine Version: 4.18 Hardware: x86-64 OS: Mac OS X Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: jactry92(a)gmail.com Created attachment 65509 --> https://bugs.winehq.org/attachment.cgi?id=65509 WINEDEBUG=+tid,+pid,+imm,+keyboard,+key,+macdrv Tested with wine-4.18-112-g717109ce79: 1. $ wine64 notepad 2. Switch to Chinese Pinyin input method, and try to type something You will find that candidate didn't display, though you still can type some Chinese characters into notepad with the input method. I didn't see similar on macOS 10.14, so I think this is a Catalina special issue. -- 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 53770] New: [ nls cause BUG ] local.nls should must be update (./wine/nls/local.nls )
by WineHQ Bugzilla 01 Nov '22

01 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=53770 Bug ID: 53770 Summary: [ nls cause BUG ] local.nls should must be update (./wine/nls/local.nls ) Product: Wine Version: 7.18 Hardware: x86 OS: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: 399989567(a)qq.com In China, there is a popular student software called DingTalk, in which the APP reads the sNativeDigits value in the registry (/HKEY_USERS/S-X-XX-XX/Control Panel International -> sNativeDigits) during getting the meeting time. Through research, I found that This value is obtained by the function get_locale_info, and the specific location is as follows: > case LOCALE_SNATIVEDIGITS: > if ((ret = locale_return_reg_string( &entry_scurrency, type, buffer, len )) != -1) return ret; > return locale_return_string( locale->scurrency, type, buffer, len ); Now, in wine7.12 to 7.18, for the Chinese environment (LOCALE_SNATIVEDIGITS), the sNativeDigits read from local.nls is "零一二三四五六七八九", but this is unreasonable, I checked the Windows10 registry and found that its value should be It is "0123456789" And if it is "零一二三四五六七八九", the program will have an error > The timer is displayed as Chinese characters, and the actual display of "一" is not "一" but "《", it's so strange , so I think we should update local.nls or modify the get_locale_info function. *** update local.nls：*** I would like to ask how the local.nls in wine is generated, is it directly used in windows? I once wanted to modify local.nls directly to fix this problem, but it seems to be a binary file, and I don't know how it is generated in wine, so I I don't know how to modify local.nls by myself. [HELP] If you have time, I would like to ask how the nls file is generated in wine *** modify the get_locale_info function：*** I have completed the modification of the function (assignment in the Chinese environment, other environments do not operate), if you need I can provide the source code directly. ————————— I hope that I can ask about the modification of the nls file, and complete the modification through my own efforts, so that I can also join the big project of wine, which is meaningful and interesting to me. Thanks very much, Looking forward to your reply。 Yous: SvenL -- 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 37

[Bug 53857] New: [ fontconfig ] Questions about some font selection logic
by WineHQ Bugzilla 01 Nov '22

01 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=53857 Bug ID: 53857 Summary: [ fontconfig ] Questions about some font selection logic Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: win32u Assignee: wine-bugs(a)winehq.org Reporter: 399989567(a)qq.com Distribution: --- Created attachment 73387 --> https://bugs.winehq.org/attachment.cgi?id=73387 Simsun Test My application uses "宋体" （Simsun） as the font of choice，which use WindowsAPI > SelectObject(hdc,hfont) When I set the property(lfPitchAndFamily) of "宋体" to 0x22(FF_SWISS) and 0x36(FF_MODERN), wine converts "宋体" into Noto Sans CJK SC and Noto Sans Mono CJK SC respectively. I looked at the source code because "宋体" is not installed on my computer, so when wine doesn't find any fonts, wine end up calling "find_any_face" API and entering the first loop, using "enum_fallbacks" API to find the fonts. When i > 3, which means the fonts in the default_fixed_list are not suitable,Wine uses "fontconfig_enum_family_fallbacks" API to find fonts through fontconfig. Here wine determines which type of font the "宋体" belongs to (serif, sans-serif, monospaced) based on the "lfPitchAndFamily" attribute of the "宋体". So ended up returning a different font: > FF_SWISS -> fc-match "sans" -> Noto Sans CJK SC > FF_MODERN -> fc-match "mono" -> Noto Sans Mono CJK SC But it's not what I expected, I want "宋体" to return Noto Sans CJK SC forever,and on my computer when I use ' $ fc-match "宋体" ', it returns "Noto Sans CJK SC". I konw "宋体" became "Noto Sans Mono CJK SC" is becaues wine design. But, I would like to ask why not directly use fontconfig to find fonts according to the font name in the "fontconfig_enum_family_fallbacks" function, but to search according to the font type. ues fc-match "fontname" instead of fc-match "sans or mono or serif" Is it because using fontconfig is a very resource-intensive thing, so wine divides the fonts into three types, and stores the results of the three fonts in the cache, so that the cache can be directly read the next time it is called? I don't know if my description is correct, feel free to contact me if you have any questions ———————————— export LC_ALL=zh_CN.UTF-8 and run my exe file the first line is "宋体" 0x36 -> became Mono the second line is "宋体" 0x22 -> became Sans Don't mind the third and fourth lines -- 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