May 2025 - Wine-gitlab - list.winehq.org

[PATCH v2 0/2] MR7893: user32/tests: Test BeginPaint() clipbox of cropped window with CS_PARENTDC.
by Dmitry Timoshkov (＠dmitry) 05 May '25

05 May '25

Extracted from https://gitlab.winehq.org/wine/wine/-/merge_requests/5665. -- v2: user32/tests: Add a message test for listbox redrawing after LB_SETCOUNT. user32/tests: Test BeginPaint() clipbox of cropped window with CS_PARENTDC. https://gitlab.winehq.org/wine/wine/-/merge_requests/7893

4 6

[PATCH 0/4] MR7967: wineandroid, winemac, winewayland, winex11: Remove now unnecessary GL function loading.
by Rémi Bernon 05 May '25

05 May '25

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/7967

1 4

[PATCH 0/1] MR7961: msvcrt: Fix buffer overflow in __STRINGTOLD_L
by Yuxuan Shui (＠yshui) 05 May '25

05 May '25

__STRINGTOLD_L expects a pointer to a `_LDOUBLE` as its first argument, which we internally declare as `MSVCRT__LDOUBLE`. Problem is, `_LDOUBLE` is 10 bytes long, whereas `MSVCRT__LDOUBLE` is 12 bytes long (ULONG * 3). Writing into the third ULONG is technically a buffer overflow. Declare `MSVCRT__LDOUBLE` instead as 2 ULONGs plus a USHORT. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7961

5 4

[PATCH 0/1] MR7958: opcservices: Fix string comparison in opc_part_uri_get_rels_uri.
by Alex Henrie (＠alexhenrie) 05 May '25

05 May '25

This has to have been a mistake: It doesn't make sense to look at the first two-and-a-half characters of relsdirW. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7958

3 2

[PATCH v2 0/3] MR6408: odbc32: Handle odbcv2 for GetData
by Alistair Leslie-Hughes (＠alesliehughes) 05 May '25

05 May '25

-- v2: odbc32: SQLColAttributesW support ODBC v2.0 odbc32: SQLGetData support ODBC v2.0 odbc32: Record loaded driver SQL_ATTR_ODBC_VERSION https://gitlab.winehq.org/wine/wine/-/merge_requests/6408

2 3

[PATCH 0/3] MR7943: windowscodecs: Fix information strings for the Ico decoder.
by Nikolay Sivov (＠nsivov) 05 May '25

05 May '25

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7943

3 4

[PATCH v2 0/2] MR7942: windowscodecs/tests: Add a test for 24bpp TIFF with separate sample planes.
by Nikolay Sivov (＠nsivov) 05 May '25

05 May '25

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- v2: windowscodecs/tiff: Add support for files with separate planes. https://gitlab.winehq.org/wine/wine/-/merge_requests/7942

3 3

[PATCH 0/3] MR7941: windowscodecs/tests: Use wide-char literals in tests.
by Nikolay Sivov (＠nsivov) 05 May '25

05 May '25

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7941

3 4

[PATCH 0/2] MR7893: user32/tests: Test BeginPaint() clipbox of cropped window with CS_PARENTDC.
by Dmitry Timoshkov (＠dmitry) 05 May '25

05 May '25

Extracted from https://gitlab.winehq.org/wine/wine/-/merge_requests/5665. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7893

4 4

Re: [PATCH v3 0/1] MR7824: winegstreamer: Handle the Stream Group Done event.
by Brendan McGrath (＠redmcg) 04 May '25

04 May '25

On Fri May 2 17:55:41 2025 +0000, Elizabeth Figura wrote: > > > I guess native is supposed to not block in that case > > > > That's a good point. If we have two streams call > `IMFMediaStream::RequestSample`, then we will process them in sequence > rather than in parallel. That is, one stream will have to wait for the > other to receive data (as we block all other streams once the source cs > is acquired in `source_async_commands_Invoke`). > > > > This MR will at least unblock a stream when there is no more data, but > Windows probably delivers data for the other stream immediately (i.e. it > can deliver data for one stream, even if the other was already waiting). > And I believe I recall seeing audio latency in Wine as a result of this. > From memory, it was a 4K video, so delivery of the video sample took a > while and as a result the audio fell behind. We should probably look to > lock the individual streams rather than the entire source when possible. > Hrm, I didn't think we had a locking problem, but if we do that should > be fixed, yeah. I'll have a think about how I can test this. I might be able to craft a file that'll delay one of the streams long enough, that whilst waiting for a sample, I can reliably request and receive a sample on the other. Thanks for the review. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7824#note_102482

1 0