November 2022 - wine-gitlab

[PATCH v2 0/8] MR50: vkd3d-shader/hlsl: Add field-level documentation to the most important structs in hlsl.h. (v2) (PART 1/2)
by Francisco Casas (＠fcasas) 12 Dec '22

12 Dec '22

First part of v2 of !38, trying to follow the wide feedback provided. Following patches in: https://gitlab.winehq.org/fcasas/vkd3d/-/tree/documentation -- v2: vkd3d-shader/hlsl: Add field-level documentation to struct hlsl_src. vkd3d-shader/hlsl: Add field-level documentation to struct hlsl_ir_node. vkd3d-shader/hlsl: Add field-level documentation to struct hlsl_ctx. vkd3d-shader/hlsl: Add field-level documentation to struct hlsl_ir_var. vkd3d-shader/hlsl: Add field-level documentation to struct hlsl_struct_field. vkd3d-shader/hlsl: Add field-level documentation to struct hlsl_type. vkd3d-shader/hlsl: Rename hlsl_struct_field.modifiers to "storage_modifiers". vkd3d-shader/hlsl: Rename hlsl_ir_var.modifiers to "storage_modifiers". https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/50

4 14

[PATCH 0/1] MR1545: Draft: rpcrt4: Fix GCC12.2 warnings.
by eric pouech (＠epo) 08 Dec '22

08 Dec '22

GCC12.2 warns about dereferencing a pointer to RpcPktHdr while it has been allocated to the size of one of the packet (hence smaller in some cases). /home/eric/work/wine/dlls/rpcrt4/rpc_message.c:111:26: warning: array subscript 'RpcPktHdr[0]' is partly outside array bounds of 'unsigned char[24]' [-Warray-bounds] 111 | Header->common.rpc_ver = RPC_VER_MAJOR; This patch fixes the warnings by accessing the created object through a pointer to their type (and not through the union). Notes: - the 'max(sizeof(...), FIELD_OFFSET(...))' thingie in RPCRT4_BuildBindNackHeader avoids also a warning as the FIELD_OFFSET() can be smaller than the size of the structure. This could be avoided by using a flexible array member for the 'protocols' field instead of 'protocols[ANYSIZE_ARRAY]'. - I only changed the allocation routines when the allocated size is smaller than the union. If the strategy is validated, one could consider applying the same allocation strategy to all helpers for symmetry reasons. Hence the draft status for now, waiting for feedback. Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1545

3 4

[PATCH 0/1] MR985: mshtml/tests: Mark tests failing randomly on Windows as flaky.
by Francois Gouget (＠fgouget) 06 Dec '22

06 Dec '22

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

4 3

[PATCH 0/8] MR1582: winhttp: Read server reply in send_request().
by Paul Gofman (＠gofman) 05 Dec '22

05 Dec '22

It turns out that WinHttpReceiveResponse() completes synchronously in async mode (unless recursive request for handling authorization or redirect is involved). Some apps depend on that and do not wait for WINHTTP_CALLBACK_STATUS_HEADERS_AVAILABLE, calling WinHttpQueryHeaders() or WinHttpWebSocketCompleteUpgrade() right after calling WinHttpReceiveResponse, relying on that to finish synchronously. My initial out of tree testing shows that no network communication is performed during WinHttpReceiveResponse() call (when recursive request is not involved). I tested that by inserting a wait between WinHttpSendRequest and WinHttpReceiveResponse and disabling network connection during the wait. WinHttpReceiveResponse still succeeds on Windows. I think the above means that the actual response receiving from server is performed during WinHttpSendRequest. WinHttpReceiveResponse is not a complete no-op however. As shown by the existing tests the notifications related to receiving response are still delivered during WinHttpReceiveResponse (albeit in the same thread). Also WinHttpReceiveResponse affects request state: querying headers or upgrading to websocket without calling WinHttpReceiveResponse does not succeed. When redirect is involved, all the WINHTTP_CALLBACK_STATUS_RECEIVING_RESPONSE, WINHTTP_CALLBACK_STATUS_RESPONSE_RECEIVED and WINHTTP_CALLBACK_STATUS_REDIRECT notifications are delivered synchronously from the calling thread. Then, the new request send notifications and response receiving notifications are delivered from the new thread. An interesting case is when WinHttpReceiveResponse is called from SendRequest callbacks in async mode. If WinHttpReceiveResponse is called from WINHTTP_CALLBACK_STATUS_SENDING_REQUEST or WINHTTP_CALLBACK_STATUS_REQUEST_SENT (i. e., when request is not complete yet), calling WinHttpReceiveResponse() suddenly succeeds an shows the following message sequence (that is partially reflected in the tests I am adding): - calling WinHttpReceiveResponse from WINHTTP_CALLBACK_STATUS_SENDING_REQUEST (which is already called on the async thread on Win10, thread A). Win8 queues WINHTTP_CALLBACK_STATUS_SENDING_REQUEST synchronously and goes async a bit later. - WINHTTP_CALLBACK_STATUS_RECEIVING_RESPONSE, thread A; - WinHttpReceiveResponse() returns to the caller WINHTTP_CALLBACK_STATUS_REQUEST_SENT callback; returning from user callback; - WINHTTP_CALLBACK_STATUS_REQUEST_SENT, thread A; - WINHTTP_CALLBACK_STATUS_SENDREQUEST_COMPLETE (another thread, although the sequence is probably synced; I am not implementing this part and calling this callback from the same thread A); - WINHTTP_CALLBACK_STATUS_RESPONSE_RECEIVED in thread A; - WINHTTP_CALLBACK_STATUS_HEADERS_AVAILABLE in thread A. So the receive_response() state RECEIVE_RESPONSE_SEND_INCOMPLETE is primarily needed to handle this case. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1582

5 14

[PATCH 0/1] MR1547: mmdevapi/tests: Mark some more capture tests as flaky.
by Sven Baars (＠sbaars) 05 Dec '22

05 Dec '22

Two instances of these three tests failing can be found here: https://gitlab.winehq.org/sbaars/wine/-/jobs/5998 https://test.winehq.org/data/c937155ff6100c6ec2d8d1873dc7878041856e1a/linux… -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1547

5 4

[PATCH v3 0/1] MR872: winex11: Always initialize escape.drawable in X11DRV_GetDC().
by Zebediah Figura (＠zfigura) 02 Dec '22

02 Dec '22

-- v3: winex11: Always initialize escape.drawable in X11DRV_GetDC(). https://gitlab.winehq.org/wine/wine/-/merge_requests/872

3 3

[PATCH 0/1] MR1201: winecrt0: Move loading of __wine_unix_call to an inline function.
by Rémi Bernon (＠rbernon) 01 Dec '22

01 Dec '22

This improves performance of unix calls a little by removing one level of indirection and a branch. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1201

3 4

[PATCH v5 0/14] MR1324: Draft: ntdll: Use a faster code path for unix calls.
by Rémi Bernon (＠rbernon) 01 Dec '22

01 Dec '22

-- v5: ntdll: Inline __wine_unix_call(_fast) dispatch in the syscall dispatcher. ntdll: Restore frame in return path of the x86 syscall dispatchers. winecrt0: Inline PE __wine_unix_call(_fast) function calls. ntdll: Only save non-volatile FPU registers for -nofpu syscalls. opengl32: Use __wine_unix_call_fast instead of __wine_unix_call. ntdll: Introduce a new __wine_unix_call_fast syscall. ntdll: Use -nofpu for NtQueryPerformanceCounter and NtYieldExecution. winebuild: Introduce a new -nofpu syscall spec flag. ntdll: Add support for syscall flags in the service CounterTable. ntdll: Avoid double indirection to get x86_64 syscall_frame pointer. ntdll: Check SYSCALL_HAVE_WRFSGSBASE syscall flag only for wrfsbase. ntdll: Swap %eax and %edx registers in the i386 syscall dispatcher. ntdll: Check syscall table and syscall number before saving FPU. ntdll: Use named labels for jumps in the syscall dispatcher. https://gitlab.winehq.org/wine/wine/-/merge_requests/1324

2 17

[PATCH v2 0/4] MR1437: ntdll: Cleanup and refactor the x86_64 and i386 syscall dispatchers.
by Rémi Bernon (＠rbernon) 01 Dec '22

01 Dec '22

In preparation for https://gitlab.winehq.org/wine/wine/-/merge_requests/1324. This also begins preparation for a slightly different route than what the MR currently takes, with syscall flags eventually stored in the CounterTable rather than overusing syscall number unused bits. To do that we're checking the syscall number and loading the syscall table (keeping it in %rbx/%ebx) earlier. This assumes that %rbx isn't modified in between, for instance by the eventual `SYS_arch_prctl` syscall, but I believe it is the case? -- v2: ntdll: Check SYSCALL_HAVE_WRFSGSBASE syscall flag only for wrfsbase. ntdll: Swap %eax and %edx registers in the i386 syscall dispatcher. ntdll: Check syscall table and syscall number before saving FPU. ntdll: Use named labels for jumps in the syscall dispatcher. https://gitlab.winehq.org/wine/wine/-/merge_requests/1437

4 9

[PATCH v16 0/5] MR1148: ntdll: Mark created files beginning with a dot as not hidden.
by Torge Matthies (＠tmatthies) 01 Dec '22

01 Dec '22

Fixes bug [53826](https://bugs.winehq.org/show_bug.cgi?id=53826). -- v16: https://gitlab.winehq.org/wine/wine/-/merge_requests/1148

3 8

2025

2024

2023

2022

wine-gitlab November 2022