- Wine-Devel - list.winehq.org

[PATCH v4 1/8] server: Actually set initial status in set_async_direct_result handler.
by Jinoh Kang June 19, 2022

June 19, 2022

Commit 15483b1a126 (server: Allow calling async_handoff() with status code STATUS_ALERTED., 2022-02-10) introduced the set_async_direct_result handler which calls async_set_initial_status(). However, the async_set_initial_status() call does nothing since async->terminated is set, leaving the async in a confusing state (unknown_status = 1 but pending/completed). So far, this issue is unlikely to have been a problem in practice for the following reasons: 1. async_set_initial_status() would have unset unknown_status, but it remains set instead. This is usually not a problem, since unknown_status is usually ever read by code paths effectively unreachable for non-device (e.g. socket) asyncs. It would still potentially allow set_async_direct_result to be called multiple times, but it wouldn't actually happen in practice unless something goes wrong. 2. async_set_initial_status() would have set initial_status; however, it is left with the default value STATUS_PENDING. If the actual status is something other than that, the handler closes the wait handle and async_satisfied (the only realconsumer of initial_status) would never be called anyway. For reasons above, this issue is not effectively observable or testable. Nonetheless, the current code does leave the async object in an inconsistent state. Fix this by removing the !async->terminated check in async_set_initial_status(). Signed-off-by: Jinoh Kang <jinoh.kang.kr(a)gmail.com> --- Notes: v1 -> v2: no changes v2 -> v3: no changes v3 -> v4: reuse async_set_initial_status() per feedback server/async.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/server/async.c b/server/async.c index 7d0ff10f7a4..e92d4583c1e 100644 --- a/server/async.c +++ b/server/async.c @@ -303,11 +303,8 @@ struct async *create_async( struct fd *fd, struct thread *thread, const async_da void async_set_initial_status( struct async *async, unsigned int status ) { assert( async->unknown_status ); - if (!async->terminated) - { - async->initial_status = status; - async->unknown_status = 0; - } + async->initial_status = status; + async->unknown_status = 0; } void set_async_pending( struct async *async ) -- 2.34.1

3 10

[PATCH v2 0/1] MR274: winedbg: Fix typos in manpage.
by Jinoh Kang (＠iamahuman) June 18, 2022

June 18, 2022

Signed-off-by: Jinoh Kang <jinoh.kang.kr(a)gmail.com> -- v2: winedbg: Fix typos in manpage. https://gitlab.winehq.org/wine/wine/-/merge_requests/274

2 1

[PATCH 0/1] MR274: winedbg: Fix typos in manpage.
by Jinoh Kang (＠iamahuman) June 18, 2022

June 18, 2022

Signed-off-by: Jinoh Kang <jinoh.kang.kr(a)gmail.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/274

3 2

[PATCH 0/1] MR276: include: Add _tcsto[u]ll declarations.
by Daniel Lehman (＠dlehman25) June 18, 2022

June 18, 2022

Signed-off-by: Daniel Lehman <dlehman25(a)gmail.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/276

2 1

[PATCH 0/4] MR275: ntdll: Plumb zero_bits parameter from virtual_map_section to virtual_map_builtin_module.
by Brendan Shanks (＠bshanks) June 18, 2022

June 18, 2022

When running a 32-bit EXE in Wow64 mode with a fairly full address space, a builtin DLL may be loaded above the 4GB line. This is due to virtual_map_builtin_module calling virtual_map_image with zero_bits hardcoded to 0. virtual_map_section is called with the correct zero_bits, this patch propagates that parameter down through load_builtin, find_builtin_dll, open_builtin_pe_file, and virtual_map_builtin_module. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/275

2 4

[PATCH v2 0/9] MR272: d3dx10: Add D3DX10CreateThreadPump implementation.
by Piotr Caban (＠piotr) June 18, 2022

June 18, 2022

The GetWorkItemCount implementation may look strange. It's done this way because of how WaitForAllItems is implemented. Alternative solution is to introduce separate counter for GetWorkItemCount. -- v2: d3dx10/tests: Add D3DX10CreateThreadPump tests. d3dx10: Add ID3DX10ThreadPump:PurgeAllItems implementation. d3dx10: Add ID3DX10ThreadPump:GetQueueStatus implementation. d3dx10: Add ID3DX10ThreadPump:WaitForAllItems implementation. d3dx10: Add ID3DX10ThreadPump:ProcessDeviceWorkItems implementation. d3dx10: Add ID3DX10ThreadPump:GetWorkItemCount implementation. d3dx10: Add ID3DX10ThreadPump:AddWorkItem implementation. d3dx10: Add D3DX10CreateThreadPump stub. d3dx10/tests: Fix texture leak in check_resource_data. https://gitlab.winehq.org/wine/wine/-/merge_requests/272

2 9

[PATCH 0/8] MR272: d3dx10: Add D3DX10CreateThreadPump implementation.
by Piotr Caban (＠piotr) June 18, 2022

June 18, 2022

The GetWorkItemCount implementation may look strange. It's done this way because of how WaitForAllItems is implemented. Alternative solution is to introduce separate counter for GetWorkItemCount. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/272

4 11

How to identify the primary battery (for Wine)
by Alex Henrie June 18, 2022

June 18, 2022

Hi Sebastian, I've been working to improve battery status reporting for applications running on Wine on Linux. However, we Wine developers are not sure what the best way is to determine which battery is the computer's primary battery. Could you take a look at https://gitlab.winehq.org/wine/wine/-/merge_requests/134 and leave a comment there or on the wine-devel mailing list? Thanks in advance, -Alex

4 6

[PATCH v2 0/1] MR273: ntdll/tests: Add more tests for \Device\NamedPipe\ root directory.
by Jinoh Kang (＠iamahuman) June 18, 2022

June 18, 2022

Signed-off-by: Jinoh Kang <jinoh.kang.kr(a)gmail.com> -- v2: ntdll/tests: Add more tests for \Device\NamedPipe\ root directory. https://gitlab.winehq.org/wine/wine/-/merge_requests/273

2 1

[PATCH 0/1] MR273: ntdll/tests: Add more tests for \Device\NamedPipe\ root directory.
by Jinoh Kang (＠iamahuman) June 18, 2022

June 18, 2022

Signed-off-by: Jinoh Kang <jinoh.kang.kr(a)gmail.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/273

2 1