September 2025 - Wine-GitLab

[PATCH v5 0/3] MR8920: cmd: Fix some TYPE command behavior (one more try).
by Joe Souza (＠JoeS209) Sept. 14, 2025

Sept. 14, 2025

Giving this one final shot. If this is not deemed acceptable, I will abandon the effort and just move on to other things, no hard feelings. This is IMO a cleaner, more conservative/less invasive change. What is fixed: - Bug #56381, "TYPE c:\windows\winhelp.exe >foo", i.e. binary mode operation. I would probably consider this the main reason for this change. I'm trying to get the compiler mentioned in the bug report working. - Ctrl-Z termination of TYPE output to the console. - "TYPE con >foo", with Ctrl-Z handling, functionally equivalent to "COPY con foo". Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56381 -- v5: cmd: Fix TYPE behavior (now uses WCMD_copy_loop). cmd: Refactor WCMD_copy_loop out of WCMD_ManualCopy, and stop copy loop at EOF for /a mode. cmd/tests: Add test to check for TYPE truncation in binary mode. https://gitlab.winehq.org/wine/wine/-/merge_requests/8920

3 5

[PATCH 0/4] MR8969: opengl32, win32u: Fix 16-bit PFD_DRAW_TO_BITMAP rendering.
by Zowie van Dillen (＠zowie) Sept. 14, 2025

Sept. 14, 2025

This MR fixes 16-bit PFD_DRAW_TO_BITMAP rendering, as tested with SimGolf and Civilization 3. The fix isn't super performant since it involves a lot of back-and-forth between CPU and GPU, which is mostly noticeable when moving staff around in SimGolf — it slows to around two or three fps —, but on the plus side it does work, which is a straight upgrade over the current version of Wine. Couple of notes: * The third commit touches several different subsystems because I had to add a constant that's visible from both opengl32 and win32u. I wasn't sure how to write this down in the commit message. * There's a bug in LLVMpipe where a 32-bit pbuffer will cause it to crash. I opened an issue for it here: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13890. I needed a 32-bit pbuffer to make this work, so I added a special check that effectively disables 16-bit bitmap rendering for LLVMpipe. * I also had to use a workaround to make blitting & OpenGL rendering work together. I wrote about it pretty extensively below. ## Combining blitting & OpenGL rendering Something that's difficult about bitmap rendering is that it allows programs to combine OpenGL drawing with direct blitting onto bitmap memory. That's difficult to imitate with the pbuffer-based implementation because there's no way to replicate memory edits on the bitmap to the GPU-based pbuffer (since there's no API calls involved in the memory edit). This had to work to make the games actually work, so I used this workaround: Each time after overwriting the bitmap from the pbuffer, we clear the pbuffer with transparent. Also instead of "overwriting" the bitmap, we instead blend the pbuffer's pixels onto the bitmap. That way we're effectively overlaying the most recent OpenGL drawings on top of the bitmap. I'm pretty confident that that approach would also help with 32-bit and 24-bit bitmap rendering, but I don't know of any programs that use 32-bit or 24-bit bitmap rendering, so I wasn't able to check. I've just left 32-bit and 24-bit bitmaps as they were. While the workaround works really well for the games, I did have to edit another test because it used glReadPixels on 16-bit bitmaps. glReadPixels will grab pixels from the transparent-background pbuffer instead of the bitmap, which gives the wrong result. I'm not under the impression that any consumer programs use bitmap rendering together with glReadPixels (it doesn't make as much sense when you could just directly read the pixels from the bitmap), but it's possible to add a wrap_glReadPixels that grabs pixels from the bitmap in case of a 16-bit memory DC. It's not important to read but I wanted to write it down for the record: I also tried another workaround to make combining blitting & OpenGL work. The thought was to overwrite the pbuffer with the bitmap just before OpenGL draws to the pbuffer, to keep them in sync. It probably would have worked out if it was possible to add something to the front of the OpenGL command buffer in a glFinish/glFlush call — then I could have inserted glDrawPixels in the front, before all of the program's rendering operations —, but it's only possible to add things to the end of the command buffer unfortunately. I tried adding a wrapper to glBegin and glClear, which checks if they were the first render operation after a glFlush or glFinish. Unfortunately that didn't work at all. I'm guessing that Civ 3 and SimGolf still do direct bitmap edits after the first call to glBegin, so by the time the program gets to glFinish/glFlush the pixels that were uploaded in the glDrawPixels command are already stale (although I didn't really check). Anyhow, that approach was pretty fruitless. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8969

2 4

[PATCH 0/2] MR8968: setupapi: Parse a 0x prefix in SetupGetBinaryField().
by Elizabeth Figura (＠zfigura) Sept. 13, 2025

Sept. 13, 2025

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

2 2

[PATCH v10 0/5] MR8890: windows.devices.enumeration: Add support for parsing AQS filter strings.
by Vibhav Pant (＠vibhavp) Sept. 13, 2025

Sept. 13, 2025

-- v10: maintainers: Add a section for Windows.Devices.Enumeration. windows.devices.enumeration: Support parsing AQS filters in IDeviceInformationStatics::FindAllAsyncAqsFilter. https://gitlab.winehq.org/wine/wine/-/merge_requests/8890

2 5

[PATCH 0/8] MR8966: d3dx: Miscellaneous fixes.
by Connor McAdams (＠cmcadams) Sept. 12, 2025

Sept. 12, 2025

Add support for D3DFMT_CxV8U8, which is required for the game Biorage. Also add support for loading DDS files with header flag values of `DDS_PF_FOURCC` alongside other flag values. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8966

2 10

Re: [PATCH v3 0/1] MR8915: d3dx10_33/tests: Enable tests. - approved
by Alexandre Julliard (＠julliard) Sept. 12, 2025

Sept. 12, 2025

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

1 0

Re: [PATCH v2 0/1] MR8950: winetest: Print Windows revision (UBR). - approved
by Alexandre Julliard (＠julliard) Sept. 12, 2025

Sept. 12, 2025

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

1 0

Re: [PATCH v3 0/1] MR8962: dbghelp: Fix pointer truncation issues when parsing 64-bit Mach-O binaries in a Wow64 process - approved
by Alexandre Julliard (＠julliard) Sept. 12, 2025

Sept. 12, 2025

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

1 0

Re: [PATCH v3 0/1] MR8949: dxcore: Avoid races with the global adapter factory - approved
by Alexandre Julliard (＠julliard) Sept. 12, 2025

Sept. 12, 2025

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

1 0

Re: [PATCH v3 0/4] MR8958: win32u: Fixes for the OpenGL drawables mess. - approved
by Alexandre Julliard (＠julliard) Sept. 12, 2025

Sept. 12, 2025

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

1 0