July 2024 - Wine-gitlab - list.winehq.org

[PATCH v9 0/3] MR5104: include: Add missing Task Scheduler Trigger definitions
by Vijay Kiran Kamuju (＠infyquest) 29 Jul '24

29 Jul '24

This is a prerequisite for stub implementation of ILogonTrigger interface, which is needed for https://bugs.winehq.org/show_bug.cgi?id=47152 -- v9: include: Added IEventTrigger declaration. include: Add ISessionStateChangeTrigger declaration. include: Add more Task Scheduler Trigger interface definitions. https://gitlab.winehq.org/wine/wine/-/merge_requests/5104

3 4

[PATCH 0/1] MR6169: comctl32: fixed first we check index then array access by index is safe
by Herman Semenov (＠GermanAizek) 29 Jul '24

29 Jul '24

I think this PR changes will protect against situation if out-of-bounds access array. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6169

3 2

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

29 Jul '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 -- v5: shell32: Added stub for IObjectCollection interface. shell32: Added stub for IEnumObjects interface. https://gitlab.winehq.org/wine/wine/-/merge_requests/6130

5 20

[PATCH v5 0/11] MR6166: Draft: separate env for windows applications (WINENV) from env for wine processes (NIXENV)
by Alois Schloegl (＠schloegl) 28 Jul '24

28 Jul '24

Because WINENV is limited (32767 bytes), and HOSTENV can be much larger, a whitelisting approach is used to keep WINENV as small as possible. Currently, only the following envvars are propagated from the host env to WINENV WINEPATH, WINEPWD, WINEHOME, WINETEMP, WINETMP, WINEQT_, WINEVK_, WINEXDG_SESSION_TYPE Moreover, the NIXENV (env for running wine processes - not applications) on the host system is not produced from WINENV anymore, but the global ENV is propagated to all wine processes and threads. This might be an alternative approach to MR!5231, MR!6140, bug #56941 and should provide a more deterministic behaviour of wine, because unrelated envvars do have no influence on the env for running windows applications. Initial tests (winemine, notepad, cmd, etc) seem to run fine, but some envvars might need additional consideration. XVDK_* was mentioned, WINE*, MESA_*, VK_*, QT_*, LIBGL_* are other suspects. Moreover, this is my first merge request, so your feedback is highly appreciated. -- v5: remove is_dynamic_env_var(...) because it is not needed anymore https://gitlab.winehq.org/wine/wine/-/merge_requests/6166

8 12

[PATCH v3 0/10] MR6166: Draft: separate env for windows applications (WINENV) from env for wine processes (NIXENV)
by Alois Schloegl (＠schloegl) 28 Jul '24

28 Jul '24

Because WINENV is limited (32767 bytes), and HOSTENV can be much larger, a whitelisting approach is used to keep WINENV as small as possible. Currently, only the following envvars are propagated from the host env to WINENV WINEPATH, WINEPWD, WINEHOME, WINETEMP, WINETMP, WINEQT_, WINEVK_, WINEXDG_SESSION_TYPE Moreover, the NIXENV (env for running wine processes - not applications) on the host system is not produced from WINENV anymore, but the global ENV is propagated to all wine processes and threads. This might be an alternative approach to MR!5231, MR!6140, bug #56941 and should provide a more deterministic behaviour of wine, because unrelated envvars do have no influence on the env for running windows applications. Initial tests (winemine, notepad, cmd, etc) seem to run fine, but some envvars might need additional consideration. XVDK_* was mentioned, WINE*, MESA_*, VK_*, QT_*, LIBGL_* are other suspects. Moreover, this is my first merge request, so your feedback is highly appreciated. -- v3: Release 9.14. opengl32: Fix match criteria for WGL_DRAW_TO_PBUFFER_ARB. winex11: Query proper GLX attribute for pbuffer bit. gdiplus: Fixed order of adding offset and result ternary operator. nsiproxy.sys: Use the pcblist64 sysctl to enumerate UDP connections on macOS. nsiproxy.sys: Use the pcblist64 sysctl to enumerate TCP connections on macOS. https://gitlab.winehq.org/wine/wine/-/merge_requests/6166

8 11

Re: [PATCH v2 0/2] MR6164: opengl32: Fix wglChoosePixelFormatARB support for pbuffer. - approved
by Alexandre Julliard (＠julliard) 28 Jul '24

28 Jul '24

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

1 0

Re: [PATCH v2 0/1] MR6161: gdiplus: fixed order adding offset and result ternary operator - approved
by Alexandre Julliard (＠julliard) 28 Jul '24

28 Jul '24

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

1 0

Re: [PATCH v9 0/2] MR6021: nsiproxy.sys: Use pcblist64 sysctl to enumerate TCP & UDP connections on macOS. - approved
by Alexandre Julliard (＠julliard) 28 Jul '24

28 Jul '24

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

1 0

[PATCH 0/4] MR6157: d3dx9: More miscellaneous fixes.
by Connor McAdams (＠cmcadams) 28 Jul '24

28 Jul '24

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

3 10

[PATCH v27 0/6] MR5503: Fix initialization of the handler_fd_ops
by Ruslan Garipov (＠ruslangaripov) 28 Jul '24

28 Jul '24

This lists all fields of the `struct fd_ops` when object of that type -- `handler_fd_ops` in server/signal.c -- is being initialized. It looks like field list in initialization of the `handler_fd_ops` in server/signal.c was out-of-sync for a long time. Take a look, for example, on patches ad1e0609a0f (server: Get rid of no loner used cancel_async from fd_ops., 2016-12-01) (which removed "reference" to the `cancel_async` field correctly, but did not add "references" to the `read` and `write` fields, for example), or 837b39b2028 (server: Add read and write fd member functions., 2015-05-05) (which updated `struct fd_ops` but did not change initialization of the `handler_fd_ops` at all). Because the main purpose of initialization of the `handler_fd_ops` made in server/signal.c is to assign address of the `handler_poll_event()` function to the `poll_event` field, while making all other fields `NULL`ed, lacking some fields in that initialization is not an error according to C standard: > 6.7.11 Initialization > > 11 ... If an object that has static or thread storage duration is not > initialized explicitly, or any object is initialized with an empty > initializer, then it is subject to default initialization, which > initializes an object as follows: > > - if it has pointer type, it is initialized to a null pointer; > > ... > > 22 If there are fewer initializers in a brace-enclosed list than there > are elements or members of an aggregate, or fewer characters in a > string literal used to initialize an array of known size than there > are elements in the array, the remainder of the aggregate is subject > to default initialization. But to maintain code consistency I believe initialization of the `handler_fd_ops` object should enumerate all fields of the `struct fd_ops` type. No functional changes intended. ```shell $ ./configure ... $ make ... $ ./wine --version wine-9.6-74-g6a1dab2af04 ``` -- v27: Fix initialization of the msg_queue_fd_ops Fix initialization of the process_fd_ops Fix initialization of the thread_fd_ops Fix initialization of the inotify_fd_ops Fix initialization of the master_socket_fd_ops Fix initialization of the handler_fd_ops https://gitlab.winehq.org/wine/wine/-/merge_requests/5503

2 6