This MR fixes seek in VRChat by copying the sequence of flushes/stop/starts that Windows does.
The order on Windows is:
1. Stop sources;
2. Flush MFTs;
3. Start sources;
4. Request output down the chain of sink inputs;
6. Flush sinks; and
7. Start the clock
This takes place whether we pause before we seek or seek without pause.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7932
The wave format is passed to DirectSoundDevice_CreateSoundBuffer, which
duplicates it including the 1 byte of extra data after the end of the
struct.
--
v3: dsound/tests: Allocate right amount of memory in test_secondary8 (ASan).
https://gitlab.winehq.org/wine/wine/-/merge_requests/7926
Discovered while I was working on ASan support. ASan shadow memory might be placed where the main
image is normally loaded, forcing it to relocate. `virtual_map_module` handles this correctly but
`virtual_map_builtin_module` doesn't.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7962
If `KeUserModeCallback` fails, `ret_ptr` and `ret_len` might be left uninitialized. Since the
returned status isn't checked in `dispatch_win_proc_params`, it can access uninitialized memory.
* * *
One way this could actually happen is if on x86_64 `KeUserModeCallback` returned `STATUS_STACK_OVERFLOW`.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7960
Fixes a specific game's crash on startup.
`d2d_device_context_draw` doesn't accept `D2D_TARGET_UNKNOWN` because `render_target->target.bitmap->rtv` isn't reliably set when calling `ID3D11DeviceContext1_OMSetRenderTargets`. Therefore, we check for that condition and return early.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7959
VxDCall vwin32 service id 0x0010 provides int21 dispatch functionality and
VxDCall vwin32 service id 0x002a provides int41 dispatch functionality.
All of these vwin32 services together with existing service id 0x0029
(for int31/dpmi functionality) have same API, first VxDCall() argument is
value for EAX register and second argument is value for ECX register.
VxDCall vwin32 service id 0x0010 is used by applications in Andrew
Schulman's book Unauthorized Windows 95. For example by CHGDIR for
getting PSP.
--
v2: vwin32.vxd: Add support for VxDCall() 0x0010 and 0x002a services
https://gitlab.winehq.org/wine/wine/-/merge_requests/7906
Add `IOCTL_WINEBTH_RADIO_START_AUTH`, which gets used to implement `BluetoothAuthenticateDeviceEx`.
--
v8: bluetoothapis/tests: Add tests for BluetoothAuthenticateDeviceEx.
bluetoothapis: Use a wizard GUI to respond to pairing requests if an authentication callback is not registered.
bluetoothapis: Implement BluetoothAuthenticateDeviceEx.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7885
This is a set of tests to prove the correctness of a fix for bug 57588 which i am going to send in a separate PR.
Also a small fix for getting DevicePropertyEnumeratorName is included.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7889
WMSyncReader starts a background read thread that reads from the IStream
passed to IWMSyncReader::OpenStream. This means it could use the IStream in the
background even when no IWMSyncReader methods are being called.
For well-behaved applications, this is probably OK. However, AQUARIUM
(Steam 2515070) frees the IStream it passes to WMSyncReader _before_
it calls IWMSyncReader::Close, which stops the read thread. This causes
the read thread to access freed memory. This is improper, but not
unreasonable, as IWMSyncReader is supposed to be a synchronous
interface, so one might assume when they weren't calling into
IWMSyncReader methods, the IStream won't be used.
This commit adds a `wg_parser_dont_read` function, which can be used to
stop wg_parser from issuing read requests. This is used by IWMSyncReader
to make sure read requests are only issued when IWMSyncReader methods
are being called.
--
v7: winegstreamer: Make sure WMSyncReader never reads in the background.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7676
This event indicates that there will be no more data. Handling it like
an EOS fixes a dead lock that occurs when a stream completes.
--
v2: winegstreamer: Handle the Stream Group Done event.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7824
This fixes Defiant not being able to connect to game servers in game.
That regressed because of the apparently accidental change of the service names in commit 1904227cc363e0fed0fc69d038a0902010f9331b. The game depends on at least NetStatisticsGet("LanmanWorkstation") to succeed ("LanmanServer" may fail on Windows as well).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7936
On Fri May 2 16:52:15 2025 +0000, Alex Henrie wrote:
> I apologize for the stupid mistake. !7956 will fix it. Literally two
> minutes after I sent it, Bernhard sent an alternative fix in !7957 which
> would also be fine.
> I recognize that this happened primarily due to human error on my part.
> Nevertheless, another part of the problem is that the 32-bit tests
> always fail, and somehow this mistake did not cause the 64-bit tests to
> fail. That means that I need to spend some time helping with the
> intermittent test failures because they're making it too easy for me to
> overlook test failures that actually matter. Until the tests can be
> expected to pass, I will have to remember to read through the entire
> list of failures whenever I send a patch.
The test-linux-64 test suite only run a few tests that are otherwise skipped in a old/new wow64 environment like the one used for test-linux-32.
It's maybe a bit confusing but it otherwise would use another runner from >30min and it wasn't deemed useful to have a full test coverage run on every config.
The test-linux-32 sadly fails often, spuriously, although there have been up and downs I think it's getting better now and hopefully we'll get back to some occasional failures only.
Nevertheless, Gitlab now shows a short summary of failing tests (in the MRs "Test summary:" section, which can be expanded for a detailed list of failures) and I think we should be able to quickly check MR failures, and compare with other MRs or the testbot pattern page, to decide whether they are likely related or not.
Usually there's only a handful of spurious failures, with some well known returning failures, and a large number of/unusual failures should already still stand out, if we're paying attention.
Fwiw I'm not blaming you specifically here, it happens quite often (and I can be blamed for a fair amount the last few months). I'm mostly making sure it doesn't go unnoticed and try to raise awareness. At least as long as things get caught and fixed quickly it's probably fine. Fixing spurious failures would be nice too but that's much more difficult than it seems.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7925#note_102379
On Fri May 2 16:52:15 2025 +0000, Rémi Bernon wrote:
> This broke comctl32:status dwrite:font (win32/wow64) gdi32:font
> user32:sysparams usp10:usp10 tests.
I apologize for the stupid mistake. !7956 will fix it. Literally two minutes after I sent it, Bernhard sent an alternative fix in !7957 which would also be fine.
I recognize that this happened primarily due to human error on my part. Nevertheless, another part of the problem is that the 32-bit tests always fail, and somehow this mistake did not cause the 64-bit tests to fail. That means that I need to spend some time helping with the intermittent test failures because they're making it too easy for me to overlook test failures that actually matter. Until the tests can be expected to pass, I will have to remember to read through the entire list of failures whenever I send a patch.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7925#note_102376
--
v4: mshtml: Remove unused struct mutation_observer_ctor.
mshtml: Use designated initializers for the Location dispex data.
mshtml: Validate builtin host functions in IE9+ using prototype_id rather
mshtml: Store the object_id of the last object in the prototype chain that
https://gitlab.winehq.org/wine/wine/-/merge_requests/7934
Add `IOCTL_WINEBTH_RADIO_START_AUTH`, which gets used to implement `BluetoothAuthenticateDeviceEx`.
--
v7: bluetoothapis/tests: Add tests for BluetoothAuthenticateDeviceEx.
bluetoothapis: Use a wizard GUI to respond to pairing requests if an authentication callback is not registered.
bluetoothapis: Implement BluetoothAuthenticateDeviceEx.
winebth.sys: Implement IOCTL_WINEBTH_RADIO_START_AUTH.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7885
--
v3: mshtml: Use designated initializers for the Location dispex data.
mshtml: Validate builtin host functions in IE9+ using prototype_id rather
mshtml: Store the object_id of the last object in the prototype chain that
https://gitlab.winehq.org/wine/wine/-/merge_requests/7934
Ralf Habacker (@rhabacker) commented about server/sock.c:
> if (errno == EADDRINUSE && sock->reuseaddr)
> errno = EACCES;
>
> - set_error( sock_get_ntstatus( errno ) );
> - return;
> + /* Windows' AF_UNIX implementation has an edge case allowing for a socket to bind to
> + * an empty path. Linux doesn't, so it throws EINVAL. We check for this situation
> + * here and avoid early-exiting if it's the case. */
> + if (!(errno == EINVAL && sock->family == WS_AF_UNIX && !*params->addr.sa_data))
> + {
> + set_error( sock_get_ntstatus( errno ) );
> + if (sock->family == WS_AF_UNIX && *params->addr.sa_data)
> + fchdir(server_dir_fd);
This should be changed.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7650#note_102241
Ralf Habacker (@rhabacker) commented about server/sock.c:
> return;
> }
>
> + if (sock->family == WS_AF_UNIX && *addr->sa_data)
> + fchdir(server_dir_fd);
Here the working directory is also changed, which needs to be reviewed.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7650#note_102239
Ralf Habacker (@rhabacker) commented about server/sock.c:
> + if (!(unix_path = mem_alloc( unix_path_len + 1 )))
> + return;
> +
> + memcpy( unix_path, (char *)(params + 1) + params->addr_len, unix_path_len );
> + unix_path[unix_path_len] = '\0';
> +
> + base_name = strrchr(unix_path, '/');
> + if (base_name)
> + {
> + if (base_name != unix_path)
> + (++base_name)[-1] = '\0';
> + }
> + else
> + base_name = unix_path;
> +
> + if (chdir( unix_path ) == -1)
At https://gitlab.winehq.org/wine/wine/-/merge_requests/7519 it is pointed out that changing the working directory may not be a good idea, so it should be checked whether this can be avoided.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7650#note_102237
This implements setting `ThreadPriorityBoost`, `ProcessPriorityBoost`, `ProcessBasePriority` and getting `ThreadPriorityBoost`, `ProcessPriorityBoost` NT info classes and adds tests where appropriate.
The actual boosting mechanism will be in part 2 to keep the size of this MR manageable.
--
v3: kernel32/tests: Add tests for GetProcessPriorityBoost/SetProcessPriorityBoost.
kernelbase: Implement SetProcessPriorityBoost.
kernelbase: Implement GetProcessPriorityBoost.
ntdll: Implement ProcessPriorityBoost class in NtSetInformationProcess.
ntdll: Implement ProcessPriorityBoost class in NtQueryInformationProcess.
ntdll: Implement ThreadPriorityBoost class in NtSetInformationThread.
ntdll: Properly implement ThreadPriorityBoost class in NtQueryInformationThread.
ntdll/tests: Add tests for setting process base priority.
ntdll: Implement ProcessBasePriority class in NtSetInformationProcess.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7869
Since the positions of win32 windows and their corresponding Wayland
surfaces are not synchronized, there are cases where parts of a window
are outside the vscreen boundaries, and thus inaccessible to input
events, but still visible and accessible from a user (i.e., Wayland
compositor) standpoint. Try to remedy this issue by instructing the Wine
server to not clip the Wayland mouse event coordinates to vscreen
boundaries.
--
Relevant discussions:
* https://gitlab.winehq.org/wine/wine/-/merge_requests/4014#note_47581
* https://gitlab.winehq.org/wine/wine/-/merge_requests/7919
@julliard @rbernon Do you think such an approach (or something along these lines) would have any future in upstream as (a possibly opt-in) workaround for the Wayland input issues?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7937
When opening the Cheat Engine [1] settings window, the window is spawned
at around 400x400, making the right and bottom sides of the window
inaccessible due to clipping. This commit moves the window to 0x0 to
ensure that all window contents on the monitor are accessible.
[1]: https://github.com/cheat-engine/cheat-engine
Signed-off-by: Julian Orth <ju.orth(a)gmail.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7919
--
v2: win32u: Only inflate dirty rect when dpi conversion is performed in expose_window_surface().
win32u: Don't redraw window in expose_window_surface() if window has surface.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7780
Instead of https://gitlab.winehq.org/wine/wine/-/merge_requests/7815, for https://gitlab.winehq.org/wine/wine/-/merge_requests/7226, this only split the sync ops to a separate vtable and let objects delegate theirs to a separate object.
This starts using a event-like interface for most objects, leaving the decision regarding if/how to split sync themselves / integrate inproc syncs for later.
--
v4: server: Use an event sync for fd objects.
server: Introduce a new event sync object.
server: Redirect fd-based objects sync to the fd.
server: Add an operation to retrieve an object sync.
server: Move object grab/release out of (add|remove)_queue.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7848
These patches make a test case attached to the bug https://bugs.winehq.org/show_bug.cgi?id=33190 work.
--
v6: win32u: NtGdiExtTextOutW() should translate x,y from logical to device units at the last step.
win32u: Fix device<->world width/height converters.
win32u: Use slightly more readable names for DP/LP converters.
win32u: Use correct helper for converting width to device units.
gdi32/tests: Add some tests for rotated font metrics.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5068
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.
--
v27: cmd: Implement tab completion for command line entry.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7843
test_logfont in dlls/gdi32/tests/font.c calls CreateFontIndirectA with a
non-null-terminated font name and expects it to not crash.
--
v3: gdi32: Limit source string length in logfont_AtoW (ASan).
https://gitlab.winehq.org/wine/wine/-/merge_requests/7925
test_logfont in dlls/gdi32/tests/font.c calls CreateFontIndirectA with a
non-null-terminated font name and expects it to not crash.
--
v2: gdi32: Limit source string length in logfont_AtoW (ASan).
https://gitlab.winehq.org/wine/wine/-/merge_requests/7925
Signed-off-by: chenjiangyi <chenjiangyi(a)uniontech.com>
peb was limited in limit_2g ,but after user_space_wow_limit was assigned a value in init_peb function , wow64_params can be allocated in limit_4g if application perfers.
@julliard
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7935
Description: The printing function (non-Windows application call) used by Wine developers
is unnecessary to abort process when the string is super long. For example, the developer
prints a long commandline of wwmapp.exe by MESSAGE. As a result, the process cannot be
started, and the conference function cannot be used.
Signed-off-by: chenjiangyi <chenjiangyi(a)uniontech.com>
Change-Id: If06f0309f9745777f89b07dff8d302cb34b2a90e
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4635
According to the DPMI specification, when DPMI function 0800h (Physical
Address Mapping) fails then the carry flag has to be set.
For example if the application request for physical memory mapping via the
DPMI 0800h call it is required to set carry flag to indicate failure.
Otherwise application would be treated as successful operation in which
case in BX:CX registers is stored linear address of the mapped memory to
which application can access. Obviously on successful path if the BX:CX
registers are not set then application would try to access random memory
and crashes.
SysToolsLib, WinIO or libpci are just few examples of 32-bit Windows
libraries which issue this DPMI call via the kernel32.dll VxDCall()
function and are expecting either the carry flag on the failure or the
valid mapped address in BX:CX registers on success.
As the wine does not implement this DPMI function, always sets the carry
flag.
Windows NTVDM DPMI host does not implement the DPMI function 0800h too and
also always sets the carry flag. Tested and verified with a very simple
gcc/djgpp application on Windows NT.
So this also change aligns the wine behavior with the Windows NT.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7905
This fixes Trials Fusion often crashing when disconnecting a controller while there are more still connected.
--
v3: hidclass: Set Status for pending IRPs of removed devices to STATUS_DEVICE_NOT_CONNECTED.
ntdll/tests: Add more NtCancelIoFile[Ex]() tests.
ntdll: Wait for all pending operations to be cancelled in NtCancelIoFile[Ex]().
https://gitlab.winehq.org/wine/wine/-/merge_requests/7797
Instead of https://gitlab.winehq.org/wine/wine/-/merge_requests/7815, for https://gitlab.winehq.org/wine/wine/-/merge_requests/7226, this only split the sync ops to a separate vtable and let objects delegate theirs to a separate object.
This starts using a event-like interface for most objects, leaving the decision regarding if/how to split sync themselves / integrate inproc syncs for later.
--
v3: server: Use an event as debug event sync.
server: Use an event as file lock sync.
server: Use an event as process startup info sync.
server: Use an event as thread context sync.
server: Use an event as thread apc sync.
server: Use an event as fd sync.
server: Redirect fd-based objects sync to the fd.
server: Move object grab/release out of (add|remove)_queue.
server: Split object sync related vtable.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7848