On 15.05.2017 22:36, Hans Leidekker wrote:
On Mon, 2017-05-15 at 16:39 -0300, Bruno Jesus wrote:

On Mon, May 15, 2017 at 4:27 PM, Jacek Caban <jacek@codeweavers.com> wrote:

...
Sorry about that, I will send a fixed version. However, this rises my
other related concern. What do you think about changing this code to
always use winsock? We'd use single implementation, making the code
cleaner and avoiding breaking other configs. I guess the original
reasoning was combination of performance and less mature winsock
implementation at the time. I don't think winsock overhead would be too
bad in this case and ws2_32 should be up to the task.

I would vote for that, wininet was already changed and we had some
discussion about changing winhttp too [1] but Hans was not amused with
the idea ;-)

Yes, there was a strong argument for moving wininet: apps depending on
winsock initialization. rpcrt4 has two implementations, one based on
Unix sockets and one based on Windows sockets. It may make sense to have
just the Windows version if performance is acceptable.

winhttp also has two implementations, although it's hidden with preprocessor macros, so it's not as bad as in case of rpcrt4. Since we have winsock implementation for mingw builds in winhttp anyway, I don't see a reason to keep Unix socket implementation there. It just adds #ifdefs and all the compatibility code for no good reason.

That said, in my opinion, it would be nice to use winsock in winhttp. I also think it's not very important through.

Maybe this is a good time to discuss again (?). Having a single point
of network input/output will simplify network debugging IMO.
Right, because we just fixed the last winsock bug ;-)

If there is a bug in winsock that winhttp would hit (and winhttp uses rather basic functionality, nothing tricky), I'd much rather have it fixed than worked around ;-)

Jacek