- Wine-GitLab - list.winehq.org

[PATCH 0/1] MR1530: mshtml: Use standard C functions for memory allocation.
by Alex Henrie (＠alexhenrie) Nov. 24, 2022

Nov. 24, 2022

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

3 2

[PATCH 0/8] MR1422: winhttp: Do not reference request from websocket.
by Paul Gofman (＠gofman) Nov. 24, 2022

Nov. 24, 2022

The initial motivation is to make WinHttpCloseHandle(request) with request previously upgraded to websocket deliver WINHTTP_CALLBACK_STATUS_HANDLE_CLOSING right away and not after websocket is closed much later (this late notification causes crash in Microsoft Flight Simulator). That happens so as the notification is sent when the object is destroyed, not when the handle is closed. This logic seems correct to me: when testing some more things involving closing handles and observing which threads get the notifications I saw Windows delivering WINHTTP_CALLBACK_STATUS_HANDLE_CLOSING in the other threads, which suggests that the notification can be queued and delayed on Windows too in case there are pending operations involving the object. So the right thing to do seems to be to have just the separate websocket and do not reference request from it. It probably deserves a separate explanation why I am adding a refcounting to netconn and copying it to webscoket instead of just nullifying the netconn in request. Doing that way (just nullifying the netconn in request) immediately caused regression in Elden Ring which started failing in a convoluted way: it doesn't wait for WebSocketReceiveResponse() to complete and calls WebSocketCompleteUpgrade(). That currently succeeds in Wine due to some lack of validation. Then, after upgrade, async WebSocketReceiveResponse proceeds, but with NULL netconn it gets an error from prior WebSocketReceiveResponse in callback and fails the thing. The core problem here is that unless recursive request is involved WebSocketReceiveResponse is always sync on Windows and, as my testing goes, does not involve network communication at all. I. e., looks like the actual reply receiving should be done in WebSocketSendRequest, WebSocketReceiveResponse only sends notifications and possibly queues recursive reque sts. I have a WIP patches for that and_with the help of those and existing winhttp test I realized that removing connection from request is wrong even without convoluted story. We have an existing test in winhttp.c which performs second request / upgrade on a request already upgraded socket. The test as is succeeds even with NULL connection in request by that is by chance only (as we don't try to receive response from our in process server yet which is failing in this case). With connection removed request opens a new one which doesn't get processed by our server, while in the same test on Windows I see that request is actually received by server, suggesting that it uses all the same existing connection on Windows, and so we should keep the same connection in request. As a separate note, I suspect that we now can erroneously cache connection for request upgraded to websocket. But that happens not on request close but under different conditions and looks the same before and after present patches, so this should be probably checked and fixed separately. Patch "winhttp: Move read buffer to websocket." might look weird as introducing the buffer for the only purpose of preserve initial data. While I don't immediately see how that can be done simplier, I have another small excuse for that. Currently the logic of closing websocket handles does the correct thing WRT notifications and aborting the operation. Yet it is still racy a bit due to we use app's buffer in socket read calls. If we happen to receive some data already after we sent notifications but before the read operation is aborted it may write to already freed or otherwise reused app's buffer. It seems to me that the only clean way to deal with that later is to use our own read buffer and copy the data only when we are going to send non-abort completion notification. So this read buffer might have more use in the future. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1422

3 10

[PATCH v2 0/1] MR1533: include: Add inline versions of the isw* functions.
by Alex Henrie (＠alexhenrie) Nov. 24, 2022

Nov. 24, 2022

I want to replace is_ascii with iswascii in urlmon without hurting performance. I added inline versions of the rest of the isw* functions because they may also be useful to us in the future. -- v2: include: Add inline versions of the isw* functions. https://gitlab.winehq.org/wine/wine/-/merge_requests/1533

3 3

[PATCH 0/1] MR1533: include: Add inline versions of the isw* functions.
by Alex Henrie (＠alexhenrie) Nov. 24, 2022

Nov. 24, 2022

I want to replace is_ascii with iswascii in urlmon without hurting performance. I added inline versions of the rest of the isw* functions because they may also be useful to us in the future. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1533

3 2

[PATCH 0/1] MR1532: kernel32/profile: Trim spaces from section names on load.
by Nikolay Sivov (＠nsivov) Nov. 24, 2022

Nov. 24, 2022

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53814 Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1532

2 1

[PATCH v2 0/1] MR1531: pdh: Use standard C functions for memory allocation.
by Alex Henrie (＠alexhenrie) Nov. 24, 2022

Nov. 24, 2022

-- v2: pdh: Use standard C functions for memory allocation. https://gitlab.winehq.org/wine/wine/-/merge_requests/1531

2 1

[PATCH 0/1] MR1531: pdh: Use standard C functions for memory allocation.
by Alex Henrie (＠alexhenrie) Nov. 24, 2022

Nov. 24, 2022

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

2 1

[PATCH v8 0/3] MR741: ntdll: Implement NtFlushProcessWriteBuffers.
by Torge Matthies (＠tmatthies) Nov. 24, 2022

Nov. 24, 2022

Based on [a patch](https://www.winehq.org/mailman3/hyperkitty/list/wine-devel(a)winehq.… by Jinoh Kang (@iamahuman) from February 2022. I removed the need for the event object and implemented fast paths for Linux. On macOS 10.14+ `thread_get_register_pointer_values` is used on every thread of the process. On Linux 4.14+ `membarrier(MEMBARRIER_CMD_GLOBAL_EXPEDITED, ...)` is used. On x86 Linux <= 4.13 `madvise(..., MADV_DONTNEED)` is used, which sends IPIs to all cores causing them to do a memory barrier. On non-x86 Linux <= 4.2 and on other platforms the fallback path using APCs is used. -- v8: ntdll: Add thread_get_register_pointer_values-based implementation of NtFlushProcessWriteBuffers. ntdll: Add sys_membarrier-based implementation of NtFlushProcessWriteBuffers. ntdll: Add MADV_DONTNEED-based implementation of NtFlushProcessWriteBuffers. https://gitlab.winehq.org/wine/wine/-/merge_requests/741

3 5

[PATCH v7 0/1] MR1282: ntoskrnl.exe: Implement ExInterlockedInsertTailList.
by Etaash Mathamsetty (＠etaash.mathamsetty) Nov. 24, 2022

Nov. 24, 2022

I'm not exactly sure what is calling this function, but it's probably that anti virus I installed to test the KeInitializeGuardedMutex implementation. edit: TkCtrl2k64.sys calls it -- v7: ntoskrnl.exe: Implement ExInterlockedInsertTailList. https://gitlab.winehq.org/wine/wine/-/merge_requests/1282

3 4

Re: [PATCH v2 0/1] MR1521: rpcss: Use I_Rpc(Free|Allocate) in MIDL_user_(allocate|free).
by Zebediah Figura (＠zfigura) Nov. 23, 2022

Nov. 23, 2022

This was already committed, and I guess it's not hurting anything, but it seems like the wrong solution to the problem. Presumably either rpcrt4 should be using NdrAllocate/NdrFree for both, or it should be using internal I_RpcAllocate/I_RpcFree. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1521#note_17270

1 0