The function SQLBindParam was missed when binding all the available functions. Will implement the SQLBindParam in a future patchset.
The other is just a fix for when parameters are NULL when passed in (Same the the W version).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6063
--
v2: odbc32: Use SQLSetConnectAttrW() instead of SQLSetConnectAttr() if possible.
odbc32: Use SQLFreeHandle() instead of SQLFreeEnv/Connect().
odbc32: Set parent functions before creating the environment handle.
odbc32: Accept SQL_FETCH_NEXT in SQLDataSources/Drivers() if the key has not been opened.
odbc32: Factor out helpers to create driver environment and connection handles.
odbc32: Implement SQLGetInfo(SQL_ODBC_VER).
odbc32: Default to ODBC version 2.
odbc32: Handle options in SQLFreeStmt().
odbc32: Stub SQLGetEnvAttr(SQL_ATTR_CONNECTION_POOLING).
odbc32: Implement SQLGet/SetConnectAttr(SQL_ATTR_CONNECTION_TIMEOUT).
odbc32: Implement SQLGet/SetConnectAttr(SQL_ATTR_LOGIN_TIMEOUT).
https://gitlab.winehq.org/wine/wine/-/merge_requests/6050
Send INVALIDATEMEDIATYPE to allow the transform type to be set before
retrying PROCESSINPUTNOTIFY.
--
v2: mf: Retry PROCESSINPUTNOTIFY if TRANSFORM_TYPE_NOT_SET is returned.
mf/tests: Add tests for custom evr presenter.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6059
I'm not sure about the need for this solution, so it's a **DRAFT**. For me it is an academic interest to check whether atomic locks will give advantages over pthread_mutex in games. First impressions are that games have become smoother, but need to think about tests that can actually be measured.
Before build need define `WINE_USE_ATOMIC_LOCKS`.
```bash
export CFLAGS="${CFLAGS} -DWINE_USE_ATOMIC_LOCKS"
```
--
v6: ws2_32: Add atomic lock support.
wine32u: Add atomic lock support.
winevulkan: Add atomic lock support.
ntdll: Add atomic lock support.
winewayland: Add atomic lock support.
include: Define custom mutex macroses.
msxml3: Fix compilation errors with Clang 18.
configure: Change C standard to C17.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6031
I'm not sure about the need for this solution, so it's a **DRAFT**. For me it is an academic interest to check whether atomic locks will give advantages over pthread_mutex in games. First impressions are that games have become smoother, but need to think about tests that can actually be measured.
Before build need define `WINE_USE_ATOMIC_LOCKS`.
```bash
export CFLAGS="${CFLAGS} -DWINE_USE_ATOMIC_LOCKS"
```
--
v5: ws2_32: Add atomic lock support.
wine32u: Add atomic lock support.
winevulkan: Add atomic lock support.
ntdll: Add atomic lock support.
winewayland: Add atomic lock support.
include: Define custom mutex macroses.
msxml3: Fix compilation errors with Clang 18.
configure: Change C standard to C17.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6031
This reverts commit 5c8ea25014f ("ntdll: Use CLOCK_REALTIME_COARSE for
NtQuerySystemTime() if it has sufficient resolution.")
CLOCK_*_COARSE only provides up to 1ms resolution at CONFIG_HZ=1000.
OTOH, there are several ways to get up to 0.5ms resolution on modern
Windows (high resolution waitable timers, NtSetTimerResolution with
0.5ms). This code path therefore has a possibility of behaving worse
than native.
Since COARSE resolution is HZ dependent, this code path only runs if the
kernel is configured with CONFIG_HZ=1000. Most distro ships does not
ship with this. Therefore, this code path is rarely tested, and is more
of a recipe for surprise. If any application rely on fast
NtQuerySystemTime they are likely already broken for majority of Wine
users.
Given the above reason, don't use CLOCK_REALTIME_COARSE. Use
gettimeofday which is internally hooked to CLOCK_REALTIME.
--
v3: ntdll: Don't use CLOCK_REALTIME_COARSE
https://gitlab.winehq.org/wine/wine/-/merge_requests/6007