April 2026 - Wine-Devel - list.winehq.org

Re: [Question] Use of old FDI.h with Microsoft copyright notice as reference

by dcf1007＠gmail.com

Stefan Dösinger wrote: > Am Donnerstag, 30. April 2026, 19:41:53 Ostafrikanische Zeit schrieb David CF > via Wine-Devel: > > I was wondering whether it is OK to use information learned from this header > > to document the Wine API. I was also wondering whether it would be > > acceptable to patch some of the functions based on what I learned from this > > header. > > Learning from headers is OK. Facts and interfaces aren't copyrightable or > using them is fair use, depending on jurisdiction. What is NOT ok is > copypasting from a copyrighted header. What is also NOT ok is looking at > incompatibly licensed *implementations*. > > I sense that your concern is that you don't know how the header got into > public view, and that it might be leaked code. Looking at leaked > implementations would be a no-go, but a header shouldn't contain > implementation code. My best guess is that the header came from an OS/2 SDK. > Maybe you can find a more official source for it. > > The ideal approach is something like this: > > 1) You have a real world application that does not work with Wine's > cabinet.dll > 2) The documentation you found in this header offers an explanation of what > the application needs > 3) You write tests in dlls/cabinet/tests that demonstrate the behavior of the > native DLL > 4) You implement the behavior in Wine. > > Somewhere in step 3 or 4 you'll likely need additional defines. Add them to > Wine's header by typing them yourself, but don't copypaste from Microsoft's > header. Yes, indeed I was wondering if learning from a header that could have been leaked might suppose a problem. I wanted to understand the types and the return calls better than what the MS Learn Win32 API and the Wine API provided, so I could trace better where Wine's implementation was not behaving as it should. My case scenario is a bit the opposite of what you imagined: I have a binary and a dll from Wine that crashe when using the call to the native cabinet.dll, whilst they end gracefully with Wine's cabinet.dll. So Wine's cabinet.dll implementation seems to be more flexible and forgiving than the native one. I have 2 goals: 1) Document better what has already been implemented and leave some documentation/hints on the behavior that the unimplemented parts are expected to have. 2) When possible, go down the rabbit hole and trace down the point where the callback differs from the native DLL and if possible fix it. I am glad to hear that learning from the headers is not a problem. After reading your message I looked into it a bit more and found that the header belongs to the "Cabinet Software Development Kit" from March 20, 1997. I found the whole SDK, as well as a history/changelog of the cabinet.dll since it was created in 1993. So I guess for my purposes it is a valid resource then. Thanks for your quick response!

April 30, 2026

Re: [Question] Use of old FDI.h with Microsoft copyright notice as reference

by Stefan Dösinger

Am Donnerstag, 30. April 2026, 19:41:53 Ostafrikanische Zeit schrieb David CF via Wine-Devel: > I was wondering whether it is OK to use information learned from this header > to document the Wine API. I was also wondering whether it would be > acceptable to patch some of the functions based on what I learned from this > header. Learning from headers is OK. Facts and interfaces aren't copyrightable or using them is fair use, depending on jurisdiction. What is NOT ok is copypasting from a copyrighted header. What is also NOT ok is looking at incompatibly licensed *implementations*. I sense that your concern is that you don't know how the header got into public view, and that it might be leaked code. Looking at leaked implementations would be a no-go, but a header shouldn't contain implementation code. My best guess is that the header came from an OS/2 SDK. Maybe you can find a more official source for it. The ideal approach is something like this: 1) You have a real world application that does not work with Wine's cabinet.dll 2) The documentation you found in this header offers an explanation of what the application needs 3) You write tests in dlls/cabinet/tests that demonstrate the behavior of the native DLL 4) You implement the behavior in Wine. Somewhere in step 3 or 4 you'll likely need additional defines. Add them to Wine's header by typing them yourself, but don't copypaste from Microsoft's header.

April 30, 2026

Re: [Question] Use of old FDI.h with Microsoft copyright notice as reference

by dcf1007＠gmail.com

https://github.com/OS2World/APP-COMM-Capitel/blob/master/setup/source.win/f…

April 30, 2026

[Question] Use of old FDI.h with Microsoft copyright notice as reference

by David CF

Dear all, Sorry to bother, but I could not find a clear answer and would like to check before doing any Wine work based on material with an unclear legal status. I was looking into Wine's implementation of FDI and cabinet.dll. While looking at code examples using FDICreate and FDICopy, I stumbled upon an old GPL project called CapiTel. The FDI.h contained in this project has many useful explanations for constants and functions that are poorly documented in the Microsoft Learn Win32 API reference, as well as in Wine's API reference. However, the file says: Copyright (C) Microsoft Corporation 1993-1997. All Rights Reserved. I was wondering whether it is OK to use information learned from this header to document the Wine API. I was also wondering whether it would be acceptable to patch some of the functions based on what I learned from this header. Thanks in advance for your help and guidance, David Carrasco Flores

April 30, 2026

[PATCH] user32: Add InitializeTouchInjection stub.

by Joe Meyer

--- dlls/user32/input.c | 9 +++++++++ dlls/user32/user32.spec | 2 +- 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/dlls/user32/input.c b/dlls/user32/input.c index 48b38166b75..74c52df9e1b 100644 --- a/dlls/user32/input.c +++ b/dlls/user32/input.c @@ -688,6 +688,15 @@ BOOL WINAPI UnregisterTouchWindow( HWND hwnd ) return TRUE; } +/***************************************************************************** + * InitializeTouchInjection (USER32.@) + */ +BOOL WINAPI InitializeTouchInjection( UINT32 max_count, DWORD dw_mode ) +{ + FIXME( "max_count %u, dw_mode %#lx stub!\n", max_count, dw_mode ); + return TRUE; +} + /***************************************************************************** * GetGestureInfo (USER32.@) */ diff --git a/dlls/user32/user32.spec b/dlls/user32/user32.spec index b8939646668..12cc31b3e34 100644 --- a/dlls/user32/user32.spec +++ b/dlls/user32/user32.spec @@ -749,7 +749,7 @@ # @ stub InitializeLpkHooks # @ stub InitializePointerDeviceInjection # @ stub InitializePointerDeviceInjectionEx -# @ stub InitializeTouchInjection +@ stdcall InitializeTouchInjection(long long) # @ stub InjectDeviceInput # @ stub InjectGenericHidInput # @ stub InjectKeyboardInput -- 2.54.0

April 28, 2026

Fwd: Potential Clean Room issues with xinputaup

by Yusuf

Hi All! For the xinputuap bits I remember that I may(?) have examined the Debug Symbols for it, reading the Clean Room guidelines it seems to be against the conditions here. I don't plan to contribute to the wine projects(nowadays I have moral objections to it) yet if you wish ban me from your project. Yusuf

April 27, 2026

Re: USB Printing (for vinyl cutter) support & AI Assisted Code Contributions Policy

by kyle＠cascade.family

I see that the Clean Room Policy https://gitlab.winehq.org/wine/wine/-/wikis/Clean-Room-Guidelines/history has been updated to include a note about LLM code. Thanks for confirming!

April 27, 2026

Re: questions/patch proposal for x11 hwcursor rendering artifacts | winex11.drv/mouse.c

by winehq＠jaceee.com

Yeah unfortunately it's proprietary game w/ wine dpi set to 96, so it's just some internal shenanigans that the devs are doing likely. Granted it would be helpful to have some version of a toggle that would allow to work around this cursor weirdness in x11/xorg/xlibre. Drawing a 384x384 floating buffer shouldn't be of an issue from a conceptual standpoint, alas. I created a thread on xlibre as well, but it might take a while for the devs to reply.

April 24, 2026

Re: questions/patch proposal for x11 hwcursor rendering artifacts | winex11.drv/mouse.c

by Stefan Dösinger

> Am 21.04.2026 um 07:34 schrieb meow via Wine-Devel <wine-devel(a)list.winehq.org>: > > And so there is one game on steam that creates a cursor of 384x384 in 1440p and that ends up blowing up and turning into a visual mess. Of course, that cursor is not 384x384, it just creates a buffer of 384x384 because the game for some reason does like 4x internal scaling or something (96dpi x 4 I assume). Did you check what Windows does in this case? As you say, cropping the cursor gives identical results to what you see on Windows, so maybe it is actually the right thing to do. It is also possible that Windows returns an error and the application responds to that by creating a smaller image. The third option is that some information returned to the application is incorrect, causing the application to behave in an unintended way. If it is an old program, it is likely that it queries the DPI, but doesn't treat the result correctly and breaks if dpi != 96. In this case you might be able to reproduce a similar issue on Windows when you disable OS-Side scaling (i.e. set compatibility option scaling performed by application)

April 21, 2026

Re: questions/patch proposal for x11 hwcursor rendering artifacts | winex11.drv/mouse.c

by winehq＠jaceee.com

Syntax error in diff. appologies: ``` diff --git a/dlls/winex11.drv/mouse.c b/dlls/winex11.drv/mouse.c index e1a5e70a6fe..9eaa2c3555e 100644 --- a/dlls/winex11.drv/mouse.c +++ b/dlls/winex11.drv/mouse.c @@ -673,7 +673,8 @@ static void send_mouse_input( HWND hwnd, Window window, unsigned int state, INPU static XcursorImage *create_xcursor_frame( HDC hdc, const ICONINFOEXW *iinfo, HANDLE icon, HBITMAP hbmColor, unsigned char *color_bits, int color_size, HBITMAP hbmMask, unsigned char *mask_bits, int mask_size, - int width, int height, int istep ) + int width, int height, int istep, + int x_width, int x_height) { XcursorImage *image, *ret = NULL; DWORD delay_jiffies, num_steps; @@ -681,15 +682,29 @@ static XcursorImage *create_xcursor_frame( HDC hdc, const ICONINFOEXW *iinfo, HA BOOL has_alpha = FALSE; XcursorPixel *ptr; - image = pXcursorImageCreate( width, height ); + image = pXcursorImageCreate( x_width, x_height ); if (!image) { ERR("X11 failed to produce a cursor frame!\n"); return NULL; } - image->xhot = iinfo->xHotspot; - image->yhot = iinfo->yHotspot; + if (!x_width || !x_height || !width || !height) + { + return NULL; + } + + if(iinfo->xHotspot > x_width) { + image->xhot = (XcursorDim)x_width - 1; + } else { + image->xhot = iinfo->xHotspot; + } + + if(iinfo->yHotspot > x_height) { + image->yhot = (XcursorDim)x_height - 1; + } else { + image->yhot = iinfo->yHotspot; + } image->delay = 100; /* fallback delay, 100 ms */ if (NtUserGetCursorFrameInfo(icon, istep, &delay_jiffies, &num_steps) != 0) @@ -705,10 +720,18 @@ static XcursorImage *create_xcursor_frame( HDC hdc, const ICONINFOEXW *iinfo, HA TRACE("Could not draw frame %d (walk past end of frames).\n", istep); goto cleanup; } - memcpy( image->pixels, color_bits, color_size ); + + if (x_width >= width && x_height >= height) { + memcpy( image->pixels, color_bits, color_size ); + } else { + for (y = 0; y < x_height; y++) + memcpy( image->pixels + y * x_width, + (XcursorPixel *)color_bits + y * width, + x_width * sizeof(XcursorPixel) ); + } /* check if the cursor frame was drawn with an alpha channel */ - for (i = 0, ptr = image->pixels; i < width * height; i++, ptr++) + for (i = 0, ptr = image->pixels; i < x_width * x_height; i++, ptr++) if ((has_alpha = (*ptr & 0xff000000) != 0)) break; /* if no alpha channel was drawn then generate it from the mask */ @@ -725,8 +748,8 @@ static XcursorImage *create_xcursor_frame( HDC hdc, const ICONINFOEXW *iinfo, HA goto cleanup; } /* use the buffer to directly modify the XcursorImage alpha channel */ - for (y = 0, ptr = image->pixels; y < height; y++) - for (x = 0; x < width; x++, ptr++) + for (y = 0, ptr = image->pixels; y < x_height; y++) + for (x = 0; x < x_width; x++, ptr++) if (!((mask_bits[y * width_bytes + x / 8] << (x % 8)) & 0x80)) *ptr |= 0xff000000; } @@ -752,6 +775,27 @@ static Cursor create_xcursor_cursor( HDC hdc, const ICONINFOEXW *iinfo, HANDLE i XcursorImages *images; XcursorImage **imgs; Cursor cursor = 0; + unsigned int x_width = 0; + unsigned int x_height = 0; + int w_width = width; + int w_height = height; + + /* Clamp requested cursor frame dimensions to max best dimensions + * available by x to avoid hwcursor overflows (or forced sw cursor switch) + * with oversized cursors on draw */ + if (scale_cursor_to_best_size ^ clamp_cursor_to_best_size) { + XQueryBestCursor( gdi_display, DefaultRootWindow( gdi_display ), + w_width, w_height, &x_width, &x_height ); + + /* Aggressively reassign cursor dimensions to max available */ + if(scale_cursor_to_best_size) { + if (width > (int)x_width) w_width = (int)x_width; + if (height > (int)x_height) w_height = (int)x_height; + } + } else { + x_width = w_width; + x_height = w_height; + } /* Retrieve the number of frames to render */ if (!NtUserGetCursorFrameInfo(icon, 0, &delay_jiffies, &nFrames)) return 0; @@ -760,8 +804,8 @@ static Cursor create_xcursor_cursor( HDC hdc, const ICONINFOEXW *iinfo, HANDLE i /* Allocate all of the resources necessary to obtain a cursor frame */ if (!(info = malloc( FIELD_OFFSET( BITMAPINFO, bmiColors[256] )))) goto cleanup; info->bmiHeader.biSize = sizeof(BITMAPINFOHEADER); - info->bmiHeader.biWidth = width; - info->bmiHeader.biHeight = -height; + info->bmiHeader.biWidth = w_width; + info->bmiHeader.biHeight = -w_height; info->bmiHeader.biPlanes = 1; info->bmiHeader.biCompression = BI_RGB; info->bmiHeader.biXPelsPerMeter = 0; @@ -769,7 +813,7 @@ static Cursor create_xcursor_cursor( HDC hdc, const ICONINFOEXW *iinfo, HANDLE i info->bmiHeader.biClrUsed = 0; info->bmiHeader.biClrImportant = 0; info->bmiHeader.biBitCount = 32; - color_size = width * height * 4; + color_size = w_width * w_height * 4; info->bmiHeader.biSizeImage = color_size; hbmColor = NtGdiCreateDIBSection( hdc, NULL, 0, info, DIB_RGB_COLORS, 0, 0, 0, (void **)&color_bits ); if (!hbmColor) @@ -787,7 +831,7 @@ static Cursor create_xcursor_cursor( HDC hdc, const ICONINFOEXW *iinfo, HANDLE i info->bmiColors[1].rgbBlue = 0xff; info->bmiColors[1].rgbReserved = 0; - mask_size = ((width + 31) / 32 * 4) * height; /* width_bytes * height */ + mask_size = ((width + 31) / 32 * 4) * w_height; /* width_bytes * height */ info->bmiHeader.biSizeImage = mask_size; hbmMask = NtGdiCreateDIBSection( hdc, NULL, 0, info, DIB_RGB_COLORS, 0, 0, 0, (void **)&mask_bits ); if (!hbmMask) @@ -802,7 +846,7 @@ static Cursor create_xcursor_cursor( HDC hdc, const ICONINFOEXW *iinfo, HANDLE i imgs[i] = create_xcursor_frame( hdc, iinfo, icon, hbmColor, color_bits, color_size, hbmMask, mask_bits, mask_size, - width, height, i ); + w_width, w_height, i, (int)x_width, (int)x_height ); if (!imgs[i]) goto cleanup; } diff --git a/dlls/winex11.drv/x11drv.h b/dlls/winex11.drv/x11drv.h index 9436f35e1ca..cdcdf95f5c0 100644 --- a/dlls/winex11.drv/x11drv.h +++ b/dlls/winex11.drv/x11drv.h @@ -478,6 +478,8 @@ extern BOOL usexcomposite; extern BOOL use_xfixes; extern BOOL managed_mode; extern BOOL private_color_map; +extern BOOL clamp_cursor_to_best_size; +extern BOOL scale_cursor_to_best_size; extern int primary_monitor; extern int copy_default_colors; extern int alloc_system_colors; diff --git a/dlls/winex11.drv/x11drv_main.c b/dlls/winex11.drv/x11drv_main.c index 81008f45c33..0b1c87fef91 100644 --- a/dlls/winex11.drv/x11drv_main.c +++ b/dlls/winex11.drv/x11drv_main.c @@ -81,6 +81,8 @@ int primary_monitor = 0; BOOL client_side_graphics = TRUE; BOOL client_side_with_render = TRUE; BOOL shape_layered_windows = TRUE; +BOOL clamp_cursor_to_best_size = FALSE; +BOOL scale_cursor_to_best_size = FALSE; int copy_default_colors = 128; int alloc_system_colors = 256; int xrender_error_base = 0; @@ -514,6 +516,12 @@ static void setup_options(void) if (!get_config_key( hkey, appkey, "AllocSystemColors", buffer, sizeof(buffer) )) alloc_system_colors = wcstol( buffer, NULL, 0 ); + if (!get_config_key( hkey, appkey, "ClampCursorToBestSize", buffer, sizeof(buffer) )) + clamp_cursor_to_best_size = IS_OPTION_TRUE( buffer[0] ); + + if (!get_config_key( hkey, appkey, "ScaleCursorToBestSize", buffer, sizeof(buffer) )) + scale_cursor_to_best_size = IS_OPTION_TRUE( buffer[0] ); + get_config_key( hkey, appkey, "InputStyle", input_style, sizeof(input_style) ); NtClose( appkey ); ```

April 21, 2026