--
v5: ntdll: Handle invalid FP state in usr1_handler() on i386.
ntdll: Handle invalid FP state in usr1_handler() on x64.
ntdll: Initilize segments registers in the frame in call_user_mode_callback().
https://gitlab.winehq.org/wine/wine/-/merge_requests/9060
This serie:
- drastically reduce winedbg attachement time when lots of modulesi
or exported symbols are present (current use case here reduces from
12 seconds to less than a second)
- fixes a crash in dbghelp.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/9078
Previously, ImmGenerateMessage could return early when ImmLockIMCC(ctx-\>hMsgBuf) failed, without unlocking the HIMC obtained via ImmLockIMC. This could leave the HIMC locked and lead to resource leaks.
This patch adds calls to ImmUnlockIMC(himc) at all early return points, and also unlocks the HIMC before returning TRUE at the end, ensuring that every ImmLockIMC call is properly balanced with a corresponding ImmUnlockIMC.
Tested on: Ubuntu 25.10 & deepin Linux V25, Wine compiled from master branch. No functional behavior of message dispatch is changed.
Signed-off-by: chenzhengyong chenzhengyong(a)uniontech.com
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/9077
Previously, ImmGenerateMessage could return early when ImmLockIMCC(ctx-\>hMsgBuf) failed, without unlocking the HIMC obtained via ImmLockIMC. This could leave the HIMC locked and lead to resource leaks.
This patch adds calls to ImmUnlockIMC(himc) at all early return points, and also unlocks the HIMC before returning TRUE at the end, ensuring that every ImmLockIMC call is properly balanced with a corresponding ImmUnlockIMC.
Tested on: Ubuntu 25.10 & deepin Linux V25, Wine compiled from master branch. No functional behavior of message dispatch is changed.
Signed-off-by: chenzhengyong chenzhengyong(a)uniontech.com
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/9074
Unlike the message queue for which I believe we can get rid of any special handling, I don't see a way to avoid a dedicated inproc sync for user APCs. This will make sure that the sync gets created on thread creation. It could arguably be lazily allocated instead, but I don't see a reason to delay the failure to a later time and end up with successfully created but unalertable thread when they are supposed to be.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/9014
These patches implement the existing functionality of `load_texture_data()` using shared code.
--
v4: d3dx10: Exclusively use shared code in load_texture_data().
d3dx10: Exclusively use shared code to load DDS files in load_texture_data().
d3dx10: Add support for compressing BC4 and BC5 formats.
d3dx10: Add support for decompressing BC4 and BC5 formats.
d3dx10: Ignore alpha channel values for WICPixelFormat32bppBGR BMP images.
d3dx10: Use shared code in load_texture_data() when possible.
d3dx{9,10}: Add a tweak to stb_dxt to more closely match native output.
https://gitlab.winehq.org/wine/wine/-/merge_requests/9034
Some background: I wanted to test EGL backend on my old laptop with Intel graphics limited with OpenGL 2.1 / GLES 2.0. When trying to run any game this led to a crash with NULL GL_RENDERER, but not with GLX. Tracing has shown that wined3d tries to create a context with high `WGL_CONTEXT_MAJOR_VERSION_ARB`/`WGL_CONTEXT_MINOR_VERSION`, which is not supported by hardware, resulting in the creation of nil context in EGL, but due to lack of error handling it's always assumed to be successful. In GLX this results in an error and creating a context does not lead to success, after which it tries again to create a context with a lower `WGL_CONTEXT_MAJOR_VERSION_ARB` / `WGL_CONTEXT_MINOR_VERSION` until the actual context is created. Proper error handling when creating EGL context as in this patch also allows wined3d to work on such hardware.
--
v2: win32u: Handle errors when creating EGL context
https://gitlab.winehq.org/wine/wine/-/merge_requests/9052