- wine-gitlab - winehq.org

[PATCH 0/6] MR9452: winevulkan: Introduce instance and device extension bitfields.
by Rémi Bernon (＠rbernon) 13 Nov '25

13 Nov '25

Moving the client specific extension filtering to the PE side, and tracking supported and enabled extension lists as bitfields. This makes it possible to store the client/host supported/enabled extension list on the vulkan objects, making it easily available and shareable with win32u. The goal is to then move the Vulkan device and instance wrappers to win32u, to benefit from their infrastructure (function pointer loading, etc), but also because D3DKMT will have to create Vulkan objects on its own for timeline and shared D3D12 fences, and allowing it to create Vulkan wrapped objects will make things easier than having a mix of host handles (in the D3DKMT stack) and wrapped handles (in the Vulkan stack). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9452

2 6

[PATCH v4 0/8] MR9438: dsound: Various
by Matteo Bruni (＠Mystral) 13 Nov '25

13 Nov '25

Some small dsound fixes I came up with while looking into Wine bug 30639 -- v4: dsound/tests: Mark weird DescriptionW propset failure on the AMD testbot machine. dsound: Return the mmdevapi endpoint ID as module. dsound: Fill all the DSPROPERTY_DIRECTSOUNDDEVICE_ENUMERATE data. dsound: Check data size in propset methods. dsound: Consistently trace locked byte count as an unsigned value. dsound: Print time as an unsigned value. dsound: Simplify check in DSOUND_RecalcFormat(). dsound/tests: Get rid of a crashing test. https://gitlab.winehq.org/wine/wine/-/merge_requests/9438

3 9

[PATCH 0/1] MR9405: dsound: Avoid use after free in DSOUND_WaveFormat (ASan).
by Bernhard Übelacker (＠bernhardu) 13 Nov '25

13 Nov '25

Contents of `mixwfe` is copied into `wfe` and `mixwfe` is freed by `CoTaskMemFree`. But then `mixwfe` is used again. This patch uses the values from `wfe`. [This is a testbot run with this patch](https://testbot.winehq.org/JobDetails.pl?Key=160647) [ASan details found by gitlab-CI](https://gitlab.winehq.org/bernhardu/wine/-/jobs/205270#L530) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9405

4 4

[PATCH v2 0/1] MR9439: mf: Return E_NOINTERFACE if service is missing
by Aric Stewart (＠aricstewart) 13 Nov '25

13 Nov '25

Signed-off-by: Aric Stewart <aric(a)codeweavers.com> -- v2: mf: Return E_NOINTERFACE if service is missing https://gitlab.winehq.org/wine/wine/-/merge_requests/9439

3 3

[PATCH 0/4] MR9443: comctl32/tab: Add a helper to draw the border background.
by Zhiyi Zhang (＠zhiyi) 13 Nov '25

13 Nov '25

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

3 5

Re: [PATCH v4 0/1] MR9423: ntdll: Warn when environment block is too large, instead of removing it
by Martino Fontana (＠tinozzo123) 13 Nov '25

13 Nov '25

As it is right now, with _all_ envars removed, then `XDG_DATA_DIRS` is always removed as well, right? Then, what about first sorting for size, and then doing a stable sort on whether it's a special envar? (So that while special envars like `XDG_DATA_DIRS` become high priority, the big envars that aren't special remains at the lowest priority.) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9423#note_121874

1 0

Re: [PATCH v3 0/1] MR9431: ole32: implement proper file flushing in FileLockBytes
by Esme Povirk (＠madewokherd) 13 Nov '25

13 Nov '25

Esme Povirk (@madewokherd) commented about dlls/ole32/filelockbytes.c: > > static HRESULT WINAPI FileLockBytesImpl_Flush(ILockBytes* iface) > { > + FileLockBytesImpl *This = impl_from_ILockBytes(iface); > + > + TRACE("(%p)\n", iface); > + > + /* verify a sane environment */ > + if (!This) return E_FAIL; > + > + if (!FlushFileBuffers(This->hfile)) > + return STG_E_WRITEFAULT; According to MSDN, this will fail if the file isn't opened with write permission (which, I think, shows that the tests aren't testing what you want). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9431#note_121872

1 0

Re: [PATCH v3 0/1] MR9431: ole32: implement proper file flushing in FileLockBytes
by Esme Povirk (＠madewokherd) 13 Nov '25

13 Nov '25

Esme Povirk (@madewokherd) commented about dlls/ole32/tests/storage32.c: > DeleteTestLockBytes(lockbytes); > } > > +static void test_lockbytes_flush_operation(void) > +{ > + static const WCHAR stmname[] = { 'T','E','S','T','S','T','R','E','A','M',0 }; > + TestLockBytes* lockbytes; > + HRESULT hr; > + IStorage* stg; > + IStream* stm; > + > + /* Test 1: Normal flush operation */ > + CreateTestLockBytes(&lockbytes); I don't think this tests what you want to test. `CreateTestLockBytes` uses the `TestLockBytes_Vtbl` implementation defined in the test itself. So calling the implementation of Flush defined in the test file doesn't really test anything about Windows. In fact, there doesn't seem to be a way to get the `ILockBytes` implementation from `filelockbytes.c` directly. I think that means that only the application-observable behavior matters. So, I think all we need the test to do is call `IStorage_Flush` on a storage file (and I think it needs to be a file, not an in-memory lockbytes) that was opened read-only. If that succeeds, then our internal ILockBytes should succeed in that case. If not, it'll depend on the behavior of `IStorage_Flush` in other situations. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9431#note_121871

1 0

Re: [PATCH v3 0/1] MR9431: ole32: implement proper file flushing in FileLockBytes
by Esme Povirk (＠madewokherd) 13 Nov '25

13 Nov '25

Esme Povirk (@madewokherd) commented about dlls/ole32/tests/storage32.c: > DeleteTestLockBytes(lockbytes); > } > > +static void test_lockbytes_flush_operation(void) > +{ > + static const WCHAR stmname[] = { 'T','E','S','T','S','T','R','E','A','M',0 }; I think we can just use `L"TESTSTREAM"` now. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9431#note_121870

1 0

Re: [PATCH v4 0/1] MR9423: ntdll: Warn when environment block is too large, instead of removing it
by Alexandre Julliard (＠julliard) 13 Nov '25

13 Nov '25

As has been pointed out, you can't decide which variables are important based on their size. Particularly since XDG_DATA_DIRS is one of the offenders, and it's used in Wine. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9423#note_121869

1 0

2025

2024

2023

2022

wine-gitlab