August 2023 - Wine-Bugs - list.winehq.org

[Bug 54194] user32:msg - test_broadcast() sometimes fails to send WM_USER-1 on Windows 7

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=54194 --- Comment #3 from François Gouget <fgouget(a)codeweavers.com> --- Note for myself: UIPI == User Interface Privilege Isolation https://en.wikipedia.org/wiki/User_Interface_Privilege_Isolation Given that this happens while sending a broadcast this would happen whenever a "high integrity-level" system process is running and thus the target of our test broadcast messages. So the only way to avoid that would be to restrict our test to one of the "very specific set of allowed UI messages" but I'm not sure that makes sense for the test. Otherwise the test would have to ignore permission denied errors. At least on Windows 7. Question is then: why don't we get this issue on newer Windows versions? Did MS drop UIPI? Or do we just never have high "integrity-level" processes running on newer Windows versions? Can we dump information on the process triggering the errors? (in user32:clipboard I had a hack to trace an hwnd's GetClassNameA() and GetWindowTextA() which helped identify the cause of some failures) -- 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.

Aug. 31, 2023

[Bug 55446] Using C run-time for unicode strings comparison breaks case insensitive LB_FINDSTRING

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=55446 --- Comment #4 from Dmitry Timoshkov <dmitry(a)baikal.ru> --- (In reply to Alexandre Julliard from comment #3) > (In reply to Dmitry Timoshkov from comment #2) > > (In reply to Alexandre Julliard from comment #1) > > > (In reply to Dmitry Timoshkov from comment #0) > > > > Under Windows SendMessageW(LB_FINDSTRING) works just fine regardless of > > > > system locale. > > > > > > Of course that depends how we define "works just fine" ;-) > > > > It means that LB_FINDSTRING returns index of the correct listbox item. > > There's no single "correct" answer for case-insensitive string matching. In which case returning an expected item index could not be correct? > > > I agree we don't want to use the C locale, but should it use the user locale > > > instead? Or the thread locale? Or the default Unicode mapping table? Some > > > tests would be interesting. > > > > I'd guess that listbox is supposed to use the locale set by LB_SETLOCALE > > like it already does in other places of the code, that way it used to work > > before the problematic commit. > > It never used the locale for partial matches, it was using the default > Unicode mapping table. > > It uses the locale for exact matching, but it's not clear that this is > correct either, because there are no tests, and because we didn't support > locale-specific matching when the locale support was implemented. This > really needs proper tests. Probably that kind of tests should have been added during the code changes similar to the commit that introduced the regression. It doesn't look fair to request adding the tests from the reporter of the bug. Are you planning to ask the commit author to add the tests to make sure that the proposed changes don't inroduce the regression, or revert the commit otherwise? :) -- 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.

Aug. 31, 2023

[Bug 53385] Vulkan was running really fine, before MESA/Xorg Update last month, current version crashes

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53385 Henri Verbeet <hverbeet(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |NOTOURBUG Status|NEEDINFO |RESOLVED -- 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.

Aug. 31, 2023

[Bug 55446] Using C run-time for unicode strings comparison breaks case insensitive LB_FINDSTRING

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=55446 --- Comment #3 from Alexandre Julliard <julliard(a)winehq.org> --- (In reply to Dmitry Timoshkov from comment #2) > (In reply to Alexandre Julliard from comment #1) > > (In reply to Dmitry Timoshkov from comment #0) > > > Under Windows SendMessageW(LB_FINDSTRING) works just fine regardless of > > > system locale. > > > > Of course that depends how we define "works just fine" ;-) > > It means that LB_FINDSTRING returns index of the correct listbox item. There's no single "correct" answer for case-insensitive string matching. > > I agree we don't want to use the C locale, but should it use the user locale > > instead? Or the thread locale? Or the default Unicode mapping table? Some > > tests would be interesting. > > I'd guess that listbox is supposed to use the locale set by LB_SETLOCALE > like it already does in other places of the code, that way it used to work > before the problematic commit. It never used the locale for partial matches, it was using the default Unicode mapping table. It uses the locale for exact matching, but it's not clear that this is correct either, because there are no tests, and because we didn't support locale-specific matching when the locale support was implemented. This really needs proper tests. -- 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.

Aug. 31, 2023

[Bug 55446] Using C run-time for unicode strings comparison breaks case insensitive LB_FINDSTRING

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=55446 --- Comment #2 from Dmitry Timoshkov <dmitry(a)baikal.ru> --- (In reply to Alexandre Julliard from comment #1) > (In reply to Dmitry Timoshkov from comment #0) > > Under Windows SendMessageW(LB_FINDSTRING) works just fine regardless of > > system locale. > > Of course that depends how we define "works just fine" ;-) It means that LB_FINDSTRING returns index of the correct listbox item. > I agree we don't want to use the C locale, but should it use the user locale > instead? Or the thread locale? Or the default Unicode mapping table? Some > tests would be interesting. I'd guess that listbox is supposed to use the locale set by LB_SETLOCALE like it already does in other places of the code, that way it used to work before the problematic commit. -- 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.

Aug. 31, 2023

[Bug 51327] GdipCreateFont initializes font with ANSI_CHARSET

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=51327 --- Comment #7 from Rafał Mużyło <galtgendo(a)o2.pl> --- Indeed. I never said it did, just making sure *you* knew it didn't. -- 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.

Aug. 31, 2023

[Bug 55131] Celeste FNA x86 Windows Game has graphical corruption on WOW64

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=55131 --- Comment #18 from Rafał Mużyło <galtgendo(a)o2.pl> --- ...PS: just make sure it's the 32bit variant of the lib. -- 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.

Aug. 31, 2023

[Bug 55131] Celeste FNA x86 Windows Game has graphical corruption on WOW64

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=55131 --- Comment #17 from Rafał Mużyło <galtgendo(a)o2.pl> --- Note the emphasis: > loaddll:build_module Loaded L"Z:\\home\\garrett\\windows-applications\\celeste-win-opengl\\d3dcompiler_47.dll" at 63500000: *builtin* Did you just copy one of the wine's libs there ? 'Native' means the native for Windows i.e. the one from DirectX package. Alternatively, quite a few games bundle it, for example AFAIK all node-webkit RPGMaker games do. One way of recognizing it was done correctly will be that regardless if it helps, the vkd3d messages will be gone, as those come only from the wine 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.

Aug. 31, 2023

[Bug 51327] GdipCreateFont initializes font with ANSI_CHARSET

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=51327 --- Comment #6 from Bartosz <gang65(a)poczta.onet.pl> --- GdipGetFamilyName doesn't support different languages: https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/gdiplus/font.c#L798 -- 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.

Aug. 31, 2023

[Bug 52092] Multiple UWP apps crash at start due to missing "Windows.Foundation.UniversalApiContract" (Xbox app for Windows PC, Minecraft installer)

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=52092 --- Comment #6 from safe.bell6727(a)alistair23.me --- Same issue on Wine 8.14, I have attached a full backtrace -- 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.

Aug. 31, 2023