- wine-gitlab - winehq.org

[PATCH v2 0/14] MR3303: Draft: winegstreamer: Implement wg_muxer
by Ziqing Hui (＠zhui) 07 Aug '23

07 Aug '23

Still working in progress. -- v2: temp winegstreamer: Implement wg_muxer. winegstreamer: Introduce array_reserve to unix lib. winegstreamer: Add mpeg4 sink class factory. winegstreamer: Add enum wg_container_type. winegstreamer: Make find_element accept NULL caps. winegstreamer: Add async command handling to media sink. winegstreamer: Add IMFClockStateSink stubs for media sink. winegstreamer: Implement IMFMediaEventGenerator for media sink. winegstreamer: Add stubs for stream sink. winegstreamer: Add stubs for media sink. mf/tests: Test IMFClockStateSink in shutdown state. mf/tests: Test sample processing for MPEG4 media sink. mf/tests: Use IMFMediaEventGenerator interface in event wait helper. https://gitlab.winehq.org/wine/wine/-/merge_requests/3303

3 15

[PATCH v4 0/6] MR3454: user32: Implement UOI_TIMERPROC_EXCEPTION_SUPPRESSION.
by Jinoh Kang (＠iamahuman) 06 Aug '23

06 Aug '23

This is required to avoid silencing (potentially fatal) exceptions from timer procedures. -- v4: win32u: Ignore unhandled info index in NtUserSetObjectInformation. win32u/tests: Add tests for NtUserSetObjectInformation. user32: Implement UOI_TIMERPROC_EXCEPTION_SUPPRESSION. user32/tests: Add tests for UOI_TIMERPROC_EXCEPTION_SUPPRESSION. include: Add definition for UOI_TIMERPROC_EXCEPTION_SUPPRESSION user32/tests: Make test_unicode_wm_char robust against superfluous messages. https://gitlab.winehq.org/wine/wine/-/merge_requests/3454

3 8

Re: [PATCH v2 0/1] MR3447: ntdll/unix: NtTerminateThread should accept NULL handle
by Jinoh Kang (＠iamahuman) 06 Aug '23

06 Aug '23

IMHO this should be made consistent with how `NtTerminateProcess()` handles NULL process handle. There's no special logic for NULL handles in the client[^wineserver] side of `NtTerminateProcess()`:[^NtTerminateProcess] ```c /****************************************************************************** * NtTerminateProcess (NTDLL.@) */ NTSTATUS WINAPI NtTerminateProcess( HANDLE handle, LONG exit_code ) { unsigned int ret; BOOL self; SERVER_START_REQ( terminate_process ) { req->handle = wine_server_obj_handle( handle ); /* <-- no NULL check here */ req->exit_code = exit_code; ret = wine_server_call( req ); self = reply->self; } SERVER_END_REQ; (...snip...) return ret; } ``` Instead, `NtTerminateProcess()` passes the handle to the wineserver[^wineserver], which is actually responsible for interpreting the process handle (and thus checking for NULL handle as well):[^terminate_process] ```c /* terminate a process */ DECL_HANDLER(terminate_process) { struct process *process; if (req->handle) /* <-- NULL check here */ { process = get_process_from_handle( req->handle, PROCESS_TERMINATE ); if (!process) return; } else process = (struct process *)grab_object( current->process ); reply->self = (current->process == process); terminate_process( process, current, req->exit_code ); release_object( process ); } ``` The `terminate_thread` handle should be made to accept NULL handle as well. [^wineserver]: Any Wine app process is a client of the *wineserver*, which emulates the core "kernel" part of the Windows. [^NtTerminateProcess]: https://gitlab.winehq.org/wine/wine/-/blob/f1749b0808c66a0341b77409cc9338ab… [^terminate_process]: https://gitlab.winehq.org/wine/wine/-/blob/f1749b0808c66a0341b77409cc9338ab… -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3447#note_41447

1 0

[PATCH 0/4] MR3517: Fixes for GDI/GDI+ newline measurements.
by Torge Matthies (＠tmatthies) 05 Aug '23

05 Aug '23

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

3 5

Re: [PATCH v3 0/1] MR3491: winegstreamer: Leave media source critical section before unlocking workqueue.
by Zebediah Figura (＠zfigura) 04 Aug '23

04 Aug '23

> Nothing can call PutWorkItem or use the queue after Shutdown has been called. True, although that fact is a little obscure (especially since MFPutWorkItem() is called from a callback. That said, my concern at this point is less about correctness than idiomaticity. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3491#note_41434

1 0

Re: [PATCH v3 0/1] MR3491: winegstreamer: Leave media source critical section before unlocking workqueue.
by Rémi Bernon (＠rbernon) 04 Aug '23

04 Aug '23

On Fri Aug 4 21:02:44 2023 +0000, Zebediah Figura wrote: > > We could maybe grab the Queue id in the cs, 0 it, and use the local > copy for unlocking. Does that sound better? > That does seem like an improvement; I can't say I see a better way to > solve the problem after looking, at least. We should probably mention in > a comment why we're releasing outside of the lock; it is not obvious at > all from the documentation that MFUnlockWorkQueue() can block. Nothing can call PutWorkItem or use the queue after Shutdown has been called. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3491#note_41432

1 0

[PATCH v2 0/3] MR3428: Avoid relying on linux/ipx.h to define SOL_IPX.
by Jinoh Kang (＠iamahuman) 04 Aug '23

04 Aug '23

Today, Wine fails to build with musl libc and Linux kernel 5.14 uAPI header files. musl libc doesn't supply any definitions for IPX, such as the SOL_IPX macro. However, it still provides linux/ipx.h from Linux uAPI header files if it exists. Linux kernel wouldn't drop linux/ipx.h from uAPI headers until 5.15, although IPX support has already been marked obsolete since 2018. Fix this by not defining HAS_IPX if linux/ipx.h has been included but nothing defines the SOL_IPX macro. Status of IPX support from other libcs are noted below: - bionic: netipx/ipx.h does not exist. linux/ipx.h may or may not exist. Note that sys/socket.h defines SOL_IPX even if linux/ipx.h is missing. - glibc: netipx/ipx.h exists. In this case, Wine assumes IPX support even if the operating system does not support it in runtime. - BSD variants: netipx/ipx.h may or may not exist. linux/ipx.h does not exist. Some BSDs supply SO_DEFAULT_HEADERS instead of SOL_IPX. -- v2: server: Avoid relying on linux/ipx.h to define SOL_IPX. ws2_32: Avoid relying on linux/ipx.h to define SOL_IPX. ntdll: Avoid relying on linux/ipx.h to define SOL_IPX. https://gitlab.winehq.org/wine/wine/-/merge_requests/3428

4 5

Re: [PATCH v3 0/1] MR3491: winegstreamer: Leave media source critical section before unlocking workqueue.
by Zebediah Figura (＠zfigura) 04 Aug '23

04 Aug '23

> We could maybe grab the Queue id in the cs, 0 it, and use the local copy for unlocking. Does that sound better? That does seem like an improvement; I can't say I see a better way to solve the problem after looking, at least. We should probably mention in a comment why we're releasing outside of the lock; it is not obvious at all from the documentation that MFUnlockWorkQueue() can block. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3491#note_41430

1 0

Re: [PATCH v3 0/1] MR3491: winegstreamer: Leave media source critical section before unlocking workqueue.
by Bernhard Kölbl (＠besentv) 04 Aug '23

04 Aug '23

On Fri Aug 4 20:16:23 2023 +0000, Zebediah Figura wrote: > > It doesn't matter much if the handle is invalid, as the PutWorkItem > call will just fail. > But the handle could in theory be reallocated for a different queue. > Also, if queues are supposed to be refcounted, it looks quite wrong that > a thread which doesn't have a reference to a handle is accessing it; > that's the sort of thing that generally causes memory errors. > It might be the case that our current implementation is preventing any > of this from being a problem in practice, but it's fragile and > unidiomatic, and it is rather confusing to anyone reading the code; it > looks like an error. We could maybe grab the Queue id in the cs, 0 it, and use the local copy for unlocking. Does that sound better? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3491#note_41426

1 0

Re: [PATCH v3 0/1] MR3491: winegstreamer: Leave media source critical section before unlocking workqueue.
by Zebediah Figura (＠zfigura) 04 Aug '23

04 Aug '23

> It doesn't matter much if the handle is invalid, as the PutWorkItem call will just fail. But the handle could in theory be reallocated for a different queue. Also, if queues are supposed to be refcounted, it looks quite wrong that a thread which doesn't have a reference to a handle is accessing it; that's the sort of thing that generally causes memory errors. It might be the case that our current implementation is preventing any of this from being a problem in practice, but it's fragile and unidiomatic, and it is rather confusing to anyone reading the code; it looks like an error. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3491#note_41425

1 0

2025

2024

2023

2022

wine-gitlab