rpcrt4: Use standard Wine list to store connections in RpcServerProtseq.

[Jacek Caban]

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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20170516/a0448376/attachment.html>