Patch for ReadFile with NULL hEvent

[Eric Pouech]

> ...Windows doesn't do it this way, although according to the docs
> other members of the overlapped structure are modified by Windows.
Ok, we need to rewrite GetOverlappedResult to use the internal 
structures (and get the hEvent we might have created in ReadFile), 
instead of relying on the one from the overlapped struct itself

>>I'd rather say it's GetOverlappedResult which is to blame. If the
>>hEvent is NULL, then we shouldn't return any error (as we do) but
>>rather assume all wait operation succeed (if hEven is NULL, ReadFile
>>and WriteFile operations are synchronous, so calling
>>GetOverlappedResult is a no-op).
> 
> 
> This turns out not to be the case.  As long as lpOverlapped is
> supplied, a NULL hEvent will work fine and allows overlapped reads.
Could you also test it with opening a file (files and sockets semantics 
are somehow different)

> Ah, I didn't know that.  If we keep calling CreateEvent over and over
> again with a NULL parameter, will we eventually run out of some
> resource?  If so, it may still be best to construct a name, since
> calling CreateEvent with the same name twice will apparently avoid
> creating another event.
if you run out of resource with calling with a NULL parameter, you'll 
also get out of resource with constructing the name, so you don't need 
to bother here

> The attached test program uses overlapped reads with a NULL hEvent in
> the OVERLAPPED structure to connect to an IP address and port given on
> the command line.  Here's an example from Windows:
> 
>     C:>overlapped-test 216.12.213.139 25
>     Calling ReadFile
>     ReadFile returned ERROR_IO_PENDING, as expected
>     ov      .hEvent=00000000
>     Calling Sleep(2000)
>     Calling GetOverlappedResult
>     GetOverlappedresult read 85 bytes:
>     220 2search2.com ESMTP Sendmail 8.10.2-SOL3/8.10.2; Mon, 17 May 2004  11:58:26 -0400
just for fun, what gives without the Sleep ?
A+