On Tue, Dec 13, 2016 at 7:33 AM, Hans Leidekker hans@codeweavers.com wrote:
Signed-off-by: Hans Leidekker hans@codeweavers.com
dlls/winhttp/net.c | 47 +++++++++++++++++++++++++++++++++-------------- 1 file changed, 33 insertions(+), 14 deletions(-)
Hi, Isn't it better to make winhttp use ws2_32 just like wininet change [1]? Then we would have a single point for all networking code and EINTR is already covered in ws2_32.
[1] http://source.winehq.org/git/wine.git/commitdiff/5436fef80722fe7896aed5e659c...
Best Regards, Bruno
On Tue, 2016-12-13 at 10:55 -0200, Bruno Jesus wrote:
On Tue, Dec 13, 2016 at 7:33 AM, Hans Leidekker hans@codeweavers.com wrote:
Signed-off-by: Hans Leidekker hans@codeweavers.com
dlls/winhttp/net.c | 47 +++++++++++++++++++++++++++++++++-------------- 1 file changed, 33 insertions(+), 14 deletions(-)
Hi, Isn't it better to make winhttp use ws2_32 just like wininet change [1]? Then we would have a single point for all networking code and EINTR is already covered in ws2_32.
[1] http://source.winehq.org/git/wine.git/commitdiff/5436fef80722fe7896aed5e659c...
I have been waiting for a more compelling reason. Moving to ws2_32 is not entirely free (e.g. from a performance or debugging perspective). I believe the wininet switch was motivated by programs that rely on wininet to initialize winsock, but I'm not aware of such problems with winhttp.
On Tuesday, December 13, 2016, Hans Leidekker hans@codeweavers.com wrote:
On Tue, 2016-12-13 at 10:55 -0200, Bruno Jesus wrote:
On Tue, Dec 13, 2016 at 7:33 AM, Hans Leidekker <hans@codeweavers.com
javascript:;> wrote:
Signed-off-by: Hans Leidekker <hans@codeweavers.com javascript:;>
dlls/winhttp/net.c | 47 ++++++++++++++++++++++++++++++
+++--------------
1 file changed, 33 insertions(+), 14 deletions(-)
Hi, Isn't it better to make winhttp use ws2_32 just like wininet change [1]? Then we would have a single point for all networking code and EINTR is already covered in ws2_32.
5436fef80722fe7896aed5e659c31fdade4ef5b3
I have been waiting for a more compelling reason. Moving to ws2_32 is not entirely free (e.g. from a performance or debugging perspective). I believe the wininet switch was motivated by programs that rely on wininet to initialize winsock, but I'm not aware of such problems with winhttp.
I understand, but the code would be much cleaner and I don't recall any bugs complaining about wininet performance. Are you fixing any bug or regression? Otherwise I think this should be discussed further after the freeze.
On Tue, 2016-12-13 at 11:56 -0200, Bruno Jesus wrote:
On Tuesday, December 13, 2016, Hans Leidekker hans@codeweavers.com wrote: On Tue, 2016-12-13 at 10:55 -0200, Bruno Jesus wrote: > On Tue, Dec 13, 2016 at 7:33 AM, Hans Leidekker hans@codeweavers.com wrote: > > Signed-off-by: Hans Leidekker hans@codeweavers.com > > --- > > dlls/winhttp/net.c | 47 +++++++++++++++++++++++++++++++++-------------- > > 1 file changed, 33 insertions(+), 14 deletions(-) > > Hi, Isn't it better to make winhttp use ws2_32 just like wininet > change [1]? Then we would have a single point for all networking code > and EINTR is already covered in ws2_32. > > [1] http://source.winehq.org/git/wine.git/commitdiff/5436fef80722fe7896aed5e659c...
I have been waiting for a more compelling reason. Moving to ws2_32 is not entirely free (e.g. from a performance or debugging perspective). I believe the wininet switch was motivated by programs that rely on wininet to initialize winsock, but I'm not aware of such problems with winhttp.I understand, but the code would be much cleaner and I don't recall any bugs complaining about wininet performance. Are you fixing any bug or regression? Otherwise I think this should be discussed further after the freeze.
It's a fix for the Office 2013 online installer on macOS.
-
Bruno Jesus -
Hans Leidekker