- Wine-GitLab - list.winehq.org

Re: [PATCH v5 0/2] MR10735: dsound: Create independent devices for each DirectSoundCreate call.
by Jon Koops (＠jonkoops) April 28, 2026

April 28, 2026

Thanks for the review @Mystral, I'll see if I can incorporate the feedback. As for the style of the tests, what would you like it to look like? I used the existing tests for dsound as a reference to implement the new ones added here. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10735#note_137962

1 0

Re: [PATCH v5 0/2] MR10735: dsound: Create independent devices for each DirectSoundCreate call.
by Matteo Bruni (＠Mystral) April 28, 2026

April 28, 2026

The MR looks good in principle. It's a bit unfortunate that you happened to follow the style of older tests, which I find quite ugly, but alas. One thing that I'd like to see here is a second "instance" of the same test but checking `DirectSoundCreate8()` (see dsound8.c). It's probably unlikely that it will show different results, but this is a good time to look for that. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10735#note_137960

1 0

Re: [PATCH v5 0/2] MR10735: dsound: Create independent devices for each DirectSoundCreate call.
by Matteo Bruni (＠Mystral) April 28, 2026

April 28, 2026

On Tue Apr 28 10:49:16 2026 +0000, Jon Koops wrote: > Also note that DirectSoundDevice-\>ref can now be cleaned up, as there > isn't any actual ref counting happening anymore, it is only ever set to > 1, and then set to 0, which immediately destroys the device right after. > However, I have opted to keep that cleanup out of this PR to keep it > simple to review. I'll see if that can be handled in a follow up PR. Thumb up on that. I'll also point out that `DirectSoundDevice` is not a public API but just an internal object, so this refcounting (or lack thereof) is not going to affect anything visible outside. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10735#note_137959

1 0

Re: [PATCH v5 0/2] MR10735: dsound: Create independent devices for each DirectSoundCreate call.
by Matteo Bruni (＠Mystral) April 28, 2026

April 28, 2026

Matteo Bruni (@Mystral) commented about dlls/dsound/tests/dsound.c: > + { > + rc=IDirectSoundBuffer_GetVolume(primary2,&vol); > + ok(rc==DS_OK, > + "IDirectSoundBuffer_GetVolume(primary2) failed: %08lx\n",rc); > + } > + > + /* Verify dso2's primary buffer has CTRLVOLUME */ > + ZeroMemory(&bufcaps, sizeof(bufcaps)); > + bufcaps.dwSize=sizeof(bufcaps); > + rc=IDirectSoundBuffer_GetCaps(primary2,&bufcaps); > + ok(rc==DS_OK,"IDirectSoundBuffer_GetCaps(primary2) failed: %08lx\n",rc); > + if (rc==DS_OK) { > + todo_wine > + ok(bufcaps.dwFlags & DSBCAPS_CTRLVOLUME, > + "primary2 should have DSBCAPS_CTRLVOLUME: %08lx\n",bufcaps.dwFlags); > + } ```suggestion:-9+0 memset(&caps, 0, sizeof(caps)); caps.dwSize = sizeof(caps); hr = IDirectSoundBuffer_GetCaps(primary2, &caps); ok(hr == DS_OK, "Unexpected hr %08lx\n", hr); todo_wine ok(bufcaps.dwFlags & DSBCAPS_CTRLVOLUME, "Unexpected dwFlags %08lx\n", caps.dwFlags); ``` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10735#note_137958

1 0

Re: [PATCH v5 0/2] MR10735: dsound: Create independent devices for each DirectSoundCreate call.
by Matteo Bruni (＠Mystral) April 28, 2026

April 28, 2026

Matteo Bruni (@Mystral) commented about dlls/dsound/tests/dsound.c: > + "IDirectSound_CreateSoundBuffer(dso2) failed: %08lx\n",rc); > + if (rc!=DS_OK || primary2==NULL) > + goto RELEASE1; > + > + /* Check whether the two IDirectSound objects share a primary buffer */ > + todo_wine > + ok(primary1!=primary2, > + "Two IDirectSound objects should have independent primary buffers\n"); > + > + /* GetVolume on dso2's primary buffer should succeed */ > + todo_wine > + { > + rc=IDirectSoundBuffer_GetVolume(primary2,&vol); > + ok(rc==DS_OK, > + "IDirectSoundBuffer_GetVolume(primary2) failed: %08lx\n",rc); > + } ```suggestion:-6+0 hr = IDirectSoundBuffer_GetVolume(primary2, &vol); todo_wine ok(hr == DS_OK, "Unexpected hr %08lx\n", hr); ``` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10735#note_137957

1 0

Re: [PATCH v5 0/2] MR10735: dsound: Create independent devices for each DirectSoundCreate call.
by Matteo Bruni (＠Mystral) April 28, 2026

April 28, 2026

Matteo Bruni (@Mystral) commented about dlls/dsound/tests/dsound.c: > + "DirectSoundCreate() failed: %08lx\n",rc); > + if (rc!=DS_OK) > + return; > + > + rc=DirectSoundCreate(NULL,&dso2,NULL); > + ok(rc==DS_OK||rc==DSERR_NODRIVER||rc==DSERR_ALLOCATED||rc==E_FAIL, > + "DirectSoundCreate() failed: %08lx\n",rc); > + if (rc!=DS_OK) { > + IDirectSound_Release(dso1); > + return; > + } > + > + rc=IDirectSound_SetCooperativeLevel(dso1,get_hwnd(),DSSCL_PRIORITY); > + ok(rc==DS_OK,"IDirectSound_SetCooperativeLevel(dso1) failed: %08lx\n",rc); > + if (rc!=DS_OK) > + goto EXIT; It doesn't look like this can legitimately fail (i.e. we leave the test only after flagging a test failure). The `if` should go. I know that there are existing tests that do exactly the same, but those should be ideally fixed and we don't want to add more of this bad pattern. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10735#note_137955

1 0

Re: [PATCH v5 0/2] MR10735: dsound: Create independent devices for each DirectSoundCreate call.
by Matteo Bruni (＠Mystral) April 28, 2026

April 28, 2026

Matteo Bruni (@Mystral) commented about dlls/dsound/tests/dsound.c: > + goto EXIT; > + > + rc=IDirectSound_SetCooperativeLevel(dso2,get_hwnd(),DSSCL_PRIORITY); > + ok(rc==DS_OK,"IDirectSound_SetCooperativeLevel(dso2) failed: %08lx\n",rc); > + if (rc!=DS_OK) > + goto EXIT; > + > + /* Create a primary buffer on dso1 with CTRL3D but without CTRLVOLUME */ > + ZeroMemory(&bufdesc, sizeof(bufdesc)); > + bufdesc.dwSize=sizeof(bufdesc); > + bufdesc.dwFlags=DSBCAPS_PRIMARYBUFFER|DSBCAPS_CTRL3D; > + rc=IDirectSound_CreateSoundBuffer(dso1,&bufdesc,&primary1,NULL); > + ok(rc==DS_OK && primary1!=NULL, > + "IDirectSound_CreateSoundBuffer(dso1) failed: %08lx\n",rc); > + if (rc!=DS_OK || primary1==NULL) > + goto EXIT; Similarly here and below. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10735#note_137956

1 0

Re: [PATCH v5 0/2] MR10735: dsound: Create independent devices for each DirectSoundCreate call.
by Matteo Bruni (＠Mystral) April 28, 2026

April 28, 2026

Matteo Bruni (@Mystral) commented about dlls/dsound/tests/dsound.c: > + DSBCAPS bufcaps; > + LONG vol; > + > + rc=DirectSoundCreate(NULL,&dso1,NULL); > + ok(rc==DS_OK||rc==DSERR_NODRIVER||rc==DSERR_ALLOCATED||rc==E_FAIL, > + "DirectSoundCreate() failed: %08lx\n",rc); > + if (rc!=DS_OK) > + return; > + > + rc=DirectSoundCreate(NULL,&dso2,NULL); > + ok(rc==DS_OK||rc==DSERR_NODRIVER||rc==DSERR_ALLOCATED||rc==E_FAIL, > + "DirectSoundCreate() failed: %08lx\n",rc); > + if (rc!=DS_OK) { > + IDirectSound_Release(dso1); > + return; > + } I think we should require the second `DirectSoundCreate()` call to return successfully if the first one goes through. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10735#note_137954

1 0

Re: [PATCH v6 0/2] MR10737: Optional handling of XQueryBestCursor
by Meow Jaceee (＠jaceee.wine) April 28, 2026

April 28, 2026

Base tests seem to be passing @julliard . Should add ones customary to the feature? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10737#note_137953

1 0

[PATCH 0/5] MR10763: opengl32: Generate code to call the get_integer hooks.
by Rémi Bernon (＠rbernon) April 28, 2026

April 28, 2026

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/10763

2 5

[PATCH 0/5] MR10716: dsound: Speed up resampling, part 6
by Anton Baskanov (＠baskanov) April 28, 2026

April 28, 2026

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/10716

3 10

[PATCH 0/1] MR10762: vbscript/tests: Add coverage for BSTR vs numeric comparison.
by Francis De Brabandere (＠francisdb) April 28, 2026

April 28, 2026

Add assertions for locale-invariant numeric-string forms ("+5", "-0", "05", " 5", "5 ", "5e0") and for type-mismatch errors raised when an unparseable BSTR ("abc", "", " ") is compared to a number with =, <> or a relational operator. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10762

2 1

[PATCH v4 0/6] MR10739: opengl32/tests: Test object names allocation and sharing.
by Rémi Bernon (＠rbernon) April 28, 2026

April 28, 2026

-- v4: opengl32/tests: Test object types shared namespaces. opengl32/tests: Test wglShareLists sharing of GLsync objects. opengl32/tests: Test wglShareLists sharing of various types. opengl32/tests: Test implicit object allocation support. opengl32/tests: Declare and load every GL/WGL functions. opengl32/tests: Remove unnecessary window creation check. https://gitlab.winehq.org/wine/wine/-/merge_requests/10739

2 7

[PATCH v3 0/6] MR10739: opengl32/tests: Test object names allocation and sharing.
by Rémi Bernon (＠rbernon) April 28, 2026

April 28, 2026

-- v3: opengl32/tests: Test object types shared namespaces. opengl32/tests: Test wglShareLists sharing of GLsync objects. opengl32/tests: Test wglShareLists sharing of various types. opengl32/tests: Test implicit object allocation support. opengl32/tests: Declare and load every GL/WGL functions. opengl32/tests: Remove unnecessary window creation check. https://gitlab.winehq.org/wine/wine/-/merge_requests/10739

3 11

[PATCH v4 0/1] MR10427: windows.ui.core.textinput: Add CoreTextServicesManager stubbed interface
by Alistair Leslie-Hughes (＠alesliehughes) April 28, 2026

April 28, 2026

-- v4: windows.ui.core.textinput: Add CoreTextServicesManager stubbed interface https://gitlab.winehq.org/wine/wine/-/merge_requests/10427

2 1

[PATCH 0/1] MR10338: comctl32/tooltips: Prevent tooltip from reappearing immediately after a click.
by Ivan Georgiev (＠ivanresen2006) April 28, 2026

April 28, 2026

When a mouse button is clicked while hovering over a tool, Windows hides the tooltip and suppresses it from reappearing until the cursor leaves the tool and re-enters it. Previously Wine would restart ID_TIMERSHOW on subsequent mouse moves over the same tool, causing the tooltip to pop up again immediately. Fix this by introducing a bClickCancelled flag that is set whenever any mouse button is pressed over an active tool, and cleared only when the cursor moves to a different tool. Also kill ID_TIMERSHOW in TOOLTIPS_Hide to prevent a pending show timer from firing after the tooltip is dismissed. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59520 Signed-off-by: Ivan Georgiev <ivanresen2006(a)gmail.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10338

3 4

[PATCH v5 0/2] MR10340: comctl32/tooltips: suppress icon and title when title is NULL or empty.
by Larry Starr (＠starrl) April 28, 2026

April 28, 2026

Per MSDN, TTM_SETTITLE with a NULL or empty title string should suppress both the title row and any associated icon. Previously an empty string was treated the same as a non-empty title, causing the icon to still be displayed and the tooltip to be incorrectly sized. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58236 Signed-off-by: Larry Starr <Larry_A_Starr(a)yahoo.com> -- v5: comctl32/tooltips: suppress icon and title when title is NULL or empty. comctl32/tooltips/tests: add regression test for TTM_SETTITLE with NULL or empty title. https://gitlab.winehq.org/wine/wine/-/merge_requests/10340

3 7

[PATCH v6 0/2] MR10451: comctl32/treeview: Implemented TVN_ITEMCHANGING & TVN_ITEMCHANGED
by Piotr Pawłowski (＠DEATH) April 28, 2026

April 28, 2026

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59456 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55707 -- v6: comctl32/treeview: Implemented TVN_ITEMCHANGING & TVN_ITEMCHANGED comctl32/tests/treeview: Enabled test_select() for comctl32 v6, made test for TVN_ITEMCHANGING & TVN_ITEMCHANGED https://gitlab.winehq.org/wine/wine/-/merge_requests/10451

4 14

[PATCH v4 0/4] MR10753: ntdll/actctx: Add privatePath probing functions in SxS loader
by Bolan Chen (＠bolanc) April 28, 2026

April 28, 2026

Besides manifest files, SxS Loader can also take a config file similar to CLR apps which can instruct the loader to look for manifests in additional paths. Autodesk installers use this somewhat obscure feature so this probe path will help Autodesk software installer to start. The config file looks like ``` <configuration> <windows> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <probing privatePath="path"/> </assemblyBinding> </windows> </configuration> ``` Microsoft mentions this feature in [application config files doc](https://learn.microsoft.com/en-us/windows/win32/sbscs/application-conf…. -- v4: ntdll/actctx: add correct fallback path using manifest.info actctx/tests: add tests ntdll/actctx: add proper probing functionality add essential functions to read .config file and parse privatePath https://gitlab.winehq.org/wine/wine/-/merge_requests/10753

2 4

[PATCH v2 0/2] MR10724: gdiplus: Elide empty spans.
by Conor McCarthy (＠cmccarthy) April 28, 2026

April 28, 2026

We assume a span is never empty and therefore can never begin at the right bound. An empty span there can break the requirement in combine_regions_to_spans() that current span Y coordinates are never less than the loop Y coordinate. Empty spans also break the in_left and in_right calculation. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59678 The added test will assert without the fix. -- v2: gdiplus/tests: Test a region intersect which produces empty spans. https://gitlab.winehq.org/wine/wine/-/merge_requests/10724

3 3

Re: [PATCH v50 0/2] MR10295: Fix ImageGetDigestStream
by Trent Waddington (＠trent.waddington) April 27, 2026

April 27, 2026

If you can direct me to any failing binaries, I'll add them to my regression suite. I'm testing 42 different binaries at the moment. 32 bit and 64 bit, exes and dlls, all imports and all four combinations of the resources or debug options. You'll notice the FIXME firing for any combination of flags without all imports. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10295#note_137890

1 0

[PATCH 0/1] MR10760: wusa: Split cabinet path before calling FDICopy.
by David Carrasco Flores (＠dcf1007) April 27, 2026

April 27, 2026

Wine's wusa currently passes the full cabinet path as the `pszCabinet` argument to `FDICopy()` and passes `NULL` as `pszCabPath`. This works with Wine's builtin cabinet implementation, but it does not match the documented FDICopy parameter usage. `FDICopy()` expects `pszCabinet` to contain only the cabinet file name, while `pszCabPath` contains the directory path. Wine's own FDICopy API documentation follows that convention, describing `pszCabinet` as the cabinet filename and `pszCabPath` as the cabinet file path. Microsoft's FDI documentation is more explicit: `pszCabinet` is the cabinet file name excluding path information, and `pszCabPath` is the cabinet path excluding the file name. The full cabinet path is then constructed internally by appending `pszCabinet` to `pszCabPath`. `pszCabPath` is an input `LPSTR` parameter and is not documented as optional. Passing `NULL` is therefore outside the documented API behavior, even though Wine's builtin cabinet.dll currently tolerates it. Native cabinet.dll crashes in this context. These changes are based on the existing path-splitting pattern used by `SetupIterateCabinetA()` in `dlls/setupapi/setupcab.c`, as well as the FDI resource-handling pattern used by `extract_cabinet()` in `dlls/msi/media.c`: - resolve the input path with `GetFullPathNameA()`; - split the result into `pszCabPath` and `pszCabinet`; - pass both values separately to `FDICopy()`; - release allocated memory on failure paths; - destroy the FDI context after `FDICopy()`, regardless of whether extraction succeeds. This improves compatibility with native cabinet.dll, which does not tolerate passing `NULL` for `pszCabPath` in this context. After applying this patch both native (from VistaSP1 and Win7SP1) and built-in cabinet.dll allow the graceful execution of wusa.exe -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10760

2 2

[PATCH 0/1] MR10759: msxml3: Improve attribute value normalization in DOM.
by Nikolay Sivov (＠nsivov) April 27, 2026

April 27, 2026

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10759

2 1

[PATCH 0/2] MR10758: wusa: Split cabinet path before calling FDICopy
by David Carrasco Flores (＠dcf1007) April 27, 2026

April 27, 2026

Wine's wusa currently passes the full cabinet path as the `pszCabinet` argument to `FDICopy()` and passes `NULL` as `pszCabPath`. This works with Wine's builtin cabinet implementation, but it does not match the documented FDICopy parameter usage. `FDICopy()` expects `pszCabinet` to contain only the cabinet file name, while `pszCabPath` contains the directory path. Wine's own FDICopy API documentation follows that convention, describing `pszCabinet` as the cabinet filename and `pszCabPath` as the cabinet file path. Microsoft's FDI documentation is more explicit: `pszCabinet` is the cabinet file name excluding path information, and `pszCabPath` is the cabinet path excluding the file name. The full cabinet path is then constructed internally by appending `pszCabinet` to `pszCabPath`. `pszCabPath` is an input `LPSTR` parameter and is not documented as optional. Passing `NULL` is therefore outside the documented API behavior, even though Wine's builtin cabinet.dll currently tolerates it. Native cabinet.dll crashes in this context. These changes are based on the existing path-splitting pattern used by `SetupIterateCabinetA()` in `dlls/setupapi/setupcab.c`, as well as the FDI resource-handling pattern used by `extract_cabinet()` in `dlls/msi/media.c`: - resolve the input path with `GetFullPathNameA()`; - split the result into `pszCabPath` and `pszCabinet`; - pass both values separately to `FDICopy()`; - release allocated memory on failure paths; - destroy the FDI context after `FDICopy()`, regardless of whether extraction succeeds. This improves compatibility with native cabinet.dll, which does not tolerate passing `NULL` for `pszCabPath` in this context. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10758

2 4

[PATCH v6 0/5] MR10748: wusa: Recognize runtime.syswow64 expressions.
by David Carrasco Flores (＠dcf1007) April 27, 2026

April 27, 2026

Some update manifests use $(runtime.syswow64) as an explicit target for the 32-bit system directory. wusa currently handles runtime.system32 with WoW64-aware redirection, but does not recognize runtime.syswow64, causing expression expansion to fail. Map runtime.syswow64 to CSIDL_SYSTEMX86 on x86_64, matching the existing runtime.programfilesx86 and runtime.commonfilesx86 handling. -- v6: Revert "wusa: Recognize runtime.syswow64 expressions." https://gitlab.winehq.org/wine/wine/-/merge_requests/10748

2 5