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
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
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
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
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