We need to use the ODBC v1 function SQLColAttributesW, to ensure that we
use the lowest verion available. This ODBC function internally will call
SQLColAttribute or SQLColAttributesW depending on what the driver supports.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2223
Fixes Gungrave G.o.r.e media playback and hang on start.
I tested separately that setting an obviously invalid AudioSpecificConfig fails on Windows as well. On Windows stream attributes incompatible with AudioSpecificConfig (e. g., sample rate) also fails. We currently don't have such checks (and that will require fully parsing AudioSpecificConfig on our side), but since we don't have to choose between the parameters and only validate them I hope missing validation is not critical until we have something depending on that.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2189
Convert all consecutive calls to d7_DrawPrimitive(TRIANGLE_FAN) into
a single call to d7_DrawPrimitive(TRIANGLE_LIST) with all the vertices.
Note, it *increase* the number of vertices, but bandwith is much less costly
than multiple calls.
Note, only a very precise subset of the calls get buffered in order to
ensure that the disruption is minimal.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=33814
--
v14: ddraw: Convert buffer API to use d3d_device struct
https://gitlab.winehq.org/wine/wine/-/merge_requests/2105
Second commit is to be removed.
Signed-off-by: Bernhard Kölbl <besentv(a)gmail.com>
--
v12: windows.media.speech: Implement Vosk create and release functions in the unixlib.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2091
I was mainly after the issue fixed by the second patch but stomped on another one while testing that and that one looks even more unfortunate to me.
1. When connect() is used on blocking socket and fails for whatever reason, next connect() will make a new independent connection attempt (both on Windows and Unix). In non-blocking mode however (and Unix sockets are always in non-blocking mode in Wine) on Linux the next connect() will always return an error (unlike Windows which will make a new connect attempt if the previous one completed and failed). So in Wine now even for blocking socket connect() will fail if previous attempt failed and return WSAECONNABORTED. The error returned by Linux connect() will be ECONNABORTED if getsockopt(SO_ERROR) was called on the socket after connect completed with failure, and true connect() fail error if getsockopt wasn't called.
2. connect() on blocking socket times out after ~21sec on Windows and after ~130 sec on Linux. That is the case when peer doesn't actively reject connection but just never replies anything. That is, client sent SYN and never heard back. So much longer timeout leads to what is seen as hang on exit in one game, but probably more important that it affect much more in various apps provoking timeouts or huge delays not just on exit.
I did not find a way to set connect() timeout for socket on Windows. That difference mostly corresponds to number of SYN send retries. That is 7 on Linux by default and 4 on Windows (the delay between attempts starts from 1s and is doubled on each next attempt). There is TCP_SYNCNT socket option (Linux specific now, unfortunately) which allows to set the number of retries. Setting that to 4 yields 32 sec timeout (vs 21 sec on Windows). The remaining difference is probably due to different amount of time waited after last SYN is sent. There is also TCP_USER_TIMEOUT parameter which allows to effectively set the delay exactly, but it might interfere with SO_KEEPALIVE somehow and I hope that 32 vs 21 is not that critical already as 130 vs 21 and probably we can avoid complicating the thing with it.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2215