August 2024 - wine-gitlab

[PATCH v20 0/6] MR6166: separate env for windows applications (WINENV) from env for wine processes (NIXENV)
by Alois Schloegl (＠schloegl) 29 Aug '24

29 Aug '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. -- v20: ntdll: main_envp has been replaced by environ ntdll: remove is_dynamic_env_var(...) because it is not needed anymore ntdll: remove unused vars ntdll: remove dead code ntdll: conversion from HOSTENV to WINENV is now using whitelisting instead of blacklisting of envvars currently only envvars "WINE"<special_var> (as defined in is_special_env_var() ) are whitelisted. ntdll: separate env for windows applications (WINENV) from env for wine processes (NIXENV) WINENV is typically limited to 32767 WCHAR, the host environment where wine processes are running can be much larger. Keeping the two envs separate enables a more granula handling of envvars. (see also MR!5231, MR!6140, bug #56941) https://gitlab.winehq.org/wine/wine/-/merge_requests/6166

4 7

[PATCH v2 0/1] MR6400: user32/test: Test UpdateLayeredWindow with alpha-blending
by Matthias Schwarzott (＠zzam) 29 Aug '24

29 Aug '24

UpdateLayeredWindow with alpha-blending does not show correct colors. Calling it with hdc_src=NULL does nothing (in contrast to windows). -- v2: user32/test: Test UpdateLayeredWindow with alpha-blending https://gitlab.winehq.org/wine/wine/-/merge_requests/6400

5 5

[PATCH v6 0/1] MR6299: ntdll: Determine the available address space dynamically for 64bit architectures.
by Garrett Mesmer (＠gmesmer) 29 Aug '24

29 Aug '24

Resolves issue https://gitlab.winehq.org/wine/wine/-/merge_requests/3598#note_75871 The host address space limit may not be `0x7fffffff0000` on any architecture (eg: ARM64). Such architectures can fully emulate x86_64 Wine (eg: QEMU, FEX, BOX64) and need to have their host address space detected. Implementing the detection regardless of the Wine build architecture should not regress anything. -- v6: ntdll: Determine the available address space dynamically for 64bit architectures. https://gitlab.winehq.org/wine/wine/-/merge_requests/6299

4 3

[PATCH 0/1] MR6400: user32/test: Test UpdateLayeredWindow with alpha-blending
by Matthias Schwarzott (＠zzam) 29 Aug '24

29 Aug '24

UpdateLayeredWindow with alpha-blending does not show correct colors. Calling it with hdc_src=NULL does nothing (in contrast to windows). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6400

3 2

[PATCH v4 0/5] MR6386: winewayland: Reduce window surface buffer queue recreations.
by Rémi Bernon (＠rbernon) 29 Aug '24

29 Aug '24

-- v4: winewayland: Avoid recreating window surface buffer queues. winewayland: Create the window surface buffer queue unconditionally. winewayland: Set the window viewport source rectangle. winewayland: Rename surface buffer size to content size. winewayland: Require the wp_viewporter protocol. https://gitlab.winehq.org/wine/wine/-/merge_requests/6386

4 8

[PATCH v3 0/3] MR6386: winewayland: Reduce window surface buffer queue recreations.
by Rémi Bernon (＠rbernon) 29 Aug '24

29 Aug '24

-- v3: winewayland: Avoid recreating window surface buffer queues. winewayland: Create the window surface buffer queue unconditionally. winewayland: Set the window viewport source rectangle. https://gitlab.winehq.org/wine/wine/-/merge_requests/6386

3 6

[PATCH 0/6] MR6398: winex11: Use offscreen rendering to scale DPI-unaware GL windows.
by Rémi Bernon (＠rbernon) 29 Aug '24

29 Aug '24

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

2 6

[PATCH v3 0/1] MR6367: explorer: Use the EnableShell option to show or hide the taskbar.
by Rémi Bernon (＠rbernon) 29 Aug '24

29 Aug '24

The option is on by default with the virtual desktop, off by default otherwise, but can be forced on/off in either case, letting it hide the taskbar in virtual desktop mode too. The standalone systray window still uses the separate ShowSystray option which can be enabled when EnableShell is off. When EnableShell is on, the systray area will always be visible in the taskbar. -- v3: explorer: Use the EnableShell option to show or hide the taskbar. https://gitlab.winehq.org/wine/wine/-/merge_requests/6367

3 3

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) 29 Aug '24

29 Aug '24

On Thu Aug 29 16:15:21 2024 +0000, Elizabeth Figura wrote: > The problem isn't the name, it's the HANDLE. I suppose we *could* > manually fix that up later, but letting RPC take care of it for us seems > fine enough to me. Actually, I'm a bit confused, because now I'm not sure where RPC does do that? I was assuming it was a user-marshalled type which implicitly calls DuplicateHandle(), but that's not the case. The lack of tests in this patch set is a little disturbing. Is it possible to test this behaviour? I don't know under what circumstances handle events are sent [and I can't easily find anyone successfully using DBT_DEVTYP_HANDLE online]. We do have support for testing PnP drivers, though, if that's necessary; see dlls/ntoskrnl.exe/tests/driver_pnp.c. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_80395

1 0

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) 29 Aug '24

29 Aug '24

On Thu Aug 29 07:59:06 2024 +0000, Rémi Bernon wrote: > I mean, DEV_BROADCAST_HANDLE has a dbch_nameoffset which you can use to > put the device name in it, and use that for filtering? Or if you need an > additional offset, dbch_reserved? > (Then IMO it'd be better to not have to pass the device path through RPC > for filtering on every message) The problem isn't the name, it's the HANDLE. I suppose we *could* manually fix that up later, but letting RPC take care of it for us seems fine enough to me. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_80394

1 0

2025

2024

2023

2022

wine-gitlab August 2024