> > the fix should be as simple as coercing the timeout values to >= 0.
>
> Popen._remaining_time() should return max(endtime - _time(), 0).

That was my first initial instinct as well, however, that change would
also affect more of the Popen behavior and need a much more thorough
investigation of the POSIX side of Popen.

> Popen._wait() should raise OverflowError if the timeout is too large for the implementation. In Windows, the upper limit in milliseconds is `_winapi.INFINITE - 1` (about 49.7 days). It's important to only allow the timeout in milliseconds to be _winapi.INFINITE when `timeout is None`.

I agree.

> The DWORD converter in _winapi needs to subclass unsigned_long_converter. The current implementation based on the legacy format unit "k" is too lenient. Negative values and values that are too large should fail.

Whilst I agree this is a correct solution, I fear the potential
3rd-party breakage alone should bump this to its own issue.

I believe that this then leads to the following action items for this issue:
1) modify Windows Popen._wait() to raise on out of bounds values [< 0
or >= INFINITE]
2) cap Popen._remaining_time() return value to >= 0
3) change _winapi DWORD converter be unsigned long
4) use Job objects to group Windows processes for termination

Have I missed anything?  I should be able to knock out PRs for these today.
-- 
Jeremy Kloth