--
v2: user32: Pass resource ID as a string in DIALOG_CreateControls32.
user32: Support passing bitmap and icon resource ID as a string when creating static conctrol.
user32: Support resource ID strings in CREATESTRUCT Unicode conversion.
https://gitlab.winehq.org/wine/wine/-/merge_requests/693
The objective of this patch series is to converge to the correct argument count checks and offset parameter dimensions when parsing the Load, Sample, SampleLevel, Gather (and variants) methods, for the different texture types.
I made the following table to summarize the expected arguments and their dimensions:
![resource_methods_dims](/uploads/43511fe82e934c2542f6152f9134cb0e/resource_methods_dims.png)
Getting these required some extensive trial-and-error, because:
- Official documentation about the methods is spread in different pages and in a somewhat inconsistent manner.
- Automatic vector truncation, scalar broadcasting, and type conversion, make shaders that pass inexact types compile.
- clamp and status arguments (for tiled resources) are not present in fxc 9, and yet, they are part of ps_5_0 and vs_5_0.
- Some methods (Load() in particular) require the mipmap level as part of the location parameter (except for Multi-Sampled textures), while other don't.
For implementing new methods I recommend passing an invalid parameter count to them in fxc 10, so that it lists available overloads.
And to do this for each texture type.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/9
foobar2000.exe's UPnP Media Renderer component (foo_out_upnp.dll)
expects that, if a select() call completes successfully with a non-empty
writefds set, any immediately following send() call on a socket in the
writefds set never fails with WSAEWOULDBLOCK.
On Wine, the Winsock select() and send() implementations both call the
Unix poll(2) under the hood to test if I/O is possible on the socket.
As it turns out, it's entirely possible that Unix poll() may yield
POLLOUT on the first call (for select) but *not* the second (for send),
even if no send() call has been made in the meanwhile.
On Linux (as of v5.19), a connected (ESTABLISHED) TCP socket that has
not been shut down indicates the (E)POLLOUT condition only if the ratio
of sk_wmem_queued (the amount of bytes queued in the send buffer) to
sk_sndbuf (the size of send buffer size itself, which can be retrieved
via SO_SNDBUF) is below a certain threshold. Therefore, a falling edge
in POLLOUT can be triggered due to a number of reasons:
1. TCP retransmission and control packets (e.g. MTU probing). Such
packets share the same buffer with application-initiated packets,
and thus counted in sk_wmem_queued_add just like application data.
See also: sk_wmem_queued_add() callers (Linux 5.19).
2. Memory pressure. This causes sk_sndbuf to shrink.
See also: sk_stream_moderate_sndbuf() callers (Linux 5.19).
Fix this by always attempting synchronous I/O first if the nonblocking
flag is set.
Note: for diagnosis, `getsockopt(fd, SOL_SOCKET, SO_MEMINFO, ...)` can be
used to retrieve both sk_wmem_queued (the amount of bytes queued in the
send buffer) and sk_sndbuf (the size of the send buffer itself, which
can also be retrieved via SO_SNDBUF).
--
v4: server: Always prefer synchronous I/O in nonblocking mode.
https://gitlab.winehq.org/wine/wine/-/merge_requests/617