--
v5: kernelbase: For FILE_FLAG_BACKUP_SEMANTICS also handle FILE_ATTRIBUTE_DIRECTORY in CreateFile.
kernel32/tests: Test FILE_FLAG_BACKUP_SEMANTICS | FILE_FLAG_POSIX_SEMANTICS | FILE_ATTRIBUTE_DIRECTORY.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8846
On Fri Aug 29 13:27:29 2025 +0000, Alexandros Frantzis wrote:
> Support for pbuffers in Mesa Wayland EGL has landed
> (https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36064). It
> won't make a difference in the short term since we will need to stick
> with the current approach (i.e., offscreen wl_surface) for backwards
> compatibility for some time. Perhaps in a couple of years it may make
> sense to take advantage of Wayland pbuffer support to simplify the
> code... if we are still using pbuffers by then :)
Nice, thank you!
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8498#note_114212
On Thu Jul 3 14:21:30 2025 +0000, Rémi Bernon wrote:
> Thanks! I'm working on getting a generic swapchain implementation based
> on FBOs and exportable images anyway, so eventually we might be able to
> use it to implement pbuffers without requiring platform support.
> Here I mostly just wanted to get pbuffers out of the way so I could make
> more changes the OpenGL window surface interface and make it converge
> with Vulkan surfaces, and I was mildly annoyed to find another lacking
> mechanism I assumed Wayland had already ;), but no big deal it should be
> fine like this.
Support for pbuffers in Mesa Wayland EGL has landed (https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36064). It won't make a difference in the short term since we will need to stick with the current approach (i.e., offscreen wl_surface) for backwards compatibility for some time. Perhaps in a couple of years it may make sense to take advantage of Wayland pbuffer support to simplify the code... if we are still using pbuffers by then :)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8498#note_114211
This MR introduces an initial implementation for `ReadPackageFromStream` in order to be able to decompress/read OPC packages, and enumerate their parts.
This is required for supporting AppX packages, which themselves are OPC packages as well. As such, the code does not implement support for reading relationships or interleaved archives, as AppX does not support either (`APPX_E_RELATIONSHIPS_NOT_ALLOWED`, `APPX_E_INTERLEAVING_NOT_ALLOWED`).
--
v2: opcservices: Implement IOpcPartSet::GetEnumerator for opened packages.
opcservices: Implement IOpcPart::GetContentType for opened packages.
opcservices: Implement IOpcPart::GetContentStream for opened packages.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8837
On Fri Aug 29 10:27:48 2025 +0000, xianwei zheng wrote:
> Without providing the software and Wine code, is there anything I can
> offer that could help you pinpoint the issue?
Please open a new bug on https://bugs.winehq.org, with a WINEDEBUG=+pid,+timestamp,+bitblt,+win,+opengl,+wgl,+x11drv trace attached if possible.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8694#note_114189
That fails because the window gains WS_CLIPSIBLINGS after SetParent(0) on native but that doesn't happen on wine.
```
HWND hwnd = ...
HWND hwnd2 = ...
SetParent(hwnd, hwnd2);
SetWindowLongPtrW(hwnd, GWL_STYLE, WS_OVERLAPPEDWINDOW);
// no WS_CLIPSIBLINGS
SetParent(hwnd, 0);
// has WS_CLIPSIBLINGS on native but not wine
SetWindowLongPtrW(hwnd, GWL_STYLE, WS_OVERLAPPEDWINDOW);
// both native and wine have WS_CLIPSIBLINGS
```
I see wine forces WS_CLIPSIBLINGS when the parent is the desktop window in win32u/window.c:set_window_long but no such thing on NtUserSetParent.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8848#note_114181