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

[PATCH] winewayland: Use xdg_popup for Win32 popup menus.

by Wehrwolfmann

On Wayland, popup menus (WS_POPUP windows with class #32768) don't close when clicking outside because the compositor only delivers pointer events to the focused surface. X11 solves this with XGrabPointer, but Wayland requires xdg_popup with an explicit grab. Add WAYLAND_SURFACE_ROLE_POPUP that creates an xdg_popup surface with xdg_popup_grab for windows matching the POPUPMENU_CLASS_ATOM (#32768). The compositor sends popup_done when the user clicks outside, which we translate to WM_CANCELMODE to dismiss the menu. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply(a)anthropic.com> --- dlls/winewayland.drv/wayland_surface.c | 114 +++++++++++++++++++++++++ dlls/winewayland.drv/waylanddrv.h | 9 ++ dlls/winewayland.drv/window.c | 35 +++++++- 3 files changed, 157 insertions(+), 1 deletion(-) diff --git a/dlls/winewayland.drv/wayland_surface.c b/dlls/winewayland.drv/wayland_surface.c index 2f8275d..752760d 100644 --- a/dlls/winewayland.drv/wayland_surface.c +++ b/dlls/winewayland.drv/wayland_surface.c @@ -327,6 +327,103 @@ err: ERR("Failed to assign subsurface role to wayland surface\n"); } +/********************************************************************** + * xdg_popup listeners + */ +static void xdg_popup_handle_configure(void *data, struct xdg_popup *xdg_popup, + int32_t x, int32_t y, + int32_t width, int32_t height) +{ + TRACE("hwnd=%p pos=%d,%d size=%dx%d\n", data, x, y, width, height); +} + +static void xdg_popup_handle_done(void *data, struct xdg_popup *xdg_popup) +{ + HWND hwnd = data; + TRACE("hwnd=%p popup_done\n", hwnd); + NtUserPostMessage(hwnd, WM_CANCELMODE, 0, 0); +} + +static void xdg_popup_handle_repositioned(void *data, + struct xdg_popup *xdg_popup, + uint32_t token) +{ +} + +static const struct xdg_popup_listener xdg_popup_listener = +{ + xdg_popup_handle_configure, + xdg_popup_handle_done, + xdg_popup_handle_repositioned, +}; + +/********************************************************************** + * wayland_surface_make_popup + * + * Gives the popup role to a plain wayland surface. The popup is + * positioned relative to the parent surface and can use an explicit + * grab so that the compositor dismisses it on outside clicks. + */ +void wayland_surface_make_popup(struct wayland_surface *surface, + struct wayland_surface *parent, + int x, int y, int width, int height) +{ + struct xdg_positioner *positioner; + + TRACE("surface=%p parent=%p pos=%d,%d size=%dx%d\n", + surface, parent, x, y, width, height); + + assert(!surface->role || surface->role == WAYLAND_SURFACE_ROLE_POPUP); + if (surface->xdg_popup) return; + + wayland_surface_clear_role(surface); + surface->role = WAYLAND_SURFACE_ROLE_POPUP; + + /* Create xdg_surface for the popup */ + surface->popup_xdg_surface = + xdg_wm_base_get_xdg_surface(process_wayland.xdg_wm_base, + surface->wl_surface); + if (!surface->popup_xdg_surface) goto err; + xdg_surface_add_listener(surface->popup_xdg_surface, + &xdg_surface_listener, surface->hwnd); + + /* Create positioner to place popup relative to parent */ + positioner = xdg_wm_base_create_positioner(process_wayland.xdg_wm_base); + if (!positioner) goto err; + + xdg_positioner_set_size(positioner, width > 0 ? width : 1, + height > 0 ? height : 1); + xdg_positioner_set_anchor_rect(positioner, x, y, 1, 1); + xdg_positioner_set_anchor(positioner, XDG_POSITIONER_ANCHOR_TOP_LEFT); + xdg_positioner_set_gravity(positioner, XDG_POSITIONER_GRAVITY_BOTTOM_RIGHT); + + /* Create popup */ + surface->xdg_popup = + xdg_surface_get_popup(surface->popup_xdg_surface, + parent->xdg_surface, positioner); + xdg_positioner_destroy(positioner); + if (!surface->xdg_popup) goto err; + + xdg_popup_add_listener(surface->xdg_popup, &xdg_popup_listener, + surface->hwnd); + + /* Grab the popup so compositor sends popup_done on outside click. */ + { + uint32_t serial = InterlockedCompareExchange(&process_wayland.input_serial, 0, 0); + if (serial) + xdg_popup_grab(surface->xdg_popup, process_wayland.seat.wl_seat, serial); + } + + wl_surface_commit(surface->wl_surface); + wl_display_flush(process_wayland.wl_display); + + return; + +err: + wayland_surface_clear_role(surface); + ERR("Failed to assign popup role to wayland surface\n"); +} + /********************************************************************** * wayland_surface_clear_role * @@ -375,6 +472,20 @@ void wayland_surface_clear_role(struct wayland_surface *surface) surface->toplevel_hwnd = 0; break; + + case WAYLAND_SURFACE_ROLE_POPUP: + if (surface->xdg_popup) + { + xdg_popup_destroy(surface->xdg_popup); + surface->xdg_popup = NULL; + } + + if (surface->popup_xdg_surface) + { + xdg_surface_destroy(surface->popup_xdg_surface); + surface->popup_xdg_surface = NULL; + } + break; } memset(&surface->pending, 0, sizeof(surface->pending)); @@ -733,6 +844,9 @@ BOOL wayland_surface_reconfigure(struct wayland_surface *surface) if (!surface->wl_subsurface) break; /* surface role has been cleared */ wayland_surface_reconfigure_subsurface(surface); break; + case WAYLAND_SURFACE_ROLE_POPUP: + if (!surface->xdg_popup) break; /* surface role has been cleared */ + break; } wayland_surface_reconfigure_size(surface, width, height); diff --git a/dlls/winewayland.drv/waylanddrv.h b/dlls/winewayland.drv/waylanddrv.h index 3b0c300..911b43c 100644 --- a/dlls/winewayland.drv/waylanddrv.h +++ b/dlls/winewayland.drv/waylanddrv.h @@ -82,6 +82,7 @@ enum wayland_surface_role WAYLAND_SURFACE_ROLE_NONE, WAYLAND_SURFACE_ROLE_TOPLEVEL, WAYLAND_SURFACE_ROLE_SUBSURFACE, + WAYLAND_SURFACE_ROLE_POPUP, }; struct wayland_keyboard @@ -282,6 +283,11 @@ struct wayland_surface struct wl_subsurface *wl_subsurface; HWND toplevel_hwnd; }; + struct + { + struct xdg_surface *popup_xdg_surface; + struct xdg_popup *xdg_popup; + }; }; struct wayland_surface_config pending, requested, processing, current; @@ -314,6 +320,9 @@ void wayland_surface_destroy(struct wayland_surface *surface); void wayland_surface_make_toplevel(struct wayland_surface *surface); void wayland_surface_make_subsurface(struct wayland_surface *surface, struct wayland_surface *parent); +void wayland_surface_make_popup(struct wayland_surface *surface, + struct wayland_surface *parent, + int x, int y, int width, int height); void wayland_surface_clear_role(struct wayland_surface *surface); void wayland_surface_attach_shm(struct wayland_surface *surface, struct wayland_shm_buffer *shm_buffer, diff --git a/dlls/winewayland.drv/window.c b/dlls/winewayland.drv/window.c index 2c3d1f8..c1ab090 100644 --- a/dlls/winewayland.drv/window.c +++ b/dlls/winewayland.drv/window.c @@ -192,16 +192,20 @@ static BOOL wayland_win_data_create_wayland_surface(struct wayland_win_data *dat struct wayland_surface *surface; enum wayland_surface_role role; BOOL visible; + DWORD style = NtUserGetWindowLongW(data->hwnd, GWL_STYLE); DWORD exstyle = NtUserGetWindowLongW(data->hwnd, GWL_EXSTYLE); struct wl_region *input_region; TRACE("hwnd=%p\n", data->hwnd); - visible = ((NtUserGetWindowLongW(data->hwnd, GWL_STYLE) & WS_VISIBLE) == WS_VISIBLE) && + visible = ((style & WS_VISIBLE) == WS_VISIBLE) && (!(exstyle & WS_EX_LAYERED) || data->layered_attribs_set); if (!visible) role = WAYLAND_SURFACE_ROLE_NONE; else if (toplevel_surface) role = WAYLAND_SURFACE_ROLE_SUBSURFACE; + else if ((style & WS_POPUP) && NtUserGetWindowRelative(data->hwnd, GW_OWNER) && + NtUserGetClassWord(data->hwnd, GCW_ATOM) == 32768) + role = WAYLAND_SURFACE_ROLE_POPUP; else role = WAYLAND_SURFACE_ROLE_TOPLEVEL; /* we can temporarily clear the role of a surface but cannot assign a different one after it's set */ @@ -236,6 +240,30 @@ static BOOL wayland_win_data_create_wayland_surface(struct wayland_win_data *dat case WAYLAND_SURFACE_ROLE_SUBSURFACE: wayland_surface_make_subsurface(surface, toplevel_surface); break; + case WAYLAND_SURFACE_ROLE_POPUP: + { + HWND owner = NtUserGetWindowRelative(data->hwnd, GW_OWNER); + struct wayland_win_data *owner_data = owner ? wayland_win_data_get(owner) : NULL; + if (owner_data && owner_data->wayland_surface) + { + RECT rect, owner_rect; + NtUserGetWindowRect(data->hwnd, &rect, 0); + NtUserGetWindowRect(owner, &owner_rect, 0); + wayland_surface_make_popup(surface, owner_data->wayland_surface, + rect.left - owner_rect.left, + rect.top - owner_rect.top, + rect.right - rect.left, + rect.bottom - rect.top); + wayland_win_data_release(owner_data); + } + else + { + if (owner_data) wayland_win_data_release(owner_data); + /* Fallback to toplevel if owner has no surface */ + wayland_surface_make_toplevel(surface); + } + break; + } } if (visible && client) wayland_client_surface_attach(client, data->hwnd); @@ -313,6 +341,11 @@ static void wayland_win_data_update_wayland_state(struct wayland_win_data *data) surface->processing.serial = 1; surface->processing.processed = TRUE; break; + case WAYLAND_SURFACE_ROLE_POPUP: + TRACE("hwnd=%p popup\n", surface->hwnd); + surface->processing.serial = 1; + surface->processing.processed = TRUE; + break; } wl_display_flush(process_wayland.wl_display); -- 2.53.0

April 10, 2026

[PATCH] gdi32: Implement GdiEntry13 as Direct3DCreate9 wrapper.

by Wehrwolfmann

On Windows, GdiEntry13 is used by WPF (wpfgfx_v0400.dll) to obtain an IDirect3D9 object via GetProcAddress(gdi32, "GdiEntry13"). WPF expects the return value to be an IDirect3D9 pointer, equivalent to calling Direct3DCreate9(D3D_SDK_VERSION). The previous implementation mapped GdiEntry13 to a stub of DdQueryDisplaySettingsUniqueness that always returned 0, causing WPF to fail to initialize its rendering pipeline and resulting in black or missing windows for all WPF applications running under Wine. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59634 --- dlls/gdi32/dc.c | 36 ++++++++++++++++++++++++++++++++---- include/ddrawgdi.h | 2 +- 2 files changed, 33 insertions(+), 5 deletions(-) diff --git a/dlls/gdi32/dc.c b/dlls/gdi32/dc.c index adfcd51..4b453dd 100644 --- a/dlls/gdi32/dc.c +++ b/dlls/gdi32/dc.c @@ -2709,15 +2709,43 @@ INT WINAPI NamedEscape( HDC hdc, const WCHAR *driver, INT escape, INT input_size return 0; } +typedef void * (WINAPI *Direct3DCreate9_func)(UINT); +static Direct3DCreate9_func pDirect3DCreate9; + +static BOOL WINAPI init_d3d9( INIT_ONCE *once, void *param, void **context ) +{ + HMODULE d3d9_module = LoadLibraryW( L"d3d9.dll" ); + if (d3d9_module) + pDirect3DCreate9 = (Direct3DCreate9_func)GetProcAddress( d3d9_module, "Direct3DCreate9" ); + if (!pDirect3DCreate9) + WARN( "Failed to load d3d9.dll or find Direct3DCreate9\n" ); + return TRUE; +} + /******************************************************************* * DdQueryDisplaySettingsUniqueness (GDI32.@) * GdiEntry13 + * + * On Windows, GdiEntry13 is used by WPF (wpfgfx_v0400.dll) to obtain + * an IDirect3D9 object. WPF calls GetProcAddress(gdi32, "GdiEntry13") + * and expects the return value to be an IDirect3D9 pointer, equivalent + * to calling Direct3DCreate9(D3D_SDK_VERSION). + * + * The original DdQueryDisplaySettingsUniqueness stub returned 0 (NULL), + * causing WPF to fail to initialize its rendering pipeline. */ -ULONG WINAPI DdQueryDisplaySettingsUniqueness(void) +void * WINAPI DdQueryDisplaySettingsUniqueness(void) { - static int warn_once; - if (!warn_once++) FIXME( "stub\n" ); - return 0; + static INIT_ONCE init_once = INIT_ONCE_STATIC_INIT; + + TRACE( "\n" ); + + InitOnceExecuteOnce( &init_once, init_d3d9, NULL, NULL ); + + if (pDirect3DCreate9) + return pDirect3DCreate9( 32 /* D3D_SDK_VERSION */ ); + + return NULL; } /******************************************************************* diff --git a/include/ddrawgdi.h b/include/ddrawgdi.h index 4b78702..c0893b9 100644 --- a/include/ddrawgdi.h +++ b/include/ddrawgdi.h @@ -27,7 +27,7 @@ extern "C" { #define DdQueryDisplaySettingsUniqueness GdiEntry13 -ULONG APIENTRY DdQueryDisplaySettingsUniqueness(void); +void * APIENTRY DdQueryDisplaySettingsUniqueness(void); #ifdef __cplusplus } -- 2.53.0

April 10, 2026

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

by Kyle Cascade

I have a branch of wine that adds support for talking to my USB vinyl cutter, allowing me to run its Silhouette Studio software AND send it to the USB device. Winedb: https://appdb.winehq.org/objectManager.php?sClass=application&iId=16375 Branch: https://gitlab.winehq.org/kyle1/wine/-/compare/master...mr2-usb-driver-stac… Incredibly, it works! It took a lot of code to actually make it happen, but so incredible that I can actually use this device without Windows now. I'm super happy. But, before I try to work towards submitting it, I should disclose that I used Claude Code extensively to build it. I couldn't find any docs on the wiki or FAQ about AI-generated patches. Given the clean room policy, is there an official stance on this? I haven't read any Windows source code, but I can't prove that the model wasn't trained on it. Kyle

April 9, 2026

Re: Possible NtLockFile / NtUnlockFile FIXME Patches for Wine

by Alexandre Julliard

"Ty via Wine-Devel" <wine-devel(a)list.winehq.org> writes: > I wonder if the tests would be allowed into wine - wine has a strict cleanroom policy > (https://gitlab.winehq.org/wine/wine/-/wikis/Clean-Room-Guidelines) which is to ensure its safety and longevity. > Previously, Y. Osipov (mcm(a)etersoft.ru) had brought this up, though I did not see any replies on the mailing list on the subject. > > In my mind, LLM's pull from all sorts of corners of the internet, without telling the user what was sourced from where. I would imagine (as NOT > a lawyer) this has implications for licensing and plagiarism that we have yet to see play out in courts, as well as potentially running afoul the > cleanroom policy (ie, see point 3 on the 'Donts' section about code that is available but not compatible, or possibly even leaked source). Given > that a user has little to no control over source material and/or training data, I would personally assume this to mean it violates cleanroom by > being unable to prove/control this - but I can also see some arguments going the other way depending on the apforforproach used. > > I bring this up because I think we probably should figure out exactly what the policy on LLM use is/is going to be, and write it out clearly. What > constitutes a cleanroom approach for one person may not be the same as another person's interpretation. Clean room is not even the main issue. In order to ship any code, we need a proper authorship record, and an LGPL-compatible license. The legal copyright/licensing status of LLM output is currently not well defined, so we can't accept such code. -- Alexandre Julliard julliard(a)winehq.org

April 9, 2026

Tbs.h impletention planning

by 中川祥

How is Wine going to implement tbs.h and TPM 2.0 libraries?( such as ncrypt) Retrieving true linux information or faked Windows info?

April 9, 2026

Re: Possible NtLockFile / NtUnlockFile FIXME Patches for Wine

by Ty

I wonder if the tests would be allowed into wine - wine has a strict cleanroom policy ( https://gitlab.winehq.org/wine/wine/-/wikis/Clean-Room-Guidelines) which is to ensure its safety and longevity. Previously, Y. Osipov (mcm(a)etersoft.ru) had brought this up, though I did not see any replies on the mailing list on the subject. In my mind, LLM's pull from all sorts of corners of the internet, without telling the user what was sourced from where. I would imagine (as NOT a lawyer) this has implications for licensing and plagiarism that we have yet to see play out in courts, as well as potentially running afoul the cleanroom policy (ie, see point 3 on the 'Donts' section about code that is available but not compatible, or possibly even leaked source). Given that a user has little to no control over source material and/or training data, I would personally assume this to mean it violates cleanroom by being unable to prove/control this - but I can also see some arguments going the other way depending on the apforforproach used. I bring this up because I think we probably should figure out exactly what the policy on LLM use is/is going to be, and write it out clearly. What constitutes a cleanroom approach for one person may not be the same as another person's interpretation. On Wed, Apr 8, 2026 at 10:20 PM tim--- via Wine-Devel < wine-devel(a)list.winehq.org> wrote: > Oh man, yeah it is. :) I'd likely never have tried to fix a FIXME in a > beast of a project like Wine without these newer models/CLI-based tools. > Totally wild. And Claude Code/Codex have been working fantastic in SRE/Ops > contexts as well. > > The actual fixing patches don't seem to have many LOC changing. It's > mostly the tests I worked through defining/generating that theoretically > prove it works which take up the most of that repo. > > The patches for the flocking fixes are at: > > > https://github.com/livingstaccato/space-wine/blob/main/patches/comctl32-fix… > > https://github.com/livingstaccato/space-wine/blob/main/patches/kernelbase-f… > > https://github.com/livingstaccato/space-wine/blob/main/patches/kernelbase-f… > > https://github.com/livingstaccato/space-wine/blob/main/patches/ntdll-fix-Nt… > > https://github.com/livingstaccato/space-wine/blob/main/patches/user32-fix-e… > > https://github.com/livingstaccato/space-wine/blob/main/patches/wineserver-f… > > https://github.com/livingstaccato/space-wine/blob/main/patches/win32u-fix-O… > > And I also had it fix a font fixme: > > https://github.com/livingstaccato/space-wine/blob/main/patches/win32u-fix-O… > > Then had it go overboard making tests: > > https://github.com/livingstaccato/space-wine/blob/main/patches/kernel32-tes… > https://github.com/livingstaccato/space-wine/tree/main/tests > > Hopefully the actual patches are high enough quality that it's helpful. Or > maybe the testing tools would be a handy addition to the Wine toolchain. > > --Tim >

April 9, 2026

Re: Possible NtLockFile / NtUnlockFile FIXME Patches for Wine

by May

Hey Tim, Another developer here, I mostly lurk on the mailing list. I'm certainly curious if WineHQ has any formal precedent on this but I'm going to offer my two cents here. Firstly, WineHQ has placed strong emphasis on following clean-room guidelines https://gitlab.winehq.org/wine/wine/-/wikis/Clean-Room-Guidelines, meaning that code pulled into Wine must be legally trustworthy regarding its separation. Given the immense amount of training data present in Claude Code, ChatGPT, and really all usable LLMs on the market, I would find it legally risky to trust how that code was sourced and generated. There's a quote on that clean room page that seems apt here, *> "For what it's worth, the policy I've personally been using has been to simply avoid unnecessary risk.", * Henri Verbeet. Additionally this question has been asked previously, with no answer: https://list.winehq.org/hyperkitty/list/wine-devel@list.winehq.org/message/… Secondly, from a noise and effectiveness perspective, AI generated code carries risks. I personally appreciate your honesty about not fully understanding regarding the how's and the why's of what your code is doing, I wish more developers were honest about that in general. However, what you're functionally asking is for someone to spend their time working on a patch that the core contributor cannot reliably maintain, refactor, or truly own the underlying logic. Open source is largely built on the establishment of trust and a lot of commitment of time from those who frankly don't have much of it; it's often rather thankless work and every line of code has to be owned by someone. I think it's awesome whenenver anyone wants to work in a territory they don't understand, learning should always be celebrated (we're in an industry where so many derive joy out of belittling others and making them feel stupid or inferior, it's really frustrating!). but at the same time, I would only contribute things I understood, could explain, and am providing in good-faith (which in regards to good-faith I believe you have, hence these many words), we owe that much to the communities from which we gain so much and to which we want to give back. All that being said, perhaps the Wine team could correct me, or maybe this will just wind up being more noise on an email thread I was pretty sure I unsubscribed from multiple times, I dunno. But I figured I'd air my thoughts, May. On Wed, Apr 8, 2026 at 9:18 PM tim--- via Wine-Devel < wine-devel(a)list.winehq.org> wrote: > Oh man, yeah it is. :) I'd likely never have tried to fix a FIXME in a > beast of a project like Wine without these newer models/CLI-based tools. > Totally wild. And Claude Code/Codex have been working fantastic in SRE/Ops > contexts as well. > > The actual fixing patches don't seem to have many LOC changing. It's > mostly the tests I worked through defining/generating that theoretically > prove it works which take up the most of that repo. > > The patches for the flocking fixes are at: > > > https://github.com/livingstaccato/space-wine/blob/main/patches/comctl32-fix… > > https://github.com/livingstaccato/space-wine/blob/main/patches/kernelbase-f… > > https://github.com/livingstaccato/space-wine/blob/main/patches/kernelbase-f… > > https://github.com/livingstaccato/space-wine/blob/main/patches/ntdll-fix-Nt… > > https://github.com/livingstaccato/space-wine/blob/main/patches/user32-fix-e… > > https://github.com/livingstaccato/space-wine/blob/main/patches/wineserver-f… > > https://github.com/livingstaccato/space-wine/blob/main/patches/win32u-fix-O… > > And I also had it fix a font fixme: > > https://github.com/livingstaccato/space-wine/blob/main/patches/win32u-fix-O… > > Then had it go overboard making tests: > > https://github.com/livingstaccato/space-wine/blob/main/patches/kernel32-tes… > https://github.com/livingstaccato/space-wine/tree/main/tests > > Hopefully the actual patches are high enough quality that it's helpful. Or > maybe the testing tools would be a handy addition to the Wine toolchain. > > --Tim >

April 9, 2026

Re: Possible NtLockFile / NtUnlockFile FIXME Patches for Wine

by tim＠livingstaccato.com

Oh man, yeah it is. :) I'd likely never have tried to fix a FIXME in a beast of a project like Wine without these newer models/CLI-based tools. Totally wild. And Claude Code/Codex have been working fantastic in SRE/Ops contexts as well. The actual fixing patches don't seem to have many LOC changing. It's mostly the tests I worked through defining/generating that theoretically prove it works which take up the most of that repo. The patches for the flocking fixes are at: https://github.com/livingstaccato/space-wine/blob/main/patches/comctl32-fix… https://github.com/livingstaccato/space-wine/blob/main/patches/kernelbase-f… https://github.com/livingstaccato/space-wine/blob/main/patches/kernelbase-f… https://github.com/livingstaccato/space-wine/blob/main/patches/ntdll-fix-Nt… https://github.com/livingstaccato/space-wine/blob/main/patches/user32-fix-e… https://github.com/livingstaccato/space-wine/blob/main/patches/wineserver-f… https://github.com/livingstaccato/space-wine/blob/main/patches/win32u-fix-O… And I also had it fix a font fixme: https://github.com/livingstaccato/space-wine/blob/main/patches/win32u-fix-O… Then had it go overboard making tests: https://github.com/livingstaccato/space-wine/blob/main/patches/kernel32-tes… https://github.com/livingstaccato/space-wine/tree/main/tests Hopefully the actual patches are high enough quality that it's helpful. Or maybe the testing tools would be a handy addition to the Wine toolchain. --Tim

April 9, 2026

Re: Possible NtLockFile / NtUnlockFile FIXME Patches for Wine

by Dan Kegel

Well, damn! AI is getting scary good. I hope a Wine developer can turn the ideas here into solid commits. - Dan tim--- via Wine-Devel <wine-devel(a)list.winehq.org> schrieb am Mi., 8. Apr. 2026, 13:05: > Hi there! > > My name is Tim Perkins. I'm a 25+ year user, but a first-time contributor > (maybe). > > I've been playing around with the TradeWars Game Server on macOS ( > https://eisonline.classictw.com/) and it kept crashing or acting weird > after a day or so of operation—faster if I was actually stressing the > server. > > I seem to have hit a flocking problem. Once I hit that problem, it just > starts eating up more and more file descriptors until bad things happen. > > I do dev during the day, but I do not know C well. However, I used Claude > Code to come up with some patches that I think aren't too sloppy, nor do > they open the gates of hell or create security vulnerabilities. > > I put all the patches and proof in a repo on GitHub at > https://github.com/livingstaccato/space-wine/tree/main and made a GitHub > action which compiles Wine on multiple platforms and runs some conformance > tests. > > After using a version of Wine with those patches implemented, I've had the > TradeWars server running stable for over a week now. > > I was hoping one of you more experienced subject matter experts could take > a look and let me know if they're viable patches? :) > > Up front, though: if you ask me "Why did you do X?" my response will > probably be, "… let me ask Claude." > > Thanks, and I hope this helps! > > --Tim >

April 8, 2026

Possible NtLockFile / NtUnlockFile FIXME Patches for Wine

by tim＠livingstaccato.com

Hi there! My name is Tim Perkins. I'm a 25+ year user, but a first-time contributor (maybe). I've been playing around with the TradeWars Game Server on macOS (https://eisonline.classictw.com/) and it kept crashing or acting weird after a day or so of operation—faster if I was actually stressing the server. I seem to have hit a flocking problem. Once I hit that problem, it just starts eating up more and more file descriptors until bad things happen. I do dev during the day, but I do not know C well. However, I used Claude Code to come up with some patches that I think aren't too sloppy, nor do they open the gates of hell or create security vulnerabilities. I put all the patches and proof in a repo on GitHub at https://github.com/livingstaccato/space-wine/tree/main and made a GitHub action which compiles Wine on multiple platforms and runs some conformance tests. After using a version of Wine with those patches implemented, I've had the TradeWars server running stable for over a week now. I was hoping one of you more experienced subject matter experts could take a look and let me know if they're viable patches? :) Up front, though: if you ask me "Why did you do X?" my response will probably be, "… let me ask Claude." Thanks, and I hope this helps! --Tim

April 8, 2026