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.
--
v8: 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
For a 32bit DLL, dbghelp exports both the 32bit and the 64bit
variant of some APIs (eg. StackWalk, SymLoadModule...).
For a 64bit DLL, only the 64bit variant is implemented and
exported (the two names point to the same address in the export
table).
This patch:
- uses the same function for both names (as native does) in .spec file
for 64bit architecture
- removes the 32bit variant from 64bit compilation,
- adapts also the corresponding import:s in imagehlp from dbghelp.
This mostly fixes 64bit apps, getting eg "StackWalk" address with
GetProcAddress() and expecting a 64bit code path.
(reported & tested by Stefan).
Signed-off-by: Eric Pouech <epouech(a)codeweavers.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8076
1. For %fs/fsbase the patch follows the macOS logic with LDT descriptor registration and Linux with switching. One notable difference is that on 32->64 transition we set %fs to GSEL(GUFS32_SEL, SEL_UPL) before restoring fsbase, otherwise FreeBSD will just revert it by reloading the selector [at the first opportunity](https://github.com/freebsd/freebsd-src/blob/5673462af5330df207…. GSEL(GUFS32_SEL, SEL_UPL) is the default %fs value on FreeBSD and is special-cased to save/restore actual fsbase value to/from PCB.
2. I was told we could get rid of fsbase glitches in signal handlers by blocking signals with [sigfastblock(2)](https://man.freebsd.org/cgi/man.cgi?query=sigfastblock) between %fs reset to the default value and fsbase reset to pthread_teb. This is currently a part of internal API for libthr, which could be exposed as pthread_signal_block_np for Wine. I'm on the fence whether it's worth it.
3. I fully admit I have no idea what registers are worth preserving around fallback sysarch(AMD64_SET_FSBASE) syscalls and whether it's appropriate to push those registers to stack. ("Kernel" stack should be fine, I assume?) Syscalls definitely clobber r8-r11.
4. For %ss see https://lkml.org/lkml/2015/4/24/216. FreeBSD doesn't have a similar workaround in the kernel, so it goes into Wine.
--
v2: ntdll: Unbreak new wow64 mode on FreeBSD.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8073
Some implibs contain code that indirectly includes winnt.h, which in
turn contains NtGetCurrentTeb. On arm64 that is implemented by reading
a global register variable. Gcc is perfectly fine with that, but clang
complains that x18 is not a reserved register on linux.
Signed-off-by: Sasha Finkelstein <fnkl.kernel(a)gmail.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8068
After `DeviceWatcher::Start()` gets called, `DeviceWatcher` enumerates through a list of all `DeviceInformation` objects on the current system through the `Added` event handlers, dispatching `EnumerationCompleted` once this has finished. This MR implements this functionality.
--
v5: windows.devices.enumeration: Implement initial device enumeration for DeviceWatcher::Start().
windows.devices.enumeration: Implement EnumerationCompleted handler for DeviceWatcher.
windows.devices.enumeration: Implement CreateWatcher.
windows.devices.enumeration: Implement Added handler for DeviceWatcher.
windows.devices.enumeration: Add tests for initial device enumeration in DeviceWatcher.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7997
It's possible to get WM_COMMAND(BN_CLICKED) during initialization in taskdialog_init(),
when window property is not yet set. Exceptions are swallowed on win32u transition.
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8084
--
v3: libs/ldap: Encrypted buffer layout is different for NTLM and Kerberos.
libs/ldap: sasl_decode() should treat intput buffer as data + token.
libs/ldap: sasl_encode() should construct output buffer as data + token.
libs/ldap: When initializing security context ask for mutual authentication.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8020
This change allows building with compiler exception support enabled (`-DUSE_COMPILER_EXCEPTIONS`) on non-i386 targets.
On i386, `_except_handler3` needs to be available. While we provide it as an import from the msvcrt DLLs, that's not sufficient for modules like
kernel32. Making this work would likely require moving `_except_handler3` to `winecrt0`.
In practice, this fixes the build with Clang, although the resulting binaries do not appear to be fully correct yet. Further investigation is needed, likely on the LLVM side.
--
v3:
https://gitlab.winehq.org/wine/wine/-/merge_requests/8067
This change allows building with compiler exception support enabled (`-DUSE_COMPILER_EXCEPTIONS`) on non-i386 targets.
On i386, `_except_handler3` needs to be available. While we provide it as an import from the msvcrt DLLs, that's not sufficient for modules like
kernel32. Making this work would likely require moving `_except_handler3` to `winecrt0`.
In practice, this fixes the build with Clang, although the resulting binaries do not appear to be fully correct yet. Further investigation is needed, likely on the LLVM side.
--
v2: winecrt0: Undefine USE_COMPILER_EXCEPTIONS in exception.c.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8067
On Mon May 19 08:23:31 2025 +0000, Nikolay Sivov wrote:
> I don't think this works, see [1]. You're freeing the same thing using
> two separate counters. My guess is that weak reference has to be a
> separate object, main object would keep a regular reference to it, once
> main thing is released it would clear itself from weak ref object. That
> will be an indication to fail Resolve(). I doesn't seem necessary to
> have multiple weak reference objects, that simplifies things.
> [1] https://gitlab.winehq.org/bernhardu/wine/-/blob/asan-pe_2025-05-06_wine-10.…
I will fix this. Thanks for spotting this.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8053#note_103799
Nikolay Sivov (@nsivov) commented about dlls/windows.ui/uisettings.c:
> IUISettings3 IUISettings3_iface;
> IUISettings4 IUISettings4_iface;
> IUISettings5 IUISettings5_iface;
> - LONG ref;
> + IWeakReferenceSource IWeakReferenceSource_iface;
> + IWeakReference IWeakReference_iface;
> + LONG ref_strong;
> + LONG ref_weak;
> };
I don't think this works, see [1]. You're freeing the same thing using two separate counters. My guess is that weak reference has to be a separate object, main object would keep a regular reference to it, once main thing is released it would clear itself from weak ref object. That will be an indication to fail Resolve(). I doesn't seem necessary to have multiple weak reference objects, that simplifies things.
[1] https://gitlab.winehq.org/bernhardu/wine/-/blob/asan-pe_2025-05-06_wine-10.…
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8053#note_103796
1. For %fs/fsbase the patch follows the macOS logic with LDT descriptor registration and Linux with switching. One notable difference is that on 32->64 transition we set %fs to GSEL(GUFS32_SEL, SEL_UPL) before restoring fsbase, otherwise FreeBSD will just revert it by reloading the selector [at the first opportunity](https://github.com/freebsd/freebsd-src/blob/5673462af5330df207…. GSEL(GUFS32_SEL, SEL_UPL) is the default %fs value on FreeBSD and is special-cased to save/restore actual fsbase value to/from PCB.
2. I was told we could get rid of fsbase glitches in signal handlers by blocking signals with [sigfastblock(2)](https://man.freebsd.org/cgi/man.cgi?query=sigfastblock) between %fs reset to the default value and fsbase reset to pthread_teb. This is currently a part of internal API for libthr, which could be exposed as pthread_signal_block_np for Wine. I'm on the fence whether it's worth it.
3. I fully admit I have no idea what registers are worth preserving around fallback syscalls to sysarch(AMD64_SET_FSBASE) and whether it's appropriate to push those to stack. ("Kernel" stack should be fine, I assume?) They definitely clobber r8-r11.
4. For %ss see https://lkml.org/lkml/2015/4/24/216. We don't have a similar workaround in the kernel, so it goes into Wine.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8073
eric pouech (@epo) commented about include/consoleapi.h:
> ULONG nLength;
> ULONG nInitialChars;
> ULONG dwCtrlWakeupMask;
> - ULONG dwConsoleKeyState;
this change (and the other ones using the correct field name) should be in a separate patch (inside the same merge request)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7843#note_103751
eric pouech (@epo) commented about programs/cmd/wcmdmain.c:
> +
> +static void build_search_string(WCHAR *inputBuffer, int len, SEARCH_CONTEXT *sc)
> +{
> + int cc = 0, nn = 0;
> + WCHAR *param = NULL, *last_param, *stripped_copy = NULL;
> + WCHAR last_stripped_copy[MAX_PATH] = L"\0";
> + BOOL need_wildcard = TRUE;
> +
> + sc->searchstr[0] = L'\0';
> +
> + /* If inputBuffer ends in a space then the user hit tab beyond the last
> + * parameter, so use that as the search pos (i.e. a wildcard search).
> + * Otherwise, parse the buffer to find the last parameter in the buffer,
> + * where tab was pressed.
> + */
> + if (inputBuffer[len-1] == L' ') {
len can be zero here (if \<tab\> is pressed at beg of line)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7843#note_103749
Failing gitlab CI examples are:
- [job #157583](https://gitlab.winehq.org/wine/wine/-/jobs/157583#L2282)
- [job #157314](https://gitlab.winehq.org/wine/wine/-/jobs/157314#L1957)
- [job #157131](https://gitlab.winehq.org/wine/wine/-/jobs/157131#L2052)
- [job #157068](https://gitlab.winehq.org/wine/wine/-/jobs/157068#L1955)
- [job #157032](https://gitlab.winehq.org/wine/wine/-/jobs/157032#L2150)
- [job #156785](https://gitlab.winehq.org/wine/wine/-/jobs/156785#L2112)
- [job #156713](https://gitlab.winehq.org/wine/wine/-/jobs/156713#L2048)
- [job 156677#](https://gitlab.winehq.org/wine/wine/-/jobs/156677#L2030)
So happens just a few times per day.
The value -1073741510 in `timeout.exe:timeout:06b4 done (-1073741510) in 5s 177B` equals to 0xC000013A, STATUS_CONTROL_C_EXIT. Therefore the assumption the ctrl-c from the test reaches sometimes the parent process.
--
v6: timeout/tests: Move the ctrl-c tests below an intermediate process.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8051
I was able to replicate the issue seen in [Bug 58113](https://bugs.winehq.org/show_bug.cgi?id=58113) on my M1.
The issue stems from the usage of AudioDevicePropertyVolumeScalar, which the audio driver for the M1 does not support (at least so it appears.) Using AudioObjectIsPropertySettable allows for fast checking for this situation, including preemptively disabling main channel audio if it appears to be unsupported.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7920
This change allows building with compiler exception support enabled (`-DUSE_COMPILER_EXCEPTIONS`) on non-i386 targets.
On i386, `_except_handler3` needs to be available. While we provide it as an import from the msvcrt DLLs, that's not sufficient for modules like
kernel32. Making this work would likely require moving `_except_handler3` to `winecrt0`.
In practice, this fixes the build with Clang, although the resulting binaries do not appear to be fully correct yet. Further investigation is needed, likely on the LLVM side.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8067
Application using Delphi runtime with Virtual-TreeView module, like xEdit, pass a NULL IDropSource to SHDoDragDrop, prevnting the drag and drop to works at all, when used in Windos Vista and above compatiblity mode, while windows xp compatibility mode works (as it use a dfferent system). Documentation stated that Windows Vista and above will create an internal IDropSource in this case.
Creating a dummy IDropSource with minimal functionality allow the drag and drop to works using the default cursor. In case of xEdit it won't show the cell that it's being dragged like on windows, a functionality that require a full implementation of IDropSource::GiveFeedback and DragSourceHelper2::InitializeFromBitmap.
Solve the functional part of #54923
I'm unsure on how to write tests for this.
--
v3: shell32: Create an internal IDropSource in SHDoDragDrop if it wasn't passed by the caller
https://gitlab.winehq.org/wine/wine/-/merge_requests/8063
Application using Delphi runtime with Virtual-TreeView module, like xEdit, pass a NULL IDropSource to SHDoDragDrop, prevnting the drag and drop to works at all, when used in Windos Vista and above compatiblity mode, while windows xp compatibility mode works (as it use a dfferent system). Documentation stated that Windows Vista and above will create an internal IDropSource in this case.
Creating a dummy IDropSource with minimal functionality allow the drag and drop to works using the default cursor. In case of xEdit it won't show the cell that it's being dragged like on windows, a functionality that require a full implementation of IDropSource::GiveFeedback and DragSourceHelper2::InitializeFromBitmap.
Solve the functional part of #54923
I'm unsure on how to write tests for this.
--
v2: shell32: Create an internal IDropSource in SHDoDragDrop if it wasn't passed by the caller
https://gitlab.winehq.org/wine/wine/-/merge_requests/8063
Application using Delphi runtime with Virtual-TreeView module, like xEdit, pass a NULL IDropSource to SHDoDragDrop, prevnting the drag and drop to works at all, when used in Windos Vista and above compatiblity mode, while windows xp compatibility mode works (as it use a dfferent system). Documentation stated that Windows Vista and above will create an internal IDropSource in this case.
Creating a dummy IDropSource with minimal functionality allow the drag and drop to works using the default cursor. In case of xEdit it won't show the cell that it's being dragged like on windows, a functionality that require a full implementation of IDropSource::GiveFeedback and DragSourceHelper2::InitializeFromBitmap.
Solve the functional part of #54923
I'm unsure on how to write tests for this.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8063