In native Windows, the COPY command will display the names of the files as they are copied. Wine should do the same. This change enables that.
--
v4: cmd/tests: Add tests for unexpected COPY filename output.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8200
Windows allows closure of a waitable timer handle while a work item is
waiting on it. Also, the current Wine ntdll implementation calls
NtWaitForMultipleObjects() on multiple handles if multiple items are
pending, and if one handle is not valid, no items will execute.
Btw there are occurrences of `INVALID_HANDLE_VALUE` elsewhere, e.g. in `RtlDeleteTimer()`, which I think are incorrect, unless Windows internals are inconsistent with its use.
--
v2: ntdll: Duplicate handles for thread pool waits.
ntdll: Initialise waitable handles with NULL.
ntdll/tests: Test early closure of handles used for threadpool waits.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8191
In native Windows, the COPY command will display the names of the files as they are copied. Wine should do the same. This change enables that.
--
v3: cmd: COPY should output file names as they are copied.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8200
When page creation fails in PROPSHEET_SetCurSel, the dialog window is destroyed, which means the
attached PropSheetInfo (psInfo) is freed. Because there is a call to PROPSHEET_SetCurSel in the
handling of WM_INITDIAG, any use of psInfo thereafter could be invalid, which wasn't taken into
account.
* * *
this feels a bit iffy but i think this is the right fix? previously we got 0 return value from `PropertySheet` because `do_loop` calls `IsWindow(hwnd)`, and when page creation failed the `hwnd` is destroyed, which resulted in `do_loop` returning 0. i just duplicated this check in `PROPSHEET_PropertySheet` too. as for the change in `DiaglogProc`, if `PROPSHEET_SetCurSel` destroyed the window then the SendMessageW isn't necessary, i believe?
also, this bit is redundant i think?
```c
/* wizards set their focus during init */
if (psInfo->ppshheader.dwFlags & INTRNL_ANY_WIZARD)
return FALSE;
return FALSE;
```
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8204
When button_count is 0, we would allocate 0 bytes for line_widths, but later line_count would be 1
so we would still try to access line_widths[0] which is out-of-bound.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8205
In native Windows, the COPY command will display the names of the files as they are copied. Wine should do the same. This change enables that.
--
v2: cmd: COPY should output file names as they are copied.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8200
Generic ATTribute Profile (GATT) is a protocol used by BLE devices for data exchange. Broadly, every LE device contains one or more GATT services, with each service having multiple characteristics, which contain the actual piece of data to be exchanged. The Win32 BLE api is defined in [`bluetoothleapis.h`](https://learn.microsoft.com/en-us/windows/win32/api/bluetoothleapis/), and operates on `HANDLE`s to PDOs created by the driver to remote devices and services, using the `GUID_BLUETOOTHLE_DEVICE_INTERFACE` and `GUID_BLUETOOTH_GATT_SERVICE_DEVICE_INTERFACE` class interfaces respectively.
This MR introduces initial support for accessing GATT services on LE devices:
* Create PDOs for remote devices that we discover GATT services on, and enabling `GUID_BLUETOOTHLE_DEVICE_INTERFACE` for them.
* Because the driver also creates PDOs for bluetooth radios, a tagged union is used to distinguish between device extension values to dispatch IOCTL and PnP IRPs appropriately.
* Enumerate through all `org.bluez.GattService1` objects on BlueZ, and store them on the PE driver inside the associated devices.
* Implement IOCTL_WINEBTH_LE_DEVICE_GET_GATT_SERVICES for device PDOs.
* Use the newly added IOCTL to implement [`BluetoothGATTGetServices`](https://learn.microsoft.com/en-us/windows/win32/api/bluetoothleapis/nf-bluetoothleapis-bluetoothgattgetservices).
--
v6: bluetoothapis/tests: Add tests for BluetoothGATTGetServices.
bluetoothapis: Implement BluetoothGATTGetServices.
winebth.sys: Implement IOCTL_WINEBTH_LE_DEVICE_GET_GATT_SERVICES.
winebth.sys: Store a list of GATT services discovered on LE devices.
winebth.sys: Create PDOs for remote Bluetooth devices.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8174
Generic ATTribute Profile (GATT) is a protocol used by BLE devices for data exchange. Broadly, every LE device contains one or more GATT services, with each service having multiple characteristics, which contain the actual piece of data to be exchanged. The Win32 BLE api is defined in [`bluetoothleapis.h`](https://learn.microsoft.com/en-us/windows/win32/api/bluetoothleapis/), and operates on `HANDLE`s to PDOs created by the driver to remote devices and services, using the `GUID_BLUETOOTHLE_DEVICE_INTERFACE` and `GUID_BLUETOOTH_GATT_SERVICE_DEVICE_INTERFACE` class interfaces respectively.
This MR introduces initial support for accessing GATT services on LE devices:
* Create PDOs for remote devices that we discover GATT services on, and enabling `GUID_BLUETOOTHLE_DEVICE_INTERFACE` for them.
* Because the driver also creates PDOs for bluetooth radios, a tagged union is used to distinguish between device extension values to dispatch IOCTL and PnP IRPs appropriately.
* Enumerate through all `org.bluez.GattService1` objects on BlueZ, and store them on the PE driver inside the associated devices.
* Implement IOCTL_WINEBTH_LE_DEVICE_GET_GATT_SERVICES for device PDOs.
* Use the newly added IOCTL to implement [`BluetoothGATTGetServices`](https://learn.microsoft.com/en-us/windows/win32/api/bluetoothleapis/nf-bluetoothleapis-bluetoothgattgetservices).
--
v5: bluetoothapis/tests: Add tests for BluetoothGATTGetServices.
bluetoothapis: Implement BluetoothGATTGetServices.
winebth.sys: Implement IOCTL_WINEBTH_LE_DEVICE_GET_GATT_SERVICES.
winebth.sys: Store a list of GATT services discovered on LE devices.
winebth.sys: Create PDOs for remote Bluetooth devices.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8174
CRYPT_ImportSystemRootCertsToReg calls sync_trusted_roots_from_known_locations which calls
check_and_store_certs. check_and_store_certs creates a chain engine with `cached`. Here the problem
is that the chain engine actually owns the store used to create it. And when later the chain engine
is freed, the store is closed too.
This means on the success path `cached` is already closed when
sync_trusted_roots_from_known_locations returns to CRYPT_ImportSystemRootCertsToReg, but
CRYPT_ImportSystemRootCertsToReg tries to close `cached` again.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8180
NdrClientCall() should only be used in 32-bit mode when
Oi or Oic stub optimizations are used. Currently our interpreted
mode targets Oicf mode and other levels are not supported.
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
v2: include: Add errlup.idl.
widl: Do not write "const" modifiers for _PARAM_STRUCT fields.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8195
--
v4: win32u: Read window dpi_context from the shared memory.
win32u: Pass id and offset separately to find_shared_session_object.
server: Move window dpi_context to the shared memory.
server: Allocate shared memory objects for windows.
server: Fix shared object offset when additional blocks are allocated.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8061
--
v3: win32u: Read window dpi_context from the shared memory.
win32u: Pass id and offset separately to find_shared_session_object.
server: Move window dpi_context to the shared memory.
server: Allocate shared memory objects for windows.
server: Fix shared object offset when additional blocks are allocated.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8061
--
v7: mshtml: Remove outdated FIXME comment.
mshtml: Try to guess the script encoding when there's no BOM.
mshtml/tests: Test mixed charset encodings for document and text resources.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7360
On Tue Jun 3 05:45:11 2025 +0000, Rémi Bernon wrote:
> I think it's still worth implementing if it used by some applications,
> as it's not possible to use Windows Store apps/extensions in Wine?
Yeah you're right. And I guess we can simply skip any tests on Windows if the codec isn't installed.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8144#note_105295
Generic ATTribute Profile (GATT) is a protocol used by BLE devices for data exchange. Broadly, every LE device contains one or more GATT services, with each service having multiple characteristics, which contain the actual piece of data to be exchanged. The Win32 BLE api is defined in [`bluetoothleapis.h`](https://learn.microsoft.com/en-us/windows/win32/api/bluetoothleapis/), and operates on `HANDLE`s to PDOs created by the driver to remote devices and services, using the `GUID_BLUETOOTHLE_DEVICE_INTERFACE` and `GUID_BLUETOOTH_GATT_SERVICE_DEVICE_INTERFACE` class interfaces respectively.
This MR introduces initial support for accessing GATT services on LE devices:
* Create PDOs for remote devices that we discover GATT services on, and enabling `GUID_BLUETOOTHLE_DEVICE_INTERFACE` for them.
* Because the driver also creates PDOs for bluetooth radios, a tagged union is used to distinguish between device extension values to dispatch IOCTL and PnP IRPs appropriately.
* Enumerate through all `org.bluez.GattService1` objects on BlueZ, and store them on the PE driver inside the associated devices.
* Implement IOCTL_WINEBTH_LE_DEVICE_GET_GATT_SERVICES for device PDOs.
* Use the newly added IOCTL to implement [`BluetoothGATTGetServices`](https://learn.microsoft.com/en-us/windows/win32/api/bluetoothleapis/nf-bluetoothleapis-bluetoothgattgetservices).
--
v4: bluetoothapis/tests: Add tests for BluetoothGATTGetServices.
bluetoothapis: Implement BluetoothGATTGetServices.
winebth.sys: Implement IOCTL_WINEBTH_LE_DEVICE_GET_GATT_SERVICES.
winebth.sys: Store a list of GATT services discovered on LE devices.
winebth.sys: Create PDOs for remote Bluetooth devices.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8174
Windows allows closure of a waitable timer handle while a work item is
waiting on it. Also, the current Wine ntdll implementation calls
NtWaitForMultipleObjects() on multiple handles if multiple items are
pending, and if one handle is not valid, no items will execute.
Btw there are occurrences of `INVALID_HANDLE_VALUE` elsewhere, e.g. in `RtlDeleteTimer()`, which I think are incorrect, unless Windows internals are inconsistent with its use.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8191
NdrClientCall() should only be used in 32-bit mode when
Oi or Oic stub optimizations are used. Currently our interpreted
mode targets Oicf mode and other levels are not supported.
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8195
--
v6: mshtml: Remove outdated FIXME comment.
mshtml: Try to guess the script encoding when there's no BOM.
mshtml/tests: Test mixed charset encodings for document and text resources.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7360
This adds support for `CROSSDEBUG="dwarf pdb"` (or the equivalent `CROSSCFLAGS`) to enable embedding DWARF debug info alongside PDB files, as well as `CROSSDEBUG="split-dwarf pdb"` to generate both split DWARF and PDB files from a single Clang-based build. This makes it easier to produce a Wine build that can be debugged using both Windows and Unix tools.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8193
Follow-up of !2786, which appears to have been abandoned.
Depends on !8182
# Execute minimal test case
1. in dlls/ws2_32/tests/sock.c wrap all calls to test functions after `Init()` until `test_afunix()` with #if 0 ... #endif
2. checkout wine into ~/src/wine
3. build into ~/src/wine-build
4. run `(cd ~/src/wine-build; WINEPREFIX=~/src/wine/.wine ../wine/tools/runtest -q -P wine -T . -M ws2_32.dll -p dlls/ws2_32/tests/i386-windows/ws2_32_test.exe sock)`
# How to debug wineserver
Since `wineserver` runs in the background, simple calls to printf() will show nothing when the test case is executed. A workaround is to open a file and call fprintf() to write debug messages to this file, which can then be inspected.
--
v29: ws2_32: Add note in bind() for AF_UNIX sockets
ws2_32/tests: In tests for AF_UNIX sockets print actual directory used
ws2_32/tests: In AF_UNIX socket tests always print used path in case of errors
ws2_32/tests: Add test for AF_UNIX sockets
server: Fix getsockname() and accept() on AF_UNIX sockets.
server: Introduce error when attempting to create a SOCK_DGRAM AF_UNIX socket.
server: Allow for deletion of socket files.
ws2_32: Add support for AF_UNIX sockets.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7650
Follow-up of !2786, which appears to have been abandoned.
Depends on !8182
# Execute minimal test case
1. in dlls/ws2_32/tests/sock.c wrap all calls to test functions after `Init()` until `test_afunix()` with #if 0 ... #endif
2. checkout wine into ~/src/wine
3. build into ~/src/wine-build
4. run `(cd ~/src/wine-build; WINEPREFIX=~/src/wine/.wine ../wine/tools/runtest -q -P wine -T . -M ws2_32.dll -p dlls/ws2_32/tests/i386-windows/ws2_32_test.exe sock)`
# How to debug wineserver
Since `wineserver` runs in the background, simple calls to printf() will show nothing when the test case is executed. A workaround is to open a file and call fprintf() to write debug messages to this file, which can then be inspected.
--
v28: ws2_32: Add note in bind() for AF_UNIX sockets
ws2_32/tests: In tests for AF_UNIX sockets print actual directory used
ws2_32/tests: In AF_UNIX socket tests always print used path in case of errors
ws2_32/tests: Add test for AF_UNIX sockets
server: Fix getsockname() and accept() on AF_UNIX sockets.
server: Introduce error when attempting to create a SOCK_DGRAM AF_UNIX socket.
server: Allow for deletion of socket files.
ws2_32: Add support for AF_UNIX sockets.
ws2_32: Add afunix.h header.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7650
This MR also adds support for the I420 10LE format.
Windows doesn't have support for the I420 10LE format. Instead, a
decoding MFT will offer P010 as an output format.
Therefore, we translate GST_VIDEO_FORMAT_I420_10LE to
WG_VIDEO_FORMAT_P010_10LE so that Wine also offers P010 as an output.
This fixes playback of videos in VRChat that use I420 10LE as the raw video color format.
--
v3: winedmo: Add support for the P010 format.
winegstreamer: Add support for the P010 format.
mfplat: Add support for the P010 format.
mfplat/tests: Add image size tests for P010.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8144
On Wed May 28 16:18:33 2025 +0000, Jacob Czekalla wrote:
> changed this line in [version 5 of the diff](/wine/wine/-/merge_requests/8166/diffs?diff_id=181329&start_sha=2a4ed9fe52845b9c0198f9d66a0a48e00c6caea0#481a308eda1925984f142699cc247376b6478487_470_470)
Thanks for the feedback! Looks like it just got merged.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8166#note_105191
--
v3: avifil32: Fix dwLength counting for fixed size samples.
avifil32: Assume OF_WRITE for OF_CREATE in AVIFileOpenW().
avifil32/tests: Test creating AVI file with OF_CREATE but without access mode.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8152
--
v2: avifil32: Fix dwLength counting for fixed size samples.
avifil32: Assume OF_WRITE for OF_CREATE in AVIFileOpenW().
avifil32/tests: Test creating AVI file with OF_CREATE but without access mode.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8152
--
v5: mshtml: Remove outdated FIXME comment.
mshtml: Try to guess the script encoding when there's no BOM.
mshtml/tests: Test mixed charset encodings for document and text resources.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7360
--
v4: mshtml: Remove outdated FIXME comment.
mshtml: Try to guess the script encoding when there's no BOM.
mshtml/tests: Test mixed charset encodings for document and text resources.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7360
Windows doesn't support I420 10LE, but uses P010 instead, thus
GST_VIDEO_FORMAT_I420_10LE is ultimately converted to
GST_VIDEO_FORMAT_P010_10LE.
This fixes playback of videos in VRChat that use i420 10le as the raw video color format.
--
v2: winedmo: Add support for the P010 format.
winegstreamer: Add support for the I420 10LE format.
winegstreamer: Add support for the P010 format.
mfplat: Add support for the P010 format.
mfplat/tests: Add image size tests for P010.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8144
Marked as WIP since it depends on !8175 for the test to run reliably (and currently includes its commits).
Tests should be run both with HKCU\\Software\\Wine\\MediaFoundation\\DisableGstByteStreamHandler enabled and disabled.
--
v3: mfsrcsnk: Support thinning.
winedmo: Support thinning.
winegstreamer: Support thinning in media source.
winegstreamer: Support thinning in wg_parser.
mf: Support thinning in media session.
mf/tests: Add tests for thinning.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8184
Over the past several weeks I've been working on and off on this. I didn't track the hours but I'm sure that I've spent 80+ hours on the feature. I've tested and retested all known scenarios and it seems to be working as expected.
--
v55: cmd: Implement tab completion for command line entry.
include: Fix mistitled field in CONSOLE_READCONSOLE_CONTROL.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7843
Marked as WIP since it depends on !8175 for the test to run reliably (and currently includes its commits).
Tests should be run both with HKCU\\Software\\Wine\\MediaFoundation\\DisableGstByteStreamHandler enabled and disabled.
--
v2: mfsrcsnk: Support thinning.
winedmo: Support thinning.
winegstreamer: Support thinning in media source.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8184
Marked as WIP since it depends on !8175 for the test to run reliably (and currently includes its commits).
Tests should be run both with HKCU\\Software\\Wine\\MediaFoundation\\DisableGstByteStreamHandler enabled and disabled.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8184
I'm dealing with a game that relies on this constant.
Tagging @rbernon since this is using a proton commit of his.
Tests should be run both with HKCU\\Software\\Wine\\MediaFoundation\\DisableGstByteStreamHandler enabled and disabled.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8183
Generic ATTribute Profile (GATT) is a protocol used by BLE devices for data exchange. Broadly, every LE device contains one or more GATT services, with each service having multiple characteristics, which contain the actual piece of data to be exchanged. The Win32 BLE api is defined in [`bluetoothleapis.h`](https://learn.microsoft.com/en-us/windows/win32/api/bluetoothleapis/), and operates on `HANDLE`s to PDOs created by the driver to remote devices and services, using the `GUID_BLUETOOTHLE_DEVICE_INTERFACE` and `GUID_BLUETOOTH_GATT_SERVICE_DEVICE_INTERFACE` class interfaces respectively.
This MR introduces initial support for accessing GATT services on LE devices:
* Create PDOs for remote devices that we discover GATT services on, and enabling `GUID_BLUETOOTHLE_DEVICE_INTERFACE` for them.
* Because the driver also creates PDOs for bluetooth radios, a tagged union is used to distinguish between device extension values to dispatch IOCTL and PnP IRPs appropriately.
* Enumerate through all `org.bluez.GattService1` objects on BlueZ, and store them on the PE driver inside the associated devices.
* Implement IOCTL_WINEBTH_LE_DEVICE_GET_GATT_SERVICES for device PDOs.
* Use the newly added IOCTL to implement [`BluetoothGATTGetServices`](https://learn.microsoft.com/en-us/windows/win32/api/bluetoothleapis/nf-bluetoothleapis-bluetoothgattgetservices).
--
v3: bluetoothapis/tests: Add tests for BluetoothGATTGetServices.
bluetoothapis: Implement BluetoothGATTGetServices.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8174