--
v2: wldap32/tests: Add some tests for LDAP authentication to a Kerberos DC.
wldap32: ldap_init() should resolve NULL hostname to default Kerberos DC.
wldap32: Use correct host when connecting to Kerberos DC.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7235
Modern Windows versions do not export these symbols.
The symbol `??0?$CDynamicArray@GPAG@QAE@I@Z` uses an unusual mangling scheme that no existing tool understands.
This causes issues on ARM64EC, which requires demangling when generating an import library.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7246
"DIR /o" (no order specifier after /o) hasn't functioned the same as it does on Windows. This change makes the functionality of /o by itself equivalent to behavior on Windows.
--
v13: programs/cmd: Add tests patch from @epo.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7131
The Windows Bluetooth stack uses private IOCTLs in order to set the [discoverability](https://learn.microsoft.com/en-us/windows/win32/api/blueto… and [connectability](https://learn.microsoft.com/en-us/windows/win32/api/bluetoo… status of a local radio, and to start/stop the device inquiry procedure. This MR introduces 3 wine-specific IOCTL codes for the same purposes, as most applications seem to the Win32 API itself for these operations:
* IOCTL_WINBTH_RADIO_SET_FLAG
* IOCTL_WINEBTH_RADIO_START_DISCOVERY
* IOCTL_WINEBTH_RADIO_STOP_DISCOVERY
--
v8: winebth.sys: Call bluez_watcher_close as part of bluetooth_shutdown.
winebth.sys: Implement IOCTL_WINEBTH_RADIO_STOP_DISCOVERY.
winebth.sys: Implement IOCTL_WINEBTH_RADIO_START_DISCOVERY.
winebth.sys: Implement IOCTL_WINEBTH_RADIO_SET_FLAG.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7216
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
v2: windowscodecs/metadata: Add initial implementation of the App1 reader.
windowscodecs/metadata: Add registration information for the Exif reader.
windowscodecs/metadata: Add registration information for the Gps reader.
windowscodecs/metadatahandler: Implement GetStream().
windowscodecs/metadatahandler: Implement GetPersistOptions().
https://gitlab.winehq.org/wine/wine/-/merge_requests/7167
This MR adds an implementation for the `IAsyncAction` and `IAsyncInfo` interfaces exported by `Windows.System.Threading`, including support for setting `IAsyncActionCompletedHandler` values for an `IAsyncAction`.
It also re-writes (or factors?) the `IAsyncOperation<boolean>` implementation in dlls/cryptowinrt to use `ThreadPoolStatics::RunAsync`, by introducing a type-punning variant of `AsyncOperationCompletedHandler<T>` (similar to `WineAsyncOperationCompletedHandler`), which is a wrapper around the `IAsyncAction` returned by `RunAsync`.
The new `IAsyncOperation<T>` implementation is simpler, and if merged, can be exported to other dlls (windows.gaming.input and windows.security.credentials.ui.userconsentverifier for now).
--
v6: cryptowinrt: Rewrite IAsyncOperation using Windows.System.Threading.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6889
This is a bit convoluted because of the amount of pieces involved. I'll
try to untangle things a bit.
The container id is meant to be globally unique and stable. We therefore
need a suitable amount of stable entropy that we can feed into a hash
function to get a stable and unique output.
This happens in winebus. The corner stone of hash inputs is the linux
device topology (sysfs path) obtained via udev. Along with all other
possible data we feed this into a hash function to obtain our container
id.
A bunch of extra wine-specific keys needed to be added to carry the
necessary metadata from the driver into the ntoskrnl (where it gets
written to the property registry of the relevant device).
Separate from this we also ingest the linux device topology (sysfs path)
in the winepulse driver.
In mmdevapi we then use winepulse's sysfs path to find the matching
device in the setupapi and query its container id. We now have the same
container id in both the device and the MMDevice, allowing applications
(in particular Games) to find the MMDevice for a given device.
For practical reasons we always resolve the sysfs path to the root
device as early as possible. Container ids are meant to be equal for sub
devices inside a "container" anyway.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7238
64-bit volatile accesses are not atomic on i386. Both
i686-w64-mingw32-gcc and x86 MSVC splits 64-bit loads into a pair of
load/store ops.
Fix this by using a FILD/FISTP pair, which is also used to implement C11
atomics by i686-w64-mingw32-gcc.
Fixes: f82b1c1fcf770a5d6fa02c3f286282be79a201b8
--
v4: include: Prevent misuse of __WINE_ATOMIC_* helper macros for non-atomic large accesses.
include: Fix ReadNoFence64 on i386.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7237
64-bit volatile accesses are not atomic on i386. Both
i686-w64-mingw32-gcc and x86 MSVC splits 64-bit loads into a pair of
load/store ops.
Fix this by using a FILD/FISTP pair, which is also used to implement C11
atomics by i686-w64-mingw32-gcc.
Fixes: f82b1c1fcf770a5d6fa02c3f286282be79a201b8
--
v3: include: Prevent misuse of __WINE_ATOMIC_* helper macros for non-atomic large accesses.
include: Fix ReadNoFence64 on i386.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7237
64-bit volatile accesses are not atomic on i386. Both
i686-w64-mingw32-gcc and x86 MSVC splits 64-bit loads into two
load/stores of a pair of 32-bit words.
Fix this by using FILD/FSTP pair, which is used to implement C11 atomics
by i686-w64-mingw32-gcc.
Fixes: f82b1c1fcf770a5d6fa02c3f286282be79a201b8
--
v2: include: Prevent misuse of __WINE_ATOMIC_* helper macros for non-atomic large accesses.
include: Fix ReadNoFence64 on i386.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7237
64-bit volatile accesses are not atomic on i386. Both
i686-w64-mingw32-gcc and x86 MSVC splits 64-bit loads into two
load/stores of a pair of 32-bit words.
Fix this by using FILD/FSTP pair, which is used to implement C11 atomics
by i686-w64-mingw32-gcc.
Fixes: f82b1c1fcf770a5d6fa02c3f286282be79a201b8
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7237
"DIR /o" (no order specifier after /o) hasn't functioned the same as it does on Windows. This change makes the functionality of /o by itself equivalent to behavior on Windows.
--
v12: programs/cmd: Tests patch from @epo
https://gitlab.winehq.org/wine/wine/-/merge_requests/7131
"DIR /o" (no order specifier after /o) hasn't functioned the same as it does on Windows. This change makes the functionality of /o by itself equivalent to behavior on Windows.
--
v10: programs/cmd: Cleanup DIR /O logic.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7131