list.winehq.org
Sign In Sign Up
Manage this list Sign In Sign Up

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview

Wine-GitLab

Threads by month
  • ----- 2026 -----
  • March
  • February
  • January
  • ----- 2025 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2024 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2023 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2022 -----
  • December
  • November
  • October
  • September
  • August
  • July
wine-gitlab@list.winehq.org

May 2025

  • 1 participants
  • 858 discussions
[PATCH 0/1] MR7900: d2d1: Compile shaders on device creation instead of device context creation.
by Francisco Casas (@fcasas) May 15, 2025

May 15, 2025
Some applications generate many device contexts each render frame. Thus, compling these shaders each time this happens might make them laggy. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7900
4 4
0 0
[PATCH 0/3] MR7889: ntoskrnl.exe/tests: Test that calling some Io functions does not result in...
by Alexander Morozov (@amorozov) May 15, 2025

May 15, 2025
This is a set of tests to prove the correctness of a fix for bug 57588 which i am going to send in a separate PR. Also a small fix for getting DevicePropertyEnumeratorName is included. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7889
3 4
0 0
[PATCH v7 0/1] MR7676: winegstreamer: Make sure WMSyncReader never reads in the background.
by Yuxuan Shui (@yshui) May 15, 2025

May 15, 2025
WMSyncReader starts a background read thread that reads from the IStream passed to IWMSyncReader::OpenStream. This means it could use the IStream in the background even when no IWMSyncReader methods are being called. For well-behaved applications, this is probably OK. However, AQUARIUM (Steam 2515070) frees the IStream it passes to WMSyncReader _before_ it calls IWMSyncReader::Close, which stops the read thread. This causes the read thread to access freed memory. This is improper, but not unreasonable, as IWMSyncReader is supposed to be a synchronous interface, so one might assume when they weren't calling into IWMSyncReader methods, the IStream won't be used. This commit adds a `wg_parser_dont_read` function, which can be used to stop wg_parser from issuing read requests. This is used by IWMSyncReader to make sure read requests are only issued when IWMSyncReader methods are being called. -- v7: winegstreamer: Make sure WMSyncReader never reads in the background. https://gitlab.winehq.org/wine/wine/-/merge_requests/7676
3 3
0 0
Re: [PATCH v4 0/1] MR7925: gdi32: Limit source string length in logfont_AtoW (ASan).
by Alex Henrie (@alexhenrie) May 15, 2025

May 15, 2025
On Fri May 2 16:52:15 2025 +0000, Rémi Bernon wrote: > This broke comctl32:status dwrite:font (win32/wow64) gdi32:font > user32:sysparams usp10:usp10 tests. I apologize for the stupid mistake. !7956 will fix it. Literally two minutes after I sent it, Bernhard sent an alternative fix in !7957 which would also be fine. I recognize that this happened primarily due to human error on my part. Nevertheless, another part of the problem is that the 32-bit tests always fail, and somehow this mistake did not cause the 64-bit tests to fail. That means that I need to spend some time helping with the intermittent test failures because they're making it too easy for me to overlook test failures that actually matter. Until the tests can be expected to pass, I will have to remember to read through the entire list of failures whenever I send a patch. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7925#note_102376
1 0
0 0
Re: [PATCH v4 0/1] MR7925: gdi32: Limit source string length in logfont_AtoW (ASan).
by Rémi Bernon May 15, 2025

May 15, 2025
On Fri May 2 16:52:15 2025 +0000, Alex Henrie wrote: > I apologize for the stupid mistake. !7956 will fix it. Literally two > minutes after I sent it, Bernhard sent an alternative fix in !7957 which > would also be fine. > I recognize that this happened primarily due to human error on my part. > Nevertheless, another part of the problem is that the 32-bit tests > always fail, and somehow this mistake did not cause the 64-bit tests to > fail. That means that I need to spend some time helping with the > intermittent test failures because they're making it too easy for me to > overlook test failures that actually matter. Until the tests can be > expected to pass, I will have to remember to read through the entire > list of failures whenever I send a patch. The test-linux-64 test suite only run a few tests that are otherwise skipped in a old/new wow64 environment like the one used for test-linux-32. It's maybe a bit confusing but it otherwise would use another runner from >30min and it wasn't deemed useful to have a full test coverage run on every config. The test-linux-32 sadly fails often, spuriously, although there have been up and downs I think it's getting better now and hopefully we'll get back to some occasional failures only. Nevertheless, Gitlab now shows a short summary of failing tests (in the MRs "Test summary:" section, which can be expanded for a detailed list of failures) and I think we should be able to quickly check MR failures, and compare with other MRs or the testbot pattern page, to decide whether they are likely related or not. Usually there's only a handful of spurious failures, with some well known returning failures, and a large number of/unusual failures should already still stand out, if we're paying attention. Fwiw I'm not blaming you specifically here, it happens quite often (and I can be blamed for a fair amount the last few months). I'm mostly making sure it doesn't go unnoticed and try to raise awareness. At least as long as things get caught and fixed quickly it's probably fine. Fixing spurious failures would be nice too but that's much more difficult than it seems. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7925#note_102379
1 0
0 0
[PATCH 0/1] MR7957: gdi32: Fix termination in destination string in logfont_AtoW.
by Bernhard Übelacker May 15, 2025

May 15, 2025
Followup of 1d3bfdc3ab. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7957
1 3
0 0
[PATCH 0/1] MR7954: msvcrt: Add truncf to the import library.
by Stefan Dösinger May 15, 2025

May 15, 2025
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58191 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7954
3 3
0 0
[PATCH v3 0/2] MR7780: win32u: Avoid uneeded (and sometimes harmful) RedrawWindow() calls in expose_window_surface().
by Paul Gofman (@gofman) May 15, 2025

May 15, 2025
-- v3: win32u: Don't inflate rect in expose_window_surface(). win32u: Don't redraw window in expose_window_surface() if window has surface. https://gitlab.winehq.org/wine/wine/-/merge_requests/7780
3 7
0 0
[PATCH v4 0/4] MR7934: mshtml: Validate builtin host functions in IE9+ using prototype_id rather than tid where possible.
by Gabriel Ivăncescu May 15, 2025

May 15, 2025
-- v4: mshtml: Remove unused struct mutation_observer_ctor. mshtml: Use designated initializers for the Location dispex data. mshtml: Validate builtin host functions in IE9+ using prototype_id rather mshtml: Store the object_id of the last object in the prototype chain that https://gitlab.winehq.org/wine/wine/-/merge_requests/7934
2 5
0 0
[PATCH 0/4] MR7955: secur32/tests: Fix NTLM tests on Windows 11.
by Piotr Caban (@piotr) May 15, 2025

May 15, 2025
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/7955
2 4
0 0
  • ← Newer
  • 1
  • ...
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • Older →

HyperKitty Powered by HyperKitty version 1.3.12.
Hosted in Mailman3.com