June 2024 - Wine-gitlab - list.winehq.org

Re: [PATCH v2 0/1] MR5909: comctl32/listview: Prevent LISTVIEW_GetNextItem failure after checking last item state in list
by Ilia Docin (＠IDocin) 26 Jun '24

26 Jun '24

On Wed Jun 26 07:26:50 2024 +0000, Zhiyi Zhang wrote: > This looks correct at first glance. Do you have an application affected > by this? It seems to me changing this only reduces some time and -1 will > be returned if it's the last item. Yes, I have. It fails on asserting return value of sending LVM_GETNEXTITEM message. I agree about aftereffect of this fix. Anyway, for me it doesn't make sense to handle ahead of time incorrect item (== infoPtr->nItemCount). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5909#note_74482

1 0

Re: [PATCH v5 0/1] MR5706: comctl32/rebar: Hide chevron if rebar's band is resized back to full size with gripper
by Ilia Docin (＠IDocin) 26 Jun '24

26 Jun '24

On Wed Jun 26 07:15:20 2024 +0000, Zhiyi Zhang wrote: > Do you have a link to the software you used to demonstrate? No. It's a commercial software. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5706#note_74478

1 0

[PATCH v2 0/6] MR5926: ntdll: Always fill the 32-bit IOSB when performing I/O on overlapped handles.
by Elizabeth Figura (＠zfigura) 26 Jun '24

26 Jun '24

Previously it was assumed that synchronous I/O fills the 64-bit IOSB, and asynchronous I/O fills the 32-bit IOSB. As the ntdll:wow64 tests show, this is incorrect. I/O on an overlapped handle, whether it is synchronous or not, fills the 32-bit IOSB, and I/O on a non-overlapped handle always fills the 64-bit IOSB. The first half is important, since completion can be signaled before we even return from the initial I/O call [NtReadFile() etc.] Filling the IOSB after signaling completion is the cause of bug 56389. This patch series fixes that. The second discrepancy does not cause any bugs, as far as I can see, and is a bit harder to fix anyway. It is therefore not addressed by this patch series. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56389 -- v2: ntdll: Always fill the 32-bit iosb for overlapped handles, for regular read/write. ntdll: Always fill the 32-bit iosb for overlapped handles, in set_async_direct_result(). ntdll: Always fill the 32-bit iosb for overlapped handles, in file_complete_async(). https://gitlab.winehq.org/wine/wine/-/merge_requests/5926

2 7

[PATCH 0/10] MR5934: ntdll: Improvements related to preferred UI languages
by Piotr Caban (＠piotr) 26 Jun '24

26 Jun '24

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

2 10

[PATCH v4 0/6] MR5870: mmdevapi: Implement loopback capture with winepulse backend.
by Paul Gofman (＠gofman) 26 Jun '24

26 Jun '24

-- v4: mmdevapi/tests: Add test for capturing render loopback. winepulse.drv: Implement pulse_get_loopback_capture_device(). winepulse.drv: Factor out wait_pa_operation_complete(). mmdevapi: Stub AUDCLNT_STREAMFLAGS_LOOPBACK support. mmdevapi: Adjust timing after main loop start in client_Initialize(). https://gitlab.winehq.org/wine/wine/-/merge_requests/5870

4 9

[PATCH 0/6] MR5926: ntdll: Always fill the 32-bit IOSB when performing I/O on overlapped handles.
by Elizabeth Figura (＠zfigura) 26 Jun '24

26 Jun '24

Previously it was assumed that synchronous I/O fills the 64-bit IOSB, and asynchronous I/O fills the 32-bit IOSB. As the ntdll:wow64 tests show, this is incorrect. I/O on an overlapped handle, whether it is synchronous or not, fills the 32-bit IOSB, and I/O on a non-overlapped handle always fills the 64-bit IOSB. The first half is important, since completion can be signaled before we even return from the initial I/O call [NtReadFile() etc.] Filling the IOSB after signaling completion is the cause of bug 56389. This patch series fixes that. The second discrepancy does not cause any bugs, as far as I can see, and is a bit harder to fix anyway. It is therefore not addressed by this patch series. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56389 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5926

3 7

[PATCH 0/5] MR5932: Cmd engine rewrite (part X)
by eric pouech (＠epo) 26 Jun '24

26 Jun '24

This is part X of cmd engine rewrite. This serie: - tackles some other variable expansion issues, - attaches redirections to CMD_NODE (where it belongs) (eg. "> foo (IF 1==1 echo a)" is a valid command), - preparing for next serie. Next serie will activate he updated lexer and parser. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5932

2 5

[PATCH v3 0/3] MR5915: include: Tweak atexit and cpuid declarations, guard DECLSPEC_UUID definition.
by Rémi Bernon 26 Jun '24

26 Jun '24

IIUC atexit isn't exported by ucrtbase, but still exists (maybe as a builtin) and is resolved to a module-local symbol which can be used to register functions executed on module process detach. It is called implicitly by C++ compilers to register static destructors. -- v3: include: Define __cpuid(ex) as intrinsics when _MSC_VER is defined. include: Don't import atexit when building with ucrtbase. include: Guard rpcndr.h DECLSPEC_UUID definition. https://gitlab.winehq.org/wine/wine/-/merge_requests/5915

1 4

[PATCH v2 0/3] MR5923: winegstreamer: Use affinity to determine 'max-threads' value.
by Brendan McGrath (＠redmcg) 26 Jun '24

26 Jun '24

GStreamer uses _SC_NPROCESSORS_CONF to determine 'max-threads'. On the Steam Deck, this is configured to be 16 (which is double its number of logical cores). _SC_NPROCESSORS_CONF also disregards a process's CPU affinity, thus it can create more threads than is useful, which ultimately wastes memory resources. Using affinity to set 'max-threads' addresses both these problems. -- v2: winegstreamer: Set MAX_THREADS to 4 for i386. winegstreamer: Use thread_count to determine 'max-threads' value. winegstreamer: Provide thread_count to init_gstreamer. https://gitlab.winehq.org/wine/wine/-/merge_requests/5923

4 11

[PATCH 0/5] MR5865: win32u: Move some invisible surface conditions out of the drivers.
by Rémi Bernon 26 Jun '24

26 Jun '24

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

2 18