Possible NtLockFile / NtUnlockFile FIXME Patches for Wine

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

[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 <[e-mail]> 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

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-fi...
https://github.com/livingstaccato/space-wine/blob/main/patches/kernelbase-fi...
https://github.com/livingstaccato/space-wine/blob/main/patches/ntdll-fix-NtL...
https://github.com/livingstaccato/space-wine/blob/main/patches/user32-fix-ed...
https://github.com/livingstaccato/space-wine/blob/main/patches/wineserver-fi...
https://github.com/livingstaccato/space-wine/blob/main/patches/win32u-fix-OE...

And I also had it fix a font fixme:
https://github.com/livingstaccato/space-wine/blob/main/patches/win32u-fix-OE...

Then had it go overboard making tests:
https://github.com/livingstaccato/space-wine/blob/main/patches/kernel32-test...
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

[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/[e-mail]/message/G...
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 <
[e-mail]> 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-fi...
>
> https://github.com/livingstaccato/space-wine/blob/main/patches/kernelbase-fi...
>
> https://github.com/livingstaccato/space-wine/blob/main/patches/ntdll-fix-NtL...
>
> https://github.com/livingstaccato/space-wine/blob/main/patches/user32-fix-ed...
>
> https://github.com/livingstaccato/space-wine/blob/main/patches/wineserver-fi...
>
> https://github.com/livingstaccato/space-wine/blob/main/patches/win32u-fix-OE...
>
> And I also had it fix a font fixme:
>
> https://github.com/livingstaccato/space-wine/blob/main/patches/win32u-fix-OE...
>
> Then had it go overboard making tests:
>
> https://github.com/livingstaccato/space-wine/blob/main/patches/kernel32-test...
> 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

[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 ([e-mail]) 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 <
[e-mail]> 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-fi...
>
> https://github.com/livingstaccato/space-wine/blob/main/patches/kernelbase-fi...
>
> https://github.com/livingstaccato/space-wine/blob/main/patches/ntdll-fix-NtL...
>
> https://github.com/livingstaccato/space-wine/blob/main/patches/user32-fix-ed...
>
> https://github.com/livingstaccato/space-wine/blob/main/patches/wineserver-fi...
>
> https://github.com/livingstaccato/space-wine/blob/main/patches/win32u-fix-OE...
>
> And I also had it fix a font fixme:
>
> https://github.com/livingstaccato/space-wine/blob/main/patches/win32u-fix-OE...
>
> Then had it go overboard making tests:
>
> https://github.com/livingstaccato/space-wine/blob/main/patches/kernel32-test...
> 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

[Alexandre Julliard]

"Ty via Wine-Devel" <[e-mail]> 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 ([e-mail]) 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
[e-mail]