- Wine-GitLab - list.winehq.org

Re: [PATCH v2 0/3] MR40: vkd3d-shader/hlsl: Support complex implicit casts, complex explicit casts and complex broadcasts. (PART 3/3) - approved
by Alexandre Julliard (＠julliard) Oct. 26, 2022

Oct. 26, 2022

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/40

1 0

[PATCH v4 0/7] MR1111: winsock: Always use Unix SO_REUSEADDR on TCP sockets.
by Paul Gofman (＠gofman) Oct. 26, 2022

Oct. 26, 2022

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=50955 The problem which this patchset aims to solve is (sometimes) huge timeout on TCP listening port availability on Linux after the listening socket was closed one or another way. By default, the listening port will also be blocked for the whole time accepted socket waits through lengthy timeouts (sometimes; most surely when the listening process with an active connection was force killed, but not limited to this condition). BSD SO_REUSEADDR socket option is aimed mainly to avoid that extra wait on binding already closed listening socket address. From [1]: "Indicates that the rules used in validating addresses supplied in a bind(2) call should allow reuse of local addresses. For AF_INET sockets this means that a socket may bind, except when there is an active listening socket bound to the address.". Unix SO_REUSEADDR does not really allow reusing address in the Winsock sense. It will just allow to ditch the timeout (which is always the case on Windows without any specific options). Unfortunately it is not the only effect of the option. It still won't allow listening on the address simultaneously (unlike Winsock SO_REUSEADDR which allows simultaneous listening), or binding to an address which is being listened. But it will allow to bind different sockets for the same address which is not the Winsock behaviour when Winsock SO_REUSEADDR is set. So the patchset enables SO_REUSEADDR on every TCP socket and introduces the bound address tracking which will allow to return an error from bind() when needed. Not related to this patchset, but Winsock SO_REUSEADDR is somewhat closer to BSD SO_REUSEPORT, although is different in a way that _REUSEPORT will load balance connections between listeners while with Winsock _REUSEADDR the connections will always go to the first listener. I hope that the bound addresses tracking introduced in these patches may be reused in the future. E. g., maybe it might be helpful on the way of implementing the todos introduced by my extended tests (those todos are not related to this patchset and exist both with and without it). 1. https://man7.org/linux/man-pages/man7/socket.7.html -- v4: ws2_32/tests: Also test bind to any together with loopback in a different order. https://gitlab.winehq.org/wine/wine/-/merge_requests/1111

3 9

[PATCH v3 0/7] MR1111: winsock: Always use Unix SO_REUSEADDR on TCP sockets.
by Paul Gofman (＠gofman) Oct. 26, 2022

Oct. 26, 2022

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=50955 The problem which this patchset aims to solve is (sometimes) huge timeout on TCP listening port availability on Linux after the listening socket was closed one or another way. By default, the listening port will also be blocked for the whole time accepted socket waits through lengthy timeouts (sometimes; most surely when the listening process with an active connection was force killed, but not limited to this condition). BSD SO_REUSEADDR socket option is aimed mainly to avoid that extra wait on binding already closed listening socket address. From [1]: "Indicates that the rules used in validating addresses supplied in a bind(2) call should allow reuse of local addresses. For AF_INET sockets this means that a socket may bind, except when there is an active listening socket bound to the address.". Unix SO_REUSEADDR does not really allow reusing address in the Winsock sense. It will just allow to ditch the timeout (which is always the case on Windows without any specific options). Unfortunately it is not the only effect of the option. It still won't allow listening on the address simultaneously (unlike Winsock SO_REUSEADDR which allows simultaneous listening), or binding to an address which is being listened. But it will allow to bind different sockets for the same address which is not the Winsock behaviour when Winsock SO_REUSEADDR is set. So the patchset enables SO_REUSEADDR on every TCP socket and introduces the bound address tracking which will allow to return an error from bind() when needed. Not related to this patchset, but Winsock SO_REUSEADDR is somewhat closer to BSD SO_REUSEPORT, although is different in a way that _REUSEPORT will load balance connections between listeners while with Winsock _REUSEADDR the connections will always go to the first listener. I hope that the bound addresses tracking introduced in these patches may be reused in the future. E. g., maybe it might be helpful on the way of implementing the todos introduced by my extended tests (those todos are not related to this patchset and exist both with and without it). 1. https://man7.org/linux/man-pages/man7/socket.7.html -- v3: ws2_32/tests: Also test bind to any together with loopback in a different order. server: Set Unix SO_REUSEADDR on all the TCP sockets. server: Track SO_REUSEADDR value. ntdll: Move SO_REUSEADDR handling to server. ws2_32/tests: Also test TCP6 in test_so_reuseaddr(). ws2_32/tests: Add tests for reusing address without SO_REUSEADDR. https://gitlab.winehq.org/wine/wine/-/merge_requests/1111

4 10

[PATCH v6 0/2] MR1015: wpcap: Convert Unix sockaddr to win32 before duplication
by Marc-Aurel Zent (＠marzent) Oct. 26, 2022

Oct. 26, 2022

Interpreting the fist two bytes of the `sockaddr` struct as `sa_family` produces incorrect behaviour on macOS and (presumbly) BSD. This change uses both Unix and Windows socket headers to convert the libpcap provided sockaddr before duplicating it. This fixes sockaddr being always NULL on macOS/BSD and ipv6 addresses not working in general since `AF_INET6` differs on Windows(23), macOS(30) and Linux(10) For reference https://www.ibm.com/docs/en/i/7.3?topic=family-af-inet-address and this is from the <sys/socket.h> on macOS ``` /* * [XSI] Structure used by kernel to store most addresses. */ struct sockaddr { __uint8_t sa_len; /* total length */ sa_family_t sa_family; /* [XSI] address family */ char sa_data[14]; /* [XSI] addr value (actually larger) */ }; ``` -- v6: wpcap: Build devices in unixlib for find_all_devices. wpcap: Split device allocation and build in find_all_devices. https://gitlab.winehq.org/wine/wine/-/merge_requests/1015

2 3

[PATCH 0/3] MR1171: uiautomationcore: Add support for more UiaConditions.
by Connor McAdams (＠cmcadams) Oct. 26, 2022

Oct. 26, 2022

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

3 4

[PATCH 0/1] MR1170: wbemprox: Fix out-of-bounds access caused by codepoints above U+00FF.
by Jinoh Kang (＠iamahuman) Oct. 26, 2022

Oct. 26, 2022

For now, assume all Unicode codepoints in range U+0100 - U+10FFFF constitute a valid identifier. Note that we already do that for range U+0080 - U+00FF. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1170

3 2

[PATCH v2 0/6] MR1111: winsock: Always use Unix SO_REUSEADDR on TCP sockets.
by Paul Gofman (＠gofman) Oct. 26, 2022

Oct. 26, 2022

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=50955 The problem which this patchset aims to solve is (sometimes) huge timeout on TCP listening port availability on Linux after the listening socket was closed one or another way. By default, the listening port will also be blocked for the whole time accepted socket waits through lengthy timeouts (sometimes; most surely when the listening process with an active connection was force killed, but not limited to this condition). BSD SO_REUSEADDR socket option is aimed mainly to avoid that extra wait on binding already closed listening socket address. From [1]: "Indicates that the rules used in validating addresses supplied in a bind(2) call should allow reuse of local addresses. For AF_INET sockets this means that a socket may bind, except when there is an active listening socket bound to the address.". Unix SO_REUSEADDR does not really allow reusing address in the Winsock sense. It will just allow to ditch the timeout (which is always the case on Windows without any specific options). Unfortunately it is not the only effect of the option. It still won't allow listening on the address simultaneously (unlike Winsock SO_REUSEADDR which allows simultaneous listening), or binding to an address which is being listened. But it will allow to bind different sockets for the same address which is not the Winsock behaviour when Winsock SO_REUSEADDR is set. So the patchset enables SO_REUSEADDR on every TCP socket and introduces the bound address tracking which will allow to return an error from bind() when needed. Not related to this patchset, but Winsock SO_REUSEADDR is somewhat closer to BSD SO_REUSEPORT, although is different in a way that _REUSEPORT will load balance connections between listeners while with Winsock _REUSEADDR the connections will always go to the first listener. I hope that the bound addresses tracking introduced in these patches may be reused in the future. E. g., maybe it might be helpful on the way of implementing the todos introduced by my extended tests (those todos are not related to this patchset and exist both with and without it). 1. https://man7.org/linux/man-pages/man7/socket.7.html -- v2: server: Set Unix SO_REUSEADDR on all the TCP sockets. server: Track SO_REUSEADDR value. ntdll: Move SO_REUSEADDR handling to server. ws2_32/tests: Also test TCP6 in test_so_reuseaddr(). ws2_32/tests: Add tests for reusing address without SO_REUSEADDR. ws2_32/tests: Make test_so_reuseaddr() more conclusive. https://gitlab.winehq.org/wine/wine/-/merge_requests/1111

3 8

[PATCH v2 0/3] MR1152: ntdll: Fixes for Overwatch 2.
by Torge Matthies (＠tmatthies) Oct. 26, 2022

Oct. 26, 2022

Overwatch 2 doesn't like the win32u `-syscall` conversion that happened a while back, because it hooks KiUserCallbackDispatcher. This MR fixes it up to match what Overwatch 2 expects. -- v2: ntdll: Pass KiUserCallbackDispatcher parameters on stack. ntdll: Add 5-byte nop to start of KiUserCallbackDispatcher. ntdll: Align stack pointer when calling KiUserCallbackDispatcher. https://gitlab.winehq.org/wine/wine/-/merge_requests/1152

6 12

[PATCH v6 0/2] MR231: SetWindowPos() parent window exposure fixes (#53153)
by Jinoh Kang (＠iamahuman) Oct. 26, 2022

Oct. 26, 2022

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

3 4

[PATCH v2 0/4] MR1157: win32u: Move DisplayConfigGetDeviceInfo from user32 and implement DISPLAYCONFIG_DEVICE_INFO_GET_TARGET_NAME.
by Paul Gofman (＠gofman) Oct. 26, 2022

Oct. 26, 2022

-- v2: win32u: Implement NtUserDisplayConfigGetDeviceInfo(DISPLAYCONFIG_DEVICE_INFO_GET_TARGET_NAME). win32u: Store output id in monitors cache. https://gitlab.winehq.org/wine/wine/-/merge_requests/1157

5 8

[PATCH v2 0/9] MR36: hlsl: UAV loads and stores.
by Zebediah Figura (＠zfigura) Oct. 26, 2022

Oct. 26, 2022

-- v2: vkd3d-shader/hlsl: Propagate copies for resource store instructions. vkd3d-shader/hlsl: Write SM4 UAV store instructions. vkd3d-shader/hlsl: Parse UAV stores. vkd3d-shader/hlsl: Implement typed UAV loads. vkd3d-shader/hlsl: Write SM4 UAV declarations. vkd3d-shader/hlsl: Allocate UAVs. tests: Add a test for storing to a UAV array. tests: Add more tests for UAV allocation. tests: Fix constructor declaration in the partial UAV write test. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/36

5 16

[PATCH 0/3] MR40: vkd3d-shader/hlsl: Support complex implicit casts, complex explicit casts and complex broadcasts. (PART 3/3)
by Francisco Casas (＠fcasas) Oct. 26, 2022

Oct. 26, 2022

Just additional complex explicit casts tests. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/40

5 6

Re: [PATCH v5 0/4] MR1159: msvcrt: add implementation for localized functions - approved
by Piotr Caban (＠piotr) Oct. 26, 2022

Oct. 26, 2022

This merge request was approved by Piotr Caban. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1159

1 0

[PATCH 0/3] MR566: shell32: Implement SHBindToFolderIDListParent.
by Mohamad Al-Jaf (＠maljaf) Oct. 26, 2022

Oct. 26, 2022

Called by IE11. Signed-off-by: Mohamad Al-Jaf <mohamadaljaf(a)gmail.com> v3: Fix failed test. Don't know how to change the subject version number. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/566

4 7

[PATCH v5 0/3] MR231: SetWindowPos() parent window exposure fixes (#53153)
by Jinoh Kang (＠iamahuman) Oct. 26, 2022

Oct. 26, 2022

Signed-off-by: Jinoh Kang <jinoh.kang.kr(a)gmail.com> -- v5: server: Don't invalidate the newly exposed child region on the parent if it doesn't clip children. server: Redraw composited window child when its z-order changes. server: Correctly expose composited parent window and its child on position change. https://gitlab.winehq.org/wine/wine/-/merge_requests/231

3 4

[PATCH 0/1] MR1169: conhost/tests: Fix some conditions on tty test termination.
by eric pouech (＠epo) Oct. 26, 2022

Oct. 26, 2022

Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1169

2 1

Re: [PATCH v6 0/2] MR979: d3d9: Implement d3dx_effect_SetRawValue
by Matteo Bruni (＠Mystral) Oct. 26, 2022

Oct. 26, 2022

On Wed Oct 19 09:55:18 2022 +0000, Patrick Hibbs wrote: > The same issue with strings occurs with Texture and shader types. > I.e. Paramater is rendered irretrievable. Calling it's relevant GetXXX() > function causes a crash if it's a scalar. Calling GetParamaterByName() > will return an invalid handle. Oh, interesting. GetParameterByName() failing afterwards is probably an indication that the SetRawValue() call overwrote parts of some internal data structure and broke the effect object to some degree. BTW, you're supposed to set texture parameters to a IDirect3DBaseTexture9 / IUnknown pointer (and similarly the value for a string parameter should probably be a string pointer rather than the string contents). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/979#note_12212

1 0

Re: [PATCH v6 0/2] MR979: d3d9: Implement d3dx_effect_SetRawValue
by Matteo Bruni (＠Mystral) Oct. 26, 2022

Oct. 26, 2022

On Wed Oct 19 11:26:44 2022 +0000, Patrick Hibbs wrote: > Done in v3 of the patch. > Should I respond to all of these if I think it's been done? > Should I mark the thread resolved if I think it's been done, or is that > something the reviewer should do? Feel free to mark the threads that you think are done with as resolved (I think I can still reopen them if I happen to disagree) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/979#note_12213

1 0

Re: [PATCH v6 0/2] MR979: d3d9: Implement d3dx_effect_SetRawValue
by Matteo Bruni (＠Mystral) Oct. 26, 2022

Oct. 26, 2022

On Wed Oct 19 09:48:02 2022 +0000, Patrick Hibbs wrote: > Actually it seems that the strings are rendered irretrievable by the > call to SetRawValue(). > Calling GetString() on a scalar string after the destruction causes a > crash in win10. While calling it with a string vector doesn't crash, but > returns D3DERR_INVALIDCALL instead. > I've updated the tests in v3 of the patch to check for this. Ah, that explains it I guess. Weird, but not too surprising. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/979#note_12211

1 0

Re: [PATCH v6 0/2] MR979: d3d9: Implement d3dx_effect_SetRawValue
by Matteo Bruni (＠Mystral) Oct. 26, 2022

Oct. 26, 2022

On Wed Oct 19 11:23:25 2022 +0000, Patrick Hibbs wrote: > Sorry about the unexpected push, I'll be more careful next time. > With regards to the bool fixups, are we sure we want to just write the > raw data given to us? I ask because I've also noticed that SetRawValue() > has a tendency to promote datatypes when given a single value and a > vector / matrix paramater. I.e. float and int become a float4 and int4 > respectively for both vectors and matrices. (MSDN calls this behavior a > "cast.") This results in the next 3 values in the paramater's buffer > being set to zero. > Assuming SetRawValue() shouldn't fix the bool values itself, should it > also avoid fixing the ints and floats? If so, how should we indicate the > need for a fixup to other functions? There doesn't seem to be any > infrastructure to support that in wine currently. (We could abuse the > paramater block support for that, but see the speculation below.) > The float and int promotions were the reason I didn't clear the > paramater after each test. As doing so would cause us to miss the writes > to the next 3 values in the paramater. As they would already be set to > zero before the call. Should I still go ahead and clear the paramaters > after each test anyway? > As a dirty hack, I added a call to zero out the paramaters after each > test with a 4x4 matrix of zero ints in v3 of the test. That call is > commented out in the push, but if you enable it it will succeed for most > of the tests under win10. (I disabled it before I fixed the string test > crashes. So it may work fine now, I haven't checked.) I haven't tried > checking the paramaters after the current one for alterations. I was > going to put that in it's own set of tests. > This part is speculation but, if it is a valid use of SetRawValue() to > set adjacent paramaters regardless of type with one call, then the > entire set of paramaters for a given effect needs to be in the same > memory block. (Which seems to be not the case in wine, as there are > plenty of calls to heap_alloc() / heap_realloc() using the param->data > pointer in effect.c.) That would also imply that there is a specific > ordering of paramaters in memory as well. Which would need to be tested > for. If this behavior is combined with the bool assumption above, then > we'd also need to test for order of operations too. > Assuming all of that needs to be done, how do we split this up? Because > I have a feeling that this patchset is going to be rather large in > scope. (If all of the assumptions and speculation are true that is.) Unfortunately I keep being unable to reply promptly. Anyway... > With regards to the bool fixups, are we sure we want to just write the raw data given to us? I ask because I've also noticed that SetRawValue() has a tendency to promote datatypes when given a single value and a vector / matrix paramater. I.e. float and int become a float4 and int4 respectively for both vectors and matrices. (MSDN calls this behavior a "cast.") This results in the next 3 values in the paramater's buffer being set to zero. Is that what happens or is just the rest of the parameter being set to 0? > Assuming SetRawValue() shouldn't fix the bool values itself, should it also avoid fixing the ints and floats? How should they be fixed? I'm still assuming that SetRawValue() more or less does what it says i.e. it just sets the value of parameters by mere byte-for-byte copy, without any kind of conversion or fixup. Do we have evidence that's not the case? > The float and int promotions were the reason I didn't clear the paramater after each test. As doing so would cause us to miss the writes to the next 3 values in the paramater. As they would already be set to zero before the call. Should I still go ahead and clear the paramaters after each test anyway? It might make sense to clear them to a non-zero value (e.g. some variation of the usual 0xdeadbeef marker) to make those results more evident. > This part is speculation but, if it is a valid use of SetRawValue() to set adjacent paramaters regardless of type with one call, then the entire set of paramaters for a given effect needs to be in the same memory block. (Which seems to be not the case in wine, as there are plenty of calls to heap_alloc() / heap_realloc() using the param->data pointer in effect.c.) That would also imply that there is a specific ordering of paramaters in memory as well. Which would need to be tested for. If this behavior is combined with the bool assumption above, then we'd also need to test for order of operations too. Yes, that wouldn't quite work right away. It's fine to just add a FIXME() for straddling parameters for the time being, if it turns out that native actually supports that. Similarly for the test. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/979#note_12210

1 0

[PATCH 0/2] MR12: vkd3d: Add Windows implementation of vkd3d_set_thread_name().
by Brendan Shanks (＠bshanks) Oct. 26, 2022

Oct. 26, 2022

-- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/12

4 7

[PATCH 0/1] MR1168: wbemprox: WQL string comparisons are case insensitive.
by Hans Leidekker (＠hans) Oct. 26, 2022

Oct. 26, 2022

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53832 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1168

2 1

[PATCH v9 0/10] MR1148: ntdll: Mark created files beginning with a dot as not hidden.
by Torge Matthies (＠tmatthies) Oct. 26, 2022

Oct. 26, 2022

Also unifies hidden file handling. Fixes bug [53826](https://bugs.winehq.org/show_bug.cgi?id=53826). -- v9: ntdll: Try to avoid requesting the file name for a handle. ntdll: Ensure that attributes are kept the same when renaming or hard-linking a file. https://gitlab.winehq.org/wine/wine/-/merge_requests/1148

3 11

[PATCH 0/2] MR1156: Allow a loaded registry key to be loaded multiple times.
by Santino Mazza (＠tati1454) Oct. 26, 2022

Oct. 26, 2022

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

4 4

[PATCH v8 0/10] MR1148: ntdll: Mark created files beginning with a dot as not hidden.
by Torge Matthies (＠tmatthies) Oct. 26, 2022

Oct. 26, 2022

Also unifies hidden file handling. Fixes bug [53826](https://bugs.winehq.org/show_bug.cgi?id=53826). -- v8: ntdll: Try to avoid requesting the file name for a handle. https://gitlab.winehq.org/wine/wine/-/merge_requests/1148

3 12