April 2026 - Wine-GitLab - list.winehq.org

[PATCH 0/1] MR10765: winmm: Handle DRVM_MAPPER_CONSOLEVOICECOM_GET messages.
by Henri Verbeet (＠hverbeet) April 29, 2026

April 29, 2026

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

3 2

[PATCH v8 0/1] MR10343: vbscript: Resolve parser conflicts with %prec and %expect.
by Francis De Brabandere (＠francisdb) April 29, 2026

April 29, 2026

Use %prec LOWER_THAN_ELSE on the empty EndIf_opt rule to explicitly resolve 4 dangling Else / End If shift/reduce conflicts. The remaining 8 conflicts are benign colon-chain ambiguities documented with %expect 8. -- v8: vbscript: Resolve parser conflicts with %prec and %expect. https://gitlab.winehq.org/wine/wine/-/merge_requests/10343

3 2

[PATCH 0/1] MR10780: ntdll: Only take PEB lock to update PEB data in RtlSetCurrentDirectory_U().
by Paul Gofman (＠gofman) April 29, 2026

April 29, 2026

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

2 2

Re: [PATCH v2 0/4] MR10654: winegstreamer: Fix wg_parser/native video stride mismatch.
by Elizabeth Figura (＠zfigura) April 29, 2026

April 29, 2026

On Wed Apr 29 14:44:33 2026 +0000, Yuxuan Shui wrote: > OK, I'll wait for Zeb to respond. > On the other hand, can you give my wmsyncreader MR !9567 some feedback then? I have encountered games using raw video and audio in practice. On the other hand, we have not yet seen games doing anything that would see a win32 decoding pipeline in wmvcore. For mfplat the situation is very different, and the decoding pipeline is visible in many ways, which is why I sent !5988. For wmvcore the difference is far less visible. We have here two different methods where we can solve a bug by being more compatible with Windows, while the other effects of that compatibility are things games are not known to care about. I don't understand why you are being so adamantly inconsistent about how we must match windows in one case despite the fact that games don't care, but there is no point matching Windows in the other case because games don't care. I for my part am advocating that we should choose one method because it is likely to be easier, and *hold off on* the other one for now. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10654#note_138223

1 0

[PATCH v6 0/2] MR10612: gdi32/uniscribe: Fix heap buffer overflow in ScriptStringAnalyse().
by समीरसिंह Sameer Singh (＠ss141309) April 29, 2026

April 29, 2026

Hi, I came across this bug while solving another issue. Steps to reproduce: 1. Open wine notepad 2. Start spamming any character that requires mark_invalid_combinations() in the notepad, such as: َ (0x064e Arabic Fatha) 3. At nearly 41 inserted Fatha, notepad will crash -- v6: gdi32/uniscribe: Resize the buffers if glyph count exceeds limit. gdi32/uniscribe: Perform bounds check in insert_glyph(). https://gitlab.winehq.org/wine/wine/-/merge_requests/10612

2 2

[PATCH 0/1] MR10777: msxml3: Create structured representation for element declarations.
by Nikolay Sivov (＠nsivov) April 29, 2026

April 29, 2026

Such representation is easy to shared with DOM for validation purposes, so that we don't have to parse it multiple times. Public API is using serialized representation. The parsing and serializing logic comes entirely from libxml2. Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10777

2 1

Re: [PATCH v2 0/4] MR10654: winegstreamer: Fix wg_parser/native video stride mismatch.
by Yuxuan Shui (＠yshui) April 29, 2026

April 29, 2026

On Wed Apr 29 14:31:49 2026 +0000, Rémi Bernon wrote: > Yes, I don't think we need to worry about reading raw samples out of > media sources / any other demuxer, unless it actually fixes some > application (which, like I said, I doubt it will ever). Also, your test > above seem to indicate that there's nothing to be done, which is > expected, as demuxer job is to hand over packets exactly as they are stored. OK, I'll wait for Zeb to respond. On the other hand, can you give my wmsyncreader MR !9567 some feedback then? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10654#note_138210

1 0

Re: [PATCH v2 0/4] MR10654: winegstreamer: Fix wg_parser/native video stride mismatch.
by Rémi Bernon (＠rbernon) April 29, 2026

April 29, 2026

On Wed Apr 29 14:27:31 2026 +0000, Yuxuan Shui wrote: > yeah i think @zfigura agreed that we should be using a pipeline that > resembles what Windows does, which would automatically give me all the > alignment fixes and i don't need to do anything. IIUC we are mostly done > on that front if we move to winedmo? except maybe `WMSyncReader` which > is my other MR. > IIUC Zeb's argument was even after we are done with this transition, an > mf media source can still produce raw video samples and therefore still > need to worry about alignment. that's what this MR is trying to fix, > this wasn't trying to fix the behavior when wg_parser is also used for > decoding. i agree with you that would be pointless as we are already > moving away from that. > unless you are saying because reading raw video from media sources are > not really used in practice so we don't need to worry about that? Yes, I don't think we need to worry about reading raw samples out of media sources / any other demuxer, unless it actually fixes some application (which, like I said, I doubt it will ever). Also, your test above seem to indicate that there's nothing to be done, which is expected, as demuxer job is to hand over packets exactly as they are stored. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10654#note_138209

1 0

Re: [PATCH v2 0/4] MR10654: winegstreamer: Fix wg_parser/native video stride mismatch.
by Yuxuan Shui (＠yshui) April 29, 2026

April 29, 2026

On Wed Apr 29 14:07:00 2026 +0000, Rémi Bernon wrote: > IMO we shouldn't bother about raw video directly in containers, it's > uncommon and unlikely to be ever encountered in practice: it's just > completely inefficient to store raw video frames in a file and except > for debugging and testing purposes I have never seen it done. In > addition, it's not what the games are doing and therefore changing the > way it's done is not going to fix their broken expectations. > The broken applications are broken because expect an actual decoding / > conversion pipeline to be there, and their expectations are coming from > the decoder / converter behaviors, which are the components that may add > extra buffer alignment for performance reasons. We should fix our > decoder / converters if they don't align buffers properly, but I believe > they now mostly do, and we should then make sure we use them in actual > pipelines as well. Anything else is pointless. yeah i think @zfigura agreed that we should be using a pipeline that resembles what Windows does, which would automatically give me all the alignment fixes and i don't need to do anything. IIUC we are mostly done on that front if we move to winedmo? except maybe `WMSyncReader` which is my other MR. IIUC Zeb's argument was even after we are done with this transition, an mf media source can still produce raw video samples and therefore still need to worry about alignment. that's what this MR is trying to fix, this wasn't trying to fix the behavior when wg_parser is also used for decoding. i agree with you that would be pointless as we are already moving away from that. unless you are saying because reading raw video from media sources are not really used in practice so we don't need to worry about that? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10654#note_138208

1 0

Re: [PATCH v2 0/4] MR10654: winegstreamer: Fix wg_parser/native video stride mismatch.
by Rémi Bernon (＠rbernon) April 29, 2026

April 29, 2026

On Wed Apr 29 14:01:09 2026 +0000, Yuxuan Shui wrote: > can we maybe conclude odd width video is bugged on Windows? IMO we shouldn't bother about raw video directly in containers, it's uncommon and unlikely to be ever encountered in practice: it's just completely inefficient to store raw video frames in a file and except for debugging and testing purposes I have never seen it done. In addition, it's not what the games are doing and therefore changing the way it's done is not going to fix their broken expectations. The broken applications are broken because expect an actual decoding / conversion pipeline to be there, and their expectations are coming from the decoder / converter behaviors, which are the components that may add extra buffer alignment for performance reasons. We should fix our decoder / converters if they don't align buffers properly, but I believe they now mostly do, and we should then make sure we use them in actual pipelines as well. Anything else is pointless. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10654#note_138199

1 0