The code is here https://source.winehq.org/source/dlls/ntdll/sync.c#0474 and it uses compare exchange operations throughout, so it should be unaffected.

The ReactOS implementation is more involved https://doxygen.reactos.org/d1/db8/srw_8c_source.html but still, it uses mostly CAS operations both for the shared and the exclusive case. So it should be largely free from issues.

The WINE team has expressed frustrations in the past about implementing the Windows APIs to spec... Only to find out Microsoft didn't

How did you patch the kernel? Like how is that possible?

With a hex editor, debugger, and skills that most developers these days seem to lack.

I patched the kernel in memory first, using a kernel debugger, to verify my fix worked before editing the file on disk.

Aren't kernel modules signed?

not in xp, iirc, vista was the first release requiring it

Windbg or SoftICE? :)

Windbg; it's free and doesn't require any setup to do this: https://learn.microsoft.com/en-us/windows-hardware/drivers/d...

(Working out how to patch such that I wouldn't crash the system if a process happens to call that API while it was in a half-modified state was also a fun problem...)

I dug out the details on the bug I patched, and it isn't the same as this one; it's a race condition with timeouts on waiting for keyed events, which I believe isn't applicable in this situation as there are no timeouts.

Here's an example showing how to patch a userspace binary:

http://www.malsmith.net/blog/patching-closed-software/

Note: not my blog. (Edit: removed a probably unnecessary, and likely inaccurate, detail).

Patching the kernel would involve a similar (but slightly more complicated) process.

Windows xp and server 2003 sources (though incomplete AFAIR) were leaked back in 2020.