- Wine-gitlab - list.winehq.org

Re: [PATCH v2 0/1] MR1565: wldap32: Use the strdup function instead of reimplementing it. - approved
by Alexandre Julliard (＠julliard) 28 Nov '22

28 Nov '22

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1565

1 0

Re: [PATCH v2 0/12] MR1570: joy.cpl: Refactoring and fixes to prevent crash on exit. - approved
by Alexandre Julliard (＠julliard) 28 Nov '22

28 Nov '22

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1570

1 0

Re: [PATCH v2 0/2] MR1557: localspl: Add FILE: port monitor implementation - approved
by Alexandre Julliard (＠julliard) 28 Nov '22

28 Nov '22

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1557

1 0

Re: [PATCH v3 0/3] MR1536: Preparation to long types migration (serie II) - approved
by Alexandre Julliard (＠julliard) 28 Nov '22

28 Nov '22

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1536

1 0

Re: [PATCH v5 0/1] MR1503: wineusb.sys: Move event handling to a single thread.
by Zebediah Figura (＠zfigura) 28 Nov '22

28 Nov '22

> > Is it guaranteed that libusb_handle_events() will always return immediately after running an event callback? > > Yes. According to the libusb_handle_events_timeout_completed() documentation, which is the main function used internally by all other libusb_handle_events variant functions - *"If a non-zero timeval is passed and no events are currently pending, this function will block waiting for events to handle up until the specified timeout. If an event arrives or a signal is raised, this function will return early."* > > libusb_handle_events() basically calls libusb_handle_events_timeout_completed() with a 60s timeval, so it'll return either when an event occurs (hotplug, transfer, err, exit, etc.) or the timeout expires. I observed all the libusb code related to libusb_handle_events(), and found it does exactly that. Thanks, I did briefly look at the documentation but missed that. > > > I'm also disturbed by the fact that this fixes anything. Partly because I don't see what's special about that thread, and partly because I don't know why we're getting SIGQUIT? > > This core dump occurs when the last application quits, so a SIGQUIT is sent to all remaining services to quit. This particular winedevice.exe (which shares both winebus.sys and wineusb.sys) receives the signal, and when each thread's SIGQUIT handler gets called, the usb event handling thread segfaults somewhere in pthread_cond_wait() while being canceled by pthread_exit(). > > Normally this should work, but something happens when the library is implemented in Wine's Windows/Unix style. According to the bug report, when the execution flow is in the Unix library, it resets the stack to the exit_frame and calls the pthread_exit(), which fails to unwind properly. It's well described in this and the following post of the report: https://bugs.winehq.org/show_bug.cgi?id=52213#c11 > > So, to workaround this I just avoided using pthread_cond_wait() and moved to single-threaded event handling, since the libusb_handle_events() suits this approach quite well. Followed similar logic to the winebus.sys event thread implementation. Wouldn't we normally be in libusb_handle_events() at this point? I guess there's just differences between different call stacks? I don't think we should be terminating threads at all. It appears that comes from 7f749d58d, but we should probably just figure out what's keeping those threads alive and give them a chance to shut down naturally, adjusting timeouts if necessary. That's all orthogonal to this change, though, or at least, I think it makes sense regardless of bug 52213, since it simplifies the code. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1503#note_17734

1 0

[PATCH 0/2] MR1574: include: Add shobjidl_core.idl.
by Alex Henrie (＠alexhenrie) 28 Nov '22

28 Nov '22

Needed to compile Tera Term. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1574

5 8

[PATCH v2 0/1] MR1562: wininet: Simplify memory allocation in HTTP_InsertCustomHeader.
by Alex Henrie (＠alexhenrie) 28 Nov '22

28 Nov '22

-- v2: wininet: Simplify memory allocation in HTTP_InsertCustomHeader. https://gitlab.winehq.org/wine/wine/-/merge_requests/1562

3 3

[PATCH v2 0/1] MR1561: vbscript: Accept private and public const global declarations.
by Robert Wilhelm (＠sloper42) 28 Nov '22

28 Nov '22

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53783 -- v2: vbscript: Accept private and public const global declarations. https://gitlab.winehq.org/wine/wine/-/merge_requests/1561

4 5

[PATCH 0/5] MR53: vkd3d-shader/hlsl: transpose(), smoothstep(), and properly convert args of element-wise intrinsics.
by Francisco Casas (＠fcasas) 28 Nov '22

28 Nov '22

This patch includes an implementation of the long-pending `transpose` intrinsic and the `smoothstep` intrinsic. While implementing `smoothstep` I realized that some intrinsics have different rules for the allowed data types than expressions: - Vectors and matrices at the same time are not allowed, regardless of their dimensions. Even if they have the same number of components. - Any combination of matrices is always allowed, even those when no matrix fits inside another, e.g.: `float2x3` is compatible with `float3x2`, resulting in `float2x2`. The common data type is the min on each dimension. This is the case for `max`, `pow`, `ldexp`, `clamp` and `smoothstep`; which suggest that it is the case for all intrinsics where the operation is applied element-wise. So this was corrected. A minor fix in `pow`'s type conversion is also included. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/53

3 14

[PATCH 0/3] MR1575: include: Add __WINE_(DEALLOC|MALLOC) attributes to wine_get_(dos|unix)_file_name.
by Brendan Shanks (＠bshanks) 28 Nov '22

28 Nov '22

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

4 5