April 2022 - Wine-Bugs - list.winehq.org

[Bug 52880] Improve software components also for using “HWiNFO”

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=52880 --- Comment #5 from Artem S. Tashkinov <aros(a)gmx.com> --- Please avoid treating Wine as a magical application which brings Windows to Linux. It does not. It brings selected user level APIs from Windows to Linux. -- 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.

April 30, 2022

[Bug 52880] Improve software components also for using “HWiNFO”

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=52880 --- Comment #4 from Artem S. Tashkinov <aros(a)gmx.com> --- The following bugs are all invalid and can be safely closed. This is bugzilla, not "I wish to get $1 000 000 because I feel like it". Namely: Bug 52878 Bug 52879 Bug 52880 Bug 52881 All these applications cannot provide full information for a simple reason: they include kernel level drivers which will never work under Wine because 1) Wine is a userspace application (these applications require Administrator privileges under Windows) 2) Implementing direct RAM/IO access for Wine is an absolute no-go as it carries a ton of security risks. -- 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.

April 30, 2022

[Bug 52354] winemac.drv not functional on non metal GPUs

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=52354 --- Comment #18 from Gcenx <gcenx83(a)gmail.com> --- Created attachment 72307 --> https://bugs.winehq.org/attachment.cgi?id=72307 wine-7.0 32Bit build attempt MacOSX10.13.sdk -- 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.

April 30, 2022

[Bug 52354] winemac.drv not functional on non metal GPUs

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=52354 --- Comment #17 from Gcenx <gcenx83(a)gmail.com> --- I've tried to compile wine-7.0 with this patch but winemac.drv fails. Firstly needed to use at least MacOSX10.12.sdk due to :info:build /opt/local/var/macports/build/_Users_gcenx_ports_x11_wine-stable/wine-stable/work/wine-wine-7.0/dlls/winemac.drv/cocoa_window.m:348:44: error: cannot find protocol declaration for 'CALayerDelegate'; did you mean 'NSDrawerDelegate'? Even using MacOSX10.13.SDK the build winemac.drv also fails :info:build dlls/winemac.drv/cocoa_window.m:476:37: error: sending 'CGRect' (aka 'struct CGRect') to parameter of incompatible type 'NSRect' (aka 'struct _NSRect') :info:build self = [super initWithFrame:frame]; :info:build ^~~~~ :info:build /opt/local/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSView.h:130:39: note: passing argument to parameter 'frameRect' here :info:build - (instancetype)initWithFrame:(NSRect)frameRect NS_DESIGNATED_INITIALIZER; :info:build ^ :info:build dlls/winemac.drv/cocoa_window.m:523:47: error: sending 'NSRect' (aka 'struct _NSRect') to parameter of incompatible type 'CGRect' (aka 'struct CGRect') :info:build [self.layer setNeedsDisplayInRect:[self convertRectToLayer:rect]]; -- 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.

April 30, 2022

[Bug 52934] wine can't load ntdll.so on asahi linux (apple M1 hardware, linux kernel/userland)

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=52934 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish(a)gmail.com -- 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.

April 30, 2022

[Bug 52929] Sleeping Dogs hangs at startup with the Vulkan renderer

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=52929 --- Comment #3 from Maxime <berillions(a)gmail.com> --- (In reply to Zeb Figura from comment #2) > This works for me with current git. In particular I expect > <https://source.winehq.org/git/wine.git/commitdiff/ > 27e84c28972ab53e11c932cb67ff5182894c1f27> may have made a difference here. > Can you please retest with current git or with 7.8 when it is released? Tried wine-git and yeah the game runs now. But when i change the graphics settings preset (Normal -> Extreme), i have the same symptom than before. The game hangs my desktop and i need to hard reboot. -- 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.

April 29, 2022

[Bug 52937] msvcr110:msvcr110 fails on Windows with the UTF-8 codepage

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=52937 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source, testcase -- 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.

April 29, 2022

[Bug 52937] New: msvcr110:msvcr110 fails on Windows with the UTF-8 codepage

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=52937 Bug ID: 52937 Summary: msvcr110:msvcr110 fails on Windows with the UTF-8 codepage Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: msvcrt Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com msvcr110:msvcr110 fails on Windows with the UTF-8 codepage: msvcr110.c:135: Test failed: expected syr-SY, got LC_COLLATE=syr-SY;LC_CTYPE=EN-US;LC_MONETARY=syr-SY;LC_NUMERIC=syr-SY;LC_TIME=syr-SY https://test.winehq.org/data/patterns.html#msvcr110:msvcr110 Note that the LC_CTYPE value in the above string corresponds to the last value it was set to. So if one tests fr-FR right before syr-SY the string contains LC_CTYPE=fr-FR. This is also why the en-US case is weird. Furthermore with a non-UTF-8 codepage setlocale() does return "syr-SY". So it looks like: 1. msvcr110 returns a long string specifying the details of the locale settings whenever they have different values. 2. msvcr110 does not support setting LC_CTYPE to syr-SY, but only when the codepage is UTF-8 for whatever reason. -- 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.

April 29, 2022

[Bug 52936] winhttp:url assumes 0xfb00 cannot be converted to the ANSI codepage, fails with UTF-8 codepage

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=52936 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source, testcase -- 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.

April 29, 2022

[Bug 52936] New: winhttp:url assumes 0xfb00 cannot be converted to the ANSI codepage, fails with UTF-8 codepage

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=52936 Bug ID: 52936 Summary: winhttp:url assumes 0xfb00 cannot be converted to the ANSI codepage, fails with UTF-8 codepage Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: winhttp Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com winhttp:url assumes 0xfb00 cannot be converted to the ANSI codepage and thus fails fails on Windows with the UTF-8 codepage: url.c:306: Test failed: expected failure url.c:307: Test failed: got 0 url.c:346: Test failed: expected failure url.c:347: Test failed: got 0 https://test.winehq.org/data/patterns.html#winhttp:url These two pairs of failures happen when calling WinHttpCreateUrl() on the following URLs respectively: 39 static WCHAR escape3[] = {'?','t','e','x','t','=',0xfb00,0}; 40 static WCHAR escape4[] = {'/','t','e','x','t','=',0xfb00,0}; So maybe these tests should be skipped when running in a UTF-8 locale since it's supposed to be able to handle any UTF-16 codepoint. What is surprising is that this test does not fail on debian11-hi-IN (where GetACP()==UTF-8). That looks like a bug too. The tests were introduced in this commit: commit 7e5b5cb1aa253ce2f20a790989d0f18bcbcab946 Author: Hans Leidekker <hans(a)codeweavers.com> Date: Tue Nov 6 16:09:04 2018 +0100 winhttp: Properly handle request paths with Unicode characters. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=46076 Signed-off-by: Hans Leidekker <hans(a)codeweavers.com> Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> -- 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.

April 29, 2022