November 2022 - Wine-GitLab

[PATCH 0/2] MR1528: winhttp: Improve WinHttpGetProxyForUrl() execution time when wpad is not available
by Paul Gofman (＠gofman) Nov. 24, 2022

Nov. 24, 2022

Fixes Marvel Snap being unable to connect to servers (part of it, another part is wmic patches), and maybe improves wait times in many other apps. Typically "http://wpad/..." (which is commonly requested as lpszAutoConfigUrl for WinHttpGetProxyForUrl) is not available and WinHttpGetProxyForUrl() is hanging for a really long time resolving this name in download_script(). On Windows 10 here the name resolution timeout is about 9sec (and I could not find a way to configure it for a longer timeout). On Linux default DNS timeouts are typically longer. Yet, while WinHttpGetProxyForUrl() execution time is not consistent here, when I run it right after reboot or after network interface reconnection it typically takes ~4-7 seconds to complete on the first run. Then, testing it again shortly after yields no noticeable timeout. I suppose Windows caches and manages that globally in some service, so maximum possible 9 seconds name resolution timeout is rarely hit. Since proxy config URL, if available, is supposed to be in the local network, having the timeout of 5 seconds for name resolution looks more than enough to me. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1528

3 4

[PATCH 0/5] MR1538: ntdll: Rename some heap constants and small refactoring.
by Rémi Bernon Nov. 24, 2022

Nov. 24, 2022

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

2 6

[PATCH v2 0/5] MR1527: wmic: Support nicconfig alias.
by Paul Gofman (＠gofman) Nov. 24, 2022

Nov. 24, 2022

The first two patches are mostly needed to make wmic.exe work on Windows as well for easier testing and distinguishing between wmic.exe bugs and underlying libraries bugs (although it also makes sense not to depend on wbemprox implementation differences in Wine). -- v2: wmic: Support array of BSTRs in convert_to_bstr(). https://gitlab.winehq.org/wine/wine/-/merge_requests/1527

3 6

[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. 23, 2022

Nov. 23, 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. 23, 2022

Nov. 23, 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. 23, 2022

Nov. 23, 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. 23, 2022

Nov. 23, 2022

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

2 1