- wine-gitlab - winehq.org

Re: [PATCH v25 0/6] MR7650: Add support for AF_UNIX sockets (followup)
by Ralf Habacker (＠rhabacker) 30 Apr '25

30 Apr '25

Ralf Habacker (@rhabacker) commented about server/sock.c: > + if (!(unix_path = mem_alloc( unix_path_len + 1 ))) > + return; > + > + memcpy( unix_path, (char *)(&params->addr) + sizeof(struct WS_sockaddr_un), unix_path_len ); > + unix_path[unix_path_len] = '\0'; > + > + base_name = strrchr(unix_path, '/'); > + if (base_name) > + { > + if (base_name != unix_path) > + (++base_name)[-1] = '\0'; > + } > + else > + base_name = unix_path; > + > + if (chdir( unix_path ) == -1) chdir() is also used here. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7650#note_102240

1 0

Re: [PATCH v25 0/6] MR7650: Add support for AF_UNIX sockets (followup)
by Ralf Habacker (＠rhabacker) 30 Apr '25

30 Apr '25

Ralf Habacker (@rhabacker) commented about server/sock.c: > return; > } > > + if (sock->family == WS_AF_UNIX && *addr->sa_data) > + fchdir(server_dir_fd); Here the working directory is also changed, which needs to be reviewed. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7650#note_102239

1 0

Re: [PATCH v25 0/6] MR7650: Add support for AF_UNIX sockets (followup)
by Ralf Habacker (＠rhabacker) 30 Apr '25

30 Apr '25

Ralf Habacker (@rhabacker) commented about server/sock.c: > + if (!(unix_path = mem_alloc( unix_path_len + 1 ))) > + return; > + > + memcpy( unix_path, (char *)(params + 1) + params->addr_len, unix_path_len ); > + unix_path[unix_path_len] = '\0'; > + > + base_name = strrchr(unix_path, '/'); > + if (base_name) > + { > + if (base_name != unix_path) > + (++base_name)[-1] = '\0'; > + } > + else > + base_name = unix_path; > + > + if (chdir( unix_path ) == -1) At https://gitlab.winehq.org/wine/wine/-/merge_requests/7519 it is pointed out that changing the working directory may not be a good idea, so it should be checked whether this can be avoided. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7650#note_102237

1 0

[PATCH v3 0/11] MR7869: Thread priority boosts (part 1)
by Marc-Aurel Zent (＠mzent) 30 Apr '25

30 Apr '25

This implements setting `ThreadPriorityBoost`, `ProcessPriorityBoost`, `ProcessBasePriority` and getting `ThreadPriorityBoost`, `ProcessPriorityBoost` NT info classes and adds tests where appropriate. The actual boosting mechanism will be in part 2 to keep the size of this MR manageable. -- v3: kernel32/tests: Add tests for GetProcessPriorityBoost/SetProcessPriorityBoost. kernelbase: Implement SetProcessPriorityBoost. kernelbase: Implement GetProcessPriorityBoost. ntdll: Implement ProcessPriorityBoost class in NtSetInformationProcess. ntdll: Implement ProcessPriorityBoost class in NtQueryInformationProcess. ntdll: Implement ThreadPriorityBoost class in NtSetInformationThread. ntdll: Properly implement ThreadPriorityBoost class in NtQueryInformationThread. ntdll/tests: Add tests for setting process base priority. ntdll: Implement ProcessBasePriority class in NtSetInformationProcess. https://gitlab.winehq.org/wine/wine/-/merge_requests/7869

3 14

[PATCH 0/4] MR7939: ntdll: Implement ProcessBasePriority class in NtSetInformationProcess.
by Marc-Aurel Zent (＠mzent) 30 Apr '25

30 Apr '25

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

2 4

[PATCH 0/1] MR7937: Draft: winewayland: Don't clip cursor coordinates to vscreen boundaries.
by Alexandros Frantzis (＠afrantzis) 30 Apr '25

30 Apr '25

Since the positions of win32 windows and their corresponding Wayland surfaces are not synchronized, there are cases where parts of a window are outside the vscreen boundaries, and thus inaccessible to input events, but still visible and accessible from a user (i.e., Wayland compositor) standpoint. Try to remedy this issue by instructing the Wine server to not clip the Wayland mouse event coordinates to vscreen boundaries. -- Relevant discussions: * https://gitlab.winehq.org/wine/wine/-/merge_requests/4014#note_47581 * https://gitlab.winehq.org/wine/wine/-/merge_requests/7919 @julliard @rbernon Do you think such an approach (or something along these lines) would have any future in upstream as (a possibly opt-in) workaround for the Wayland input issues? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7937

3 2

[PATCH 0/1] MR7919: winewayland.drv: Move windows to the top-left of the screen
by Julian Orth (＠mahkoh) 30 Apr '25

30 Apr '25

When opening the Cheat Engine [1] settings window, the window is spawned at around 400x400, making the right and bottom sides of the window inaccessible due to clipping. This commit moves the window to 0x0 to ensure that all window contents on the monitor are accessible. [1]: https://github.com/cheat-engine/cheat-engine Signed-off-by: Julian Orth <ju.orth(a)gmail.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7919

3 6

[PATCH v2 0/2] MR7780: win32u: Avoid uneeded (and sometimes harmful) RedrawWindow() calls in expose_window_surface().
by Paul Gofman (＠gofman) 30 Apr '25

30 Apr '25

-- v2: win32u: Only inflate dirty rect when dpi conversion is performed in expose_window_surface(). win32u: Don't redraw window in expose_window_surface() if window has surface. https://gitlab.winehq.org/wine/wine/-/merge_requests/7780

3 4

[PATCH v4 0/5] MR7848: server: Use events as a sync for several objects.
by Rémi Bernon (＠rbernon) 30 Apr '25

30 Apr '25

Instead of https://gitlab.winehq.org/wine/wine/-/merge_requests/7815, for https://gitlab.winehq.org/wine/wine/-/merge_requests/7226, this only split the sync ops to a separate vtable and let objects delegate theirs to a separate object. This starts using a event-like interface for most objects, leaving the decision regarding if/how to split sync themselves / integrate inproc syncs for later. -- v4: server: Use an event sync for fd objects. server: Introduce a new event sync object. server: Redirect fd-based objects sync to the fd. server: Add an operation to retrieve an object sync. server: Move object grab/release out of (add|remove)_queue. https://gitlab.winehq.org/wine/wine/-/merge_requests/7848

2 6

[PATCH v27 0/1] MR7843: cmd: Implement tab completion for command line entry.
by Joe Souza (＠JoeS209) 30 Apr '25

30 Apr '25

Over the past several weeks I've been working on and off on this. I didn't track the hours but I'm sure that I've spent 80+ hours on the feature. I've tested and retested all known scenarios and it seems to be working as expected. -- v27: cmd: Implement tab completion for command line entry. https://gitlab.winehq.org/wine/wine/-/merge_requests/7843

2 2

2025

2024

2023

2022

wine-gitlab