January 2014 - Wine-Devel - list.winehq.org

Re: msvcrt: Add INFINITY and NAN definitions to math.h.

by Francois Gouget

On Fri, 10 Jan 2014, Jacek Caban wrote: [...] > Looking at how it's done in my Linux headers, there is > __builtin_nanf() and __builtin_inff() guarded by GCC >= 3.3 that we > could use. This would work on Linux. But the Solaris headers don't define NAN which is what uncovered this problem in the first place... In other words the msvcrt headers cannot rely on the system headers to define INFINITY and NAN. > How is it defined on MSVC? They define INFINITY by multiplying two very large floats that they know will overflow (which makes assumptions on the maximum exponant and causes a Visual C++ compiler warning). Then they define NAN as INFINITY * 0. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...

Jan. 10, 2014

Re: [website] Make https for wiki

by Jeremy Newman

We cannot apply this patch until the Wiki has a certificate and has been setup with an SSL vhost. -N On 01/10/2014 08:10 AM, Andrey Gusev wrote: > This should fix bug http://bugs.winehq.org/show_bug.cgi?id=34443

Jan. 10, 2014

Re: msvcrt: Add INFINITY and NAN definitions to math.h.

by Jacek Caban

Hi Francois, On 01/10/14 15:29, Francois Gouget wrote: > --- > > The INFINITY and NAN definitions have been added to math.h in recent > versions of msvcrt (i.e. they were not present in Visual C++ 2008 but > are in Visual C++ 2013). This means we have to provide them too > otherwise code that compiles with Visual C++ could fail to compile with > Winelib. > > To do so I'm just reusing the definition we have in wine/port.h. > > This definition bothers me a bit in that it clearly depends on the > in-memory representation of these floating point constants, which might > not be very portable (depending on whether the system uses IEEE 754 or > not, etc). In d3dx9_36 we used to define NAN as '0.0f / 0.0f'. Other > definitions would be variants like 'INFINITY * 0.0f', etc. I can't > really claim that those are really more portable and the compiler may > (and some do) complain about them. Hence why I went with the wine/port.h > definitions in the end. If they're good enough for port.h they should be > good for math.h too. > > > include/msvcrt/math.h | 20 ++++++++++++++++++++ > 1 file changed, 20 insertions(+) > > diff --git a/include/msvcrt/math.h b/include/msvcrt/math.h > index 34aa268..42d6bfe 100644 > --- a/include/msvcrt/math.h > +++ b/include/msvcrt/math.h > @@ -146,6 +146,26 @@ static const union { > # endif > #endif > > +#ifndef INFINITY > +/* From wine/port.h */ > +static inline float __port_infinity(void) > +{ > + static const unsigned __inf_bytes = 0x7f800000; > + return *(const float *)&__inf_bytes; > +} > +#define INFINITY __port_infinity() > +#endif > + > +#ifndef NAN > +/* From wine/port.h */ > +static inline float __port_nan(void) > +{ > + static const unsigned __nan_bytes = 0x7fc00000; > + return *(const float *)&__nan_bytes; > +} > +#define NAN __port_nan() > +#endif > + > #ifdef __cplusplus > } > #endif In wine/port.h, we implement worst-case scenario where math.h doesn't define NAN/INFINITY. In this case, since glibc/system math.h won't be used and our msvcrt math.h will be included instead, we should try to provide better NAN/INFINITY versions when possible. Looking at how it's done in my Linux headers, there is __builtin_nanf() and __builtin_inff() guarded by GCC >= 3.3 that we could use. How is it defined on MSVC? Jacek

Jan. 10, 2014

Re: ws2_32/tests: Add a trailing '\n' to a win_skip() call.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=4157 Your paranoid android. === wxppro (32 bit sock) === sock.c:557: Test failed: oob_server (4bc): unexpectedly at the OOB mark: 0 === w2008s64 (32 bit sock) === sock.c:557: Test failed: oob_server (750): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 00000000 === w2008s64 (64 bit sock) === sock.c:557: Test failed: oob_server (654): unexpectedly at the OOB mark: 0

Jan. 10, 2014

Re: [2/2] dpnet: Partial Implement IDirectPlay8Peer SetPeerInfo (try 2)

by Bruno Jesus

On Fri, Jan 10, 2014 at 5:38 AM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Hi, > Remove pointer checks > > Changelog: > dpnet: Partial Implement IDirectPlay8Peer SetPeerInfo > Hi, I'm not used to review patches but please take a look at the points below. + if(This->peername) + HeapFree(GetProcessHeap(), 0, This->peername); + if(This->data) + HeapFree(GetProcessHeap(), 0, This->data); + You don't need to check for NULL. + len = lstrlenW(pdpnPlayerInfo->pwszName); + This->peername = HeapAlloc(GetProcessHeap(), 0, len * sizeof(WCHAR)); + memcpy(This->peername, pdpnPlayerInfo->pwszName, len * sizeof(WCHAR)); If peername is a string don't you need a len + 1 to mark NULL in the end? I'm not sure but since you can use lstrlenW can't you use heap_strdupW? + This->data = HeapAlloc(GetProcessHeap(), 0, pdpnPlayerInfo->dwDataSize); + memcpy(This->data, pdpnPlayerInfo->pvData, pdpnPlayerInfo->dwDataSize); Don't you need to store the dwDataSize in datasize you created in the struct? > Best Regards > Alistair Leslie-Hughes > Best regards, Bruno

Jan. 10, 2014

Re: Command Stream Update

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-01-09 22:26, schrieb Jerome Leclanche: > Interesting. I get it pretty much everywhere, but it's easiest to > test in towns. Ping me on irc (jleclanche) and I can do some > tests. A regression test with CSMT=disabled would be helpful. Every single revision should work with CSMT=disabled, in theory. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSz8S4AAoJEN0/YqbEcdMwpu0P/1Bafnt4HEb6xJMVGw+i/tFa 2k7fhO/PSwdL5LUspaUkMFLRyS330qraM+W8Z8jdkNdogXS7QVRe96LHMHV5cJ6n 8jfpdYKg9YfscG6dd1783xO1FI+AQfcPQ1jlrM62gmOQQwbCDqOmzglJU61rP53B wZWRLujCasHTTdDcmHzQHiDzeidSevkhFhOiICBXGq5GFGARcWPxtEr5Cv65GqIb cQ3UegWh0Evd7AMm0uWd9fdhQK/r3ymYwdEDui15zcMsuA8N6q0JWW+Psc3aBYOx gQ8EHxosXS2hp4+Gfnw7BFuoi329ZTGvghgnPWH7MEIopZk0S/3nUjxbcyN5voIr Uv9cgSaFfmesTMfEHuIumPFAkqmeC9I+W+szn3OQOE+KEWMgpnnCXMZocVRF60U3 d44ikvm3QE4rAadzRl8LodoOc4DYqfMJcJl6GyM77XBnghyprCpD4XBJv9X0AlmI hq2wFBsn+FkJZ8uasykMcjWbY4t+MY/1EEUceO1bqxfG2JXG8Sz3BOGsLMRGGStP 7GqIVrWRQna8B+U/UeAw11be7P3jtevNBAl6lAIxtgO0k7jIDGfGNVEVTUdxcqmZ rYeQq0k/O5XkDCd1/x/iPRlvDJaMQE2Af07LzUuiVmgi0YX3gRm3godSFCJT9wFT OUaF+uxUHEc4L3VblceZ =sLVQ -----END PGP SIGNATURE-----

Jan. 10, 2014

Re: [2/2] dpnet: Partial Implement IDirectPlay8Peer SetPeerInfo

by Nikolay Sivov

On 1/10/2014 11:18, Alistair Leslie-Hughes wrote: > Hi, > > > Changelog: > dpnet: Partial Implement IDirectPlay8Peer SetPeerInfo > > > Best Regards > Alistair Leslie-Hughes > > + if(This->peername) > + HeapFree(GetProcessHeap(), 0, This->peername); > + if(This->data) > + HeapFree(GetProcessHeap(), 0, This->data); > + You don't need to check for NULL.

Jan. 10, 2014

Re: Command Stream Update

by Jerome Leclanche

On Thu, Jan 9, 2014 at 8:06 PM, Vincent Pelletier <plr.vincent(a)gmail.com> wrote: > On Thu, 9 Jan 2014 18:48:34 +0000, Jerome Leclanche <adys.wh(a)gmail.com> > wrote: >> The issue doesn't show up with plain Wine, only with your patches >> applied. It happens with both CMST=disabled and enabled. >> >> This seems to be the same issue we were hitting last time I tested >> your CS patches, on IRC. The problem only seems to show up outdoors, >> not indoors. nvidia 331.20-3 > > FWIW, I cannot (with a quick try in orgrimar) reproduce this issue with > Stefan's patches. I do see a +10 to +15 fps increase when enabling CMST > with identical settings, with DX9 renderer. > > nvidia 319.76, geforce gtx 650 > > What area do you get this problem in ? > What renderer are you using ? If needed, I think I can post extracts > from my config file. > > Regards, > -- > Vincent Pelletier Interesting. I get it pretty much everywhere, but it's easiest to test in towns. Ping me on irc (jleclanche) and I can do some tests. J. Leclanche

Jan. 9, 2014

Re: Command Stream Update

by Vincent Pelletier

On Thu, 9 Jan 2014 18:48:34 +0000, Jerome Leclanche <adys.wh(a)gmail.com> wrote: > The issue doesn't show up with plain Wine, only with your patches > applied. It happens with both CMST=disabled and enabled. > > This seems to be the same issue we were hitting last time I tested > your CS patches, on IRC. The problem only seems to show up outdoors, > not indoors. nvidia 331.20-3 FWIW, I cannot (with a quick try in orgrimar) reproduce this issue with Stefan's patches. I do see a +10 to +15 fps increase when enabling CMST with identical settings, with DX9 renderer. nvidia 319.76, geforce gtx 650 What area do you get this problem in ? What renderer are you using ? If needed, I think I can post extracts from my config file. Regards, -- Vincent Pelletier

Jan. 9, 2014

Re: Command Stream Update

by Jerome Leclanche

The issue doesn't show up with plain Wine, only with your patches applied. It happens with both CMST=disabled and enabled. This seems to be the same issue we were hitting last time I tested your CS patches, on IRC. The problem only seems to show up outdoors, not indoors. nvidia 331.20-3 J. Leclanche On Thu, Jan 9, 2014 at 10:25 AM, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 2014-01-08 20:03, schrieb Jerome Leclanche: >> Still a massive perf loss on WoW when outdoors. This spams: >> >> err:d3d:wined3d_debug_callback 0x7f4c0: "GL_INVALID_VALUE error >> generated. Point size must not be negative.". err:d3d:state_pscale >> >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from glPointSize(...); @ >> ../../../wine-multimedia/dlls/wined3d/state.c / 1572 J. Leclanche > At which settings does this happen? Which driver? Does it happen with > CSMT=disabled? Do the ERRs show up with plain Wine? > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJSznkKAAoJEN0/YqbEcdMw72gP/2vnKMiBsRzG7vLcV2BGV3hV > 95v/hu9yK8+Fw3h8h/AFvMNScRZL9uxGibxPSMNBDQ0pbaYH5y1VN8+GQEdDcOPV > bmjjKrwuGAU3cJ3Sn0eDFloTqAy+Lip/+TrPCe+Ga7zwjuVBELon790bfRuUy6yZ > /o+1L9wZoDvqffj10JIqGnjX6ibPQPQkeb5izc+Y2ju5o7xedOd85p4Wvtm8iSZV > qAmKQF+2p1G+Hz7LikUMCYI0Cn3qRK7dap1twSczJ4bWdC4aU5+QL/AvJ4ebvsJx > aIPeFJfSl6r3upLXxMUgT1FfCvIGi3ioGPUUukpCOsnw7A1Kza3I4S44HfbOEl/y > sO6FVhSjNsia4PqgaF9iRbaof02qD3Pb7mjSuIzTS4qPr1vBAuJGBqQhWD1TWfTw > JvQa5Pc+urJzJ2pW52/ObRsEzNS9rktmsePGK/2g88TAKkP8G54Ra0qZtq9X1VCd > ylI5HxVdhNeIR/NFVqegfrX/UtmHxU5LLBOZvX0RbESnV+0shR5JFOsi/PCU4zPw > bT/wAP+AkWcfVB3wsji/J952V8fvymd3h2PCFtLkXWloRBg+XNFSxDkgPmjdIBCB > 8gDYqS+MbpS0DwVuNdEeto+OcSgT05YKz1SMWOQRXOp3npAbibZzNOlCMCZjCArr > 77LL7H0h7XKg58uC4eHo > =yb0B > -----END PGP SIGNATURE-----

Jan. 9, 2014