While it's nice to see that this allows the game to boot on Windows 7, the solution is inherently flawed since all it's doing is invalidate the statically linked dependency on the GetOverlappedResultEx call. It otherwise does not change or affect _how_ that call is used in the game itself.
So what we have here is undefined behaviour as GetOverlappedResultEx() and GetOverlappedResult() differs in how many input parameters they accept and what those parameters control and mean. Even _if_ the game's call to GetOverlappedResultEx() would make its way to GetOverlappedResult() (which I am unsure about), the given stack would differ from the expectation.
Yeah, the game launches. But then what happens when these undefined GetOverlappedResultEx-that-isn't calls are made? Even if the game doesn't crash outright when it attempts to make that call, what are the long-term consequences of the invalid behavior? The crash of a thread? Growing unseen memory corruption?
So while it's a flawed workaround, it's not a perfect solution and a better one would have to be implemented as soon as possible.
Since GetOverlappedResultEx() and GetOverlappedResult() are mostly compatible with one another it's probably more than possible for someone with experience of binary modding a game to just change out the existing GetOverlappedResultEx() calls to a GetOverlappedResult() call, drop the last parameter and have the third parameter set to 0/false. That would be a much better fix than trying to mangle a GetOverlappedResultEx() call into a GetOverlappedResult() that were never designed to handle it.