- wine-gitlab - winehq.org

Re: [PATCH v2 0/1] MR6415: mscoree: Update Wine Mono to 9.3.0. - approved
by Alexandre Julliard (＠julliard) 30 Aug '24

30 Aug '24

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

1 0

Re: [PATCH v2 0/1] MR6416: secur32: Ensure unixlib function tables and enum stay in sync. - approved
by Alexandre Julliard (＠julliard) 30 Aug '24

30 Aug '24

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

1 0

Re: [PATCH v2 0/1] MR6414: secur32: Simplify the cred_enabled_protocols logic slightly. - approved
by Alexandre Julliard (＠julliard) 30 Aug '24

30 Aug '24

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

1 0

Re: [PATCH v2 0/5] MR6411: Cmd engine rewrite (part XXIII) - approved
by Alexandre Julliard (＠julliard) 30 Aug '24

30 Aug '24

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

1 0

Re: [PATCH v32 0/4] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events.
by Rémi Bernon (＠rbernon) 30 Aug '24

30 Aug '24

On Fri Aug 30 18:00:21 2024 +0000, Vibhav Pant wrote: > > Maybe we can avoid sending the paths every time by moving the > filtering to plugplay, adapting the interface a bit for this. There > could be additional methods to register paths / get plugplay handles in > return, and later use these handle as device handles. > Perhaps, but wouldn't this make both plugplay service, and the > notification code sechost/service.c a lot more stateful as a result? Re: > device handles, if you're referring to the `dbch_handle` field in > `DEV_BROADCAST_HANDLE`, we already get that from the user using > `RegisterDeviceNotification`, and the current code just uses them for > sending notifications. I don't think adding custom structs is justified at this point, especially as it requires rewriting large parts of the code in multiple modules at the same time. > Perhaps, but wouldn't this make both plugplay service, and the notification code sechost/service.c a lot more stateful as a result? Re: device handles, if you're referring to the `dbch_handle` field in `DEV_BROADCAST_HANDLE`, we already get that from the user using `RegisterDeviceNotification`, and the current code just uses them for sending notifications. Fwiw I'm fine keeping the paths, and using the `reserved` field to describe them. I was just considering additional improvements but this specifically doesn't need to be done now. However, passing process-private handles around to other processes and later getting them back looks wrong. What happens if you register for notification on a handle then close it right away? Does the notification keep firing with the old handle value? It seem surprising and it would be a nice thing to test for instance. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_80567

1 0

Re: [PATCH v2 0/1] MR6413: msi: Bump version to 5.0. - approved
by Alexandre Julliard (＠julliard) 30 Aug '24

30 Aug '24

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

1 0

Re: [PATCH v2 0/2] MR6410: msiexec: Don't remove quotes from properties passed on the command line. - approved
by Alexandre Julliard (＠julliard) 30 Aug '24

30 Aug '24

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

1 0

Re: [PATCH v2 0/1] MR6403: winemac.drv: Call CGWindowListCreateImageFromArray through a dlsym-obtained pointer. - approved
by Alexandre Julliard (＠julliard) 30 Aug '24

30 Aug '24

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

1 0

Re: [PATCH v2 0/1] MR6406: include: Add input assembler related constants in d3d11.idl - approved
by Alexandre Julliard (＠julliard) 30 Aug '24

30 Aug '24

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

1 0

Re: [PATCH v2 0/1] MR6405: winemapi: Don't write past the end of the argv array. - approved
by Alexandre Julliard (＠julliard) 30 Aug '24

30 Aug '24

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

1 0

Re: [PATCH v8 0/1] MR6299: ntdll: Determine the available address space dynamically for 64bit architectures. - approved
by Alexandre Julliard (＠julliard) 30 Aug '24

30 Aug '24

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

1 0

Re: [PATCH v2 0/1] MR6404: packager: Prefer native version. - approved
by Alexandre Julliard (＠julliard) 30 Aug '24

30 Aug '24

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

1 0

Re: [PATCH v6 0/5] MR6386: winewayland: Reduce window surface buffer queue recreations. - approved
by Alexandre Julliard (＠julliard) 30 Aug '24

30 Aug '24

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

1 0

[PATCH v2 0/1] MR6420: winevulkan: Update to VK spec version 1.3.295.
by Georg Lehmann (＠DadSchoorse) 30 Aug '24

30 Aug '24

I have been putting this off for too long because handling VK_KHR_maintenance7 is not trivial. But by now a lot of other extensions have been released, so we should at least support those. -- v2: winevulkan: Update to VK spec version 1.3.295. https://gitlab.winehq.org/wine/wine/-/merge_requests/6420

2 1

[PATCH 0/1] MR6419: ntdll: Ignore HW breakpoints on the Unix side.
by Paul Gofman (＠gofman) 30 Aug '24

30 Aug '24

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

4 4

[PATCH 0/1] MR6418: user32: Implement EVENT_OBJECT_FOCUS for listbox items.
by Esme Povirk (＠madewokherd) 30 Aug '24

30 Aug '24

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

2 1

[PATCH v14 0/2] MR6130: shell32: Added stubs for the EnumerableObjectCollection COM class.
by Kevin Martinez (＠kevinrmartinez) 30 Aug '24

30 Aug '24

Stub added for the IEnumObjects and IObjectCollection interfaces, so that programs won't crash when calling it. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53620 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56891 -- v14: shell32: Added stub for IObjectCollection interface. shell32: Added stub for IEnumObjects interface. https://gitlab.winehq.org/wine/wine/-/merge_requests/6130

3 3

[PATCH 0/1] MR6416: secur32: Ensure unixlib function tables and enum stay in sync.
by Brendan Shanks (＠bshanks) 30 Aug '24

30 Aug '24

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

3 2

[PATCH 0/1] MR6415: mscoree: Update Wine Mono to 9.3.0.
by Esme Povirk (＠madewokherd) 30 Aug '24

30 Aug '24

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

3 2

[PATCH 0/1] MR6414: secur32: Simplify the cred_enabled_protocols logic slightly.
by Huw Davies (＠huw) 30 Aug '24

30 Aug '24

This avoids an (incorrect) compiler warning. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6414

2 1

Re: [PATCH v32 0/4] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events.
by Vibhav Pant (＠vibhavp) 30 Aug '24

30 Aug '24

> Maybe we can avoid sending the paths every time by moving the filtering to plugplay, adapting the interface a bit for this. There could be additional methods to register paths / get plugplay handles in return, and later use these handle as device handles. Perhaps, but wouldn't this make both plugplay service, and the notification code sechost/service.c a lot more stateful as a result? Re: device handles, if you're referring to the `dbch_handle` field in `DEV_BROADCAST_HANDLE`, we already get that from the user using `RegisterDeviceNotification`, and the current code just uses them for sending notifications. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_80535

1 0

[PATCH 0/1] MR6405: winemapi: Don't write past the end of the argv array.
by Huw Davies (＠huw) 30 Aug '24

30 Aug '24

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

3 2

Re: [PATCH v32 0/4] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events.
by Elizabeth Figura (＠zfigura) 30 Aug '24

30 Aug '24

On Fri Aug 30 05:47:12 2024 +0000, Rémi Bernon wrote: > > @rbernon I'm okay with using reserved as an offset to pass the device > path, but we'd still have to pass it for every message for filtering. I > didn't want to utilize `reserved` mostly out of caution, if it ever > turned out to be that the field did have some undocumented semantics > after all. > Maybe we can avoid sending the paths every time by moving the filtering > to plugplay, adapting the interface a bit for this. There could be > additional methods to register paths / get plugplay handles in return, > and later use these handle as device handles. That seems like an awful lot of complication just to avoid defining a structure? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_80533

1 0

[PATCH 0/1] MR6412: winecoreaudio: Set the synth volume to the greater of the left and right channels.
by Huw Davies (＠huw) 30 Aug '24

30 Aug '24

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

3 3

[PATCH 0/5] MR6399: Implement GetExtendedTcp/UdpTable on top of a new server call
by Tim Clem (＠tclem) 30 Aug '24

30 Aug '24

This series is motivated by performance requirements for GetExtendedTcpTable, especially the tables that require owner PIDs. In the worst case, the existing code scans all /proc/\<pid\>/fd directories for all Wine process for every socket, and may repeat the entire scan up to 5 times if the number of connections outgrew the buffer. With esync, processes can easily have hundreds of entries in /proc/\<pid\>/fd. And, in certain environments, reading the files under /proc can be very slow; I've seen GetExtendedTcpTable take almost 2 seconds to complete. Some applications (GOG Galaxy, Steam) use the TCP table to check that incoming connections to local services are from a set of whitelisted processes. It's possible for the GetExtendedTcpTable to take longer than the timeout on the socket, which results in failed communication between the client and service. wineserver knows about all sockets and what process they belong to. The only missing information needed for GetExtendedTcpTable is the state of TCP sockets, which is recoverable from getsockopt(TCP_INFO). I've added a function in server/handle.c that enumerates all handles of a given type in all processes. The new server calls use that to find all sockets and return the needed information. Apologies for commit 3 being large. I couldn't think of a way to split it without introducing dead code. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6399

4 14

2025

2024

2023

2022

wine-gitlab