Did you want to create an issue to fix _winapi.WaitForSingleObject() or the DWORD converter in _winapi? I suppose all call sites of _winapi functions that take DWORD parameters will have to be checked.

I was thinking to the DWORD converter change as a separate PR that would not be a candidate for backport. While _winapi contents are considered "private", I know that when I write scripts only for use on Windows, I'll reach for that module for functions before considering using ctypes. All the needed "wrapping stuff" (exceptions for errors, reference counting, etc) is handled for me.

The change of negative values to exceptions, while probably not relied upon, would be a breaking change for a dot release. Being limited to a new release (3.11) would be easier to reason about downstream rather than a "random" bugfix release (say, 3.9.12). IMO.

Please add tests and a NEWS entry.

How difficult is to write tests?

Tests can spawn a child process that exits after a few seconds. With this PR, a timeout that's larger than 4294967.295 should raise OverflowError. For example, the current implementation mistakenly wraps 4294968 around to 0.704, leading to TimeoutExpired. With this PR, a negative timeout should be handled as 0. For example, the current implementation wraps -1 to 4294966.296, and the wait will succeed when the child exits, instead of raising TimeoutExpired.

The issue has been closed, is there anything left to do here?