This fixes a bug when the session topology contains an invalid
source, which makes the session thread to hang and stop executing
commands.
--
v4: mf: Handle error when IMFMediaSource_Start fails.
mf: Handle errors when subscribing to events.
mf/tests: Test media session error handling.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2496
This fixes a bug when the session topology contains an invalid
source, which makes the session thread to hang and stop executing
commands.
--
v3: mf: Handle errors when subscribing to events.
mf/tests: Test media session error handling.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2496
Check the content of the output buffer in addition to checking the
return value.
Also show that multibyte characters are not truncated when the output
buffer is too small.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2613
On Fri Apr 7 14:53:00 2023 +0000, Rémi Bernon wrote:
> > I'm not sure what you mean by very integrated with win32u. Exposing
> builtin IMEs as "normal" IMEs is not affected by changes that I suggest.
> For driver interface, it would just replace one driver entry by another.
> I think I was confused by the idea of adding win32u specific interface
> for the callbacks. I'll consider doing this, as I think it also make
> sense to pass NtUserNotifyIMEStatus calls.
> I'm curious then, is there any advantage of using `NtUserMessageCall` vs
> `NtUserCallOneParam` or one of the other flavor? `NtUserMessageCall`
> takes a hwnd as first parameter, it feels a bit wrong to use an HIMC there.
I'd expect that `NtUserMessageCall` would be a bit nicer for wow64, because it may just pass through arguments like `NtUserSpyGetMsgName`, but yeah, handle type mismatch is not that nice.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2598#note_29322