- wine-devel - winehq.org

Problem receiving UDP broadcast on wxppro and w2008s64
by Bruno Jesus 07 Apr '15

07 Apr '15

Hi, Francois, I hope you can help me in this situation. The patch attached to bug 31994 [1] (compiled version at [2]) runs fine in most testbot machines (tested dozens of times) and my personal XP machine, but for some reason it doesn't work in xppro and w2008s64. The test creates 2 UDP sockets and send a broadcast from socket A to the network where B is bound, but the broadcasted packet never is received by B resulting in test timeout due to recvfrom never getting data. According to [3] all testbots share similar IP addresses like and I can't imagine a reason for them not to work: wxppro: testing broadcast for interface IP 10.42.42.134 (don't work) w2003std: testing broadcast for interface IP 10.42.42.140 (works) wvistau64: testing broadcast for interface IP 10.42.42.138 (works) w2008s64: testing broadcast for interface IP 10.42.42.216 (don't work) Any ideas? I wonder if it could be a firewall. The test also works fine in NT4. [1] https://bugs.winehq.org/attachment.cgi?id=51182 [2] https://testbot.winehq.org/GetFile.pl?JobKey=12594&StepKey=1 [3] https://testbot.winehq.org/JobDetails.pl?Key=12591 Best Regards, Bruno

2 5

Re: locale: [1/1] patch - 0x10000000 flag is NORM_STOP_ON_NULL (plus test fix)
by Marvin 07 Apr '15

07 Apr '15

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://testbot.winehq.org/JobDetails.pl?Key=12697 Your paranoid android. === w2000pro (32 bit locale) === locale.c:1776: Test failed: Without NORM_STOP_ON_NULL flag - strings `don\0a` (5) and `don\0b` (5) expected CSTR_LESS_THAN, got 2

1 0

CoInternetParseUrl and concepts explanation.
by Philippe Groarke 06 Apr '15

06 Apr '15

Hello, I am currently exploring Wine code base looking for low hanging fruits I can contribute to. I think CoInternetParseUrl and other URLMon stubs seemed easy enough I want to try and implement some. I also see many URLMon stubs when using Wine for games and applications. In CoInternetParseUrl, you use a switch case depending on the parameters passed. These in turn call specific methods for each parameter, which most do the same thing, call IInternetProtocolInfo_ParseUrl with the desired parse option . This function is defined in urlmon header. It seems to call a saved This on runtime, derefencing a saved (?) virtual table calling ParseUrl. It is also implemented in the header (static FORCEINLINE) and also calls the ParseUrl. There are some STDMETHODCALLTYPE pure virtual methods inside a IInternetProtocoleInfo class. A struct virtual table IInternetProtocolInfoVtbl O_o I cannot find the actual ParseUrl implementation, though in misc.c, there are many references to CHECK_CALLED(ParseUrl) and SET_EXPECT(ParseUrl). I have no clue what is going on here to be completely honest. Finally, in misc.c there are some pCoInternetParseUrl and CoInternetParseUrl tests. But nothing that seems to implement what I need. My question is, why go through all these hoops instead of implementing CoInternetParseUrl inside internet.c. I am sure there is good reasoning behind this, I would just like to understand why. Also, where do I implement ParseUrl or IInternetProtocolInfo_ParseUrl? Thank you for any help in understanding what is going on here. Good day, Philippe

2 1

Re: [PATCH 2/4] ntdll/test: Add ntdll test function test_file_full_size_information
by Nikolay Sivov 06 Apr '15

06 Apr '15

On 04.04.2015 10:03, Jianqiu Zhang wrote: > + trace("TotalAllocationUnits %08x %08x\n", fsi.TotalAllocationUnits.HighPart, fsi.TotalAllocationUnits.LowPart); > + trace("CallerAvailableAllocationUnits %08x %08x\n", fsi.CallerAvailableAllocationUnits.HighPart, fsi.CallerAvailableAllocationUnits.LowPart); > + trace("ActualAvailableAllocationUnits %08x %08x\n", fsi.ActualAvailableAllocationUnits.HighPart, fsi.ActualAvailableAllocationUnits.LowPart); > + trace("SectorsPerAllocationUnit %08x\n", fsi.SectorsPerAllocationUnit); > + trace("BytesPerSector %08x\n", fsi.BytesPerSector); > + Hi, Jianqiu. This is not exactly a test, as you're just printing a result. Same thing with patch 3/4. Also to print LONGLONG values you use wine_dbgstr_longlong() probably.

2 3

Re: [PATCH 1/2] ws2_32: Fix compile on OS X.
by Bruno Jesus 06 Apr '15

06 Apr '15

On Sun, Apr 5, 2015 at 4:07 PM, Socapex <philippe.groarke(a)gmail.com> wrote: > If HAS_IPX isn't defined, compilation will throw error since > WS_IPX_* aren't declared. > --- > dlls/ws2_32/socket.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/dlls/ws2_32/socket.c b/dlls/ws2_32/socket.c > index 09c8416..bc4d40a 100644 > --- a/dlls/ws2_32/socket.c > +++ b/dlls/ws2_32/socket.c > @@ -365,6 +365,7 @@ static inline const char *debugstr_sockopt(int level, int optname) > DEBUG_SOCKLEVEL(WS_NSPROTO_IPX); > switch(optname) > { > +#ifdef HAS_IPX > DEBUG_SOCKOPT(WS_IPX_PTYPE); > DEBUG_SOCKOPT(WS_IPX_FILTERPTYPE); > DEBUG_SOCKOPT(WS_IPX_DSTYPE); > @@ -372,6 +373,7 @@ static inline const char *debugstr_sockopt(int level, int optname) > DEBUG_SOCKOPT(WS_IPX_MAXSIZE); > DEBUG_SOCKOPT(WS_IPX_ADDRESS); > DEBUG_SOCKOPT(WS_IPX_MAX_ADAPTER_NUM); > +#endif > } > break; Hi, unfortunately I don't have OSX so I only test my patches in Linux and FreeBSD, so sometimes these problems happen, sorry. I think it's better to simply remove the #ifdef around wsnwlink.h [1], this will not reduce the debug capabilities of debugstr_sockopt. Since wsnwlink.h is an internal include it will always be available, can you it, please? [1] From socket.c: 160 #ifdef HAS_IPX 161 # include "wsnwlink.h" 162 #endif Best Regards, Bruno

2 1

Re: [PATCH 2/2] ws2_32: Remove trailing white-spaces.
by Stefan Dösinger 05 Apr '15

05 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Am 2015-04-05 um 21:07 schrieb Socapex: > -/* Note: EAI_NODATA is deprecated, but still > +/* Note: EAI_NODATA is deprecated, but still Generally we don't commit whitespace-only changes because they cause problems with git blame (though git blame has been improved in that regard) and merges. Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVIYsNAAoJEN0/YqbEcdMwLUEP/jy+kbilEFxb+W5HrbvV5x4Y GKTrrE0sBYv3RmcLEdCEmivTt5BOHerIxmoy5Li2wsH/S1FglwcdVETTBBG9v8tV 0dEgJ/p3GAB8RPQTRtvHTyr5aiUqOQg0HNW08puy/OHF3Zr3BTiFfzNLfKcVRTj5 Vvp28AwThDTqjG85ajOezBfxw/H6g4D8GtmsETYr2NYQZD9lt+C28op9K5hxSuA9 E05Af00Rxye7qb8ry715cAbBg2nO/MDygRt5iYpCX6Rd8fmRuM5O27MJLDQkq/pU GDKilQuWmiwZPEQcs3PKbOql3xditgvLrGKk4jkYAiXfTtaxIvwz9GDA6KVXynom Hv/m2BFKV1odoBYkDWlZZ42XVj1aZFKFZIknVTddDoRN/AVfTBO3cz5TPWOwr0q3 jGWOBT31ksWStdXOaQsPyUjX7ZKws2T2ZTRZTKoY0o/c/LYAXIgqz0VNwVnVaIs2 x+xlrdEpg58E1JuLBL93F0z3Pe+YQXqdv3RhWNSgzosK3VmaEC8+GzWBUR8gQMlJ UW0WRSycE9AktMGJv1+Grf/PIk8pHRN+4veL4065M5a4jaeclghx/HxqswuI8WCV Ty1qe5eHeNbD/9cEzbRSHBOV5g/V+xmvgzY5M0DJ2TTSMchmkJzC00m0khRMWhaj JMLgp7jnoWasLLA2ufZH =MEUF -----END PGP SIGNATURE-----

1 0

Re: [PATCH 1/2] ws2_32: Fix compile on OS X.
by Stefan Dösinger 05 Apr '15

05 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, You have to use your real name, not a nickname. We need this to be able to show where our code comes from. With best regards, Stefan Am 2015-04-05 um 21:07 schrieb Socapex: > If HAS_IPX isn't defined, compilation will throw error since > WS_IPX_* aren't declared. > --- > dlls/ws2_32/socket.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/dlls/ws2_32/socket.c b/dlls/ws2_32/socket.c > index 09c8416..bc4d40a 100644 > --- a/dlls/ws2_32/socket.c > +++ b/dlls/ws2_32/socket.c > @@ -365,6 +365,7 @@ static inline const char *debugstr_sockopt(int level, int optname) > DEBUG_SOCKLEVEL(WS_NSPROTO_IPX); > switch(optname) > { > +#ifdef HAS_IPX > DEBUG_SOCKOPT(WS_IPX_PTYPE); > DEBUG_SOCKOPT(WS_IPX_FILTERPTYPE); > DEBUG_SOCKOPT(WS_IPX_DSTYPE); > @@ -372,6 +373,7 @@ static inline const char *debugstr_sockopt(int level, int optname) > DEBUG_SOCKOPT(WS_IPX_MAXSIZE); > DEBUG_SOCKOPT(WS_IPX_ADDRESS); > DEBUG_SOCKOPT(WS_IPX_MAX_ADAPTER_NUM); > +#endif > } > break; > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVIYmzAAoJEN0/YqbEcdMwmcMP/0UWQMONOFklXHtI9ibTn5rU Y8idfpQRQEj7s4UqKT5XdHbbGsmGa24byBybhWf54z/ykTqcwvcun4xDUs0/pmCK WRWx9hlgGd4xPSGrnum9XC/tnywjyP5s8eyRUU4CeMmBOIwauj15iePd/v4W+BA+ iHTyY4rjzyoyatmZURoaZaFFj/n5cLoqyqQ+fTNeP22z+Wjl7N76wXYbsylRsatB NKe8bAdBAQZL8LNngjpCVXW0PsKaH88LIdVPZpvI0T+hH8+LYRToKbfqCXtwkwYb LuE9RCdfAcRbIQTCe4FrpfduGUtQN2Nlxu7pIOH9GghWITTjIZn/XV0VYSBVDrNc d2zZ0lmyEWPU6H5RU/dzfhkJMhKP7RzZkd3j7yDKsjBlC651ysDT6ev/HpX2Jx7O aYf70/48Qk5BhbEZblQuPrssz/p4ErXHz2UQRGodqLjJm+ATSwkSlwsAGZ8iyjn0 3JQuL3BDDSF3CAjfQBLfcRXS4tNgNd58rr5dfoLmOhkKG+LIbYIQ55104UG03xDc 5LFubLU8i8r89OBR3yeZXLIX3BdR3oxANVDoPjjbbJiAKIoej5yJOCyLb8cPbchN CufNxeiY+wrKNWtuW6UXONaEJqt2MpcY0HUV70s9qRXZ2iZoPKDFkR5mPudR7qbj ZIUAqSKGQcWwmCw+aEk+ =ShND -----END PGP SIGNATURE-----

1 0

Re: [PATCH 3/3] d3drm/tests: Split tests between different versions, initially adding frame QueryInterface tests.
by Stefan Dösinger 05 Apr '15

05 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This series looks good to me, and this time I ran the tests on Windows and Wine :-) Am 2015-04-03 um 14:25 schrieb Aaryaman Vasishta: > +struct qi_test > +{ > + REFIID iid; > + REFIID refcount_iid; > + HRESULT hr; > + BOOL refcount_todo; > +}; refcount_todo is always FALSE in your tables, so you might as well remove it. I don't think it's necessary to resend the patch because of that though. You can just remove it when you add the vtable inheritance test. If you expect future tests to need refcount_todo you can also keep the field. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVIWyeAAoJEN0/YqbEcdMwZPgP/AoYCerTMFiXH9lYnmueThK/ UPGcBOLhdU0dT0U8lI0ZVzX7mbvtvjoVFUn/cAGgBZTUH175BK3SHbuIljJ+R954 +xQtRda5QrEu759UIkuc6v+REUtNQWzPtWLRX8EhZLhTEJaTEdsGeGUKAKRwGFmc UsMEff5r1gIIFgFDSlwSm1daAduOwkNcnzFwbxTbm7Kg/qCn50nSTfWj4Nk/sYYl kr6vzKH5EAt5nL9tvtXT7q8YDu+e2TC96B2xzoseRnS3st44nAgqjSb9E7fB05Cu Lem/zEEoGJI3mrLWpoDVDoYFFaHPifoqRgyf6EcT9ID0vUmJhM97WgBWw0+b8fFR yxJ/nsBol56Rb4xssOrXINDfF2E+7S9RMu/oxSbVbW8GV3vN4ssgZ5/Q8itmCdJd u7Kyfx/OS72xE9rrUXIQrS0EM7yFq1j6cZa/xv6xGzO0SpeIbWrB2Pnujvr5GTt/ KkPqJVoiFr8VOaZfK2SQreGTaBK4f6rDdW+jkfnQLU38uVSmDTowdO3oD6aPCy2s mgB8JmhBuDsU5RAWoA61PzTtDPmdWLhmHZJWfLC4PG9/IN0m3G3JhFUAUy3qr8UZ 543kGtR21tmPHLKXc+Bt20B0j+RY0sxu8CvVJPb3qa7VmDP+c3thnjkgng1ZJo0F CrXo+6/IKapzItlvTFIE =ssTG -----END PGP SIGNATURE-----

1 0

Re: locale: [1/1] patch - 0x10000000 flag is NORM_STOP_ON_NULL (marvins test fix)
by Marvin 04 Apr '15

04 Apr '15

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://testbot.winehq.org/JobDetails.pl?Key=12662 Your paranoid android. === w2000pro (32 bit locale) === locale.c:1776: Test failed: Without NORM_STOP_ON_NULL flag - strings `don\0a` (5) and `don\0b` (5) expected CSTR_LESS_THAN, got 2 === wvistau64 (32 bit locale) === locale.c:2010: Test failed: NORM_STOP_ON_NULL passed, though its equal to length autodetect (-1) - strings `don\0at` (-1) and `don\__` (-1) expected CSTR_EQUAL, got 0 locale.c:2014: Test failed: NORM_STOP_ON_NULL is not set, strings considered as null terminated - so strings `don\0at` (-1) and `don\__` (-1) expected CSTR_EQUAL, got 0 locale.c:2018: Test failed: NORM_STOP_ON_NULL passed, and lengths are defined exlicitly - so strings `don\0at` (6) and `don\__` (6) are expected CSTR_EQUAL due to flag, got 0 locale.c:2022: Test failed: NORM_STOP_ON_NULL passed, and length is defined exlicitly for one string - anyway strings `don\0at` (6) and `don\__` (-1) are expected CSTR_EQUAL due to flag, got 0 locale.c:2028: Test failed: NORM_STOP_ON_NULL | NORM_IGNORECASE passed, though its equal to length autodetect (-1) - so strings `don\0at` (-1) and `dOn\At` (-1) expected CSTR_EQUAL, got 0 locale.c:2032: Test failed: NORM_STOP_ON_NULL | NORM_IGNORECASE passed, and lengths are defined explicitely - so strings `don\0at` (-1) and `dOn\At` (-1) expected CSTR_EQUAL, got 0 === w2008s64 (32 bit locale) === locale.c:2010: Test failed: NORM_STOP_ON_NULL passed, though its equal to length autodetect (-1) - strings `don\0at` (-1) and `don\__` (-1) expected CSTR_EQUAL, got 0 locale.c:2014: Test failed: NORM_STOP_ON_NULL is not set, strings considered as null terminated - so strings `don\0at` (-1) and `don\__` (-1) expected CSTR_EQUAL, got 0 locale.c:2018: Test failed: NORM_STOP_ON_NULL passed, and lengths are defined exlicitly - so strings `don\0at` (6) and `don\__` (6) are expected CSTR_EQUAL due to flag, got 0 locale.c:2022: Test failed: NORM_STOP_ON_NULL passed, and length is defined exlicitly for one string - anyway strings `don\0at` (6) and `don\__` (-1) are expected CSTR_EQUAL due to flag, got 0 locale.c:2028: Test failed: NORM_STOP_ON_NULL | NORM_IGNORECASE passed, though its equal to length autodetect (-1) - so strings `don\0at` (-1) and `dOn\At` (-1) expected CSTR_EQUAL, got 0 locale.c:2032: Test failed: NORM_STOP_ON_NULL | NORM_IGNORECASE passed, and lengths are defined explicitely - so strings `don\0at` (-1) and `dOn\At` (-1) expected CSTR_EQUAL, got 0 === w7u (32 bit locale) === locale.c:2010: Test failed: NORM_STOP_ON_NULL passed, though its equal to length autodetect (-1) - strings `don\0at` (-1) and `don\__` (-1) expected CSTR_EQUAL, got 0 locale.c:2014: Test failed: NORM_STOP_ON_NULL is not set, strings considered as null terminated - so strings `don\0at` (-1) and `don\__` (-1) expected CSTR_EQUAL, got 0 locale.c:2018: Test failed: NORM_STOP_ON_NULL passed, and lengths are defined exlicitly - so strings `don\0at` (6) and `don\__` (6) are expected CSTR_EQUAL due to flag, got 0 locale.c:2022: Test failed: NORM_STOP_ON_NULL passed, and length is defined exlicitly for one string - anyway strings `don\0at` (6) and `don\__` (-1) are expected CSTR_EQUAL due to flag, got 0 locale.c:2028: Test failed: NORM_STOP_ON_NULL | NORM_IGNORECASE passed, though its equal to length autodetect (-1) - so strings `don\0at` (-1) and `dOn\At` (-1) expected CSTR_EQUAL, got 0 locale.c:2032: Test failed: NORM_STOP_ON_NULL | NORM_IGNORECASE passed, and lengths are defined explicitely - so strings `don\0at` (-1) and `dOn\At` (-1) expected CSTR_EQUAL, got 0 === w8 (32 bit locale) === locale.c:2010: Test failed: NORM_STOP_ON_NULL passed, though its equal to length autodetect (-1) - strings `don\0at` (-1) and `don\__` (-1) expected CSTR_EQUAL, got 0 locale.c:2014: Test failed: NORM_STOP_ON_NULL is not set, strings considered as null terminated - so strings `don\0at` (-1) and `don\__` (-1) expected CSTR_EQUAL, got 0 locale.c:2018: Test failed: NORM_STOP_ON_NULL passed, and lengths are defined exlicitly - so strings `don\0at` (6) and `don\__` (6) are expected CSTR_EQUAL due to flag, got 0 locale.c:2022: Test failed: NORM_STOP_ON_NULL passed, and length is defined exlicitly for one string - anyway strings `don\0at` (6) and `don\__` (-1) are expected CSTR_EQUAL due to flag, got 0 locale.c:2028: Test failed: NORM_STOP_ON_NULL | NORM_IGNORECASE passed, though its equal to length autodetect (-1) - so strings `don\0at` (-1) and `dOn\At` (-1) expected CSTR_EQUAL, got 0 locale.c:2032: Test failed: NORM_STOP_ON_NULL | NORM_IGNORECASE passed, and lengths are defined explicitely - so strings `don\0at` (-1) and `dOn\At` (-1) expected CSTR_EQUAL, got 0 === wvistau64 (64 bit locale) === locale.c:2010: Test failed: NORM_STOP_ON_NULL passed, though its equal to length autodetect (-1) - strings `don\0at` (-1) and `don\__` (-1) expected CSTR_EQUAL, got 0 locale.c:2014: Test failed: NORM_STOP_ON_NULL is not set, strings considered as null terminated - so strings `don\0at` (-1) and `don\__` (-1) expected CSTR_EQUAL, got 0 locale.c:2018: Test failed: NORM_STOP_ON_NULL passed, and lengths are defined exlicitly - so strings `don\0at` (6) and `don\__` (6) are expected CSTR_EQUAL due to flag, got 0 locale.c:2022: Test failed: NORM_STOP_ON_NULL passed, and length is defined exlicitly for one string - anyway strings `don\0at` (6) and `don\__` (-1) are expected CSTR_EQUAL due to flag, got 0 locale.c:2028: Test failed: NORM_STOP_ON_NULL | NORM_IGNORECASE passed, though its equal to length autodetect (-1) - so strings `don\0at` (-1) and `dOn\At` (-1) expected CSTR_EQUAL, got 0 locale.c:2032: Test failed: NORM_STOP_ON_NULL | NORM_IGNORECASE passed, and lengths are defined explicitely - so strings `don\0at` (-1) and `dOn\At` (-1) expected CSTR_EQUAL, got 0 === w2008s64 (64 bit locale) === locale.c:2010: Test failed: NORM_STOP_ON_NULL passed, though its equal to length autodetect (-1) - strings `don\0at` (-1) and `don\__` (-1) expected CSTR_EQUAL, got 0 locale.c:2014: Test failed: NORM_STOP_ON_NULL is not set, strings considered as null terminated - so strings `don\0at` (-1) and `don\__` (-1) expected CSTR_EQUAL, got 0 locale.c:2018: Test failed: NORM_STOP_ON_NULL passed, and lengths are defined exlicitly - so strings `don\0at` (6) and `don\__` (6) are expected CSTR_EQUAL due to flag, got 0 locale.c:2022: Test failed: NORM_STOP_ON_NULL passed, and length is defined exlicitly for one string - anyway strings `don\0at` (6) and `don\__` (-1) are expected CSTR_EQUAL due to flag, got 0 locale.c:2028: Test failed: NORM_STOP_ON_NULL | NORM_IGNORECASE passed, though its equal to length autodetect (-1) - so strings `don\0at` (-1) and `dOn\At` (-1) expected CSTR_EQUAL, got 0 locale.c:2032: Test failed: NORM_STOP_ON_NULL | NORM_IGNORECASE passed, and lengths are defined explicitely - so strings `don\0at` (-1) and `dOn\At` (-1) expected CSTR_EQUAL, got 0

1 0

Re: [PATCH 1/7] advapi32: Initialize buffer length to zero in LsaLookupSids to prevent crash.
by Nikolay Sivov 04 Apr '15

04 Apr '15

On 04.04.2015 17:22, Qian Hong wrote: > > (*Names)[i].Name.Buffer = NULL; > + (*Names)[i].Name.Length = 0; > + (*Names)[i].Name.MaximumLength = 0; Maybe it's better to hide this in RtlInitUnicodeStringEx(..., NULL) ?

2 1

Re: mshtml: Removed return to ensure AddRef is called on an internal interface
by Piotr Caban 04 Apr '15

04 Apr '15

The patch is wrong, nsCycleCollectionISupports doesn't support AddRef/Release.

4 6

Re: locale: [1/1] patch - 0x10000000 flag is NORM_STOP_ON_NULL
by Marvin 04 Apr '15

04 Apr '15

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://testbot.winehq.org/JobDetails.pl?Key=12661 Your paranoid android. === wvistau64 (32 bit locale) === locale.c:1985: Test failed: NORM_STOP_ON_NULL passed, though its equal to length autodetect (-1) - strings `don\0at` (-1) and `don\__` (-1) expected CSTR_EQUAL, got 0 locale.c:1989: Test failed: NORM_STOP_ON_NULL is not set, strings considered as null terminated - so strings `don\0at` (-1) and `don\__` (-1) expected CSTR_EQUAL, got 0 locale.c:1993: Test failed: NORM_STOP_ON_NULL passed, and lengths are defined exlicitly - so strings `don\0at` (6) and `don\__` (6) are expected CSTR_EQUAL due to flag, got 0 locale.c:1997: Test failed: NORM_STOP_ON_NULL passed, and length is defined exlicitly for one string - anyway strings `don\0at` (6) and `don\__` (-1) are expected CSTR_EQUAL due to flag, got 0 locale.c:2003: Test failed: NORM_STOP_ON_NULL | NORM_IGNORECASE passed, though its equal to length autodetect (-1) - so strings `don\0at` (-1) and `dOn\At` (-1) expected CSTR_EQUAL, got 0 locale.c:2007: Test failed: NORM_STOP_ON_NULL | NORM_IGNORECASE passed, and lengths are defined explicitely - so strings `don\0at` (-1) and `dOn\At` (-1) expected CSTR_EQUAL, got 0 === w2008s64 (32 bit locale) === locale.c:1985: Test failed: NORM_STOP_ON_NULL passed, though its equal to length autodetect (-1) - strings `don\0at` (-1) and `don\__` (-1) expected CSTR_EQUAL, got 0 locale.c:1989: Test failed: NORM_STOP_ON_NULL is not set, strings considered as null terminated - so strings `don\0at` (-1) and `don\__` (-1) expected CSTR_EQUAL, got 0 locale.c:1993: Test failed: NORM_STOP_ON_NULL passed, and lengths are defined exlicitly - so strings `don\0at` (6) and `don\__` (6) are expected CSTR_EQUAL due to flag, got 0 locale.c:1997: Test failed: NORM_STOP_ON_NULL passed, and length is defined exlicitly for one string - anyway strings `don\0at` (6) and `don\__` (-1) are expected CSTR_EQUAL due to flag, got 0 locale.c:2003: Test failed: NORM_STOP_ON_NULL | NORM_IGNORECASE passed, though its equal to length autodetect (-1) - so strings `don\0at` (-1) and `dOn\At` (-1) expected CSTR_EQUAL, got 0 locale.c:2007: Test failed: NORM_STOP_ON_NULL | NORM_IGNORECASE passed, and lengths are defined explicitely - so strings `don\0at` (-1) and `dOn\At` (-1) expected CSTR_EQUAL, got 0 === w7u (32 bit locale) === locale.c:1985: Test failed: NORM_STOP_ON_NULL passed, though its equal to length autodetect (-1) - strings `don\0at` (-1) and `don\__` (-1) expected CSTR_EQUAL, got 0 locale.c:1989: Test failed: NORM_STOP_ON_NULL is not set, strings considered as null terminated - so strings `don\0at` (-1) and `don\__` (-1) expected CSTR_EQUAL, got 0 locale.c:1993: Test failed: NORM_STOP_ON_NULL passed, and lengths are defined exlicitly - so strings `don\0at` (6) and `don\__` (6) are expected CSTR_EQUAL due to flag, got 0 locale.c:1997: Test failed: NORM_STOP_ON_NULL passed, and length is defined exlicitly for one string - anyway strings `don\0at` (6) and `don\__` (-1) are expected CSTR_EQUAL due to flag, got 0 locale.c:2003: Test failed: NORM_STOP_ON_NULL | NORM_IGNORECASE passed, though its equal to length autodetect (-1) - so strings `don\0at` (-1) and `dOn\At` (-1) expected CSTR_EQUAL, got 0 locale.c:2007: Test failed: NORM_STOP_ON_NULL | NORM_IGNORECASE passed, and lengths are defined explicitely - so strings `don\0at` (-1) and `dOn\At` (-1) expected CSTR_EQUAL, got 0 === w8 (32 bit locale) === locale.c:1985: Test failed: NORM_STOP_ON_NULL passed, though its equal to length autodetect (-1) - strings `don\0at` (-1) and `don\__` (-1) expected CSTR_EQUAL, got 0 locale.c:1989: Test failed: NORM_STOP_ON_NULL is not set, strings considered as null terminated - so strings `don\0at` (-1) and `don\__` (-1) expected CSTR_EQUAL, got 0 locale.c:1993: Test failed: NORM_STOP_ON_NULL passed, and lengths are defined exlicitly - so strings `don\0at` (6) and `don\__` (6) are expected CSTR_EQUAL due to flag, got 0 locale.c:1997: Test failed: NORM_STOP_ON_NULL passed, and length is defined exlicitly for one string - anyway strings `don\0at` (6) and `don\__` (-1) are expected CSTR_EQUAL due to flag, got 0 locale.c:2003: Test failed: NORM_STOP_ON_NULL | NORM_IGNORECASE passed, though its equal to length autodetect (-1) - so strings `don\0at` (-1) and `dOn\At` (-1) expected CSTR_EQUAL, got 0 locale.c:2007: Test failed: NORM_STOP_ON_NULL | NORM_IGNORECASE passed, and lengths are defined explicitely - so strings `don\0at` (-1) and `dOn\At` (-1) expected CSTR_EQUAL, got 0 === wvistau64 (64 bit locale) === locale.c:1985: Test failed: NORM_STOP_ON_NULL passed, though its equal to length autodetect (-1) - strings `don\0at` (-1) and `don\__` (-1) expected CSTR_EQUAL, got 0 locale.c:1989: Test failed: NORM_STOP_ON_NULL is not set, strings considered as null terminated - so strings `don\0at` (-1) and `don\__` (-1) expected CSTR_EQUAL, got 0 locale.c:1993: Test failed: NORM_STOP_ON_NULL passed, and lengths are defined exlicitly - so strings `don\0at` (6) and `don\__` (6) are expected CSTR_EQUAL due to flag, got 0 locale.c:1997: Test failed: NORM_STOP_ON_NULL passed, and length is defined exlicitly for one string - anyway strings `don\0at` (6) and `don\__` (-1) are expected CSTR_EQUAL due to flag, got 0 locale.c:2003: Test failed: NORM_STOP_ON_NULL | NORM_IGNORECASE passed, though its equal to length autodetect (-1) - so strings `don\0at` (-1) and `dOn\At` (-1) expected CSTR_EQUAL, got 0 locale.c:2007: Test failed: NORM_STOP_ON_NULL | NORM_IGNORECASE passed, and lengths are defined explicitely - so strings `don\0at` (-1) and `dOn\At` (-1) expected CSTR_EQUAL, got 0 === w2008s64 (64 bit locale) === locale.c:1985: Test failed: NORM_STOP_ON_NULL passed, though its equal to length autodetect (-1) - strings `don\0at` (-1) and `don\__` (-1) expected CSTR_EQUAL, got 0 locale.c:1989: Test failed: NORM_STOP_ON_NULL is not set, strings considered as null terminated - so strings `don\0at` (-1) and `don\__` (-1) expected CSTR_EQUAL, got 0 locale.c:1993: Test failed: NORM_STOP_ON_NULL passed, and lengths are defined exlicitly - so strings `don\0at` (6) and `don\__` (6) are expected CSTR_EQUAL due to flag, got 0 locale.c:1997: Test failed: NORM_STOP_ON_NULL passed, and length is defined exlicitly for one string - anyway strings `don\0at` (6) and `don\__` (-1) are expected CSTR_EQUAL due to flag, got 0 locale.c:2003: Test failed: NORM_STOP_ON_NULL | NORM_IGNORECASE passed, though its equal to length autodetect (-1) - so strings `don\0at` (-1) and `dOn\At` (-1) expected CSTR_EQUAL, got 0 locale.c:2007: Test failed: NORM_STOP_ON_NULL | NORM_IGNORECASE passed, and lengths are defined explicitely - so strings `don\0at` (-1) and `dOn\At` (-1) expected CSTR_EQUAL, got 0

1 0

Re: [PATCH 7/7] advapi32/tests: Add more tests for LsaLookupSids and LsaLookupNames2.
by Marvin 04 Apr '15

04 Apr '15

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://testbot.winehq.org/JobDetails.pl?Key=12659 Your paranoid android. === w2003std (32 bit lsa) === lsa: unhandled exception c0000005 at 7C81BB52 === wvistau64 (64 bit lsa) === No test summary line found === w2008s64 (64 bit lsa) === No test summary line found

1 0

Re: msxml3: Explicitly list acceptable libxml2->msxml node types for unknode (try 2)
by Jacek Caban 04 Apr '15

04 Apr '15

Hi Nikolay, On 01/04/15 22:41, Nikolay Sivov wrote: > + switch (This->node.node->type) > + { > + case XML_ELEMENT_NODE: > + case XML_ATTRIBUTE_NODE: > + case XML_TEXT_NODE: > + case XML_CDATA_SECTION_NODE: > + case XML_ENTITY_REF_NODE: > + case XML_ENTITY_NODE: > + case XML_PI_NODE: > + case XML_COMMENT_NODE: > + case XML_DOCUMENT_NODE: > + case XML_DOCUMENT_TYPE_NODE: > + case XML_DOCUMENT_FRAG_NODE: > + case XML_NOTATION_NODE: Most of those types have their own IXMLDOMNode implementations, so they should never be the case in here. Also, ideally we shouldn't even create unknode object for types that are not supported, so it should be fixed in create_node or its callers. Is it possible in the case that you're fixing? Jacek

2 1

Re: [PATCH 3/4] ntdll/test: Add test_file_size_information
by Marvin 04 Apr '15

04 Apr '15

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://testbot.winehq.org/JobDetails.pl?Key=12656 Your paranoid android. === w8 (32 bit file) === file.c:397: Test failed: mismatched file size for L"WindowsUpdate.log"

1 0

Re: ntdll: Return STATUS_SUCCESS from SetInformationJobObject
by Nikolay Sivov 04 Apr '15

04 Apr '15

I don't think it's a good idea to always claim success. It might be better to actually store those UILIMIT flags (probably by extending set_job_limits ). Alternatively if you don't want to store those for some reason you can return success for this class only while keeping a fixme, but not for all unimplemented classes.

2 1

Re: [PATCH 2/4] ntdll/test: Add ntdll test function test_file_full_size_information
by Marvin 04 Apr '15

04 Apr '15

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://testbot.winehq.org/JobDetails.pl?Key=12655 Your paranoid android. === w8 (32 bit file) === file.c:397: Test failed: mismatched file size for L"WindowsUpdate.log"

1 0

Re: [PATCH] gdiplus: Avoid unnecessary pre-multiplied alpha conversions in GdipDrawImagePointsRect
by Vincent Povirk 03 Apr '15

03 Apr '15

Looks good to me.

1 0

Re: [PATCH] comctl32: Do not resize windows when giving an updown control the same buddy.
by Anton Baskanov 03 Apr '15

03 Apr '15

Hello! Have you verified this behavior on native comctl32? I've tried to send UDM_SETBUDDY with the same HWND repeatedly, and the buddy is resized every time. I've tested it on Windows 7 x64 with both version 5 and 6 of comctl32. On Wed, Apr 1, 2015 at 4:02 AM, Mark Harmstone <hellas(a)burntcomma.com> wrote: > When an updown control receives UDM_SETBUDDY with the HWND of its existing > buddy, it should do nothing. At present Wine resizes the buddy as it > would do initially, resulting in the textbox getting progressively smaller > every time UDM_SETBUDDY is sent. > > --- > dlls/comctl32/updown.c | 3 +++ > 1 file changed, 3 insertions(+) > > > > >

2 2

Re: [PATCH 4/4] d3drm/tests: Add vtable comparison tests in test_frame_qi
by Stefan Dösinger 03 Apr '15

03 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-04-02 um 18:36 schrieb Aaryaman Vasishta: > REFIID iid; > REFIID refcount_iid; > + REFIID vtable_iid; > HRESULT hr; > BOOL refcount_todo; > + BOOL vtable_equal; > + BOOL vtable_todo; > }; I think this is more complicated than it needs to be. All you should need is the vtable_iid field. Then, in the inner loop do something like if (IsEqualGUID(tests[i].vtable_iid, tests[j].vtable_iid)) ok(iface1 == iface2, ...); else ok(iface1 != iface2, ...); I may be missing something though. If you want to compare two Win32 BOOLs for equality you have to be careful: BOOL a = 1; BOOL b = 2; if (a) printf("this is true.\n"); if (b) printf("this is also true.\n"); if (a == b) printf("oops, this is false.\n"); For something like that you can use if (!a == !b) printf("yay, this is true!\n"); IsEqualGUID(a, b) is defined as !memcmp(a, b, sizeof(GUID)), so IsEqualGUID() == (ptr1 == ptr2) should be OK though. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVHakvAAoJEN0/YqbEcdMwPPYP/08CiwYXURzl7Ias7EKvZGO8 QlYjp4CSEorj44LMOMPMELbN+50NJOngxhXA0mecIhZYA9Dgd5NZtVvDWBIPPu/B tXe+0+Xw/EvzubfzMYjOX5/lOKm400CW3fPEbxwYrzdFOSmeNhclZpfD+9jjuekG Lj2XUSk/TAi1B8NlD0x0LE7P6gGb61rg7jeJNZGgfPYMsuAoB2OtekvbIvpbCZmb 3WlOXtzmqVMHjsEsw47i8pdL/DwCFFfpE0xWWdhfgCChFUG/Ul/V56ltN5ERtudO j+jKtY5oNhunIyALwIifwhYNq/bY9CdfovIOI7sNfM3bXwSCZGEk+5Oq3/dnd4rP /Ejp+Kd5xk4SDMC3kyE6VucZkyFD58plgEDNlgSXx2ND/o3Mw91PTDaGj5xT0Fy1 Enk6oqORgXQhvtUaDH5Y5rOyh+AMquWhhN5N43ymT0UW40D4b6UBNSSwuQeqKaxS d1CqkbjUcivIBVd1k8GiuXEgjaEvwMlv8kPj1FGu/GCoMeyoRy7mXN1NOapPdFVu Gz2e8xR8Bri7oglvsS25i6gjYeYvP8qhTcc8tKBU2tr6MHFN3sUkuOZwtLKJLirc NxdSzaylgVGpCFQ0cwNSjm+eY0WvBd4eLychal+cs2plMmMAkYVTLDRBC4ZReCkw KIL1cdIMHQIZSSrDu22h =tKFs -----END PGP SIGNATURE-----

2 2

Re: kernel32: Stub out GetFileMUIPath.
by Nikolay Sivov 03 Apr '15

03 Apr '15

> +@ stdcall GetFileMUIPath(long ptr ptr ptr ptr ptr ptr) Second and third arguments should be 'wstr'.

1 0

Re: advapi32: Handle NULL DACL in SetSecurityInfo
by Sebastian Lackner 03 Apr '15

03 Apr '15

On 02.04.2015 17:20, Piotr Caban wrote: > --- > dlls/advapi32/security.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > It doesn't match the Windows behaviour, please add at least a couple of tests. https://newtestbot.winehq.org/JobDetails.pl?Key=12622&log_204=1#k204

3 4

Re: user32/tests: Avoid side-effect in an assert.
by Marvin 03 Apr '15

03 Apr '15

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://testbot.winehq.org/JobDetails.pl?Key=12631 Your paranoid android. === wvistau64 (32 bit win) === win.c:7487: Test failed: didn't get start_event in.c:7429: Test failed: button under static window didn't get WM_LBUTTONUP

1 0

Re: [1/3] server: Allow to open a directory without any permission bits.
by Piotr Caban 02 Apr '15

02 Apr '15

On 04/02/15 09:42, Sebastian Lackner wrote: > Its a bit ugly, but probably the best solution to workaround the restrictions of the unix api. ;) There's similar problem with regular files (not directories). The owner should be able to read/write permissions. Also is there any need for unix_fd in this case? Thanks, Piotr

2 1

Re: [PATCH 3/4] d3drm/tests: Split tests between different versions, initially adding frame QueryInterface tests
by Stefan Dösinger 02 Apr '15

02 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, There are a few more issues: Am 2015-04-02 um 18:36 schrieb Aaryaman Vasishta: > + * Copyright 2012 Andr� Hentschel > + * Copyright 2011-2014 Henri Verbeet for CodeWeavers The encoding is still messed up. Is there any code you have taken from the other file? test_qi() is from dlls/ddraw/tests/ddraw*.c, so you should keep Henri's line. Taking along all the Copyright lines if you take something from an existing file is a safe choice though. Also, you should still fix your editor settings anyways. You can add your own name there if you want. (Fwiw, I don't know why we're maintaining these lines at all. The last thing I heard was that they don't have any legal meaning anyway. Also, git keep track of authorship pretty well.) > +#define CHECK_REFCOUNT(obj,rc) \ > + { \ > + int rc_new = rc; \ > + int count = get_refcount((IUnknown *)obj); \ > + ok(count == rc_new, "Invalid refcount. Expected %d got %d\n", rc_new, count); \ > + } Do you need this? You're using this in one place as far as I can see, you can also just use the get_refcount() and ok() calls directly. > +static int get_refcount(IUnknown *object) > +{ > + IUnknown_AddRef(object); > + return IUnknown_Release(object); > +} Refcounts are ULONG. > + hr = IDirect3DRM_CreateFrame(d3drm, NULL, &frame); > + ok(hr == D3DRM_OK, "Cannot get IDirect3DRMFrame3 interface (hr = %x)\n", hr); The string is a bit misleading, I think something like "Failed to create frame" is better. Not a big issue though. The same applies to d3drm2.c and d3drm3.c -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVHaNRAAoJEN0/YqbEcdMwZsAP/RvHLPjullG+tQC+JOZvzGDg nm2CZanwOzmC8ZEvWpXKxhCUjTIVUu0XB7yV33BgPywgRKBUUXkqEuGN+Z/wk7Lm rqNuPx17nPHL7aKjw9DxU3QP75t7RbFxU6N3Wz3Veoi+ox4xwxwmrIxRMkFNtxhv tPREjNp9yQVO79ZlLzI1VzeMVnTHKgVn/L+s68nADUkcBFrQaH6SBhB232utwbtp DdkwYOWCK0xGweaLAkt33X2Qhp+qbdtQjIoK/UZvq190owrW2tC2ORnIFhB/7zDR +FrpGzwGuTnhVocrLYCtVtB1RW5t0QealNjhlwv9HI03NSi/J7MmcwGOIE3TIatm TCCDvp034+EMThEvTDODATbYyihbgihG/jjiaQwznu+A66N9lOvhKRCbiasTjTym X06ti98dmpq9BwMd+8sRVe+U1zi9nRmGqvrcncmxUyZ1QoFdrDWFEpRog1jJvaho 8zO9NIzwsG839bqRyZIyZ0DvteaGXD7o907Nkr7aDt4jMjUmuj0ij+nrDvif9kTJ 5WOppUgN7JN4HhWNo4y5i3jei8X2TDDI9z76Juiv1DM0cbWbr2UTHSvFRysPiqGT vCg+boC2pZd94vQKnMYbyAg+06KDneZwiNYBVQpirY3Bua7PY7TwxkBgXQfh2sNv B2fjxmZVRMB3dWylqJmg =wYMH -----END PGP SIGNATURE-----

2 1

Re: [PATCH] undefined symbols compiling for macosx >10.8
by Ken Thomases 02 Apr '15

02 Apr '15

That symbol is in the 10.8 SDK. We build against that SDK all the time. It works fine. Here's the documentation for that function: <https://developer.apple.com/library/mac/documentation/Security/Reference/se…>. Notice that under Availability it says, "Available in OS X v10.8 and later." Here is the declaration from Security.framework/Headers/SecureTransport.h: ---------- OSStatus SSLGetProtocolVersionMax (SSLContextRef context, SSLProtocol *maxVersion) __OSX_AVAILABLE_STARTING(__MAC_10_8, __IPHONE_5_0); ---------- Notice the __MAC_10_8 identifier in the __OSX_AVAILABLE_STARTING() decorator. You need to fix your build environment and/or your build commands. Whatever problem you're encountering while trying to build is specific to your system. -Ken On Apr 2, 2015, at 11:58 AM, Sergey Isakov <isakov-sl(a)bk.ru> wrote: > Your proposition that SDK10.8 contains the symbol is wrong > —— > #if MAC_OS_X_VERSION_MAX_ALLOWED >= 1080 > +#ifdef SSLGetProtocolVersionMax > if(SSLGetProtocolVersionMax != NULL) { > ---- > > On 01 апр. 2015 г., at 21:36, Ken Thomases <ken(a)codeweavers.com> wrote: > >> If you were having problems building Wine without this patch, then you have a system configuration problem. Or you're configuring Wine incorrectly. >> >> -Ken >> >> On Apr 1, 2015, at 11:52 AM, Sergey Isakov <isakov-sl(a)bk.ru> wrote: >> >>> Sorry but I committed the patch make me compilation be possible. >>> >>> On 01 апр. 2015 г., at 18:34, Ken Thomases <ken(a)codeweavers.com> wrote: >>> >>>> Hi, >>>> >>>> This patch makes no sense. Wine builds just fine for OS X versions greater than 10.8. Indeed, as near as I know, it still builds just fine for 10.5 and up (the Mac driver requires 10.6 or later, but on 10.5 it just will be skipped; it won't break anything). >>>> >>>> On Apr 1, 2015, at 6:48 AM, Sergey Isakov <isakov-sl(a)bk.ru> wrote: >>>> >>>>> Undefined symbols for architecture i386: >>>>> "_kCGDisplayShowDuplicateLowResolutionModes", referenced from: >>>>> -[WineApplicationController modeMatchingMode:forDisplay:] in cocoa_app.o >>>>> ld: symbol(s) not found for architecture i386 >>>> >>>> If you're getting this error, you're not building against a 10.8+ SDK properly. The compiler is seeing the headers for a 10.8+ SDK but the linker is seeing libraries and frameworks from some pre-10.8 SDK. >>>> >>>> >>>>> Instead of checking for NULL we should check #ifdef >>>> >>>> No. The things being tested are not macros in any version of the SDK. Your #ifdef checks will never pass. You have effectively done "#if 0". >>>> >>>> Finally, changes to separate DLLs (secur32 and winemac.drv, in this case) should be in separate patches unless they are inter-dependent. >>>> >>>> -Ken >>>> >>> >> >

1 0

Re: [PATCH] vbscript: Fixed Hex(try 3)
by Marvin 02 Apr '15

02 Apr '15

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://testbot.winehq.org/JobDetails.pl?Key=12612 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === w2003std (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: [1/4] windowscodecs: Add test for PNG gAMA metadata.
by Vincent Povirk 02 Apr '15

02 Apr '15

I forgot to NULL-terminate a string, please ignore. On Wed, Apr 1, 2015 at 5:24 PM, Vincent Povirk <madewokherd(a)gmail.com> wrote: >

1 0

Re: [PATCH] findstr: Added test for findstr. (try 2)
by Kaipeng Zeng 02 Apr '15

02 Apr '15

Excuse me,can anyone have a look at this patch? I appreciate for any comment. Thanks！ 2015-03-24 13:55 GMT+08:00 Kaipeng Zeng <kaipeng94(a)gmail.com>: > Thanks Stefan! > > Superseded patch 110143 . > ChangeLog: > - Exclude change to configure > - Return exit code of findstr in runcmd() >

2 1

Re: [1/3] server: Implement job limit flags (try 2)
by Nikolay Sivov 02 Apr '15

02 Apr '15

On 02.04.2015 10:38, Andrew Cook wrote: > Changes in try 2: > - Removed the goto in SetInformationJobObject, ExtendedLimit will need its own > wineserver call eventually anyway I don't think you'll need a separate server call for extended info case. All fields should be enabled with flags, so you don't have to invent special values to ignore some limits. > + switch (class) > + { > + > + case JobObjectExtendedLimitInformation: > + if (len != sizeof(JOBOBJECT_EXTENDED_LIMIT_INFORMATION)) > + return STATUS_INVALID_PARAMETER; > + > + basic_limit = &(((JOBOBJECT_EXTENDED_LIMIT_INFORMATION *)info)->BasicLimitInformation); > + if (basic_limit->LimitFlags & ~JOB_OBJECT_EXTENDED_LIMIT_VALID_FLAGS) > + return STATUS_INVALID_PARAMETER; > + > + SERVER_START_REQ( job_set_limits ) > + { > + req->handle = wine_server_obj_handle( handle ); > + req->limit_flags = basic_limit->LimitFlags; > + status = wine_server_call( req ); > + } > + SERVER_END_REQ; > + break; This still looks strange, if you need only flags you can use switch() to prepare this flags value depending on info class, and handle invalid arguments same way you do know, no need to duplicate server calling block. Actually since extended info contains basic info you only need a switch() to test for invalid arguments, and you can cast unconditionally to JOBOBJECT_BASIC_LIMIT_INFORMATION* to get flags.

1 0

Re: [1/3] server: Implement job limit flags
by Alexandre Julliard 02 Apr '15

02 Apr '15

Andrew Cook <ariscop(a)gmail.com> writes: > + switch (class) > + { > + > + case JobObjectExtendedLimitInformation: > + if (len != sizeof(JOBOBJECT_EXTENDED_LIMIT_INFORMATION)) > + return STATUS_INVALID_PARAMETER; > + > + basic_limit = &(((JOBOBJECT_EXTENDED_LIMIT_INFORMATION *)info)->BasicLimitInformation); > + if (basic_limit->LimitFlags & ~JOB_OBJECT_EXTENDED_LIMIT_VALID_FLAGS) > + return STATUS_INVALID_PARAMETER; > + > + goto set_basic_limits; > + > + case JobObjectBasicLimitInformation: > + if (len != sizeof(JOBOBJECT_BASIC_LIMIT_INFORMATION)) > + return STATUS_INVALID_PARAMETER; > + > + basic_limit = info; > + if (basic_limit->LimitFlags & ~JOB_OBJECT_BASIC_LIMIT_VALID_FLAGS) > + return STATUS_INVALID_PARAMETER; > + > + set_basic_limits: > + SERVER_START_REQ( set_job_limits ) > + { > + req->handle = wine_server_obj_handle( handle ); > + req->limit_flags = basic_limit->LimitFlags; > + status = wine_server_call( req ); > + } > + SERVER_END_REQ; > + break; A goto target in the middle of a switch statement is not very nice, please try to find a better way. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: msctf: Always return FALSE in DllCanUnloadNow
by Sebastian Lackner 02 Apr '15

02 Apr '15

On 02.04.2015 03:34, Alistair Leslie-Hughes wrote: > Hi, > Fixes https://bugs.winehq.org/show_bug.cgi?id=31579 > > Changelog: > msctf: Always return FALSE in DllCanUnloadNow > > > Best Regards > Alistair Leslie-Hughes > > > I doubt that the patch has any real disadvantage, but wouldn't it be better to fix the refcounting instead of just removing this feature? Qian Hong even attached a suggested patch on the bugreport.

3 2

Re: comctl32/tests: Fix couple of metrics tests that fail on some systems (try 3)
by Marvin 02 Apr '15

02 Apr '15

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://testbot.winehq.org/JobDetails.pl?Key=12601 Your paranoid android. === wvistau64 (32 bit listview) === listview.c:5190: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5195: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w2008s64 (32 bit listview) === listview.c:5190: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5195: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w7u (32 bit listview) === listview.c:5190: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5195: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w2008s64 (64 bit listview) === listview.c:5190: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5195: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000

2 1

Re: [PATCH (try2)] gdiplus: Avoid unnecessary pre-multiplied alpha conversions in GdipDrawImagePointsRect
by Vincent Povirk 02 Apr '15

02 Apr '15

I think we also need resample_bitmap_pixel to be set up to handle PARGB. Nearest neighbor interpolation should work OK as is, but bilinear interpolation uses blend_colors which only works correctly for ARGB. (The implementation of blend_colors that we had before 9c579023f0750539bdf7815f8545c4620540387a should actually be correct for PARGB.) On Wed, Apr 1, 2015 at 11:38 AM, Andrew Eikum <aeikum(a)codeweavers.com> wrote: > Not all of the operations we perform in the DrawImage family need to > be post-multiplied. We can avoid doing a pre-to-post-multiplied alpha > conversion by detecting whether we need post-multiplied ahead of time. > Avoiding this conversion saves considerable time, about 3/1000s in my > particular test case. > > --- > > try2: Fix return value from color_over_fgpremult > > dlls/gdiplus/gdiplus_private.h | 20 +++++++++++++ > dlls/gdiplus/graphics.c | 66 ++++++++++++++++++++++++++++-------------- > 2 files changed, 65 insertions(+), 21 deletions(-) > > diff --git a/dlls/gdiplus/gdiplus_private.h b/dlls/gdiplus/gdiplus_private.h > index 065f5ed..57b3de3 100644 > --- a/dlls/gdiplus/gdiplus_private.h > +++ b/dlls/gdiplus/gdiplus_private.h > @@ -121,6 +121,26 @@ static inline ARGB color_over(ARGB bg, ARGB fg) > return (a<<24)|(r<<16)|(g<<8)|b; > } > > +/* fg is premult, bg and return value are not */ > +static inline ARGB color_over_fgpremult(ARGB bg, ARGB fg) > +{ > + BYTE b, g, r, a; > + BYTE bg_alpha, fg_alpha; > + > + fg_alpha = (fg>>24)&0xff; > + > + if (fg_alpha == 0) return bg; > + > + bg_alpha = (((bg>>24)&0xff) * (0xff-fg_alpha)) / 0xff; > + > + a = bg_alpha + fg_alpha; > + b = ((bg&0xff)*bg_alpha + (fg&0xff)*0xff)/a; > + g = (((bg>>8)&0xff)*bg_alpha + ((fg>>8)&0xff)*0xff)/a; > + r = (((bg>>16)&0xff)*bg_alpha + ((fg>>16)&0xff)*0xff)/a; > + > + return (a<<24)|(r<<16)|(g<<8)|b; > +} > + > extern const char *debugstr_rectf(const RectF* rc) DECLSPEC_HIDDEN; > > extern const char *debugstr_pointf(const PointF* pt) DECLSPEC_HIDDEN; > diff --git a/dlls/gdiplus/graphics.c b/dlls/gdiplus/graphics.c > index 580390f..89c108e 100644 > --- a/dlls/gdiplus/graphics.c > +++ b/dlls/gdiplus/graphics.c > @@ -354,9 +354,9 @@ static GpStatus get_clip_hrgn(GpGraphics *graphics, HRGN *hrgn) > return GdipGetRegionHRgn(graphics->clip, NULL, hrgn); > } > > -/* Draw non-premultiplied ARGB data to the given graphics object */ > +/* Draw ARGB data to the given graphics object */ > static GpStatus alpha_blend_bmp_pixels(GpGraphics *graphics, INT dst_x, INT dst_y, > - const BYTE *src, INT src_width, INT src_height, INT src_stride) > + const BYTE *src, INT src_width, INT src_height, INT src_stride, const PixelFormat fmt) > { > GpBitmap *dst_bitmap = (GpBitmap*)graphics->image; > INT x, y; > @@ -372,7 +372,10 @@ static GpStatus alpha_blend_bmp_pixels(GpGraphics *graphics, INT dst_x, INT dst_ > continue; > > GdipBitmapGetPixel(dst_bitmap, x+dst_x, y+dst_y, &dst_color); > - GdipBitmapSetPixel(dst_bitmap, x+dst_x, y+dst_y, color_over(dst_color, src_color)); > + if (fmt & PixelFormatPAlpha) > + GdipBitmapSetPixel(dst_bitmap, x+dst_x, y+dst_y, color_over_fgpremult(dst_color, src_color)); > + else > + GdipBitmapSetPixel(dst_bitmap, x+dst_x, y+dst_y, color_over(dst_color, src_color)); > } > } > > @@ -380,7 +383,7 @@ static GpStatus alpha_blend_bmp_pixels(GpGraphics *graphics, INT dst_x, INT dst_ > } > > static GpStatus alpha_blend_hdc_pixels(GpGraphics *graphics, INT dst_x, INT dst_y, > - const BYTE *src, INT src_width, INT src_height, INT src_stride) > + const BYTE *src, INT src_width, INT src_height, INT src_stride, PixelFormat fmt) > { > HDC hdc; > HBITMAP hbitmap; > @@ -404,7 +407,8 @@ static GpStatus alpha_blend_hdc_pixels(GpGraphics *graphics, INT dst_x, INT dst_ > hbitmap = CreateDIBSection(hdc, (BITMAPINFO*)&bih, DIB_RGB_COLORS, > (void**)&temp_bits, NULL, 0); > > - if (GetDeviceCaps(graphics->hdc, SHADEBLENDCAPS) == SB_NONE) > + if (GetDeviceCaps(graphics->hdc, SHADEBLENDCAPS) == SB_NONE || > + fmt & PixelFormatPAlpha) > memcpy(temp_bits, src, src_width * src_height * 4); > else > convert_32bppARGB_to_32bppPARGB(src_width, src_height, temp_bits, > @@ -420,7 +424,7 @@ static GpStatus alpha_blend_hdc_pixels(GpGraphics *graphics, INT dst_x, INT dst_ > } > > static GpStatus alpha_blend_pixels_hrgn(GpGraphics *graphics, INT dst_x, INT dst_y, > - const BYTE *src, INT src_width, INT src_height, INT src_stride, HRGN hregion) > + const BYTE *src, INT src_width, INT src_height, INT src_stride, HRGN hregion, PixelFormat fmt) > { > GpStatus stat=Ok; > > @@ -470,7 +474,7 @@ static GpStatus alpha_blend_pixels_hrgn(GpGraphics *graphics, INT dst_x, INT dst > stat = alpha_blend_bmp_pixels(graphics, rects[i].left, rects[i].top, > &src[(rects[i].left - dst_x) * 4 + (rects[i].top - dst_y) * src_stride], > rects[i].right - rects[i].left, rects[i].bottom - rects[i].top, > - src_stride); > + src_stride, fmt); > } > > GdipFree(rgndata); > @@ -503,7 +507,7 @@ static GpStatus alpha_blend_pixels_hrgn(GpGraphics *graphics, INT dst_x, INT dst > ExtSelectClipRgn(graphics->hdc, hregion, RGN_AND); > > stat = alpha_blend_hdc_pixels(graphics, dst_x, dst_y, src, src_width, > - src_height, src_stride); > + src_height, src_stride, fmt); > > RestoreDC(graphics->hdc, save); > > @@ -514,9 +518,9 @@ static GpStatus alpha_blend_pixels_hrgn(GpGraphics *graphics, INT dst_x, INT dst > } > > static GpStatus alpha_blend_pixels(GpGraphics *graphics, INT dst_x, INT dst_y, > - const BYTE *src, INT src_width, INT src_height, INT src_stride) > + const BYTE *src, INT src_width, INT src_height, INT src_stride, PixelFormat fmt) > { > - return alpha_blend_pixels_hrgn(graphics, dst_x, dst_y, src, src_width, src_height, src_stride, NULL); > + return alpha_blend_pixels_hrgn(graphics, dst_x, dst_y, src, src_width, src_height, src_stride, NULL, fmt); > } > > static ARGB blend_colors(ARGB start, ARGB end, REAL position) > @@ -656,8 +660,9 @@ static BOOL color_is_gray(ARGB color) > return (r == g) && (g == b); > } > > -static void apply_image_attributes(const GpImageAttributes *attributes, LPBYTE data, > - UINT width, UINT height, INT stride, ColorAdjustType type) > +/* returns preferred pixel format for the applied attributes */ > +static PixelFormat apply_image_attributes(const GpImageAttributes *attributes, LPBYTE data, > + UINT width, UINT height, INT stride, ColorAdjustType type, PixelFormat fmt) > { > UINT x, y; > INT i; > @@ -669,6 +674,9 @@ static void apply_image_attributes(const GpImageAttributes *attributes, LPBYTE d > BYTE min_blue, min_green, min_red; > BYTE max_blue, max_green, max_red; > > + if (!data || fmt != PixelFormat32bppARGB) > + return PixelFormat32bppARGB; > + > if (attributes->colorkeys[type].enabled) > key = &attributes->colorkeys[type]; > else > @@ -702,6 +710,9 @@ static void apply_image_attributes(const GpImageAttributes *attributes, LPBYTE d > { > const struct color_remap_table *table; > > + if (!data || fmt != PixelFormat32bppARGB) > + return PixelFormat32bppARGB; > + > if (attributes->colorremaptables[type].enabled) > table = &attributes->colorremaptables[type]; > else > @@ -731,6 +742,9 @@ static void apply_image_attributes(const GpImageAttributes *attributes, LPBYTE d > int gray_matrix[5][5]; > BOOL identity; > > + if (!data || fmt != PixelFormat32bppARGB) > + return PixelFormat32bppARGB; > + > if (attributes->colormatrices[type].enabled) > colormatrices = &attributes->colormatrices[type]; > else > @@ -769,6 +783,9 @@ static void apply_image_attributes(const GpImageAttributes *attributes, LPBYTE d > { > REAL gamma; > > + if (!data || fmt != PixelFormat32bppARGB) > + return PixelFormat32bppARGB; > + > if (attributes->gamma_enabled[type]) > gamma = attributes->gamma[type]; > else > @@ -793,6 +810,8 @@ static void apply_image_attributes(const GpImageAttributes *attributes, LPBYTE d > *src_color = (*src_color & 0xff000000) | (red << 16) | (green << 8) | blue; > } > } > + > + return fmt; > } > > /* Given a bitmap and its source rectangle, find the smallest rectangle in the > @@ -1237,7 +1256,7 @@ static GpStatus brush_fill_pixels(GpGraphics *graphics, GpBrush *brush, > if (stat == Ok) > apply_image_attributes(fill->imageattributes, fill->bitmap_bits, > bitmap->width, bitmap->height, > - src_stride, ColorAdjustTypeBitmap); > + src_stride, ColorAdjustTypeBitmap, lockeddata.PixelFormat); > > if (stat != Ok) > { > @@ -2990,15 +3009,18 @@ GpStatus WINGDIPAPI GdipDrawImagePointsRect(GpGraphics *graphics, GpImage *image > return OutOfMemory; > src_stride = sizeof(ARGB) * src_area.Width; > > - /* Read the bits we need from the source bitmap into an ARGB buffer. */ > + /* Read the bits we need from the source bitmap into a compatible buffer. */ > lockeddata.Width = src_area.Width; > lockeddata.Height = src_area.Height; > lockeddata.Stride = src_stride; > - lockeddata.PixelFormat = PixelFormat32bppARGB; > lockeddata.Scan0 = src_data; > + if (bitmap->format == PixelFormat32bppPARGB) > + lockeddata.PixelFormat = apply_image_attributes(imageAttributes, NULL, 0, 0, 0, ColorAdjustTypeBitmap, bitmap->format); > + else > + lockeddata.PixelFormat = PixelFormat32bppARGB; > > stat = GdipBitmapLockBits(bitmap, &src_area, ImageLockModeRead|ImageLockModeUserInputBuf, > - PixelFormat32bppARGB, &lockeddata); > + lockeddata.PixelFormat, &lockeddata); > > if (stat == Ok) > stat = GdipBitmapUnlockBits(bitmap, &lockeddata); > @@ -3011,7 +3033,7 @@ GpStatus WINGDIPAPI GdipDrawImagePointsRect(GpGraphics *graphics, GpImage *image > > apply_image_attributes(imageAttributes, src_data, > src_area.Width, src_area.Height, > - src_stride, ColorAdjustTypeBitmap); > + src_stride, ColorAdjustTypeBitmap, lockeddata.PixelFormat); > > if (do_resampling) > { > @@ -3059,7 +3081,8 @@ GpStatus WINGDIPAPI GdipDrawImagePointsRect(GpGraphics *graphics, GpImage *image > } > > stat = alpha_blend_pixels(graphics, dst_area.left, dst_area.top, > - dst_data, dst_area.right - dst_area.left, dst_area.bottom - dst_area.top, dst_stride); > + dst_data, dst_area.right - dst_area.left, dst_area.bottom - dst_area.top, dst_stride, > + lockeddata.PixelFormat); > > GdipFree(src_data); > > @@ -4009,7 +4032,8 @@ static GpStatus SOFTWARE_GdipFillRegion(GpGraphics *graphics, GpBrush *brush, > if (stat == Ok) > stat = alpha_blend_pixels_hrgn(graphics, gp_bound_rect.X, > gp_bound_rect.Y, (BYTE*)pixel_data, gp_bound_rect.Width, > - gp_bound_rect.Height, gp_bound_rect.Width * 4, hregion); > + gp_bound_rect.Height, gp_bound_rect.Width * 4, hregion, > + PixelFormat32bppARGB); > > GdipFree(pixel_data); > } > @@ -5811,7 +5835,7 @@ GpStatus WINGDIPAPI GdipReleaseDC(GpGraphics *graphics, HDC hdc) > /* Write the changed pixels to the real target. */ > alpha_blend_pixels(graphics, 0, 0, graphics->temp_bits, > graphics->temp_hbitmap_width, graphics->temp_hbitmap_height, > - graphics->temp_hbitmap_width * 4); > + graphics->temp_hbitmap_width * 4, PixelFormat32bppARGB); > > /* Clean up. */ > DeleteDC(graphics->temp_hdc); > @@ -6366,7 +6390,7 @@ static GpStatus SOFTWARE_GdipDrawDriverString(GpGraphics *graphics, GDIPCONST UI > > /* draw the result */ > stat = alpha_blend_pixels(graphics, min_x, min_y, pixel_data, pixel_area.Width, > - pixel_area.Height, pixel_data_stride); > + pixel_area.Height, pixel_data_stride, PixelFormat32bppARGB); > > GdipFree(pixel_data); > > -- > 2.3.5 > > >

1 1

Re: [PATCH 4/4] d3drm/tests: Add tests to compare vtables for frame{1-3}, object and visual
by Stefan Dösinger 01 Apr '15

01 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-04-01 um 18:15 schrieb Aaryaman Vasishta: > +struct vtable_test > +{ > + REFIID iid; > + BOOL equal; > + BOOL todo; > +}; You should be able to integrate this into the existing qi test table, similar to how the refcount_iid field works. If you need more than one TODO field (e.g. one for refcount_iid and one for vtable inheritance) use flags. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVHHR+AAoJEN0/YqbEcdMwNa4P/08HSs3DE722aHW2nyx0Zfs1 KPeEn3yqm32PUrBbFs8gptp5+KxKqpsd7mzN3OgHxx+ipRCbcSrVEFhMYuels/Sl YX8rYrpGam+kKOSBOV8mnwjR1Fc9K3KDi5vyODmi4hFWb+gWArtONOVTm8HQwk/P S339yQDjsRArCugbVywmAMEi8J4ImTvuG102vZIyHFysmPG9CQQ5ndE7naE+B58s MJ557ErCWtDdazOis3CtFFVe1jBvwcZyfKi+6LSTyhVxVOiP3Mc84k+5cdT7929u UzXlHkJlS7qxAjxHz0gF1gdvCS/jlUQV5pGNrwoLg4FQEY7I5jPqR8QkseccygYC bHH/JaNfFcaELF5OTkyJCCH0Xa7hAPSWk8/RRcutzboe2s6n3SRUXuM9lAE9tBZL lopYNRYqb7wuxMFzdsRD5MG9zyqOGdg1dx/t75WMcniD36g65CDHkTaIRDX1nrCE 4ZTBhmXoAQxz60nrMHbZDye9rxTd1+RPvs45X9BOFpolfUAJt6luX8+ib0v5myMf qL8QzYT+lsNiFtZMwGrSRb3Wj4nm+KWeH2E8WBx3oYrQZe1LWFH6ZlkyTRamEKDY ooC8tNxrhOqQOV5eD8+Y3DDN+jE6jI53vpC3RAUMUtHXYrYHLiwKKpgyCjXU/vBi Ym2oC3yNbzOon0NQZ9UR =E3pj -----END PGP SIGNATURE-----

1 0

Re: [PATCH] uxtheme: Load MUI file when theme loaded.
by Nikolay Sivov 01 Apr '15

01 Apr '15

On 04/02/2015 12:00 AM, Mark Harmstone wrote: > Version 4 uxthemes, as used in Vista and above, are split over two files - the > msstyles file, and a language-dependent MUI file storing the theme's name, the > fonts it uses, etc. In preparation for v4 support, this patch adds MUI loading > to uxtheme. > > --- > dlls/uxtheme/msstyles.c | 98 ++++++++++++++++++++++++++++++++++++++++++++++++- > dlls/uxtheme/msstyles.h | 1 + > 2 files changed, 98 insertions(+), 1 deletion(-) > Path resolution you've implemented looks very similar to what GetFileMUIPath() is supposed to return. It would be great to have it at least partially implemented instead of potentially duplicating it. It'd be perfectly fine if you implement only subset of flags that you'll actually need for uxtheme.

1 0

Re: comctl32/tests: Fix couple of metrics tests that fail on some systems (try2)
by Marvin 01 Apr '15

01 Apr '15

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://testbot.winehq.org/JobDetails.pl?Key=12597 Your paranoid android. === w2008s64 (32 bit listview) === listview.c:5190: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5195: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w7u (32 bit listview) === listview.c:3933: Test failed: got right 112, bottom 19 listview.c:5190: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5195: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w2008s64 (64 bit listview) === listview.c:5190: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5195: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000

1 0

Re: d3dx9_36: Add D3DXFrameFind stub.
by Nikolay Sivov 01 Apr '15

01 Apr '15

On 04/01/2015 08:59 PM, Andrey Gusev wrote: > Fixes https://bugs.winehq.org/show_bug.cgi?id=38334 > > Thanks to Matteo Bruni for valuable help. > > +D3DXFRAME * WINAPI D3DXFrameFind(const D3DXFRAME *frame_root, const char *name) > +{ > + FIXME("frame_root %p, name %s stub.\n", frame_root, debugstr_a(name)); > + > + return NULL; > +} > + If it's just a matter of searching for a name in a tree, I think it's better to add actual implementation instead of a stub.

1 0

Re: [PATCH] undefined symbols compiling for macosx >10.8
by Ken Thomases 01 Apr '15

01 Apr '15

If you were having problems building Wine without this patch, then you have a system configuration problem. Or you're configuring Wine incorrectly. -Ken On Apr 1, 2015, at 11:52 AM, Sergey Isakov <isakov-sl(a)bk.ru> wrote: > Sorry but I committed the patch make me compilation be possible. > > On 01 апр. 2015 г., at 18:34, Ken Thomases <ken(a)codeweavers.com> wrote: > >> Hi, >> >> This patch makes no sense. Wine builds just fine for OS X versions greater than 10.8. Indeed, as near as I know, it still builds just fine for 10.5 and up (the Mac driver requires 10.6 or later, but on 10.5 it just will be skipped; it won't break anything). >> >> On Apr 1, 2015, at 6:48 AM, Sergey Isakov <isakov-sl(a)bk.ru> wrote: >> >>> Undefined symbols for architecture i386: >>> "_kCGDisplayShowDuplicateLowResolutionModes", referenced from: >>> -[WineApplicationController modeMatchingMode:forDisplay:] in cocoa_app.o >>> ld: symbol(s) not found for architecture i386 >> >> If you're getting this error, you're not building against a 10.8+ SDK properly. The compiler is seeing the headers for a 10.8+ SDK but the linker is seeing libraries and frameworks from some pre-10.8 SDK. >> >> >>> Instead of checking for NULL we should check #ifdef >> >> No. The things being tested are not macros in any version of the SDK. Your #ifdef checks will never pass. You have effectively done "#if 0". >> >> Finally, changes to separate DLLs (secur32 and winemac.drv, in this case) should be in separate patches unless they are inter-dependent. >> >> -Ken >> >

1 0

Re: [PATCH 3/4] d3drm/tests: Split tests seperately for IDirect3DRM{1-3} interfaces
by Stefan Dösinger 01 Apr '15

01 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-04-01 um 18:15 schrieb Aaryaman Vasishta: > +++ b/dlls/d3drm/tests/d3drm.c > @@ -1841,6 +1841,104 @@ static void test_d3drm_qi(void) > IDirect3DRM_Release(d3drm); > } > > +static void test_frame_qi(void) > +{ There's no need to add this to d3drm.c and d3drm3.c. The versions in d3drm1.c, d3drm2.c and d3drm3.c are enough. Ideally d3drm.c will go away at some point. > + hr = Direct3DRMCreate(&d3drm); > + ok(hr == D3DRM_OK, "Cannot get IDirect3DRM interface (hr = %x)\n", hr); > + > + test_qi("d3drm_qi", (IUnknown *)d3drm, &IID_IDirect3DRM, tests, sizeof(tests) / sizeof(*tests)); > + > + IDirect3DRM_Release(d3drm); This test is version independent because there is only one way to create the d3drm object. You can just keep it in d3drm.c for now, or move it to d3drm1.c in a separate patch if you want. > --- a/dlls/d3drm/tests/Makefile.in > +++ b/dlls/d3drm/tests/Makefile.in > @@ -2,4 +2,7 @@ TESTDLL = d3drm.dll > IMPORTS = d3drm dxguid ddraw user32 uuid > C_SRCS = \ > d3drm.c \ > + d3drm1.c \ > + d3drm2.c \ > + d3drm3.c \ > vector.c This doesn't match the Makefile.in file I have. You have a reordered IMPORTS line. This is why the testbot failed. Do you have other patches in your tree? > +* Copyright 2012 Andr� Hentschel This shows up wrong in my mail client. It may be a setup issue on my side. It shows up OK on http://source.winehq.org/patches/data/110484 when viewed with the browser, but if I download the patch with wget it is broken as well. Please make sure your text editor is configured to save the files as UTF8. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVHCwnAAoJEN0/YqbEcdMwqsMP/1pigFRsvxOMAYpIHbPoQzda rnKNX4egG04IFvrlObvEVNm6GUW02hgm7SB5+UcdCkXclbGbDjxW0R8M4RqoYOHs swdSxFIZX9s/wPqHJOv33oK8TDPKYUX2SwXyhyOEN7rh3LKJF4DeYGP0uW+wSMed bCXeJ9bx3X55cAGMJhP9jVdcq8ADTh8z0sYANHLBkD80OCac+KxFMmsGrxUD2e2H l6ATINj9BKlgAYGbFnoweNkiv4+O9y6zXBgOQu8Df6Jlr+mu86Jv0zi5S7MHEj4h tWwNyNyaDjTIUlfMdF3cCrKDhLhgYuuwQqij/iAdrEcGFEFn+QKeX0THCGwLeto8 nzwmEZFKYT2keJsMoHQ5tf0U6tT0xedsOjHHTHg/cg1BBj7ogtJ0YcEaxIYtF7uP 47tkjEL9iKXaN7bfdugH1D4buvufUzlZYIvehdbyNcWs3/HYHdiBAbER1ah3yAn9 TlpYdHpZstimuDkMMMLCExW/nlnGZlxz+orF9RNMm/SowtAe1aMVGGHMS5+6ZBfb 4z85+OWG8bR9D+e7+OeOYr/3Z62wiKLppRVQiJ4NgrGgv4ex2rIjqkiKBTEgSZm7 WTptfVrMCQ8zHEpos8iZHZOcoOLVFX4ylQaNNXmssGtwcLqH/P8o7KAk3o6RO+g0 qlkMVFMPEn7fE9h8WJfj =Jeuf -----END PGP SIGNATURE-----

3 3

Re: [PATCH 4/4] d3drm/tests: Add tests to compare vtables for frame{1-3}, object and visual
by Marvin 01 Apr '15

01 Apr '15

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://testbot.winehq.org/JobDetails.pl?Key=12593 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 3/4] d3drm/tests: Split tests seperately for IDirect3DRM{1-3} interfaces
by Marvin 01 Apr '15

01 Apr '15

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://testbot.winehq.org/JobDetails.pl?Key=12592 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH] undefined symbols compiling for macosx >10.8
by Ken Thomases 01 Apr '15

01 Apr '15

Hi, This patch makes no sense. Wine builds just fine for OS X versions greater than 10.8. Indeed, as near as I know, it still builds just fine for 10.5 and up (the Mac driver requires 10.6 or later, but on 10.5 it just will be skipped; it won't break anything). On Apr 1, 2015, at 6:48 AM, Sergey Isakov <isakov-sl(a)bk.ru> wrote: > Undefined symbols for architecture i386: > "_kCGDisplayShowDuplicateLowResolutionModes", referenced from: > -[WineApplicationController modeMatchingMode:forDisplay:] in cocoa_app.o > ld: symbol(s) not found for architecture i386 If you're getting this error, you're not building against a 10.8+ SDK properly. The compiler is seeing the headers for a 10.8+ SDK but the linker is seeing libraries and frameworks from some pre-10.8 SDK. > Instead of checking for NULL we should check #ifdef No. The things being tested are not macros in any version of the SDK. Your #ifdef checks will never pass. You have effectively done "#if 0". Finally, changes to separate DLLs (secur32 and winemac.drv, in this case) should be in separate patches unless they are inter-dependent. -Ken

1 0

Re: [PATCH] vbscript: Implemented Oct(try 4)
by Marvin 01 Apr '15

01 Apr '15

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://testbot.winehq.org/JobDetails.pl?Key=12481 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === w2003std (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

3 2

Wine on Javascript
by Zhenbo Li 01 Apr '15

01 Apr '15

Hi All, I'm came up with this idea since last year, and I'm glad to share this idea to you today. We tried to compile wine with clang[1], and most of the blocks have been fixed[2]. I tried it on my computer, and wine was built successfully, but `make test` failed.' I think wine+clang would work fine soon. Besides, the JavaScript engines are improving, for example, Google V8[3], and we can expect a better performance[4]. Now, let's connect them: Why not run wine's IR with a JavaScript engine?[5] At least, we have such benefits: 1. We can offer a online demo for wine 2. Wine can work on portable devices 3. Wine user can use the same prefix on different devices 4. We can have a better backend[6] This is my humble idea. I'm looking forward to your reply. [1]: http://wiki.winehq.org/Clang [2]: https://llvm.org/bugs/show_bug.cgi?id=10638 [3]: https://code.google.com/p/v8/ [4]: http://arewefastyet.com/ [5]: http://kripken.github.io/emscripten-site/ [6]: https://software.intel.com/en-us/articles/graphics-acceleration-for-html5-a… -- Have a nice (April Fool) day! Zhenbo Li

3 2

Re: [PATCH] vbscript: Fixed Hex(try 2)
by Marvin 01 Apr '15

01 Apr '15

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://testbot.winehq.org/JobDetails.pl?Key=12560 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === w2003std (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

3 2

Re: [1/6] kernel32/tests: Extend IsProcessInJob tests (try 2)
by Marvin 01 Apr '15

01 Apr '15

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://testbot.winehq.org/JobDetails.pl?Key=12559 Your paranoid android. === w7u (32 bit process) === prprocess.c:2496: Test failed: WaitForSingleObject returned 258

1 0

Re: [4/6] ntdll: Implement IsProcessInJob
by Marvin 01 Apr '15

01 Apr '15

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://testbot.winehq.org/JobDetails.pl?Key=12555 Your paranoid android. === w7u (32 bit process) === process.c:2274: Test failed: WaitForSingleObject returned 258 process.c:2278: Test failed: AssignProcessToJobObject unexpectedly succeeded process.c:2279: Test failed: Expected GetLastError() to be 5 (ERROR_ACCESS_DENIED) is -559038737

1 0

Re: [PATCH 4/4] d3drm/tests: Add QueryInterface tests for IDirect3DRMFrame3
by Aaryaman Vasishta 31 Mar '15

31 Mar '15

The tests also pass when the frame is created via IDirect3DRM_CreateFrame and IDirect3DRM2_CreateFrame. On Tue, Mar 31, 2015 at 1:36 AM, Aaryaman Vasishta < jem456.vasishta(a)gmail.com> wrote: > --- > dlls/d3drm/tests/d3drm.c | 99 > ++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 99 insertions(+) > > diff --git a/dlls/d3drm/tests/d3drm.c b/dlls/d3drm/tests/d3drm.c > index 515aace..6029b1a 100644 > --- a/dlls/d3drm/tests/d3drm.c > +++ b/dlls/d3drm/tests/d3drm.c > @@ -1841,6 +1841,104 @@ static void test_d3drm_qi(void) > IDirect3DRM_Release(d3drm); > } > > +static void test_frame_qi(void) > +{ > + static const struct qi_test tests[] = > + { > + { &IID_IDirect3DRMFrame3, &IID_IDirect3DRMFrame3, S_OK, > FALSE }, > + { &IID_IDirect3DRMFrame2, &IID_IDirect3DRMFrame3, S_OK, > FALSE }, > + { &IID_IDirect3DRMFrame, &IID_IDirect3DRMFrame3, S_OK, > FALSE }, > + { &IID_IDirect3DRM, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMDevice, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMObject, &IID_IDirect3DRMFrame3, S_OK, > FALSE }, > + { &IID_IDirect3DRMDevice2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMDevice3, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMViewport, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMViewport2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRM3, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRM2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMVisual, &IID_IDirect3DRMFrame3, S_OK, > FALSE }, > + { &IID_IDirect3DRMMesh, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMMeshBuilder, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMMeshBuilder2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMMeshBuilder3, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMFace, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMFace2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMLight, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMTexture, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMTexture2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMTexture3, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMWrap, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMMaterial, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMMaterial2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMAnimation, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMAnimation2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMAnimationSet, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMAnimationSet2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMObjectArray, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMDeviceArray, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMViewportArray, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMFrameArray, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMVisualArray, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMLightArray, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMPickedArray, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMFaceArray, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMAnimationArray, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMUserVisual, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMShadow, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMShadow2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMInterpolator, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMProgressiveMesh, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMPicked2Array, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMClippedVisual, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirectDrawClipper, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirectDrawSurface7, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirectDrawSurface4, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirectDrawSurface3, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirectDrawSurface2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirectDrawSurface, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DDevice7, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DDevice3, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DDevice2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DDevice, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3D7, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3D3, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3D2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3D, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirectDraw7, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirectDraw4, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirectDraw3, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirectDraw2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirectDraw, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DLight, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IUnknown, &IID_IDirect3DRMFrame3, S_OK, > FALSE }, > + }; > + HRESULT hr; > + IDirect3DRM *d3drm; > + IDirect3DRM3 *d3drm3; > + IDirect3DRMFrame3 *frame3; > + > + hr = Direct3DRMCreate(&d3drm); > + ok(hr == D3DRM_OK, "Cannot get IDirect3DRM interface (hr = %x)\n", > hr); > + > + if (FAILED(hr = IDirect3DRM_QueryInterface(d3drm, &IID_IDirect3DRM3, > (void **)&d3drm3))) > + { > + win_skip("Cannot get IDirect3DRM3 interface (hr = %x), skipping > tests\n", hr); > + IDirect3DRM_Release(d3drm); > + return; > + } > + > + hr = IDirect3DRM3_CreateFrame(d3drm3, NULL, &frame3); > + ok(hr == D3DRM_OK, "Cannot get IDirect3DRMFrame3 interface (hr = > %x)\n", hr); > + CHECK_REFCOUNT(frame3, 1); > + > + test_qi("frame_qi", (IUnknown *)frame3, &IID_IDirect3DRMFrame3, > tests, sizeof(tests) / sizeof(*tests)); > + > + IDirect3DRMFrame3_Release(frame3); > + IDirect3DRM3_Release(d3drm3); > + IDirect3DRM_Release(d3drm); > +} > + > START_TEST(d3drm) > { > test_MeshBuilder(); > @@ -1857,4 +1955,5 @@ START_TEST(d3drm) > test_d3drm_load(); > test_frame_mesh_materials(); > test_d3drm_qi(); > + test_frame_qi(); > } > -- > 1.9.3 (Apple Git-50) > >

2 2

Re: [PATCH] comctl32: Handle BM_SETSTATE sent to themed buttons.
by Nikolay Sivov 31 Mar '15

31 Mar '15

On 03/31/2015 10:45 PM, Mark Harmstone wrote: > This patch changes comctl32 to handle BM_SETSTATE itself when sent to > a themed button, rather than forwarding it to user32. This way, the > theming isn't temporarily lost when user32 repaints it. > > + case BM_SETSTATE: > + { > + int state = (int)SendMessageW(hwnd, BM_GETSTATE, 0, 0); > + if (wParam) > + SetWindowLongW(hwnd, 0, state | BST_PUSHED); > + else > + SetWindowLongW(hwnd, 0, state & ~BST_PUSHED); > + > + InvalidateRect(hwnd, NULL, FALSE); > + break; > + } > + I guess you can GetWindowLongW(...,0,...) instead of sending a message? But what's more important is that all these difference in behavior comparing to user32 controls should not be visible only when you have an active theme. It's actually another version of same Button control with additional messages and different behavior in some aspects, including theming-aware drawing. So my point is that theming support is secondary, what's important is class redirection support, and I'm worried if these theming-only changes will make it more difficult to fix properly later. P.S. 0 window data index is actually implementation details of user32 (I don't know if it's compatible with native one with that regard or not).

1 0

Re: gdiplus/tests: Use printf() for memory dumps instead of trace(). (try 2)
by Thomas Faber 31 Mar '15

31 Mar '15

On 2015-03-29 12:29, Thomas Faber wrote: > trace is unsuitable since it adds a file:line prefix every time. Is there a preferred way to handle this instead of using printf? Or is this simply a case that seems pointless to fix because tests should never fail anyway (in which case a patch to remove these dumps completely might make sense)? Thanks! -Thomas PS: Here's what I see with trace(), which was my reasoning for the patch: image.c:4241: Test marked todo: 16: data should match image.c:4249: 40image.c:4249: 40image.c:4249: 40image.c:4249: 40image.c:4249: 40image.c:4249: 40image.c:4249: 80image.c:4249: 80image.c:4249: 80image.c:4249: 80image.c:4249: 80image.c:4249: 80image.c:4249: 40image.c:4249: 40image.c:4249: 40image.c:4249: 40image.c:4249: 40image.c:4249: 40image.c:4249: 40image.c:4249: 40image.c:4249: 40image.c:4249: 40image.c:4249: 40image.c:4249: 40image.c:4250:

2 1

Re: [PATCH] gdiplus: Avoid unnecessary post-to-pre-multiplied alpha conversions in GdipDrawImagePointsRect
by Vincent Povirk 31 Mar '15

31 Mar '15

On Tue, Mar 31, 2015 at 9:05 AM, Andrew Eikum <aeikum(a)codeweavers.com> wrote: > + if (bg_alpha == 0) return fg; This doesn't seem right. Foreground is premultiplied, but we expect the result to not be premultiplied.

1 0

Re: [PATCH 6/7] ddraw/tests: Add more d3d7 lighting tests.
by Henri Verbeet 31 Mar '15

31 Mar '15

On 30 March 2015 at 20:18, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + static WORD Indices[] = {0, 1, 2, 2, 3, 0}; You have a typo here. :)

2 1

Re: [PATCH 1/7] ddraw: D3DLIGHT lights default to active.
by Henri Verbeet 31 Mar '15

31 Mar '15

On 30 March 2015 at 20:18, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > @@ -184,7 +184,7 @@ static HRESULT WINAPI d3d_light_SetLight(IDirect3DLight *iface, D3DLIGHT *data) > - if (data->dwSize >= sizeof(D3DLIGHT2) && (((D3DLIGHT2 *)data)->dwFlags & D3DLIGHT_NO_SPECULAR)) > + if (!(flags & D3DLIGHT_NO_SPECULAR)) > light7->dcvSpecular = data->dcvColor; > else > light7->dcvSpecular = *(const D3DCOLORVALUE *)zero_value; I'm not holding this against the patch too much because it's ddraw, but I think "if (flags & D3DLIGHT_NO_SPECULAR)" and then flipping the branches reads a bit nicer. If the declaration of "zero_value" is fixed you can avoid the cast as well. > @@ -200,9 +200,10 @@ static HRESULT WINAPI d3d_light_SetLight(IDirect3DLight *iface, D3DLIGHT *data) > + memcpy(&light->light, data, sizeof(D3DLIGHT)); There's something to be said for "sizeof(D3DLIGHT)" here, although I don't think "sizeof(*data)" would have been worse.

2 1

Re: [3/3] kernel32: force 4096 byte page alignment (resend)
by Alexandre Julliard 31 Mar '15

31 Mar '15

David Naylor <dbn(a)freebsd.org> writes: > FreeBSD prefers to use a 0x200000 (super) page alignment however this causes > the image base to be displaced from the requested 0x7b800000. Forcing a > smaller page size ensures FreeBSD can place the image startin at 0x7b800000. This would have to be done in winegcc, with appropriate configure checks. It's probably easier to change the address to leave more room. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: comctl32/tests: Fix couple of metrics tests that fail on some systems
by Dmitry Timoshkov 31 Mar '15

31 Mar '15

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > + /* estimate using stock font metrics */ > + hdc = GetDC(0); > + hOldFont = SelectObject(hdc, GetStockObject (SYSTEM_FONT)); > + GetTextMetricsA(hdc, &tm); > + SelectObject(hdc, hOldFont); > + ReleaseDC(0, hdc); Probably DEFAULT_GUI_FONT should be used instead of SYSTEM, you really don't want to see SYSTEM_FONT on the screen, or just use its metrics. -- Dmitry.

2 1

Re: comctl32/tests: Fix couple of metrics tests that fail on some systems
by Marvin 31 Mar '15

31 Mar '15

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://testbot.winehq.org/JobDetails.pl?Key=12538 Your paranoid android. === w2003std (32 bit listview) === listview.c:5151: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5156: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w7u (32 bit listview) === listview.c:3914: Test failed: got right 112, bottom 19 listview.c:5151: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5156: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w8 (32 bit listview) === listview.c:5151: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5156: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w2008s64 (64 bit listview) === listview.c:5151: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5156: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000

1 0

Re: msvcrt: Use Dragon4 algorithm to fix inconsistent rounding behaviour for sprintf and add tests. The Dragon4 algorithm implementation is based on http://www.ryanjuckett.com/programming/printing-floating-point-numbers/.
by YongHao Hu 31 Mar '15

31 Mar '15

Excuse me, Is there anything to do to improve this patch? Thanks. On 2015年03月25日 15:46, YongHao Hu wrote: > Try 3: > - Superseded Patch 109456. > - Use appropriate win32 types instead of typedef. > (Thanks Dmitry Timoshkov) > > Try 2: > - Superseded Patch 109432 > - Use typedef instead of C99 types > - Delete useless #ifndef > - Add memset to test > > Try1: > - Fix bug https://bugs.winehq.org/show_bug.cgi?id=37913 . > - The Dragon4 algorithm implementation is based on > http://www.ryanjuckett.com/programming/printing-floating-point-numbers/. > > --- > dlls/msvcrt/dragon4.h | 668 > ++++++++++++++++++++++++++++++++++++++++++ > dlls/msvcrt/printf.h | 43 +-- > dlls/msvcrt/tests/printf.c | 96 ++++++ > dlls/msvcrt/wine_printfloat.h | 246 ++++++++++++++++ > 4 files changed, 1036 insertions(+), 17 deletions(-) > create mode 100644 dlls/msvcrt/dragon4.h > create mode 100644 dlls/msvcrt/wine_printfloat.h > >

2 2

Re: [7/8] server: Implement waiting for job objects.
by Marvin 31 Mar '15

31 Mar '15

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://testbot.winehq.org/JobDetails.pl?Key=12521 Your paranoid android. === w7u (32 bit process) === process.c:2552: Test failed: WaitForSingleObject returned 258

1 0

Re: [1/8] server: Basic implementation of job objects. (rev 2)
by Marvin 30 Mar '15

30 Mar '15

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://testbot.winehq.org/JobDetails.pl?Key=12516 Your paranoid android. === w7u (32 bit process) === process.c:2532: Test failed: WaitForSingleObject returned 258

1 0

Re: [PATCH 3/3] comctl32/listview: Always forward HDM_SETORDERARRAY to a header
by Marvin 30 Mar '15

30 Mar '15

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://testbot.winehq.org/JobDetails.pl?Key=12515 Your paranoid android. === w2000pro (32 bit listview) === listview.c:5162: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5167: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w2003std (32 bit listview) === listview.c:5162: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5167: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w2008s64 (32 bit listview) === listview.c:5162: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5167: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w7u (32 bit listview) === listview.c:5162: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5167: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w8 (32 bit listview) === listview.c:5162: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5167: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w2008s64 (64 bit listview) === listview.c:5162: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5167: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000

1 0

Re: [PATCH 7/7] ddraw/tests: Port the lighting test to the previous d3d versions.
by Marvin 30 Mar '15

30 Mar '15

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://testbot.winehq.org/JobDetails.pl?Key=12513 Your paranoid android. === wvistau64 (32 bit ddraw1) === ddraw1.c:2498: Test failed: Expected message 0x46, but didn't receive it. ddraw1.c:2500: Test failed: Expected screen size 1024x768, got 0x0. ddraw1.c:2506: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2537: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2545: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2572: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2592: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2616: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2643: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2660: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2697: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2708: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2735: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2755: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2772: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2799: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2816: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2854: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. === w8 (32 bit ddraw1) === ddraw1.c:1376: Test failed: Expected color 0x00ff0000 for test 0, got 0x0000ff00. ddraw1.c:1400: Test failed: Expected color 0x000000ff for test 0, got 0x0000ff00.

1 0

Re: [PATCH 6/7] ddraw/tests: Add more d3d7 lighting tests.
by Marvin 30 Mar '15

30 Mar '15

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://testbot.winehq.org/JobDetails.pl?Key=12512 Your paranoid android. === w8 (32 bit visual) === visual.c:1494: Test failed: unexpected colortable on offscreen surface

1 0

Re: [PATCH 3/7] ddraw: Make sure to activate / deactivate the light on D3DLIGHT_ACTIVE flag changes.
by Sergey Isakov 30 Mar '15

30 Mar '15

Sorry, but seems current revision has no “flags” variable On 30 марта 2015 г., at 21:18, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > --- > dlls/ddraw/light.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/dlls/ddraw/light.c b/dlls/ddraw/light.c > index baaf6a3..c632c32 100644 > --- a/dlls/ddraw/light.c > +++ b/dlls/ddraw/light.c > @@ -201,7 +201,11 @@ static HRESULT WINAPI d3d_light_SetLight(IDirect3DLight *iface, D3DLIGHT *data) > > wined3d_mutex_lock(); > memcpy(&light->light, data, sizeof(D3DLIGHT)); > - if (flags & D3DLIGHT_ACTIVE) > + if (!(light->light.dwFlags & D3DLIGHT_ACTIVE) && flags & D3DLIGHT_ACTIVE) > + light_activate(light); > + else if (light->light.dwFlags & D3DLIGHT_ACTIVE && !(flags & D3DLIGHT_ACTIVE)) > + light_deactivate(light); > + else if (flags & D3DLIGHT_ACTIVE) > light_update(light); > light->light.dwFlags = flags; > wined3d_mutex_unlock(); > -- > 2.0.5 > > >

1 0

Re: [PATCH 1/5] wined3d: Give tex_type and its values a better name.
by Henri Verbeet 30 Mar '15

30 Mar '15

On 28 March 2015 at 17:06, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -179,7 +179,7 @@ static void surface_get_blt_info(GLenum target, const RECT *rect, GLsizei w, GLs > case GL_TEXTURE_2D: > info->binding = GL_TEXTURE_BINDING_2D; > info->bind_target = GL_TEXTURE_2D; > - info->tex_type = tex_2d; > + info->tex_type = WINED3D_FFP_TEXTURE_TYPE_2D; > coords[0][0] = (float)rect->left / w; > coords[0][1] = (float)rect->top / h; > coords[0][2] = 0.0f; Note that there isn't anything particularly fixed-function about blits. That currently doesn't matter a whole lot since this is effectively only used for onscreen/offscreen depth blits, but I get the impression your intention is to use this for the blitter interface in general. In that case, something like wined3d_shader_resource_type may be more appropriate, since eventually we'll have to deal with e.g. buffers and array textures as well (for ID3D10Device::CopySubresourceRegion() in particular.) > +enum wined3d_ffp_texture_type > { > - tex_1d = 0, > - tex_2d = 1, > - tex_3d = 2, > - tex_cube = 3, > - tex_rect = 4, > - tex_type_count = 5, > + WINED3D_FFP_TEXTURE_TYPE_1D = 0, > + WINED3D_FFP_TEXTURE_TYPE_2D = 1, > + WINED3D_FFP_TEXTURE_TYPE_3D = 2, > + WINED3D_FFP_TEXTURE_TYPE_CUBE = 3, > + WINED3D_FFP_TEXTURE_TYPE_RECT = 4, > + WINED3D_FFP_TEXTURE_TYPE_COUNT = 5, > }; Somewhat related to above, if this is supposed to be fixed-function we don't need WINED3D_FFP_TEXTURE_TYPE_1D. If it's supposed to be for blits we do, but the "FFP" in the name would be inappropriate. > -/* Similar to tex_types, except that it doesn't have 1d textures > - * (can't be bound), rect textures (handled via np2_fixup) and > - * none / unknown (treated as 2d and handled via dummy textures). */ > +/* Similar to wined3d_ffp_texture_type, except that it doesn't > + * have 1d textures (can't be bound), rect textures (handled via > + * np2_fixup) and none / unknown (treated as 2d and handled via > + * dummy textures). */ wined3d_ffp_texture_type doesn't have a none/unknown element either.

2 2

Re: [PATCH 3/5] wined3d: Use bitfields in struct arbfp_blit_type.
by Henri Verbeet 30 Mar '15

30 Mar '15

On 28 March 2015 at 17:06, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > struct arbfp_blit_type > { > - enum complex_fixup fixup; > - GLenum textype; > + enum complex_fixup fixup : 4; > + enum wined3d_ffp_texture_type textype : 3; > + unsigned padding : 1; > }; > I don't keep a very close eye on arb_program_shader.c, but I suspect this doesn't quite do what you think it does. The structure is going to get aligned to the alignment of the largest scalar field (which would be 32 bits in this case because of enum/unsigned), so you'll have another 24 bits of padding after the "padding" field.

1 0

Re: dwrite/tests: Test the correct return code.
by Marvin 30 Mar '15

30 Mar '15

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://testbot.winehq.org/JobDetails.pl?Key=12500 Your paranoid android. === wvistau64 (32 bit font) === font.c:1818: Test failed: got 0x8faecafe === w2008s64 (32 bit font) === font.c:1818: Test failed: got 0x8faecafe === w7u (32 bit font) === font.c:1818: Test failed: got 0x8faecafe === w8 (32 bit font) === font.c:1818: Test failed: got 0x8faecafe === wvistau64 (64 bit font) === font.c:1818: Test failed: got 0x8faecafe === w2008s64 (64 bit font) === font.c:1818: Test failed: got 0x8faecafe

1 0

Re: [7/7] ws2_32: Better trace setsockopt/getsockopt (try 2)
by Alexandre Julliard 30 Mar '15

30 Mar '15

Bruno Jesus <00cpxxx(a)gmail.com> writes: > Use wine_dbg_sprintf instead of plain sprintf, that simplified the patch =) What you really want is to implement a debugstr_sockopt and something like a debugstr_optval and use these in normal TRACE statements, instead of hiding the trace inside a helper function. Also you can't append to a wine_dbg_sprintf string, that's why it's const... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: kernel32: add a stub for QueryThreadCycleTime
by Dmitry Timoshkov 30 Mar '15

30 Mar '15

Austin English <austinenglish(a)gmail.com> wrote: > +@ stdcall QueryThreadCycleTime(ptr ptr) ... > +BOOL WINAPI QueryThreadCycleTime(HANDLE thread, PULONG64 cycle) 'ptr' is not suitable for HANDLE in the .spec file. -- Dmitry.

1 0

Re: d3drm/tests: Add QueryInterface tests for IDirect3DRMFrame
by Stefan Dösinger 29 Mar '15

29 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-03-29 um 15:37 schrieb Aaryaman Vasishta: > + { &IID_IDirect3DRM, NULL, E_NOINTERFACE, FALSE }, It's funny that this interface returns the right error value on QI. > + hr = IDirect3DRM_CreateFrame(d3drm3, NULL, &frame3); Minor nitpick: IDirect3DRM3_CreateFrame . You can resend the patch with a fix if you want, but I'm OK with this patch as it is. Something to think about for future tests: It may make sense to split up d3drm.c into d3drm1.c, d3drm2.c and d3drm3.c for each interface version, similar to the ddraw tests. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVGBWOAAoJEN0/YqbEcdMwLkUP/3S8gOP5XSYOgOkELFOSznNp ir09O5ef1HUpECpZjCks7ez4IbUhswcb/idJ3UeEx3lSBy4vIk3vY0usXcXKkfMl TlioDlOuzKhpXxb/5lZ/SUoG/nguBvzisKeifAA1gi8ne+3REhWeJvY6iBNDNDEX dNUYiTP+qxsq8c+bzgydxDuu0OT7LVEXrVrDO1g3qOebJjFSdkXOnf1bCntejX4S WdnxPlioWBMvffP42r0oinXzjoqobi5BDw8r4YppflEUou1bH3oT7fczJEpK4rBm 2ZDz9EOhvMOa6M5PSiqwPpINfI1PpH+p9S0r3iMZz8ux2VbXDyfJ0i/5CdzQ3HX8 rnNq/NcObXVgweBYIN7uFvjlo0Si963ACYDperAVyBNgP/oJXsz3dA5ysvrf6Lf8 Xy1kdP2B79AxWR3DRumQS9sbruaofENF16/7d9MZE933uWY9xBS6JIKTP0AVdDsP tqF8ppHwVdPfpiazYnrG1ivpE0jNIPJJ67I6FWRC1S8k7QQVmbAdVnDgczDs6lLx hiZbjksd4Uf16oGO29bXeZ2YM3Zi75K9pCa7ruYoftcF2ihd0tU01+jbM6hY32qm K1RKe7/HCMANoal7pQEukARHVRvHDpVFRGJzeMbysc8yumnpbgl7/UI9z0wZvoYI aCAXfxi21aSdCzxC7mIU =9SMA -----END PGP SIGNATURE-----

2 2

Re: [PATCH 4/5] comctl32/listview: Always forward LVM_GETCOLUMNORDERARRAY to header
by Marvin 29 Mar '15

29 Mar '15

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://testbot.winehq.org/JobDetails.pl?Key=12491 Your paranoid android. === w7u (32 bit listview) === listview.c:5141: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5146: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === wvistau64 (64 bit listview) === listview.c:5141: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5146: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w2008s64 (64 bit listview) === listview.c:5141: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5146: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000

2 1

Re: dsound: Fix angle to sound source calculation.
by Andrew Eikum 29 Mar '15

29 Mar '15

Forwarding on to wine-devel, Stas, and Ruslan from Bug 38041. Any thoughts on the coning breakage, Stas? Andrew On Mon, Mar 23, 2015 at 09:52:32PM +0000, Mark Harmstone wrote: > Hi, > > I've had a play with it, and yes, I think he's right. It seems to be a > lot more robust than my code. One thing though that I think he's > overlooked is that he changes the behaviour of AngleBetweenVectorsRad, > which is called by AngleBetweenVectorsDeg and thus the coning code - > I think this patch will probably break that. > > I've not tested it yet, but there's a chance this patch might fix > bug 38041. > > Mark > > On 23/03/15 14:39, Andrew Eikum wrote: > > This seems sane to me, but I never had a good grasp on this to begin > > with. Does it look OK to you, Mark? > > > > Andrew > > > > On Sun, Mar 22, 2015 at 08:59:15PM +0300, Стас Цымбалов wrote: > >> This patch fixes incorrect sound positioning in dsound. > >> As of now, angle to sound source is calculated as angle between > >> vDistance and vOrientFront. > >> This leads to incorrect results for all sources that are not in the > >> same plane as speakers. > >> In extreme case: for sources directly above or below origin, angle is > >> calculated to -90 degrees, and they are played in the left speaker. > >> > >> This patch changes angle calculation: angle to sound source is > >> calculated as angle between vDistance and plane given by vectors > >> vOrientFront and vOrientTop. > >> --- > >> dlls/dsound/sound3d.c | 25 ++++++++++++++----------- > >> 1 file changed, 14 insertions(+), 11 deletions(-) > > > >> From 1ebe3761b0d6acfca58cec17472336a05b7f2679 Mon Sep 17 00:00:00 2001 > >> From: Stas Cymbalov <dummyunit(a)gmail.com> > >> Date: Sun, 22 Mar 2015 18:22:49 +0300 > >> Subject: dsound: Fix angle to sound source calculation. > >> > >> --- > >> dlls/dsound/sound3d.c | 25 ++++++++++++++----------- > >> 1 file changed, 14 insertions(+), 11 deletions(-) > >> > >> diff --git a/dlls/dsound/sound3d.c b/dlls/dsound/sound3d.c > >> index 9a0226a..ffd4d45 100644 > >> --- a/dlls/dsound/sound3d.c > >> +++ b/dlls/dsound/sound3d.c > >> @@ -112,7 +112,6 @@ static inline D3DVALUE AngleBetweenVectorsRad (const D3DVECTOR *a, const D3DVECT > >> > >> cos = product/(la*lb); > >> angle = acos(cos); > >> - if (cos < 0.0f) { angle -= M_PI; } > >> TRACE("angle between (%f,%f,%f) and (%f,%f,%f) = %f radians (%f degrees)\n", a->x, a->y, a->z, b->x, > >> b->y, b->z, angle, RadToDeg(angle)); > >> return angle; > >> @@ -264,16 +263,20 @@ void DSOUND_Calc3DBuffer(IDirectSoundBufferImpl *dsb) > >> else > >> { > >> vLeft = VectorProduct(&dsb->device->ds3dl.vOrientFront, &dsb->device->ds3dl.vOrientTop); > >> - flAngle = AngleBetweenVectorsRad(&dsb->device->ds3dl.vOrientFront, &vDistance); > >> - flAngle2 = AngleBetweenVectorsRad(&vLeft, &vDistance); > >> - > >> - /* AngleBetweenVectorsRad performs a dot product, which gives us the cosine of the angle > >> - * between two vectors. Unfortunately, because cos(theta) = cos(-theta), we've no idea from > >> - * this whether the sound is to our left or to our right. We have to perform another dot > >> - * product, with a vector at right angles to the initial one, to get the correct angle. > >> - * The angle should be between -180 degrees and 180 degrees. */ > >> - if (flAngle < 0.0f) { flAngle += M_PI; } > >> - if (flAngle2 > 0.0f) { flAngle = -flAngle; } > >> + /* To calculate angle to sound source we need to: > >> + * 1) Get angle between vDistance and a plane on which angle to sound source should be 0. > >> + * Such a plane is given by vectors vOrientFront and vOrientTop, and angle between vector > >> + * and a plane equals to M_PI_2 - angle between vector and normal to this plane (vLeft in this case). > >> + * 2) Determine if the source is behind or in front of us by calculating angle between vDistance > >> + * and vOrientFront. > >> + */ > >> + flAngle = AngleBetweenVectorsRad(&vLeft, &vDistance); > >> + flAngle2 = AngleBetweenVectorsRad(&dsb->device->ds3dl.vOrientFront, &vDistance); > >> + if (flAngle2 > M_PI_2) > >> + flAngle = -flAngle; > >> + flAngle -= M_PI_2; > >> + if (flAngle < -M_PI) > >> + flAngle += 2*M_PI; > >> } > >> TRACE("panning: Angle = %f rad, lPan = %d\n", flAngle, dsb->volpan.lPan); > >> > >> -- > >> 2.0.5 > >> > > > >> > > >

4 4

Re: d3drm/tests: Add QueryInterface tests for IDirect3DRMFrame
by Marvin 29 Mar '15

29 Mar '15

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://testbot.winehq.org/JobDetails.pl?Key=12490 Your paranoid android. === w2000pro (32 bit d3drm) === d3drm.c:1738: Test failed: Got refcount 2 for test "frame_qi" 0, 1, expected 0. d3drm.c:1738: Test failed: Got refcount 2 for test "frame_qi" 0, 2, expected 0. d3drm.c:1728: Test failed: Got hr 0x80040111 for test "frame_qi" 0, 3. d3drm.c:1728: Test failed: Got hr 0x80040111 for test "frame_qi" 0, 4. d3drm.c:1728: Test failed: Got hr 0 for test "frame_qi" 0, 5. d3drm: unhandled exception c0000005 at 780273CD === wxppro (32 bit d3drm) === d3drm.c:1738: Test failed: Got refcount 2 for test "frame_qi" 0, 1, expected 0. d3drm.c:1738: Test failed: Got refcount 2 for test "frame_qi" 0, 2, expected 0. d3drm.c:1728: Test failed: Got hr 0x80040111 for test "frame_qi" 0, 3. d3drm.c:1728: Test failed: Got hr 0x80040111 for test "frame_qi" 0, 4. d3drm.c:1728: Test failed: Got hr 0 for test "frame_qi" 0, 5. d3drm: unhandled exception c0000005 at 77C46F07 === w2003std (32 bit d3drm) === d3drm.c:1738: Test failed: Got refcount 2 for test "frame_qi" 0, 1, expected 0. d3drm.c:1738: Test failed: Got refcount 2 for test "frame_qi" 0, 2, expected 0. d3drm.c:1728: Test failed: Got hr 0x80040111 for test "frame_qi" 0, 3. d3drm.c:1728: Test failed: Got hr 0x80040111 for test "frame_qi" 0, 4. d3drm.c:1728: Test failed: Got hr 0 for test "frame_qi" 0, 5. d3drm: unhandled exception c0000005 at 77BD7D8D

1 0

Re: [PATCH] user32: Support activation context class redirection in CreateWindow.
by Nikolay Sivov 29 Mar '15

29 Mar '15

On 03/29/2015 01:54 AM, Mark Harmstone wrote: > This patch implements the class redirection feature of activation contexts, as > used by version 6 of comctl32. Among other things, this is a necessary step in > fixing the behaviour seen in bug 38124. > > --- > dlls/user32/win.c | 62 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 62 insertions(+) > In principle it looks almost okay, except that I don't think we need it right now, as long as comctl32 doesn't register versioned classes at all. It will just wait time for every window creation requested looking for something that can't be created. Comments on code itself to follow. > + classatom = get_int_atom_value(className); > + if (classatom) > + GlobalGetAtomNameW(classatom, classNameStr, sizeof(classNameStr) / sizeof(*classNameStr)); > + else > + strcpyW(classNameStr, className); You don't need to copy in case of a string. > + if (wcrd->name_len == 0) > + return FALSE; I don't think it can be 0, ever. Name comes from class name from module manifest and assembly version string. > + memcpy(redirClassName, (unsigned char*)askd.lpData + wcrd->name_offset, wcrd->name_len); > + redirClassName[wcrd->name_len / sizeof(WCHAR)] = 0; All strings in context data are null-terminated, so you don't need this complexity. In fact you don't need to copy anything at all, you can just use a (WCHAR*)((BYTE*)askd.lpData + wcrd->name_offset) as a ready-to-use pointer, I think it's a preferred way, given that overhead of this redirection lookup should be minimal. So your helper only needs to return a pointer - original one or computed from redirection data. And atoms should be resolved outside of it. > + WCHAR redirClassName[256]; Is it defined somewhere to be limited to that? > + > + wndPtr = create_window_handle( parent, owner, redirClassName, module, unicode ); > + > + if (GetLastError() == ERROR_INVALID_HANDLE && GetClassInfoW( 0, redirClassName, &wc )) > + wndPtr = create_window_handle( parent, owner, redirClassName, module, unicode ); > + I don't quite get what you're trying to do here? How does same call help if called second time? Also last error check is strange.

1 0

Re: [PATCH] wined3d: Fix some videocards property detection
by Stefan Dösinger 28 Mar '15

28 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This patch has a few unrelated changes. The core change is that it re-introduces a hack we once had in Wine and removed because it broke newer mac GPUs. The CrossOver version of the hack works a bit better than the unconditional Wine version, but it's still ugly. Am 2015-03-28 um 06:15 schrieb Sergey Isakov: > + /* Non-Apple GL vendors report uniforms correctly */ > + if (!match_apple(gl_info, gl_renderer, gl_vendor, card_vendor, device)) return FALSE; > + /* All dx9 cards are overreported on OSX */ > + if (!match_dx10_capable(gl_info, gl_renderer, gl_vendor, card_vendor, device)) return TRUE; > + /* Nvidia and Intel DX10 cards support > 256 uniforms */ > + if (card_vendor != HW_VENDOR_AMD) return FALSE; It is terrible that OSX lies about the GPU capability and then forces applications to have a crystal ball that tells them what the GPU can actually do. - From a pragmatic point of view I don't think OSX will ever change in this regard. It was a design decision by Apple to do this, and they stopped updating drivers for the old hardware a long time ago. I am open to re-introducing the hack if we can find a way to detect the bug more directly. E.g. try to declare a shader with 257 uniforms, read them with indirect addressing so the driver can't optimize the access and then check for software fallbacks. There's a CGL function for checking that, but I don't remember from the top of my head how it works. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVFoC/AAoJEN0/YqbEcdMwcUIP/Rw24kSROYMK2Xvfe9vyEZ9S NQd9RPHRQRNiXuXRfAmAUKm/PF17O7SUMKLAwjg90HGZySdDOH4MCb7rwaXryKYU qV1ba75KR/JOi7db0r/WrZjf+mQ2+z1hES0SEg9jSYHxIcSNRhWvjB3H3rId7Och TAEvsiT897rE7U/2GQmnw9popFPOPRm0Y2YY4f1XecF1XSdmBokpdmpcDzoRTxbX 8q11cWlPyqi3u6xiyX7SwEwoh7v/zpNd4c1yuL6kytSfV1w+sD4fMC4BitIvfd2X OltqvQz5MfexglNlLJaeE1yplhrEKE2NHHdoIXhOhg7TdOeHYJfvrzgpjLWlUVnC 6BWsSkgge3OO3Pk7Fhi7Lht0EPhds+iq+7NCLwDV051Qi89kBlyJOY33bMMjryez wHo+YEZEvk0IkkVQGkAjJfZzLFtxjMzIxcixijkJc3/aYwuF0ZyDVqFe3hj4gPTw Ei1IThyWC4hdVqIuduD4t+5VH3GwU6JiYE6a16uHVTfoTSboN9te1WzV+lnhRFMf P54xaJ+98sJrpq+670WU68jHzM/BmXXojyF+lxv8t0noXmHLJy7S4yskzDhowMMG myjbDbeb/fB2O/oSdeOEXkskl2+XkotROM9qwF7a/yyaGe1/f47Y16gmrPyeCFD5 0Z68wLM5//XliOz91+hs =1uP/ -----END PGP SIGNATURE-----

2 1

[BISECTED REGRESSION] file dialog does not shown
by Andrey Skvortsov 28 Mar '15

28 Mar '15

Hi, original problem is described here: https://bugs.winehq.org/show_bug.cgi?id=34825 I have the same problem with running Nanocad 5.1. The file open/import dialog does not open with wine-1.7.39. I bisected the problem to commit: [bbf2cce16041e90d621a1f5889ea1bd760e21a0e] comdlg32: Do not modify dialog resource directly. I reverted this commit on latest wine and that fixed my issue with file open dialog. -- Best regards, Andrey Skvortsov Secure eMail with gnupg: See http://www.gnupg.org/ PGP Key ID: 0x57A3AEAD

2 1

Re: [PATCH] wined3d: Fix some videocards property detection
by Stefan Dösinger 28 Mar '15

28 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Please keep wine-devel in CC. There are more developers than just myself :-) . Am 2015-03-28 um 12:38 schrieb Sergey Isakov: > I know this crash. It was appeared because this patch was > introduced in the wrong place as I describe in the bug 38277 Too > slow test Advanced Pixel Shaders in 3DMark2001SE > <https://bugs.winehq.org/show_bug.cgi?id=38277> My patch works > fine. It may work fine on the Macs you tested or even all the macs that ever shipped, but it is still ugly to hardcode GPU capabilities that the driver should provide. There are OpenGL flags winemac.drv can set to disable the software fallback: https://developer.apple.com/library/mac/qa/qa1502/_index.html . What happens when you set them? Do they influence the reported capabilities? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVFpW6AAoJEN0/YqbEcdMwaz4P/298Ha4rtgWPYEFF+w6HzAWP f7G9fenhHkgjaudNwjcFXTr1dweYTVwvVll5Ahpu9bRd4iC/hM4jyKf2TVcpcXbM +yIri1UnsgSt63YJ1+XRfvVsV28BYlhqnlZvqKkmNHf/5dxg0iOfz0noDYAcspFZ BjfVQOFgaRmuiS9AyVpgc5WO2+IptKvDa1ExSOSNhOO5ye7T9Nh071QoWCgakqza invrADPRjRm/Ri7JV6CtQeRZCLYdMjeONchhJOHif2KYjk8/J5PNVAUeSSt73ZXQ TPA/VmPAs9mge3QlKgD9NgIab8auPt0tHW3MLLluKbLmwOJSMsOuxx85VC4yxlvK K/h0Q7Ldx8BvmsraLjmNMPmB9FMUNuxmEhjrkdbN90v9FwfsfZs5PGm6V+Rmt4uq gBHQxY2wd6xUt6I4AFH+6s088Ubl7zQRdAsE12LTMnRHF0ctIvHZCVdtdgVG/0hu ZpxrnHgoWm4E9arzslkHOxaqAh1Tln8k9WtpF6PcGNv4xbLWKLNiRBHMF4fK9MQI PtbT7gzL71+38lArzqnCzKb4Ijw1X7PkgA//4ZlkENyCp9SKxWpLQaDq853mhGlQ Q8z6TqAgb1wIwqO/rfiX6Rqj+aWt9Zet4XDhLaLbsifRnGjr4gad9LSC28GzQfet d80ZXwigJshmdtl05+I6 =+1lX -----END PGP SIGNATURE-----

2 2

Re: [PATCH] krnl386.exe16: Fix NULL pointer dereferencing
by Stefan Dösinger 28 Mar '15

28 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-03-27 um 19:16 schrieb Sergey Isakov: > This if statement body will perform only if driver_request is NULL > pointer. Next statements will cause crash. Bug 38159 NULL pointer > dereferencing <https://bugs.winehq.org/show_bug.cgi?id=38159> I think in this case the segfault is intentional. The caller passes a stupid parameter. Also I'm not sure if it actually segfaults. In vm86 mode memory is mapped to this page, so NULL may be a valid address. The best solution would be to write a test and see what happens on an ancient DOS, but we don't have a test infrastructure for DOS and Win16. The next best idea might be to just remove the entire block. It's funny though since (according to git) the patch that added this check already added the "/* FIXME - to be deleted ?? */" comment. At some point we may as well remove the entire DOS code since we just call dosbox these days and 64 bit CPUs don't allow vm86 mode anyway. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVFpBqAAoJEN0/YqbEcdMwVUQP/itrU95T4mlo2vo7f4J3k7fd Wx4goKV1/s5iPT+56T3q+MsqYp0gcNgmiwmVrf+HSNl94jXo1ysWfsuD1LeAAPGi O6FJBpszJdjw+fjm0whKidM3L+QYOEqGb/8AP5ZuXQ2zE0+iDA2cGo5oFrP2LpmM ZR7t3uYTIqk4VYWuZz4rlfSaHu552LpT/zEIYghteL/ANTqkad+oVleOFLB6Nbb/ j1PK7QKl6D+n6Kd2KSwlI9jj3XADf14i96J2knNh7yyLVZAsjNTe/3F9eoI98N5M cI22fGkW6jp70HoS1yMpJG66jqrhamAi6QBzMUI2cfAhHtjngKj36X3MRZMXIiK7 4E1g/Z7hcJ3ZtbrfzHnUdUXCQMXHszA93U69QRERTnjatDB+VNTZ67AaPGMXBiE9 2i5KlGg5TXjZPJwPqetHuGZ18uUXwCXfbC5+VPXP5AqbhxltE6IPfbKs95Bo90gh EvZsooU7pqNJxNAfscDIKliDsIcFV3TATqEyr/LCeczKNbE1DOKQ/afBrGyivabe f/YzcLLHfx5x8Lxx5bsmn2+3xR+LVfppH/rCSC5YA2ZwU6gB8NeuDAHh/BvsV7E1 i9IkN43sbQ4xZQFckBsyhdcpJd0kCCp3n1kmCfCWx3c2uIwLNvzzwT9HM8mY36my qcBfCcz1CCOpKpaayCSL =78sc -----END PGP SIGNATURE-----

1 0

Re: [PATCH] user32: Use function parameter if it set to be not stub
by Stefan Dösinger 28 Mar '15

28 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-03-27 um 21:52 schrieb Sergey Isakov: > { + if (!lpDisplayDevice) { + return FALSE; + } This is probably correct, but it needs a test. Currently this function crashes if this parameter is NULL. I can imagine that EnumDisplayDevices(NULL, 1, NULL, 0) returns TRUE if display 1 exists and FALSE otherwise. > + + if (i) { FIXME("(%s,%d,%p,0x%08x), > stub!\n",debugstr_w(lpDevice),i,lpDisplayDevice,dwFlags); - - if > (i) return FALSE; + } This is an unrelated change and matters more for what the patch description says it does. Though if I understand this right we want this check to be "if (i || lpDevice)" because the application can also pass in a device name. > > + if (lpDevice) { + strcpyW(lpDisplayDevice->DeviceName, > lpDevice); + } else { memcpy(lpDisplayDevice->DeviceName, > primary_device_name, sizeof(primary_device_name)); + } This is yet another unrelated change. It looks OK, but I don't think it really matters. Copying the input display name will at best paper over the fact that our implementation of this function does not support multiple display devices. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVFo0tAAoJEN0/YqbEcdMw+eQP/1SnlfkRjPZ/8PW8+m3iOYHC OTLWOE7Io94FzLfFQO487pCbsqgd9199UWp3IolfUe/y2vS4LtosxQQh1tLG7j7A rsypwNjV8OwSHvXiL5BH/4QvZTAqoctW484E7z7IHzMXMqa2Oyrj5K3QXHVes6O5 9xEB1UuSkB19Z0jIQqHPR4Hc/o8gYuCAER05BiTqOZcBSsrVhfOOZ+FKR7krWqdP o3VkOmUSWhX+9ziTsKmWGsBEZk0r81RMG2cbT/eShAtBBZs/+YtUfYiNY2q+tCoF fMiEfiMU7e1TqroBJAw37gYju+qt3xon/RuyOQD13a3hwWSDzMeoE9PAf9TxCK4Q OinEV45U8RiDkczviuOQluojfmJSXmVCC2BjPPQ2ZtmGXyuRXLrlRZ4KsCE/xhyV p2+Za2U/cvfqy0ug5isnnFGu/lKi1RCeGXsbHX6ZF5amTEfuklQpWolacrGilxZ2 kYiBtV93A/IJzUPaj2d97JbEFG2nMP6pT+KTSFBJIY2bzzzhnX1Fltd8kt3Vp/rv MOUPs/peC9sv17wDc5LREPAbA7LOBuN4M3M+5O2glO/F96gt8FSsPYyZy9sMRXEv eEuQgGbFbm9KKCWBK53mm78aAFiulqEd3S4vFXnvNU5sFxUW/BO3TxDZJhPEAK2v BeJJ0ZjH01mfQ8lhDQph =RL+u -----END PGP SIGNATURE-----

1 0

Re: [PATCH] vbscript: Fixed Hex
by Marvin 28 Mar '15

28 Mar '15

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://testbot.winehq.org/JobDetails.pl?Key=12482 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === w2003std (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: [PATCH] vbscript: Implemented Oct(try 3)
by Marvin 28 Mar '15

28 Mar '15

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://testbot.winehq.org/JobDetails.pl?Key=12480 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === w2003std (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: [2/9] kernel32/tests: Add tests for IsProcessInJob.
by Marvin 28 Mar '15

28 Mar '15

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://testbot.winehq.org/JobDetails.pl?Key=12470 Your paranoid android. === w7u (32 bit process) === process.c:2177: Test failed: WaitForSingleObject returned 258

2 1

Re: [PATCH] vbscript: Implemented Oct(try 2)
by Shuai Meng 28 Mar '15

28 Mar '15

Hi, I find Oct("test") returns error number 13 on windows, while 445 on wine. So I shall resend this patch. 2015-03-27 23:28 GMT+08:00 Shuai Meng <mengshuaicalendr(a)gmail.com>: > testbot: > https://newtestbot.winehq.org/JobDetails.pl?Key=12461 > Changelog: > Added support for other subtypes; > Added more tests. > --- > dlls/vbscript/global.c | 53 ++++++++++++++++++++++++++++++ > +++++++++++++-- > dlls/vbscript/tests/api.vbs | 31 ++++++++++++++++++++++++++ > 2 files changed, 82 insertions(+), 2 deletions(-) > > >

1 0

winegcc & stdin
by Leon Bogaert 27 Mar '15

27 Mar '15

I'm getting an error when using winegcc with stdin: > $ cat test.c | winegcc -xc -c - > gcc: warning: ‘-x c’ after last input file has no effect > gcc: error: -E or -x required when input is from standard input > winegcc: gcc failed Does anyone know what I could be doing wrong? I'm trying to use stdin because that's what the go (cgo) build tool is trying to use. Leon

2 2

Re: [PATCH] icnsformat.c: wrong pointer to formal parameters
by Bruno Jesus 27 Mar '15

27 Mar '15

On Fri, Mar 27, 2015 at 3:01 PM, Sergey Isakov <isakov-sl(a)bk.ru> wrote: > Bug 38288 > Wrong pointer in icnsformat.c IcnsFrameEncode_WriteSource Hi Sergey. Usually the patch subject is the dll name followed by the change. I think a better subject in this case would be: windowscodecs: Fix wrong pointer to formal parameter

1 0

[GSOC 2015] Direct3DRM - Implement rendering for D3DRM
by Aaryaman Vasishta 27 Mar '15

27 Mar '15

Hello! I have submitted my proposal on melange. Please take a look at it whenever possible. Any feedback would be very appreciated. Thank You! jam

1 0

[BISECTED REGRESSION] icons in nanocad have black background
by Andrey Skvortsov 27 Mar '15

27 Mar '15

Hi, The issue was originally described here: https://bugs.winehq.org/show_bug.cgi?id=34825 I bisected both issues, but I'll create separate thread to the issue with file dialog. First bad commit that causes black background on icons is: [ b81a7d976e3c3de36a01401d125871d3014e6c67 ] gdi32: Always use the DIB engine for monochrome bitmap rendering. To see how the issue looks like, I attached small screenshots. -- Best regards, Andrey Skvortsov Secure eMail with gnupg: See http://www.gnupg.org/ PGP Key ID: 0x57A3AEAD

2 1

Re: [PATCH] vbscript: Implemented Oct(try 2)
by Marvin 27 Mar '15

27 Mar '15

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://testbot.winehq.org/JobDetails.pl?Key=12462 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === w2003std (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: [PATCH] schannel_gnutls: when calling pgnutls_server_name_set ensure that the values are sane
by Jacek Caban 27 Mar '15

27 Mar '15

Hi Nikos, On 03/27/15 17:25, Nikos Mavrogiannopoulos wrote: > This patch addresses issue with schan_imp_set_session_target() > translation to gnutls API. It does not pass invalid (null) parameters to > it, as this seems to cause issues. Addresses > https://bugs.winehq.org/show_bug.cgi?id=38134 Take a look at schan_imp_set_session_target caller in schannel.c. It already ensures that passed target is not NULL. If your patch indeed fixes a real problem, it's probably because it also ignores an empty string. That's, however, something that should also be done on caller side. Thanks, Jacek

1 0

Re: [PATCH] wineconsole: Set input stream buffer length per OS limit
by Nikolay Sivov 27 Mar '15

27 Mar '15

On 26.03.2015 14:32, Hugh McMaster wrote: > --- > programs/wineconsole/wineconsole.c | 32 ++++++++++++++++++++++++++++++-- > 1 file changed, 30 insertions(+), 2 deletions(-) > > diff --git a/programs/wineconsole/wineconsole.c b/programs/wineconsole/wineconsole.c > index 3c2faf5..81300ed 100644 > --- a/programs/wineconsole/wineconsole.c > +++ b/programs/wineconsole/wineconsole.c > @@ -797,6 +797,11 @@ static UINT WINECON_ParseOptions(const char* lpCmdLine, struct wc_init* wci) > return 0; > } > > +#define MAXSTRING_NON_NT 128 > +#define MAXSTRING_NT351 260 > +#define MAXSTRING_NT4_W2K 2048 > +#define MAXSTRING_XP 8192 > + Why do you need this mess?

3 3

Re: [PATCH 5/6] wined3d: Introduce a shader_snprintf() function.
by Henri Verbeet 27 Mar '15

27 Mar '15

On 26 March 2015 at 20:12, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > It could be used in more places, some of them need additional rework > though. > I'm not sure this is what you had in mind. I didn't feel like making > these strings heap allocated, it seems to get quite ugly that way. It's not quite fully worked out at this point, but what I have in mind is roughly to use wined3d_shader_buffer. The shader_glsl_priv structure can then keep a list of scratch buffers from which you can get one to construct these kinds of intermediate strings and release back to when you're done with them. It would probably also involve cleanup functions for e.g. glsl_src_param and glsl_dst_param at some point. In principle this patch is in the right direction, but I'd rather avoid putting this in now and then having to change it again later.

1 0

Re: [PATCH] cmd: Add basic handling of Ctrl-C
by Nikolay Sivov 27 Mar '15

27 Mar '15

On 26.03.2015 14:32, Hugh McMaster wrote: > + /* Enable handling of Ctrl-C signals */ > + if (SetConsoleCtrlHandler((PHANDLER_ROUTINE)console_ctrl_handler, TRUE)) > + WINE_TRACE("cmd: Ctrl handler was installed.\n"); > + else > + WINE_ERR("cmd: Unable to install Ctrl handler.\n"); > + Judging by the fact that you needed a cast, that's not right.

3 3

Re: [PATCH 3/4] advapi32: Add DACL inheritance support in SetSecurityInfo
by Erich E. Hoover 27 Mar '15

27 Mar '15

On Thu, Mar 26, 2015 at 2:59 PM, Erich E. Hoover <erich.e.hoover(a)wine-staging.com> wrote: > On Thu, Mar 26, 2015 at 12:10 PM, Piotr Caban <piotr.caban(a)gmail.com> wrote: >> ... >> The inheritance doesn't occur when function from ntdll are used for setting >> DACL. This makes your code inside server incorrect. Also your code is not >> checking handle permissions correctly. If you try to test it keep in mind >> that if correct inheritance flags are set in security descriptor control >> field the permissions will be filled when you right-click on file and >> display security properties on windows. > > I don’t have the time to write a test at the moment, but I find it > highly unlikely that MS would implement security descriptors in a > high-level DLL. If that were the case then an application could > easily hijack the API in order to permit access to files that would > otherwise be inaccessible. I would guess that > UNPROTECTED_DACL_SECURITY_INFORMATION and SE_DACL_AUTO_INHERITED > probably enter into this somehow. > > Besides that I think we should start implementing stored ACLs first, > before even thinking about implementing suitable inheritance > mechanisms. I submitted a bunch of patches for this some time ago, > but Alexandre wasn’t happy with using extended user attributes to > store this information. I’m just not sure that it’s useful to > implement inheritance without storing the ACLs, it’ll certainly fix > some apps but it will likely break a bunch of others. Whoops, forgot reply-all - sorry for the duplicate Piotr. Best, Erich

2 1

Re: [PATCH 1/5] include: Add Wine-specific theming hook struct to winuser.h
by Alexandre Julliard 27 Mar '15

27 Mar '15

Mark Harmstone <hellas(a)burntcomma.com> writes: > @@ -4060,6 +4060,15 @@ WORD WINAPI SYSTEM_KillSystemTimer( WORD ); > WINUSERAPI BOOL CDECL __wine_send_input( HWND hwnd, const INPUT *input ); > #endif > > +/* Wine-specific version of the undocumented structs > + * used by uxtheme to hook into user32. */ > + > +typedef struct > +{ > + WNDPROC DefWindowProcA; > + WNDPROC DefWindowProcW; > +} WINEUSERAPIHOOK; This doesn't belong in winuser.h. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] comctl32: Redraw themed button on WM_ENABLE.
by Alexandre Julliard 27 Mar '15

27 Mar '15

Mark Harmstone <hellas(a)burntcomma.com> writes: > When a themed button received a WM_ENABLE message, comctl32 redraws it, > then passes the message to the parent proc in user32. Unfortunately, this > is the wrong way round - as user32 redraws the window itself, the themed > button will be redrawn as its unthemed counterpart. It sounds like it's only hiding the problem. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] vbscript: Implemented Oct
by Marvin 27 Mar '15

27 Mar '15

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://testbot.winehq.org/JobDetails.pl?Key=12441 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === w2003std (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

2 1

Re: [2/3] windowscodecs: Implement PngDecoder_Block_GetCount.
by Alexandre Julliard 27 Mar '15

27 Mar '15

Vincent Povirk <madewokherd(a)gmail.com> writes: > From 398cd35190fddb05de97f6b125897be6c0e9e92d Mon Sep 17 00:00:00 2001 > From: Vincent Povirk <vincent(a)codeweavers.com> > Date: Wed, 25 Mar 2015 14:26:28 -0500 > Subject: [PATCH 2/3] windowscodecs: Implement PngDecoder_Block_GetCount. > > --- > dlls/windowscodecs/pngformat.c | 80 +++++++++++++++++++++++++++++++++++++++--- > 1 file changed, 76 insertions(+), 4 deletions(-) ../../../tools/runtest -q -P wine -T ../../.. -M windowscodecs.dll -p windowscodecs_test.exe.so metadata && touch metadata.ok metadata.c:949: Test succeeded inside todo block: GetCount failed, hr=80070057 metadata.c:952: Test succeeded inside todo block: GetCount failed, hr=0 metadata.c:953: Test succeeded inside todo block: unexpected count 1 Makefile:375: recipe for target 'metadata.ok' failed -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 3/4] advapi32: Add DACL inheritance support in SetSecurityInfo
by Erich E. Hoover 26 Mar '15

26 Mar '15

I do not believe this is the correct place to make this change. Inheritance still needs to occur even when SetSecurityInfo is not used, which pretty much means it has to be within the wineserver itself so that the same code can be used for CreateFile. The code I put together for this (as written it is somewhat dependent on my other ACL code) can be found here: https://github.com/wine-compholio/wine-staging/tree/master/patches/server-I… The first patch is for CreateFile and the second one is for SetSecurityInfo. I'm happy to try and change this to help you solve your problem without my other ACL code, it's been on my TODO list anyway - I've just been too busy with work lately :/ Best, Erich

4 4

Re: urlmon: Remove unneeded NONAMELESSXXX directives.
by Jacek Caban 26 Mar '15

26 Mar '15

Hi Francois, On 03/26/15 15:29, Francois Gouget wrote: > Also put them in the files that need them. It may be a bit late for such question after so many patches already went in, but what's the point of this patch? Those defines are defined in central place, so that we don't have to deal with them in each .c file. Even if they are not needed for some .c files, they are harmless. BTW, I think we could even consider putting this macro in a central place like windef.h inside __WINESRC__ guard. Jacek

1 0

named memory-mapped file
by Leon Bogaert 26 Mar '15

26 Mar '15

Hi all, I don't know if this is the correct list. If it's not I'm sorry. I have kind of a weird question. I'm playing this game iRacing which exposed it's api via named memory map ( https://github.com/meltingice/node-iracing/blob/master/lib/irsdk_utils.cpp). Is there a way I can access that named memory-mapped file via Linux? I did some Googling and I don't think it's possible but I thought I made sure to ask around here. If that isn't possible I think I'll write a simple program that would run under wine and expose that data in a Linux-friendly manner. Leon

3 4

how to upload and view reports
by Shubham kumar 26 Mar '15

26 Mar '15

Sir, i have applied for winetest graphical user interface project. Problem is to see the test results in application itself we first need to know that how it shows report on test.winehq.org so that, we could get idea on how it shows report after uploading. But, on the website i could not find any link to upload the report. Where/How am i supposed to upload the report and view the test results on website?

2 1

Application for GSoc 2015 - Implement vbscript.dll builtins for Wine
by Shuai Meng 26 Mar '15

26 Mar '15

Hello everyone, I'm Shuai Meng, a student from Beihang University of China, who have attended Gosc 2014 for wine vbscript. I would like to continue to work on this module this year: on one hand, I am familiar with it through last year's experience; on the other hand, as I have studied it deeper and deeper, I find it more difficult than imagined, and I think understanding and fulfilling this interpreter of vbscript is very meaningful and interesting. Last year, the relatively simple built-in functions have been implemented by my effort, with the generous help of many warm-hearted people. The left functions are more challenging, I have to study more about COM and DLL in order to understand the mechanism. Now let's talk about the details of my plan, the functions unimplemented can be sorted as below: 1.The first kind is the functions about date and time, they have not been implemented because Wine's vbscript is not able to parse date constant in the form of "#yy-mm-dd#" yet. The functions below can be hopefully implemented as long as I sovle this problem: IsDate CDate Day Month Weekday Year Hour Minute Second DateValue TimeValue DateSerial TimeSerial DateAdd DateDiff DatePart. 2.The second kind is about strings, they are LenB LeftB RightB MidB InStrB Replace String StrComp. I have sent some patches to implement String, which all failed. Then I realized that I have to solve the problem of locale before I can implement them. 3.The third kind is about characters: Asc AscB ChrB ChrW Escape Unescape, I have already sent patch for Asc, but due to the same problem as strings, it didn't work. Again I have to implement GetLocale and SetLocale function, however as Piotr pointed, these two functions are not registered in native typelib, so I have to figure out another way to implement them, instead of using idl files. 4.The fourth kind is about arrays: IsArray LBound UBound Array Filter Join Split. Though haven't considered them seriously, but I can feel that they harder than those listed before. 5.The fifth kind is about math, but only left Randomize and Rnd, they are a little difficult, but I think it's unnecessary to implement them manually, I mean there must be a wrapper function. I have found some samples in jscript and other modules, I will learn from them. 6.The sixth kind is others: Eval Execute ExecuteGlobal GetRef LoadPicture InputBox FormatNumber FormatCurrency FormatPercent FormatDateTime, they are the most difficult, I am not sure whether I can implement them, but I will try. 7.The remaining functions are about Error handling: Err_Description Err_HelpContext Err_HelpFile Err_Source Err_Raise. I haven't studied them yet, but sooner or later I will meet them. This is my idea for GSoC 2015, I appreciate for any comment. Thank you.

1 0

Re: ntdll/tests: Add tests for GetFinalPathNameByHandleA/W.
by Marvin 26 Mar '15

26 Mar '15

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://testbot.winehq.org/JobDetails.pl?Key=12425 Your paranoid android. === wvistau64 (32 bit file) === file.c:369: Test failed: attributes of file "testfile.xxx" are 0x0820 === wvistau64 (64 bit file) === file.c:369: Test failed: attributes of file "testfile.xxx" are 0x0820

1 0

Re: winecfg: add note about 32 bit prefixes to dialog
by Stefan Dösinger 26 Mar '15

26 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I think making this visible on some way is a good idea. I have wondered about this myself, and so have many other users. > Context behind this: To run Simcity 2000 I change my Wine prefix > settings to mimic NT 3.5 so that it uses a different file chooser > dialog which doesn't crash the game (for whatever reason). This > last time installing things I was confused about why I didn't see > the option for NT 3.5 until slackner reminded me on IRC that I need > a 32 bit prefix to have that option. Somewhat offtopic to your patch: Is this a known bug in the game? Does it crash in Windows XP or newer unless you set Win9x or Win NT compatibility? It may be a good idea to investigate the actual crash. > So, I thought it might be useful if the dialog could have a note > explaining why those options aren't there if you're running from a > 64 bit prefix -- and thus this patch. To make room for the text I > made the applications Listbox 20 pixels shorter. - From a user interface point of view, what do you think about adding those old Windows versions in the listbox, maybe with a different text like "Windows 98 not available in 64 bit", and programming the code to set the dropdown field back to the last setting if the user decides to choose one of those settings? Or instead of having the modified text, pop up an error box and set the setting back. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVEea8AAoJEN0/YqbEcdMwQCsP/0Uw+ogXWRBtTZz46g8s6hAD wZjtYdFWfx9FMbITjpA9E2VLvmHj4tN6wZDanqOLuaHIRL3Mxa8eKaeZZ+LqE6pL mZWWJcWEQ+V8C/Fr6UTFUsbFhhSDTPhw9BJH/vZBof7uw0evNfBvV6lFQ+nf5bq7 Tpcwu+cBCeVlm9atvChZLwFAuBqjeVuH5ibyGnADIxKScHKvM9rbuJf2f3g3d7bW jCpR5sxoXfgeDeZYyaFh4o3WPHjVKriT3Twz2pYgHe/yZbxgoto72a7WNr5dMdHu 4/2FCQoBoDX2HahnCgWiL7fSDLk3pZFBQ78JRZUKDcS5nj868PszszAn4REVPXEW sgL5dgQqEJs0WhlhAePnUhuPudEaOIdKRDHqMftqJZpTwMxBwo16vnEnsLejrhlB Br2s2YIlqhpF0GKx4TeaefYFlJI/uRlxyhsmUBOvcfZ/BrLtpY9JMSHg0nGPnbI4 IUyU6iBQ5KSLjyDFDFTQ/gS19vbVtzJuEI88wtcUb0I2FknIa2zZN7GBDKN+VxOl hhtiiz1wgfxrrejVTxRKVVDF6bk5BpBWHLIyVIWVxZLiKy46I5Zie2MhbG74A5ks P1vph231JUHeea51wxFOfbUjw7LcTwhHswj8YM2I1EPizOH0AWJS5WQg0K+19o+g ch59pOw13mCF3Fl3LCtz =8FQi -----END PGP SIGNATURE-----

4 4

Re: [PATCH] advapi32: succeed for null pointer in ChangeServiceConfig2
by Nikolay Sivov 25 Mar '15

25 Mar '15

On 19.03.2015 15:06, Bernhard Übelacker wrote: > Hello, > attached patch avoids an issue when trying to run Flatout 2 with copy > protection. > > When starting Flatout2.exe for the first time it wants to install some > services, but shows in wine some error messages. > > The only visible sign in terminal output, that something went wrong, is > this: > err:rpc:I_RpcReceive we got fault packet with status 0x3e6 > > And of course later some dialog showing error 998 (=0x3e6) and a > unhandled exception. > > This is because the SC_RPC_CONFIG_INFOW parameter has in its > descr->lpDescription a null pointer instead of a valid LPWSTR. > > Right now this null pointer would be accessed in > svcctl_ChangeServiceConfig2W and causes an exception there , but is > hidden by the RPC layer. > > (And of course this makes the SF4 protection still not working.) > > Kind regards, > Bernhard > Is it actually called with infolevel 1?

3 9

Re: msvcrt: Fix _copysign bugs for NAN/INF(try 2)
by Henri Verbeet 25 Mar '15

25 Mar '15

On 25 March 2015 at 12:51, Zheng Chen <chanchengcc(a)gmail.com> wrote: > The last patch was damaged by my email client. > I would recommend everyone that doesn't already use it to spend a couple of minutes to learn git send-email. It avoids a lot of issues, and in general just saves everyone (not just reviewers) a lot of time.

2 1

Re: msvcrt: Use NAN and INFINITY definitions from port.h in printf tests
by Marvin 25 Mar '15

25 Mar '15

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://testbot.winehq.org/JobDetails.pl?Key=12406 Your paranoid android. === w2000pro (32 bit printf) === printf.c:693: Test failed: r = 8 printf.c:694: Test failed: failed: "1.#QNAN0" printf.c:701: Test failed: r = 13 printf.c:702: Test failed: failed: "1.#QNAN0e+000" printf.c:710: Test failed: failed: "1.#QNAN" printf.c:718: Test failed: failed: "0000001.#R" === wxppro (32 bit printf) === printf.c:693: Test failed: r = 8 printf.c:694: Test failed: failed: "1.#QNAN0" printf.c:701: Test failed: r = 13 printf.c:702: Test failed: failed: "1.#QNAN0e+000" printf.c:710: Test failed: failed: "1.#QNAN" printf.c:718: Test failed: failed: "0000001.#R" === w2003std (32 bit printf) === printf.c:693: Test failed: r = 8 printf.c:694: Test failed: failed: "1.#QNAN0" printf.c:701: Test failed: r = 13 printf.c:702: Test failed: failed: "1.#QNAN0e+000" printf.c:710: Test failed: failed: "1.#QNAN" printf.c:718: Test failed: failed: "0000001.#R" === wvistau64 (32 bit printf) === printf.c:693: Test failed: r = 8 printf.c:694: Test failed: failed: "1.#QNAN0" printf.c:701: Test failed: r = 13 printf.c:702: Test failed: failed: "1.#QNAN0e+000" printf.c:710: Test failed: failed: "1.#QNAN" printf.c:718: Test failed: failed: "0000001.#R" === w2008s64 (32 bit printf) === printf.c:693: Test failed: r = 8 printf.c:694: Test failed: failed: "1.#QNAN0" printf.c:701: Test failed: r = 13 printf.c:702: Test failed: failed: "1.#QNAN0e+000" printf.c:710: Test failed: failed: "1.#QNAN" printf.c:718: Test failed: failed: "0000001.#R" === w7u (32 bit printf) === printf.c:693: Test failed: r = 8 printf.c:694: Test failed: failed: "1.#QNAN0" printf.c:701: Test failed: r = 13 printf.c:702: Test failed: failed: "1.#QNAN0e+000" printf.c:710: Test failed: failed: "1.#QNAN" printf.c:718: Test failed: failed: "0000001.#R" === w8 (32 bit printf) === printf.c:693: Test failed: r = 8 printf.c:694: Test failed: failed: "1.#QNAN0" printf.c:701: Test failed: r = 13 printf.c:702: Test failed: failed: "1.#QNAN0e+000" printf.c:710: Test failed: failed: "1.#QNAN" printf.c:718: Test failed: failed: "0000001.#R" === wvistau64 (64 bit printf) === printf.c:693: Test failed: r = 8 printf.c:694: Test failed: failed: "1.#QNAN0" printf.c:701: Test failed: r = 13 printf.c:702: Test failed: failed: "1.#QNAN0e+000" printf.c:710: Test failed: failed: "1.#QNAN" printf.c:718: Test failed: failed: "0000001.#R" === w2008s64 (64 bit printf) === printf.c:693: Test failed: r = 8 printf.c:694: Test failed: failed: "1.#QNAN0" printf.c:701: Test failed: r = 13 printf.c:702: Test failed: failed: "1.#QNAN0e+000" printf.c:710: Test failed: failed: "1.#QNAN" printf.c:718: Test failed: failed: "0000001.#R"

1 0

Re: msvcrt: Fix _copysign bugs for NAN/INF
by Piotr Caban 25 Mar '15

25 Mar '15

Hi, On 03/24/15 11:10, Zheng Chen wrote: > --- > dlls/msvcrt/math.c | 17 ++++++++--------- > 1 file changed, 8 insertions(+), 9 deletions(-) looks like your email client has destroyed the patch (line wraps). You can solve it by e.g. attaching the patch to email. Thanks, Piotr

2 1

winevdm DOS memory range mmap() shenanigans...
by Andreas Mohr 25 Mar '15

25 Mar '15

Hi all, for fun I just tried to run a Lemmings demo downloaded from http://www.pcgaming.ws/download.php?game=lemmings Picture my not overly amused face when I then got the message " winevdm: Cannot start DOS application C:\lemmings\VGALEMMI.EXE because the DOS memory range is unavailable. You should install DOSBox. ". After some wild fprintf trickery in various winevdm / virtual.c / mmap.c parts and subsequent mmap() Internet research it turned out that this message is annoyingly imprecise: a simple echo 0 > /proc/sys/vm/vmmap_min_addr (original value here: 65536) will allow the corresponding mapping, thereby enabling the game to (partially - then seems to have interesting issues at some VGA register parts) launch. I would therefore strongly suggest adding per-platform hint strings in failure case (either passed directly out of the inner reserve_dos_area() helper, or perhaps near the winevdm message). In the Linux case, this message would obviously be something like: ...range is unavailable (you might need to specially tweak /proc/sys/vm/vmmap_min_addr - note that this is a risky operation...). Since this is an important tweak (otherwise tons of DOS applications will bail out, thus rather negatively affecting Wine implementation debugging/reliability progress since nobody will make it there), it would be useful to add such hinting one way or another (I might find the time to do so, and possibly given some additional counseling I might even be able to come up with a sufficiently perfect patch). Thanks, Andreas Mohr

3 2

Re: comctl32/tests: Listview doesn't subclass its header
by Marvin 25 Mar '15

25 Mar '15

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://testbot.winehq.org/JobDetails.pl?Key=12399 Your paranoid android. === w7u (32 bit listview) === listview.c:5121: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5126: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === wvistau64 (64 bit listview) === listview.c:5121: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5126: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w2008s64 (64 bit listview) === listview.c:5121: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5126: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000

2 1

Regarding GSOC 2015 : Winetest Graphical User Interface
by Sushant makode 24 Mar '15

24 Mar '15

Hello, I am a graduate student at IIIT Hyderabad India and I am interested in this project idea. ( Winetest Graphical User Interface ) I have been reading the documentation.My understanding is to add a form to existing winetest.exe which will have a table with available tests, results. These results will be read from the data which is read by the web interface possibly on the fly. I think we can run specific tests as follows e.g. cd dlls/advapi32/tests make test make services.ok Then after executing the test cases, an option to rerun the test can also be provided alongside the result of the test case. A consolidated result would be put on the same form in winetest. I am working on my GSOC proposal meanwhile It would be helpful if someone can you give some documentation regarding the winetest.exe and how to make changes to it. Thanks in advance. -- Thanks And Regards, Sushantkumar M. Tech. CSE IIIT Hyderabad

1 0

My ideas for GSoC 2015
by HuddenSin Yuan 24 Mar '15

24 Mar '15

Hello, everyone. I’m Yuan Chen, a college student from China. I will have plenty of time to join GSoC 2015 and I have send two patches about mshtml.dll before and now I study gdi32 module and the Computer Graphics. Here is my idea for GSoC 2015. Improve the basic drawing functions and add GM_ADVANCED mode support ===================================== I found several bugs which show many basic curve and fonts drawing functions don’t support the GM_ADVANCED mode[1][2][3]. And the curve will become odd under this mode. I have written a test case to show these problems[9]. 1.add GM_ADVANCED mode support When I find that wine use polygon to fit the rect in GM_ADVANCED mode(polygon function is not good enough according to [4]). So I think we can use bezier spline or B spline to fit the curve like ellipse or arc in GM_ADVANCED mode[5][6]. There is also a paper about fonts capturing[7]. So the driver functions of curve and fonts like draw_arc, draw_glyph will be improved and added the GM_ADVANCED support. 2.improve the basic drawing functions In order to fix those above, we need to improve and add some basic helper functions in dlls/gdi32/dibdrv/graphics.c. get_arc_points will be improved and some helper functions will be added which help to calculate the coordinate of points of the curves in GM_ADVANCED mode.This part will take about three weeks. The bezier function need to be improved to n points instead of 3n+1 points according to Bresenham’s Algorithm[8]. This function will take less than one week. And I also try to improve the ellipse_first_quadrant functions using the Bresenham’s Algorithm.[10] Perhaps my idea is not mature enough, I will be appreciate it very much if anyone give me some advice! Thanks! [1]https://bugs.winehq.org/show_bug.cgi?id=33190 [2]https://bugs.winehq.org/show_bug.cgi?id=35333 [3]https://bugs.winehq.org/show_bug.cgi?id=35169 [4]https://bugs.winehq.org/show_bug.cgi?id=36891 [5]http://sarahfrisken.com/efficientCurveFitting.pdf [6]http://www.dtic.mil/dtic/tr/fulltext/u2/a350611.pdf [7]http://www.cs.uml.edu/~wanthony/91.427_f2008/cglr1/reference.pdf [8]http://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm [9]see the attachment “testforadvanced.txt" [10]see the attachment "0001-gdi32-Improve-the-algorithm-of-ellipse_first_quadrant.txt" ---------------------------------------- Best Regards , Yuan Chen

1 0

Re: Google Summer of Code 2015
by Matteo Bruni 24 Mar '15

24 Mar '15

2015-03-24 11:38 GMT+01:00 Лёша Долгавин <dolgavin.alexey(a)gmail.com>: > Hello Matteo, > Hi Alexey, > I'm the last year student of Moscow institute. > I found you as possible mentors in project ideas. And I want to implement > missing APIs in D3DX (math and/or mesh functions). Cool! > So, I have a question: do I need to do some task or you will choose students > for this project from their proposal? Yes, you will have to write a proposal in Melange (i.e. the GSoC website) and have submitted at least one patch to wine-patches to be considered for acceptance. I suggest you to download Wine's source code, build it and give a look at the D3DX code (both the implementation of the existing functions and the tests, that's in dlls/d3dx9_36/ and the tests/ subdirectory within). Then it might be a good idea to try to run some game using d3dx on Wine, you can e.g. search bugs.winehq.org to find some. You can then try to implement one of the missing functions and see how it's like. Eventually you'll have to choose a set of the missing APIs you want to work on during your GSoC and write a suitable proposal. You'll get feedback on it and you'll be able to update it so don't worry on getting it exactly right on the first try. If you have further questions don't hesitate to ask. It's much better if you also include wine-devel(a)winehq.org in cc the next times, others might be able to reply faster / better than me. There is also the #winehackers IRC channel on freenode available. > I have strong knowledge in math and have experience in commercial software > developing. That's good. Make sure to write that in your proposal :)

1 0

Re: [PATCH] findstr: Added test for findstr.
by Stefan Dösinger 24 Mar '15

24 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Thanks for your patch! I have a few comments: Am 2015-03-23 um 04:14 schrieb Kaipeng Zeng: > index 5f5e9d5..f3056c7 100755 > --- a/configure > +++ b/configure You don't have to include the change to configure in your patch, Alexandre will update it himself. > diff --git a/configure.ac b/configure.ac > index d23227a..822affe 100644 > ... > WINE_CONFIG_PROGRAM(findstr,,[install]) > +WINE_CONFIG_TEST(programs/findstr/tests) > WINE_CONFIG_PROGRAM(hh,,[install]) I don't think we have any precedent for having tests without having at least a stub implementation. Personally I don't see anything wrong with having just a test for now. Can you make sure that the test is properly built and included in winetest.exe? Do you intend to implement the program itself? > +static DWORD runcmd(const char* cmd, char *output) > ... > + CloseHandle(hRead); > + return TRUE; > +} I think it would be a good idea to return the return value of findstr here instead of always returning true when CreateProcess succeeds. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVD/UWAAoJEN0/YqbEcdMwh8EP/37ev7ZrJHzmNy5AJfbuzY/s 3wxUIKIo5hwrjJeiwpdFCWAtDQGMo3Hz8weLLyAaCpT4OVrzz/DvbWFLxX3zCl2Z 9EhetkZkyfiPBUF1T+s/WdTse51J9qeP8mFI7NgQdwuwUOXyp2Ba7Kq8DVBM6sNW MtWsKdItE298jTzL21oQ59w9ar6YrFwRTcVcvLQ3JPmLKSfJ5MR2qT1SxIO6nVC9 Omqc89R9Ba3jSFv+5c3l0Zn6zgnf/U5YBPmsOMYb9DWLNvD0ZgiBh5NZkLxYcV16 NLHQWxJy3mO11RNyjSn1Ank26rR1MiM4kVT7tK3WvneM1IZW7Z/RugGaymtTgfBq vIIMKidz2hPrIwmuy4AYSEb9ScJIT+b2DCbwgJEWgmxTPl3mymW5ltXLx8yzcmhV y7GNYGVKuaH6CZeyHLimeLGA845qCzXW15vWxaB6PGw+lVlqpq4mWJnWcB2NOsC+ Auw4vubTf8KTs2UHyQily9AaahthU5IkZA6sPBDpTlZCNlGpRXa+gW88WpKjd5wV 5y9otOU49Fhp704uZAiVcX9ag5cTFaseu0AsTN/TKmYToA50bzAmJr+2/+nJEQIf lcahIWPeyYw1u7rF3cOEZfkN7FIx/ab1gv1hETLvyoKz/nnYb9NPztnnK3HDFNRP XJl+R82YChN/YV946HfO =6sQQ -----END PGP SIGNATURE-----

3 6

Re: msvcrt: fix _copysign(1., -0.) error
by Piotr Caban 24 Mar '15

24 Mar '15

On 03/22/15 14:51, Kevin Chan wrote: > float CDECL MSVCRT__copysignf( float num, float sign ) > { > - /* FIXME: Behaviour for Nan/Inf? */ > - if (sign < 0.0) > - return num < 0.0 ? num : -num; > - return num < 0.0 ? -num : num; > + /* FIXME: Behaviour for signbit(NAN) is different in Linux and > + * Windows, where Windows gives a zero for -NAN > + */ > + if (signbit(sign)) > + return signbit(num) ? num : -num; > + return signbit(num) ? -num : num; It doesn't make sense to add this comment and remove it in next patch. I would also prefer if signbit fallback implementation is changed in this patch. +/* FIXME: Doesnot work with +-NAN and -0. */ There's a typo in this comment. Also it works for NAN with sign bit set to 0. +#define signbit(x) ((x) < 0 ? 1 : 0) This can be simplified to: #define signbit(x) ((x)<0)

2 1

Re: msvcrt: Add errno EDOM setting for atan(NAN)/exp(NAN)/tanh(NAN)
by Piotr Caban 24 Mar '15

24 Mar '15

Hi, On 24/03/15 09:01, Zheng Chen wrote: > --- > dlls/msvcrt/math.c | 3 +++ > 1 file changed, 3 insertions(+) The patch needs to be generated on top of clean wine. This will not apply without applying all your earlier patches. Please send a patch that contains all the changes to atan, exp and tanh functions. Thanks, Piotr

2 1

Re: msvcrt: remove errno EDOM from atan, exp and tanh
by Piotr Caban 24 Mar '15

24 Mar '15

Hi, On 03/22/15 14:50, Kevin Chan wrote: > double CDECL MSVCRT_atan( double x ) > { > - if (!isfinite(x)) *MSVCRT__errno() = MSVCRT_EDOM; > return atan(x); > } I've done a little more testing. The function is not setting errno in INF and -INF case. It does set errno to EDOM when argument is NAN. Thanks, Piotr

2 1

Re: [PATCH] comctl32: Use correct font for themed headers. (try 4)
by Nikolay Sivov 24 Mar '15

24 Mar '15

Looks good, thanks.

1 0

submitting report
by Shubham kumar 24 Mar '15

24 Mar '15

I ran winetest.exe on my pc and it generated a output file resDD89.tmp. How can i view this report? On which website i have to upload this file to generate the log? Thank you

2 1

Re: [PATCH] comctl32: Use correct font for themed headers. (try 3)
by Nikolay Sivov 23 Mar '15

23 Mar '15

On 03/23/2015 10:44 PM, Mark Harmstone wrote: Hey, looks much better, thanks. One minor thing left, and I'm sorry that I missed it last time: > + if (theme) { > + DrawThemeText(theme, hdc, HP_HEADERITEM, state, phdi->pszText, > + lstrlenW(phdi->pszText), DT_LEFT|DT_END_ELLIPSIS|DT_VCENTER|DT_SINGLELINE, > + 0, &r); > + } else { > + Will it work as docs claim if you simply pass -1 as a text length? Otherwise looks good to me.

1 0

Re: [PATCH 1/5] wined3d: Only set TEXTURE_COMPARE_FUNC when ARB_depth_texture is supported.
by Henri Verbeet 23 Mar '15

23 Mar '15

On 23 March 2015 at 18:59, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > - if (desc->compare) > - GL_EXTCALL(glSamplerParameteri(sampler->name, GL_TEXTURE_COMPARE_MODE, GL_COMPARE_R_TO_TEXTURE)); > - GL_EXTCALL(glSamplerParameteri(sampler->name, GL_TEXTURE_COMPARE_FUNC, > - wined3d_gl_compare_func(desc->comparison_func))); > + if (gl_info->supported[ARB_DEPTH_TEXTURE]) > + { > + if (desc->compare) > + GL_EXTCALL(glSamplerParameteri(sampler->name, GL_TEXTURE_COMPARE_MODE, GL_COMPARE_R_TO_TEXTURE)); > + GL_EXTCALL(glSamplerParameteri(sampler->name, GL_TEXTURE_COMPARE_FUNC, > + wined3d_gl_compare_func(desc->comparison_func))); > + } Does the driver generate GL errors without this? The way I read the ARB_sampler_objects spec that would a driver bug. (Specifically, it states that TEXTURE_COMPARE_MODE/TEXTURE_COMPARE_FUNC are accepted by SamplerParameter(), without qualifying that with a dependency on ARB_depth_texture. I guess a driver that doesn't support depth textures can essentially just ignore the texture compare mode/function, since it would never encounter a texture it would apply to.)

2 1

Re: d3dx9_36: Align texture dimensions to block size for compressed textures in D3DXCheckTextureRequirements.
by Stefan Dösinger 23 Mar '15

23 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/23/15 15:50, Sebastian Lackner wrote: > + format = D3DFMT_DXT5; > + width = 5; height = 5; > ... > + ok(mipmaps == 1, "Returned mipmaps %d, expected %d\n", mipmaps, 1); I'm curious, why does it report 1 mipmap level? Maybe because width / 2 is smaller than the block size, even though the block-size aligned width would allow a second level. What does d3dx9 return when you have width = height = 10 for example? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVEDcbAAoJEN0/YqbEcdMwVyAQAIusV1Z29v1LQQGKJtBdZk9C g+KRkCEcHalFEjwSHL4689U+GtQVigN1OSIJAtsSvrHBpslwtwsA+q7Crgamuk2X zQ+sxYOHE3QIoD2yy/uQElKxfLZWzBQjeUjZGMdYPLv4Bc2NRp4tMexPMKsHVeDx WubraUfiG40uWwcuFTfODuwuybZjWBUk89PIy865PS++/24wO12WB5vP+dK4XEB4 Mrv4Vzv+8f2zVO+tIWtXgr439f4skF4o5peOwe8qN7KxNSkqKduIWf/5dLfgZhgt lqUrziNNcWaVy5poM/cVeo7P4KKMJLjlT9ehItGee1S7gUUiatyGAKyttN5zauiV SRqJSq8sKWSGCDb/779aTonPVkLnHZVWHblJAihrCBuyE3tZVJpgg9xE3rWMyM8d IstQxbGEgDgQmrXxkeox6M3FnkBp3NL8ALzL5NHHoUxPJMg1yz5cGWuiqdBGYPM1 LmqynuRlXERLBMen/Rn69f/KFdGgqitPhzPupZ3nIGAi1Cku4Vjwd92nUS9ruZS9 uTT0t+wAjCvfKMBCfj0nnmQ4y7W9bmCxDVZs/Md83Ed4G49crTo7XTtrZnWDH4GU gFoGbn+BjcU7uankhoC5tq+XatHr6oRkWIrO5jJg2Oyk9Wns5cyanuvfGdwYrQT8 T+IYcghTfBRrDRNKHrqg =YJRY -----END PGP SIGNATURE-----

2 1

Re: d3dx9_36: Align texture dimensions to block size for compressed textures in D3DXCheckTextureRequirements.
by Henri Verbeet 23 Mar '15

23 Mar '15

On 23 March 2015 at 15:50, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > + if (w % fmt->block_width) > + w += fmt->block_width - w % fmt->block_width; > + if (h % fmt->block_height) > + h += fmt->block_height - h % fmt->block_height; Could you please just use the conventional way to align something?

1 0

Counting bits set in a 32 bit value
by Bruno Jesus 23 Mar '15

23 Mar '15

Hi all, after some manual testing I noticed that the joystick structure member dwButtonNumber is not the last button pressed but instead the count of pressed buttons. There is a bit field of buttons set in the structure member dwButton, to fix the number in dwButtonNumber I guess the easiest way is to count the bits set. I think that keeping a counter with ++/-- operations could lead to out of sync situations if the joystick is not polled fast enough. Is there any precedent need for this in wine? Is there an accepted solution for it? Internet searching shows different ways like bit counting with shift, using cpu instructions or internal compiler functions. Best wishes, Bruno

2 1

Re: dsound: Fix angle to sound source calculation.
by Andrew Eikum 23 Mar '15

23 Mar '15

This seems sane to me, but I never had a good grasp on this to begin with. Does it look OK to you, Mark? Andrew On Sun, Mar 22, 2015 at 08:59:15PM +0300, Стас Цымбалов wrote: > This patch fixes incorrect sound positioning in dsound. > As of now, angle to sound source is calculated as angle between > vDistance and vOrientFront. > This leads to incorrect results for all sources that are not in the > same plane as speakers. > In extreme case: for sources directly above or below origin, angle is > calculated to -90 degrees, and they are played in the left speaker. > > This patch changes angle calculation: angle to sound source is > calculated as angle between vDistance and plane given by vectors > vOrientFront and vOrientTop. > --- > dlls/dsound/sound3d.c | 25 ++++++++++++++----------- > 1 file changed, 14 insertions(+), 11 deletions(-) > From 1ebe3761b0d6acfca58cec17472336a05b7f2679 Mon Sep 17 00:00:00 2001 > From: Stas Cymbalov <dummyunit(a)gmail.com> > Date: Sun, 22 Mar 2015 18:22:49 +0300 > Subject: dsound: Fix angle to sound source calculation. > > --- > dlls/dsound/sound3d.c | 25 ++++++++++++++----------- > 1 file changed, 14 insertions(+), 11 deletions(-) > > diff --git a/dlls/dsound/sound3d.c b/dlls/dsound/sound3d.c > index 9a0226a..ffd4d45 100644 > --- a/dlls/dsound/sound3d.c > +++ b/dlls/dsound/sound3d.c > @@ -112,7 +112,6 @@ static inline D3DVALUE AngleBetweenVectorsRad (const D3DVECTOR *a, const D3DVECT > > cos = product/(la*lb); > angle = acos(cos); > - if (cos < 0.0f) { angle -= M_PI; } > TRACE("angle between (%f,%f,%f) and (%f,%f,%f) = %f radians (%f degrees)\n", a->x, a->y, a->z, b->x, > b->y, b->z, angle, RadToDeg(angle)); > return angle; > @@ -264,16 +263,20 @@ void DSOUND_Calc3DBuffer(IDirectSoundBufferImpl *dsb) > else > { > vLeft = VectorProduct(&dsb->device->ds3dl.vOrientFront, &dsb->device->ds3dl.vOrientTop); > - flAngle = AngleBetweenVectorsRad(&dsb->device->ds3dl.vOrientFront, &vDistance); > - flAngle2 = AngleBetweenVectorsRad(&vLeft, &vDistance); > - > - /* AngleBetweenVectorsRad performs a dot product, which gives us the cosine of the angle > - * between two vectors. Unfortunately, because cos(theta) = cos(-theta), we've no idea from > - * this whether the sound is to our left or to our right. We have to perform another dot > - * product, with a vector at right angles to the initial one, to get the correct angle. > - * The angle should be between -180 degrees and 180 degrees. */ > - if (flAngle < 0.0f) { flAngle += M_PI; } > - if (flAngle2 > 0.0f) { flAngle = -flAngle; } > + /* To calculate angle to sound source we need to: > + * 1) Get angle between vDistance and a plane on which angle to sound source should be 0. > + * Such a plane is given by vectors vOrientFront and vOrientTop, and angle between vector > + * and a plane equals to M_PI_2 - angle between vector and normal to this plane (vLeft in this case). > + * 2) Determine if the source is behind or in front of us by calculating angle between vDistance > + * and vOrientFront. > + */ > + flAngle = AngleBetweenVectorsRad(&vLeft, &vDistance); > + flAngle2 = AngleBetweenVectorsRad(&dsb->device->ds3dl.vOrientFront, &vDistance); > + if (flAngle2 > M_PI_2) > + flAngle = -flAngle; > + flAngle -= M_PI_2; > + if (flAngle < -M_PI) > + flAngle += 2*M_PI; > } > TRACE("panning: Angle = %f rad, lPan = %d\n", flAngle, dsb->volpan.lPan); > > -- > 2.0.5 > >

1 0

Re: [PATCH 4/4] ddraw/tests: Port test_color_fill to earlier versions.
by Henri Verbeet 23 Mar '15

23 Mar '15

On 20 March 2015 at 12:47, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + if (tests[i].caps & DDSCAPS_ZBUFFER) > + { > + surface_desc.dwFlags &= ~DDSD_PIXELFORMAT; > + surface_desc.dwFlags |= DDSD_ZBUFFERBITDEPTH; > + U2(surface_desc).dwZBufferBitDepth = get_device_z_depth(device); > + } > + > + hr = IDirectDraw2_CreateSurface(ddraw, &surface_desc, &surface, NULL); > + ok(SUCCEEDED(hr), "Failed to create surface, hr %#x, surface %s.\n", hr, tests[i].name); > + This crashes for me: ddraw2.c:7654: Test failed: Failed to create surface, hr 0x88760091, surface sysmem zbuffer. ddraw2.c:7654: this is the last test seen before the exception ddraw2: unhandled exception c0000005 at 00437C9D And similarly for ddraw1: ddraw1.c:6636: Test failed: Failed to create surface, hr 0x88760091, surface sysmem zbuffer. ddraw1.c:6636: this is the last test seen before the exception ddraw1: unhandled exception c0000005 at 004167BD

1 0

Re: [PATCH 5/5] wined3d: Don't use the builtin FFP uniforms for texture transformation matrices.
by Henri Verbeet 23 Mar '15

23 Mar '15

On 20 March 2015 at 13:50, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + get_texture_matrix(context, state, tex, &mat); > + GL_EXTCALL(glUniformMatrix4fv(prog->vs.texture_matrix_location[tex], 1, FALSE, (GLfloat *)&mat)); Like 110106. > + for (i = 0; i < MAX_TEXTURES; ++i) > + { > + char name[22]; > + > + sprintf(name, "ffp_texture_matrix[%u]", i); I'd feel slightly happier if this kind of thing used snprintf(), but I also think it's about time we start using something along the lines of shader_addline() for these.

1 0

Re: [PATCH 3/5] wined3d: Don't use the builtin FFP uniform for the projection matrix.
by Henri Verbeet 23 Mar '15

23 Mar '15

On 20 March 2015 at 13:50, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + if (update_mask & WINED3D_SHADER_CONST_FFP_PROJ) > + { > + struct wined3d_matrix projection; > + > + get_projection_matrix(context, state, &projection); > + GL_EXTCALL(glUniformMatrix4fv(prog->vs.projection_matrix_location, 1, FALSE, (GLfloat *)&projection)); I'd prefer that as "&projection._11", avoiding the cast.

1 0

Re: user32: Fix padding in user_thread_info structure.
by Alexandre Julliard 23 Mar '15

23 Mar '15

Sebastian Lackner <sebastian(a)fds-team.de> writes: > Based on the comment above only TEB->Win32ClientInfo should be used to store the struct user_thread_info. > The padding got out of sync in cb3b7237925a24ba4c5696dd079fdc5d99a48577 where the 64-bit situation was ignored. > The pshpack4 is required because the struct has a size of 31 ULONGs, and gcc will otherwise align the whole > struct up to 8 bytes on 64-bit. I've confirmed manually with C_ASSERTs that the offsets/sizes are right and > that it matches what we expect. I don't see any need to change the packing, there's still enough room. I'd suggest to simply replace the padding with an assert on the structure size. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] comctl32: Use correct font for themed headers. (try 2)
by Nikolay Sivov 23 Mar '15

23 Mar '15

On 23.03.2015 10:51, Mark Harmstone wrote: Hi, Mark. Thanks for looking into this. > + > + if (theme) { > + LOGFONTW lf; > + HRESULT hr = GetThemeFont(theme, hdc, HP_HEADERITEM, state, TMT_FONT, &lf); > + if (SUCCEEDED(hr)) { > + font = CreateFontIndirectW(&lf); > + if (!font) > + TRACE("Failed to create font\n"); > + else { > + TRACE("font = %s\n", debugstr_w(lf.lfFaceName)); > + oldfont = SelectObject(hdc, font); > + created_font = TRUE; > + } > + } else { > + font = (HFONT)SendMessageW(infoPtr->hwndSelf, WM_GETFONT, 0, 0); > + oldfont = SelectObject(hdc, font); > + } > + } > + > DrawTextW (hdc, phdi->pszText, -1, > &textRect, DT_LEFT|DT_VCENTER|DT_SINGLELINE|DT_CALCRECT); > cw = textRect.right - textRect.left + 2 * infoPtr->iMargin; > + > + if (font) SelectObject(hdc, oldfont); > + if (created_font) DeleteObject(font); This seems to essentially duplicate GetThemeTextExtent(). Any reason why you can't use it instead?

1 0

Adding HID joystick support to FreeBSD
by Bruno Jesus 23 Mar '15

23 Mar '15

Hi, all. In order to add HID joystick support to FreeBSD I need to do some changes I never did before so I could use some help. I tried to understand the changes made by Ken in order to add the winmm OSX driver but I don't get it =) In simple words I need to ensure that usbhid.h and dev/usb/usbhid.h exist and only if they exist compile the winejoystick driver. I believe it's a change in configure.ac but I tried adding these .h files to the long list of other .h files and it didn't work. Also I guess a similar change is needed like Ken did to enable the driver building: -test "$ac_cv_header_linux_joystick_h" = "yes" || enable_winejoystick_drv=${enable_winejoystick_drv:-no} +test "$ac_cv_header_linux_joystick_h" = "yes" -o "$ac_cv_header_IOKit_hid_IOHIDLib_h" = "yes" || enable_winejoystick_drv=${enable_winejoystick_drv:-no} Can anyone help? Best wishes and thanks in advance, Bruno

6 7

Re: comctl32/listview: Update view on style change only if LVS_TYPEMASK styles have changed
by Marvin 23 Mar '15

23 Mar '15

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://testbot.winehq.org/JobDetails.pl?Key=12359 Your paranoid android. === w7u (32 bit listview) === listview.c:5121: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5126: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === wvistau64 (64 bit listview) === listview.c:5121: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5126: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w2008s64 (64 bit listview) === listview.c:5121: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5126: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000

2 1

WIP: FreeBSD 10 usbhid joystick support
by Bruno Jesus 23 Mar '15

23 Mar '15

For those wondering (probably a few, lol) this is the WIP patch that is actually working for the standard HID gamepad I have. I also tried testing in a PS2 controller attached in a USB converter but FreeBSD does not recognize it. The configure part is still missing and it required "-lusbhid" to compile and I didn't find the correct place to add that so I'm currently compiling manually. I labeled it as FreeBSD 10 only because it was the only one I tried, probably may require changes to support other BSD systems. This task is proving to be harder than I expected due to my lack of knowledge in the area and any help testing is appreciated specially with different gamepads/joysticks (for example a joystick with a HAT). The problem with configure.ac is that both usbhid.h and dev/usb/usbhid.h must be included and that would require a compound "-o" switch to ensure that both must be present in order to make the driver. The last problem is where to put that -lusbhid is required when compiling the file. And of course testing in the configure script if usbhid lib is present. Best regards, Bruno

1 0

Re: [PATCH 3/3] scrrun: Support BYREF types for integer keys
by Marvin 22 Mar '15

22 Mar '15

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://testbot.winehq.org/JobDetails.pl?Key=12362 Your paranoid android. === wvistau64 (64 bit dictionary) === dictionary.c:542: Test failed: got hash 0x000001f4 === w2008s64 (64 bit dictionary) === dictionary.c:542: Test failed: got hash 0x000001f4

1 0

Re: [PATCH 2/3] scrrun: Added support for VT_DATE keys, and BYREF float key types
by Marvin 22 Mar '15

22 Mar '15

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://testbot.winehq.org/JobDetails.pl?Key=12361 Your paranoid android. === wvistau64 (64 bit dictionary) === dictionary.c:508: Test failed: got hash 0x000001f4 === w2008s64 (64 bit dictionary) === dictionary.c:508: Test failed: got hash 0x000001f4

1 0

Re: msvcrt: Fix bugs in math.c
by Piotr Caban 22 Mar '15

22 Mar '15

Hi, On 03/22/15 12:28, 陈正 wrote: > - Fixed the problem of atan(INF)/tanh(INF)/exp(INF) causing errno EDOM > - Fixed the error of _copysign(1., -0.) returning 1 Please don't send unrelated changes in one patch, please split it into 2 patches. The changes that remove errno setting from atan, tanh and exp looks good for me. > float CDECL MSVCRT__copysignf( float num, float sign ) > { > - /* FIXME: Behaviour for Nan/Inf? */ > - if (sign < 0.0) > - return num < 0.0 ? num : -num; > - return num < 0.0 ? -num : num; > + /* FIXME: Behaviour for signbit(NAN) is different in Linux and > + * Windows, where Windows gives a zero for -NAN > + */ > + if (signbit(sign)) > + return signbit(num) ? num : -num; > + return signbit(num) ? -num : num; > } Why don't you add an isnan() check? Is there any reason for returning "signbit(num) ? -num : num" instead of returning num? It would be nice to also change signbit definition on systems that doesn't support it, so it at least works for normal numbers. Thanks, Piotr

3 6

Re: [PATCH 2/4] ddraw/tests: The testbot applies color keying without a key.
by Marvin 22 Mar '15

22 Mar '15

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://testbot.winehq.org/JobDetails.pl?Key=12332 Your paranoid android. === w8 (32 bit ddraw1) === ddraw1.c:6302: Test failed: Got unexpected color 0x000000ff. ddraw1.c:6306: Test failed: Got unexpected color 0x00000080.

2 2

Re: [PATCH] wined3d: Don't use the builtin FFP uniform for the normal matrix.
by Matteo Bruni 21 Mar '15

21 Mar '15

2015-03-20 18:56 GMT+01:00 Matteo Bruni <mbruni(a)codeweavers.com>: > + memcpy(out, &temp, sizeof(temp)); Meh. Then there is the missing check for the singular matrix case as Sebastian spotted. I'll do some tests and resend, or send just a patch readding some calls to set GL_MODELVIEW if that takes too long.

1 0

Re: [PATCH] advapi32: succeed for null pointer in ChangeServiceConfig2
by Stefan Dösinger 20 Mar '15

20 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Good work debugging this. My knowledge about advapi32 is limited, but I have a comment about the test: Am 2015-03-19 um 13:06 schrieb Bernhard Übelacker: > + pConfig->lpDescription = NULL; > + ret = pChangeServiceConfig2A(svc_handle, SERVICE_CONFIG_DESCRIPTION,buffer); > + ok(ret, "ChangeServiceConfig2A failed with null pointer\n"); > + if (!ret) { > + goto cleanup; > + } Adding the test like this may work, but I don't think it is the right way. This call may overwrite settings set by the previous ChangeServiceConfig2A call if it succeeds. If it fails (and doesn't crash) the test can continue just fine since the previous call set up the configuration. I think it would be better to move this into its own test. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVDAHWAAoJEN0/YqbEcdMwNOgP/irtATTOHllTYLRxVI13UiNi muUvj+pkXYLHzmx6Fzrp90nlu6SCE5yqk4JkE+sHJO3xReQ0r5b7hnAKmgiAEsqk cVLjBXbyrP+gciLPfSJiYUHTwbfFOiEfKhcpcS4llGj2iHpU3XgEkvvTVrxzTfBz lAyp1shmD4zBLq9urW2/zc5YsXtzVOIRSKW2X+S8nyem+pikRi15F7Dm07hftquw Xv/krwZw/36/FKP6gkMk+5594OHmjHiknn+cQFkTZdLXiTdtSqzVWigTfn7IR4rT 0Y0eCeDQI16mcitAVnYgmaaOodIe/J8KmleBJb13VEQxQOIhPyU5ujHys6avoJks JeD/n2NUhzHtNqwxdiGLMnZJXPK3Jt9wSMF6EQu2hY0XURYwwPVEeWegjo/PfdO/ 9fwSRlTfBLVnYIM66fFbntR7M8S/aaYnXdRWNF49GRRgRLb7HMMC27yBnoGif1dC nhaFWS98jM4kByDSf3ib/OPqIdjPc9K/j6X2ilp/Tjx8ybiXxpB/GFojmyaP0j7p fZ4BH4edz85IrzS9Usq53ugpP1lViDeUWcoZrF6wBUrXgiP/EzqV+SNJTesDbFzX DjkhwhuQxsnmKS5hLQkX24uCmY0trs1CFm3eoN+eg2+tXVknLfrQ2M88AblPPxbS Wg5PW20xgEIZ1dbXShSZ =lLfe -----END PGP SIGNATURE-----

1 0

Re: mlang/tests: Use BSTR strings instead of plain WCHARs when API tells so
by Dmitry Timoshkov 20 Mar '15

20 Mar '15

The tests were written this way to ensure that mlang methods do not depend on BSTR layout (and yes, at least IE6 depends on this). -- Dmitry.

2 2

Re: user32/tests: Test return value of EnumDesktopsA (PVS-Studio)
by Marvin 19 Mar '15

19 Mar '15

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://testbot.winehq.org/JobDetails.pl?Key=12320 Your paranoid android. === w2000pro (32 bit winstation) === winstation.c:688: Test failed: EnumDesktopsA failed! === wvistau64 (64 bit winstation) === winstation.c:688: Test failed: EnumDesktopsA failed! === w2008s64 (64 bit winstation) === winstation.c:688: Test failed: EnumDesktopsA failed!

1 0

Compiling with GCC 5.0
by Michael Cronenworth 19 Mar '15

19 Mar '15

Has anyone given GCC 5.0 a shot? It breaks x86_64 for me and other Fedora 22+ users (22 and up use 5.0). Running wine as pure 32-bit does not exhibit issues. We're using 1.7.36 with wine-staging applied. In 64-bit mode it will not create a valid wine-prefix so I cannot run winedbg and nothing eventful happens with gdb attached to wine. Any ideas on how to debug this further? Here is the terminal output when a fresh prefix is attempted to be made: http://fpaste.org/187377/25868142/ Regards, Michael

3 9

Re: mstask: Added IEnumWorkItems stub
by Marvin 19 Mar '15

19 Mar '15

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://testbot.winehq.org/JobDetails.pl?Key=12318 Your paranoid android. === w2000pro (32 bit task_scheduler) === task_scheduler: unhandled exception c0000005 at 6AC2AEEF

1 0

Re: [PATCH] kernel32: Implement GetFinalPathNameByHandle
by Sebastian Lackner 19 Mar '15

19 Mar '15

On 19.03.2015 16:22, Andrew Eikum wrote: > --- > dlls/kernel32/kernel32.spec | 4 +- > dlls/kernel32/path.c | 97 +++++++++++++++++++++++++++++++++++++++++++++ > dlls/kernel32/tests/file.c | 88 ++++++++++++++++++++++++++++++++++++++++ > include/winbase.h | 2 + > 4 files changed, 189 insertions(+), 2 deletions(-) > Why do you do the work twice? It would have been much easier if you would have just helped us to review and improve our Staging patchset which is there since about half a year ago, and supports a lot more flags. https://github.com/wine-compholio/wine-staging/blob/master/patches/kernel32… https://github.com/wine-compholio/wine-staging/blob/master/patches/kernel32… Why does noone bother anymore to test those patches, the author Michael Müller asked for feedback there long time ago: https://bugs.winehq.org/show_bug.cgi?id=36073#c4 I'll submit the patches in a few minutes so that you can decide if its better/worse than the current approach. Regards, Sebastian

3 6

Re: [PATCH] kernel32: Implement GetFinalPathNameByHandle
by Marvin 19 Mar '15

19 Mar '15

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://testbot.winehq.org/JobDetails.pl?Key=12304 Your paranoid android. === wvistau64 (32 bit file) === file.c:369: Test failed: attributes of file "testfile.xxx" are 0x0820 === w7u (32 bit file) === file.c:4060: Test failed: SetFileValidData failed 87 file.c:4063: Test failed: SetFileValidData failed 87 === wvistau64 (64 bit file) === file.c:369: Test failed: attributes of file "testfile.xxx" are 0x0820

1 0

Re: [PATCH] kernel32: Implement GetFinalPathNameByHandle
by Dmitry Timoshkov 19 Mar '15

19 Mar '15

Andrew Eikum <aeikum(a)codeweavers.com> wrote: > + info->FileName[info->FileNameLength / sizeof(WCHAR)] = 0; > + if (!RtlDosPathNameToNtPathName_U( info->FileName, &nt_name, NULL, NULL )) > + { > + SetLastError( ERROR_PATH_NOT_FOUND ); > + return 0; > + } > + > + name_wchars = nt_name.Length / sizeof(WCHAR); > + if (name_wchars + 1 > len) > + { > + RtlFreeUnicodeString( &nt_name ); > + return name_wchars + 1; > + } > + > + memcpy( outstr, nt_name.Buffer, nt_name.Length ); > + outstr[name_wchars] = 0; Where did you get an idea that you should return an nt path from this API? There is no a single check in the tests for a returned file name, and this whole thing looks over complicated. -- Dmitry.

1 0

Re: [PATCH] kernel32: Implement GetFinalPathNameByHandle
by Piotr Caban 19 Mar '15

19 Mar '15

On 03/19/15 16:22, Andrew Eikum wrote: > + char data[MAX_PATH * sizeof(WCHAR) + sizeof(info->FileNameLength)]; Is the path limited to MAX_PATH characters?

2 1

Re: [PATCH] kernel32: Implement GetFinalPathNameByHandle
by Nikolay Sivov 19 Mar '15

19 Mar '15

On 19.03.2015 18:22, Andrew Eikum wrote: > +/************************************************************************* > + * GetFinalPathNameByHandleA (KERNEL32.@) > + */ > +DWORD WINAPI GetFinalPathNameByHandleA(HANDLE handle, char *outstr, DWORD len, > + DWORD flags) > +{ > + WCHAR *wstr; > + DWORD dw; > + > + if (len > 0) > + { > + wstr = HeapAlloc( GetProcessHeap(), 0, len * sizeof(WCHAR) ); > + if (!wstr) > + { > + SetLastError( ERROR_OUTOFMEMORY ); > + return 0; > + } > + } > + else > + wstr = NULL; > + > + dw = GetFinalPathNameByHandleW( handle, wstr, len, flags ); > + > + if (dw > 0 && dw < len) > + { > + /* success */ > + > + dw = WideCharToMultiByte( CP_ACP, 0, wstr, -1, NULL, 0, NULL, NULL ); > + if (dw > len) > + { > + /* buffer too small */ > + HeapFree( GetProcessHeap(), 0, wstr ); > + return dw; > + } > + > + dw = WideCharToMultiByte( CP_ACP, 0, wstr, -1, outstr, len, NULL, NULL ); > + if (!dw) > + { > + HeapFree( GetProcessHeap(), 0, wstr ); > + return 0; > + } > + > + /* don't report NUL */ > + dw = dw - 1; > + } > + > + HeapFree( GetProcessHeap(), 0, wstr ); > + > + return dw; > +} > + This doesn't look right. Proper way would be: - call GetFinalPathNameByHandleW() with NULL buffer to get required length; - allocated WCHAR buffer and get a path in it; - call WideCharToMultiByte() with NULL output buffer to get required length for CP_ACP string; - do what you need to do if A buffer length is too small. Right now you're assuming that WCHAR representation has same number of characters as CP_ACP one, I don't think it's always a case.

2 1

Bug that still exists for almost 10 years.
by Joshua Hale 19 Mar '15

19 Mar '15

Hello, I'm helping with the first private server for Phantasy Online Universe that will be made public really soon, but the game can't run correctly with this problem: https://bugs.winehq.org/show_bug.cgi?id=6955 It's been about almost 10 years that this issue has been submitted. We were told in 2009 that there was plans to get this fixed. https://forum.winehq.org/viewtopic.php?f=2&t=6626 but nothing has came from it. This is a bit important that this gets fixed soon or else the Mac wine wrapper at launch will be a dud... Can somebody tell me the progress of this? -- Thanks, Joshua Hale

2 1

Re: [PATCH] advapi32: succeed for null pointer in ChangeServiceConfig2
by Nikolay Sivov 19 Mar '15

19 Mar '15

On 19.03.2015 15:06, Bernhard Übelacker wrote: > @@ -2217,7 +2217,13 @@ BOOL WINAPI ChangeServiceConfig2W( SC_HANDLE hService, DWORD dwInfoLevel, > > info.dwInfoLevel = dwInfoLevel; > info.u.descr = lpInfo; > - err = svcctl_ChangeServiceConfig2W( hService, info ); > + > + if (info.u.descr->lpDescription) > + { > + err = svcctl_ChangeServiceConfig2W( hService, info ); > + } else { > + err = ERROR_SUCCESS; > + } In this case it's better to return earlier, no need to step into try..expect block if you know you won't call anything.

1 0

Re: [2/2] shell32: Fix SHFileOperation(FO_MOVE) for a directory with subdirectories.
by Marvin 19 Mar '15

19 Mar '15

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://testbot.winehq.org/JobDetails.pl?Key=12288 Your paranoid android. === wvistau64 (32 bit shlfileop) === shlfileop.c:818: Test failed: Expected ERROR_CANCELLED or DE_DIFFDIR === wvistau64 (64 bit shlfileop) === shlfileop.c:818: Test failed: Expected ERROR_CANCELLED or DE_DIFFDIR

1 0

Re: [1/2] shell32/tests: Add a couple of SHFileOperation(FO_MOVE) tests for a directory.
by Marvin 19 Mar '15

19 Mar '15

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://testbot.winehq.org/JobDetails.pl?Key=12287 Your paranoid android. === wvistau64 (32 bit shlfileop) === shlfileop.c:818: Test failed: Expected ERROR_CANCELLED or DE_DIFFDIR === wvistau64 (64 bit shlfileop) === shlfileop.c:818: Test failed: Expected ERROR_CANCELLED or DE_DIFFDIR

2 1

Re: ntdll: Use lockfree implementation for get_cached_fd. (resend)
by Alexandre Julliard 19 Mar '15

19 Mar '15

Sebastian Lackner <sebastian(a)fds-team.de> writes: > Contains a couple of small improvements compared with the last > attempt. As a reminder, the #ifdefs are there because we do not have > 64-bit interlocked instructions on PowerPC (and I have also no idea if > its possible at all to implement them properly). I'm not sure we care enough about PowerPC to require this, but in any case it would have to be done without spreading #ifdefs all over the code. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [2/3] ntdll: Expose wine_uninterrupted_[read|write]_memory as exports.
by Alexandre Julliard 19 Mar '15

19 Mar '15

Sebastian Lackner <sebastian(a)fds-team.de> writes: > Since APCs are also implemented outside of ntdll, we need to expose memory management functions. > The alternative solution would be to move ws2_32 code to ntdll. That would be preferable, if you find a way to do it cleanly. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] include: Add undocumented theming hook structs to winuser.h.
by Dmitry Timoshkov 19 Mar '15

19 Mar '15

[please keep wine-devel in the cc: list] Mark Harmstone <hellas(a)burntcomma.com> wrote: > >> Adds the undocumented structs to winuser.h which are needed for uxtheme to hook > >> into user32. As researched by ReactOS: see https://www.reactos.org/wiki/Techwiki:RegisterUserApiHook > > > > Referencing reactos as a source of the information makes it unlikely > > to improve the chances of including the patch in Wine. > > What? Why? They've already done the research... To make long story short - ReactOS' understanding of allowed research practices doesn't match the accepted Wine standards. > > Moreover, as > > was already discussed many times, theme interface is completely > > undocumented and different between Windows versions, therefore it's > > very unlikely that there is an application that depends on the > > details of this interface, thus making it unnecessary to duplicate > > it in Wine. > > > > Well, I'm about to submit patches to allow uxtheme to hook into user32, > so it can theme the non-client areas like scrollbars. Clearly some > sort of shared interface is needed for this, would you not agree? Just making this interface Wine specific would work better IMHO. Using that approach you could add the needed pieces one by one. -- Dmitry.

1 0

Re: [PATCH] vbscript: Implemented GetLocale(try 2)
by Piotr Caban 19 Mar '15

19 Mar '15

On 03/17/15 09:29, Shuai Meng wrote: > -#define DISPID_GLOBAL_VBMSGBOXHELPBUTTON 207 > -#define DISPID_GLOBAL_VBMSGBOXSETFOREGROUND 208 > -#define DISPID_GLOBAL_VBMSGBOXRIGHT 209 > -#define DISPID_GLOBAL_VBMSGBOXRTLREADING 210 > +#define DISPID_GLOBAL_VBMSGBOXHELPBUTTON 208 > +#define DISPID_GLOBAL_VBMSGBOXSETFOREGROUND 209 > +#define DISPID_GLOBAL_VBMSGBOXRIGHT 210 > +#define DISPID_GLOBAL_VBMSGBOXRTLREADING 211 > > #define DISPID_GLOBAL_CCUR 100 > #define DISPID_GLOBAL_CINT 101 > @@ -210,6 +210,7 @@ > #define DISPID_GLOBAL_EXECUTE 204 > #define DISPID_GLOBAL_EXECUTEGLOBAL 205 > #define DISPID_GLOBAL_GETREF 206 > +#define DISPID_GLOBAL_GETLOCALE 207 This changes are not matching the typelib in native vbscript.dll. It looks like GetLocale function is not defined there at all.

2 3

uartz.dll and some other newbie questions
by Ali Aminian 19 Mar '15

19 Mar '15

Hello I have 3 newbie questions. 1_I'm interested in quartz.dll but i can't find any resources. can any one help me where can i find information about this dll. 2_plus wine used to crash during playing video files in games when "native quartz.dll" had been installed. I'm interested to know what was the problem. 3_Wine documentation says native dlls should be enabled through winecfg or through command line: "WINEDLLOVERRIDES=quartz=n wine myapp.ex.e" but where does wine look for native dlls.(for instance how quartz.dll should be installed without winetricks)

2 1

Wine GSoC 2015 | mshtml.dll
by Zhenbo Li 18 Mar '15

18 Mar '15

Hello, everyone I'm Zhenbo Li, a college student who participated in GSoC 2014 for mshtml.dll. I'm glad to continue working on mshtml this year. My idea is to implement IHTMLXMLHttpRequest+IHTMLStorage(sessionStorage) as my project. 1.IHTMLXMLHttpRequest ================== XMLHttpRequest is used heavily in AJAX programming.[1] Wine has implemented most of it in msxml component, but it's a stub in mshtml. Most js code doesn't treat wine IE as IE6 or earlier, so they will not choost ActiveX[2] to work around it(like Firebug Lite[3]) My current implementation only works fine for absolute urls[4]. I've located the first obstacle: typedef struct { //... IUri *base_uri; //... } httprequest; After finding a way to pass base_uri from mshtml.dll to msxml3.dll, Wine Gecko should support IHTMLXMLHttpRequest for relative urls[5]. 2. sessionStorage =============== IHTMLStorage[6] is used widely, including Firebug Lite[3]. A well-implemented IHTMLStorage interface should support both sessionStorage and localStorage. I tried to write both of them, but found that it may be necessary to adjust wine-gecko code to support that(Thank Jacek). Therefore, implementing sessionStorage can be the first step of implementing localStorage. This is my idea for GSoC 2015, I appreciate for any comment. Thank you. [1]: https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest [2]: http://en.wikipedia.org/wiki/XMLHttpRequest#Support_in_Internet_Explorer_ve… [3]: https://getfirebug.com/firebuglite [4]: http://lzbtesthustoj1000.u.qiniudn.com/xmlhttprequest_absolute_path.html [5]: http://lzbtesthustoj1000.u.qiniudn.com/new_xmlhttp.html [6]: https://msdn.microsoft.com/en-us/library/cc288313%28v=vs.85%29.aspx -- Have a nice day! Zhenbo Li

1 1

Re: [PATCH 7/7] wined3d: Don't use the builtin FFP uniform for the modelview matrix.
by Stefan Dösinger 18 Mar '15

18 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi I've given this only a very quick look. My first impression is that a few things can be split out into separate patches, e.g. get_modelview_matrix. That's a fairly minor thing though. On a somewhat related subject, I think we should check at some point that the state linking still works as intended and doesn't accidentally merge everything together into one huge state that's always updated. Am 2015-03-17 um 15:52 schrieb Matteo Bruni: > @@ -775,6 +777,15 @@ static void shader_glsl_load_constants(void *shader_priv, struct wined3d_context > checkGLcall("glUniform4fv"); > } > > + if (update_mask & WINED3D_SHADER_CONST_FFP_MODELVIEW) > + { > + struct wined3d_matrix mat; > + > + get_modelview_matrix(context, state, &mat); > + GL_EXTCALL(glUniformMatrix4fv(prog->vs.modelview_matrix_location, 1, FALSE, (GLfloat *)&mat)); > + checkGLcall("glUniformMatrix4fv"); > + } > + > if (update_mask & WINED3D_SHADER_CONST_PS_F) > shader_glsl_load_constantsF(pshader, gl_info, state->ps_consts_f, > prog->ps.uniform_f_locations, &priv->pconst_heap, priv->stack, constant_version); Is it a good idea to put this in shader_glsl_load_constants? It may make sense to split fixed function and shader constants into separate functions. We'll never need shader constants and the modelview matrix in the same program. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVCKLoAAoJEN0/YqbEcdMw9wIQAIrMIkc5I9LTRiYnUI+VRAxq wkSX0Uwny7D1sVPCpJxrUu6I04K0u2oWIr0o5XmYQzzETrgthPCsifaHVGlInuaq BfJQCGE1OFEEtFKBtIIB8TCQpMM6dwxYnCc4Zo+rPX2oodJFe9TplJnQw/WUw/Td OeMXNKD316ESUbTa9O5CdMyEcw9+U0TKc2MUGHX5QjGMqKEoYA8wfP+r5VU/dNHo 5hMNenwMawaXgICAsxwQQr/YmCRrUuLvLeAJSCNLGgqSH6v5S4tVmW9tgTjT9Idv RHtFkrsiKg0FKDcyQc1vdmFYtpijE44bM4ULdFCJfIgeRl76Gt0WI17aEZpVvJOx HG5nZsidn/TXwkGWla8CT6k7l4JF8rDNgFbOWkQ7JMTRBThamphABgGR9I57L+9+ mCDUqm775VWpBMHbS4iEM4y1s/K17zDRisd9lbP9JFTOGJ2qT31d3+6Ba4t6FGJR mRZiLE+QVWaScWEJaktC4Cbcl1xKQfu653XdL6YumxRBU5fWBEGZnbSwGh/ePpim YZrC0zHE8E1pVwu6hUfNzahB8L/7P7NoPoWb813NBkk8tul7dCCWcZZ0W75cJgac R0sb4mPaLZ+TrWR4YaQ1jZ66WsABKcDPiGZmAzJpxnCcIVy2uZcC3C3zxXDTQqHZ A3SrlC8X/Vx4iFLg1eD7 =jJVx -----END PGP SIGNATURE-----

2 1

Re: [PATCH 7/7] wined3d: Don't use the builtin FFP uniform for the modelview matrix.
by Henri Verbeet 18 Mar '15

18 Mar '15

On 17 March 2015 at 15:52, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > +void get_identity_matrix(struct wined3d_matrix *mat) > +{ > + static const struct wined3d_matrix identity = > + {{{ > + 1.0f, 0.0f, 0.0f, 0.0f, > + 0.0f, 1.0f, 0.0f, 0.0f, > + 0.0f, 0.0f, 1.0f, 0.0f, > + 0.0f, 0.0f, 0.0f, 1.0f, > + }}}; > + > + memcpy(mat, &identity, sizeof(identity)); Shouldn't that just be "*mat = identity;"? And yeah, if you could split this up a bit that would be nice, as it is I think the state handler changes in particular are a bit hard to review properly.

1 0

Re: [PATCH 1/7] wined3d: Report ATI1N and ATI2N volume textures as not supported.
by Henri Verbeet 18 Mar '15

18 Mar '15

On 17 March 2015 at 15:52, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > This causes test failures here: ../../../tools/runtest -q -P wine -T ../../.. -M d3d8.dll -p d3d8_test.exe.so device && touch device.ok ... device.c:6019: Test succeeded inside todo block: Got unexpected hr 0 for format ATI1N, pool D3DPOOL_DEFAULT, size 1x1x1. etc.

1 0

GSoC 2015 proposal
by Iván Matellanes 18 Mar '15

18 Mar '15

Hi devs! I'm a last-year Computer Engineering student from the Basque Country (Spain), and I'd like to take part in the upcoming edition of the Google Summer of Code. I've already explored the wiki and have some ideas to discuss with you. As some of you might remember, I sent some patches back in October/November about msvcrt file operations. If possible, I'd like to continue developing that API since it's the one I'm most comfortable with. I've thought of the following so far: 1. Implement some stream functions from msvcirt: choose some subset of these functions and implement them. 2. Implement internal exception-related functions from msvcrt (like _crt_debugger_hook, __CxxExceptionFilter, and so on): these are needed by several apps apparently, but mostly undocumented. I wonder if low-level details knowledge is required for this task (x86 assembly maybe?). 3. Implement part of the concurrency runtime: having a brief look at the documentation on MSDN, it seems a huge API and I wouldn't really know where to begin. I've worked with OpenMP before, but this one looks like more complex. I'm open to suggestions and new ideas, of course. Thanks for your time, and I look forward to hear your thoughts and comments. And thanks as well to other students who posted their ideas in this list. Best, Iván

2 1

RFC: Add an icon to hh.exe?
by Francois Gouget 18 Mar '15

18 Mar '15

I noticed that winemenubuilder falls back to the default Wine icon for a number of Windows menus, and in particular for all the help / documentation shortcuts. The reason is that we define no default icon for .chm files. On Windows this icon is in hh.exe but in Wine hh.exe has no icon. So would it be ok if I send a patch that copies the winhlp32 default icon and uses that for hh.exe and then .chm files? Is there a way to reuse the winhlp32.exe icon without copying it to programs/hh? Is that actually desired? (it makes programs/hh depend on programs/winhlp32 which we may not want) Do we instead want a different icon? On Windows the hh.exe icon is totally different from the winhlp32.exe one but it's actually absolutely ugly so I don't really want anything like it. Still it's possible to come up with something. Yet another way would be to not add an icon to hh.exe and instead point the .chm default icon to winhlp32.exe. But presumably we'll have to add the hh.exe icon sooner or later anyway so we might as well now. -- Francois Gouget <fgouget(a)codeweavers.com>

2 1

Re: Assorted spelling fixes.
by Henri Verbeet 18 Mar '15

18 Mar '15

On 18 March 2015 at 08:44, Francois Gouget <fgouget(a)free.fr> wrote: > diff --git a/dlls/d3d10core/tests/device.c b/dlls/d3d10core/tests/device.c > index 68012ac..f8a74eb 100644 > --- a/dlls/d3d10core/tests/device.c > +++ b/dlls/d3d10core/tests/device.c > @@ -1238,7 +1238,7 @@ struct gs_out > }; > > [maxvertexcount(4)] > -void main(point float4 vin[1] : POSTION, inout TriangleStream<gs_out> vout) > +void main(point float4 vin[1] : POSITION, inout TriangleStream<gs_out> vout) In principle this change is correct, but if you do that it no longer matches the shader bytecode.

1 0

Re: [PATCH] include: Add undocumented theming hook structs to winuser.h.
by Dmitry Timoshkov 18 Mar '15

18 Mar '15

Mark Harmstone <hellas(a)burntcomma.com> wrote: > Adds the undocumented structs to winuser.h which are needed for uxtheme to hook > into user32. As researched by ReactOS: see https://www.reactos.org/wiki/Techwiki:RegisterUserApiHook Referencing reactos as a source of the information makes it unlikely to improve the chances of including the patch in Wine. Moreover, as was already discussed many times, theme interface is completely undocumented and different between Windows versions, therefore it's very unlikely that there is an application that depends on the details of this interface, thus making it unnecessary to duplicate it in Wine. -- Dmitry.

1 0

Re: Assorted spelling fixes.
by Marvin 18 Mar '15

18 Mar '15

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://testbot.winehq.org/JobDetails.pl?Key=12263 Your paranoid android. === w8 (32 bit device) === device.c:1222: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1267: Test failed: Reset failed, hr 0x88760868. device.c:1269: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1273: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1280: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1281: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1282: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1283: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1284: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1285: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1290: Test failed: Screen width is 640, expected 800. device.c:1291: Test failed: Screen height is 480, expected 600. device.c:1297: Test failed: Back buffer width is 640, expected 800. device.c:1299: Test failed: Back buffer height is 480, expected 600. device.c:1329: Test failed: Screen width is 640, expected 1024. device.c:1330: Test failed: Screen height is 480, expected 768. device.c:2557: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2562: Test failed: The focus window is active. device.c:2570: Test failed: Got unexpected hr 0x88760869. device.c:2576: Test failed: Got unexpect screen size 800x600. device.c:2591: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2600: Test failed: Got unexpect screen size 800x600. device.c:2613: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2621: Test failed: Got unexpect width 640. device.c:2622: Test failed: Got unexpect height 480.

1 0

Re: [PATCH] vbscript: Implemented GetLocale(try 2)
by Nikolay Sivov 18 Mar '15

18 Mar '15

On 17.03.2015 11:29, Shuai Meng wrote: > + return return_int(res, GetSystemDefaultLCID()); How did you test that it's system default and not user default or current thread locale?

2 1

Re: [3/4] msvcp120/tests: Add file_size test.
by Piotr Caban 18 Mar '15

18 Mar '15

Hi, On 17/03/15 16:41, YongHao Hu wrote: > +static void test_tr2_sys_file_size(void) > +{ > + unsigned long long val; > + val = p_tr2_sys_file_size("dir/d1/d1f1"); > + ok(val==0, "test fail: file_size is %llu\n", val); The tests needs to pass on wine. You can test your patch by running `make test` in dlls/msvcp120/tests directory. Because of that you can't test a function that is defined as stub in spec file. GetProcAddress will load such function but when called stub will cause an exception. When the function is implemented you can add tests that doesn't work on wine and mark them with todo_wine. Thanks, Piotr

2 1

Re: [PATCH 2/3] ddraw/tests: Port test_color_fill to earlier versions.
by Marvin 18 Mar '15

18 Mar '15

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://testbot.winehq.org/JobDetails.pl?Key=12260 Your paranoid android. === w8 (32 bit ddraw1) === ddraw1.c:6215: Test failed: Got unexpected color 0x00000000. ddraw1.c:6217: Test failed: Got unexpected color 0x00000000. ddraw1.c:6219: Test failed: Got unexpected color 0x00000000. ddraw1.c:6221: Test failed: Got unexpected color 0x00000000.

1 0

Re: [2/4] msvcp120/tests: Add 64bit and arm's initialization of xtime functions.
by Nikolay Sivov 18 Mar '15

18 Mar '15

On 17.03.2015 18:41, YongHao Hu wrote: > + if(sizeof(void*) == 8) { /* 64-bit initialization */ > + SET(p__Xtime_diff_to_millis2, > + "_Xtime_diff_to_millis2"); > + SET(p_xtime_get, > + "xtime_get"); > + } else { > +#ifdef __arm__ > + SET(p__Xtime_diff_to_millis2, > + "_Xtime_diff_to_millis2"); > + SET(p_xtime_get, > + "xtime_get"); > +#else > + SET(p__Xtime_diff_to_millis2, > + "_Xtime_diff_to_millis2"); > + SET(p_xtime_get, > + "xtime_get"); > +#endif Why do you need this if export name is always the same?

2 1

Re: [PATCH 2/2] d3drm/tests: Add more interfaces for d3drm1_QueryInterface and remove dependency on InitFunctionPtrs().
by Stefan Dösinger 17 Mar '15

17 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-03-17 um 18:49 schrieb Aaryaman Vasishta: > -static BOOL InitFunctionPtrs(void) > -{ > - d3drm_handle = LoadLibraryA("d3drm.dll"); > - > - if(!d3drm_handle) > - { > - skip("Could not load d3drm.dll\n"); > - return FALSE; > - } > - > - D3DRM_GET_PROC(Direct3DRMCreate) > - > - return TRUE; > -} Removing this is a good change, but it should be in a separate patch. Please do the same for vector.c, in another separate patch. > + { &IID_IDirect3DRM, &IID_IDirect3DRM, S_OK, FALSE }, > + { &IID_IDirect3DRMDevice, NULL, CLASS_E_CLASSNOTAVAILABLE, FALSE }, Minor issue: Is the line misalignment here intentional? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVCJ+8AAoJEN0/YqbEcdMwBw8P/RmJiYSf0C75cddsSSYqZb2v JdPPqOhHHt5kedsMCrV68rYzqTwKpztaFszWiffOyZgEvxMh+a6qoLM2BnfT8mxQ PdNxftnKcsyI0RQCAYOBBBDSS9YXGCs1ohB0sLZIdX5kSgc5M6JGiziPb51rXicW Kv2eJxaYM96YsEXDjw6ShAGCCYByQ/qHVeAmztmGF36FEgH92FzaVdFujGdEz1Px nG4trHla0OYmVk9Q6Pppd3LA4KOBvbdYhPM5DHqNOk7FVNRGfdKi7ZjWUnP11Kc3 NXSZE2koQXpPYYtVNVKSr244mLmJjqNjXlHwPa42LQ3cwUnoqVBqCwvXaFlnu/CE R/gsDbHoUnWoMBbHZc5MUxRS+zDXXjAsKdbPBI4sDQQI8XoXNLoGudW05VjFXb1w qQObPWTLs62j8u8iHyJ+GpVyohaqtixX6i4P8uBjS7X+sOCyuR6bC9s4w1HPeP6A 04O3IwzE2+E6xV6sFeJj7Ibu8OCy96zJ/dKnH/iorI9kGdl5amQBvCjhROw20b8D ApXallY+3p44RFqNis/xHvqYxVXRzqMu7ZQAjm77jXNAvC96n2iMYmgdGRLth5Of Mxzw6NOWXnT6g9D/h6G+VtLrIWHXS/4ExaKoIIpyyqK1JNSSRLbeHQCrpLUpm4ks sTiU6Hr+oM1c/H7+Tlg2 =x4GY -----END PGP SIGNATURE-----

1 0

Re: [PATCH 2/2] d3drm/tests: Add more interfaces for d3drm1_QueryInterface and remove dependency on InitFunctionPtrs().
by Aaryaman Vasishta 17 Mar '15

17 Mar '15

Made d3drm use wine's implementation instead of loading dll at runtime. On Tue, Mar 17, 2015 at 11:19 PM, Aaryaman Vasishta < jem456.vasishta(a)gmail.com> wrote: > --- > dlls/d3drm/tests/Makefile.in | 2 +- > dlls/d3drm/tests/d3drm.c | 132 > +++++++++++++++++++++++++++---------------- > 2 files changed, 84 insertions(+), 50 deletions(-) > > diff --git a/dlls/d3drm/tests/Makefile.in b/dlls/d3drm/tests/Makefile.in > index dc6e8d1..b5fdb56 100644 > --- a/dlls/d3drm/tests/Makefile.in > +++ b/dlls/d3drm/tests/Makefile.in > @@ -1,5 +1,5 @@ > TESTDLL = d3drm.dll > -IMPORTS = dxguid ddraw user32 uuid > +IMPORTS = d3drm dxguid ddraw user32 uuid > > C_SRCS = \ > d3drm.c \ > diff --git a/dlls/d3drm/tests/d3drm.c b/dlls/d3drm/tests/d3drm.c > index f9925ae..edc451b 100644 > --- a/dlls/d3drm/tests/d3drm.c > +++ b/dlls/d3drm/tests/d3drm.c > @@ -26,9 +26,6 @@ > > #include "wine/test.h" > > -static HMODULE d3drm_handle = 0; > - > -static HRESULT (WINAPI * pDirect3DRMCreate)(IDirect3DRM **d3drm); > > #define CHECK_REFCOUNT(obj,rc) \ > { \ > @@ -37,28 +34,6 @@ static HRESULT (WINAPI * pDirect3DRMCreate)(IDirect3DRM > **d3drm); > ok(count == rc_new, "Invalid refcount. Expected %d got %d\n", > rc_new, count); \ > } > > -#define D3DRM_GET_PROC(func) \ > - p ## func = (void*)GetProcAddress(d3drm_handle, #func); \ > - if(!p ## func) { \ > - trace("GetProcAddress(%s) failed\n", #func); \ > - FreeLibrary(d3drm_handle); \ > - return FALSE; \ > - } > - > -static BOOL InitFunctionPtrs(void) > -{ > - d3drm_handle = LoadLibraryA("d3drm.dll"); > - > - if(!d3drm_handle) > - { > - skip("Could not load d3drm.dll\n"); > - return FALSE; > - } > - > - D3DRM_GET_PROC(Direct3DRMCreate) > - > - return TRUE; > -} > > static int get_refcount(IUnknown *object) > { > @@ -242,7 +217,7 @@ static void test_MeshBuilder(void) > D3DCOLOR color; > CHAR cname[64] = {0}; > > - hr = pDirect3DRMCreate(&d3drm); > + hr = Direct3DRMCreate(&d3drm); > ok(hr == D3DRM_OK, "Cannot get IDirect3DRM interface (hr = %x)\n", > hr); > > hr = IDirect3DRM_CreateMeshBuilder(d3drm, &pMeshBuilder); > @@ -538,7 +513,7 @@ static void test_MeshBuilder3(void) > DWORD size; > CHAR cname[64] = {0}; > > - hr = pDirect3DRMCreate(&d3drm); > + hr = Direct3DRMCreate(&d3drm); > ok(hr == D3DRM_OK, "Cannot get IDirect3DRM interface (hr = %x)\n", > hr); > > if (FAILED(hr = IDirect3DRM_QueryInterface(d3drm, &IID_IDirect3DRM3, > (void **)&d3drm3))) > @@ -644,7 +619,7 @@ static void test_Mesh(void) > DWORD size; > CHAR cname[64] = {0}; > > - hr = pDirect3DRMCreate(&d3drm); > + hr = Direct3DRMCreate(&d3drm); > ok(hr == D3DRM_OK, "Cannot get IDirect3DRM interface (hr = %x)\n", > hr); > > hr = IDirect3DRM_CreateMesh(d3drm, &mesh); > @@ -685,7 +660,7 @@ static void test_Face(void) > CHAR cname[64] = {0}; > int icount; > > - hr = pDirect3DRMCreate(&d3drm); > + hr = Direct3DRMCreate(&d3drm); > ok(hr == D3DRM_OK, "Cannot get IDirect3DRM interface (hr = %x)\n", > hr); > > hr = IDirect3DRM_CreateFace(d3drm, &face1); > @@ -925,7 +900,7 @@ static void test_Frame(void) > DWORD count; > CHAR cname[64] = {0}; > > - hr = pDirect3DRMCreate(&d3drm); > + hr = Direct3DRMCreate(&d3drm); > ok(hr == D3DRM_OK, "Cannot get IDirect3DRM interface (hr = %x)\n", > hr); > > hr = IDirect3DRM_CreateFrame(d3drm, NULL, &pFrameC); > @@ -1257,7 +1232,7 @@ static void test_Viewport(void) > window = CreateWindowA("static", "d3drm_test", WS_OVERLAPPEDWINDOW, > 0, 0, 300, 200, 0, 0, 0, 0); > GetClientRect(window, &rc); > > - hr = pDirect3DRMCreate(&d3drm); > + hr = Direct3DRMCreate(&d3drm); > ok(hr == D3DRM_OK, "Cannot get IDirect3DRM interface (hr = %x)\n", > hr); > > hr = DirectDrawCreateClipper(0, &pClipper, NULL); > @@ -1308,7 +1283,7 @@ static void test_Light(void) > DWORD size; > CHAR cname[64] = {0}; > > - hr = pDirect3DRMCreate(&d3drm); > + hr = Direct3DRMCreate(&d3drm); > ok(hr == D3DRM_OK, "Cannot get IDirect3DRM interface (hr = %x)\n", > hr); > > hr = IDirect3DRM_CreateLightRGB(d3drm, D3DRMLIGHT_SPOT, 0.5, 0.5, > 0.5, &light); > @@ -1363,7 +1338,7 @@ static void test_Material2(void) > DWORD size; > CHAR cname[64] = {0}; > > - hr = pDirect3DRMCreate(&d3drm); > + hr = Direct3DRMCreate(&d3drm); > ok(hr == D3DRM_OK, "Cannot get IDirect3DRM interface (hr = %x)\n", > hr); > > if (FAILED(hr = IDirect3DRM_QueryInterface(d3drm, &IID_IDirect3DRM3, > (void **)&d3drm3))) > @@ -1447,7 +1422,7 @@ static void test_Texture(void) > DWORD size; > CHAR cname[64] = {0}; > > - hr = pDirect3DRMCreate(&d3drm); > + hr = Direct3DRMCreate(&d3drm); > ok(hr == D3DRM_OK, "Cannot get IDirect3DRM interface (hr = %x)\n", > hr); > > initimg.buffer1 = &pixel; > @@ -1488,7 +1463,7 @@ static void test_Device(void) > window = CreateWindowA("static", "d3drm_test", WS_OVERLAPPEDWINDOW, > 0, 0, 300, 200, 0, 0, 0, 0); > GetClientRect(window, &rc); > > - hr = pDirect3DRMCreate(&d3drm); > + hr = Direct3DRMCreate(&d3drm); > ok(hr == D3DRM_OK, "Cannot get IDirect3DRM interface (hr = %x)\n", > hr); > > hr = DirectDrawCreateClipper(0, &pClipper, NULL); > @@ -1551,7 +1526,7 @@ static void test_frame_transform(void) > IDirect3DRMFrame *frame; > D3DRMMATRIX4D matrix; > > - hr = pDirect3DRMCreate(&d3drm); > + hr = Direct3DRMCreate(&d3drm); > ok(hr == D3DRM_OK, "Cannot get IDirect3DRM interface (hr = %x)\n", > hr); > > hr = IDirect3DRM_CreateFrame(d3drm, NULL, &frame); > @@ -1589,7 +1564,7 @@ static void test_d3drm_load(void) > D3DRMLOADMEMORY info; > const GUID* req_refiids[] = { &IID_IDirect3DRMMeshBuilder, > &IID_IDirect3DRMFrame, &IID_IDirect3DRMMaterial }; > > - hr = pDirect3DRMCreate(&d3drm); > + hr = Direct3DRMCreate(&d3drm); > ok(hr == D3DRM_OK, "Cannot get IDirect3DRM interface (hr = %x)\n", > hr); > > info.lpMemory = data_d3drm_load; > @@ -1665,7 +1640,7 @@ static void test_frame_mesh_materials(void) > IDirect3DRMTexture *texture; > int i; > > - hr = pDirect3DRMCreate(&d3drm); > + hr = Direct3DRMCreate(&d3drm); > ok(hr == D3DRM_OK, "Direct3DRMCreate returned %x\n", hr); > > info.lpMemory = data_frame_mesh_materials; > @@ -1736,7 +1711,7 @@ struct qi_test > }; > > static void test_qi(const char *test_name, IUnknown *base_iface, > - REFIID refcount_iid, const struct qi_test *tests, > UINT entry_count) > + REFIID refcount_iid, const struct qi_test *tests, UINT > entry_count) > { > ULONG refcount, expected_refcount; > IUnknown *iface1, *iface2; > @@ -1788,15 +1763,79 @@ static void test_d3drm_qi(void) > { > static const struct qi_test tests[] = > { > - { &IID_IDirect3DRM3, &IID_IDirect3DRM3, S_OK, TRUE }, > - { &IID_IDirect3DRM2, &IID_IDirect3DRM2, S_OK, TRUE }, > - { &IID_IDirect3DRM, &IID_IDirect3DRM, S_OK, FALSE }, > - { &IID_IUnknown, &IID_IDirect3DRM, S_OK, FALSE }, > + { &IID_IDirect3DRM3, &IID_IDirect3DRM3, S_OK, > TRUE }, > + { &IID_IDirect3DRM2, &IID_IDirect3DRM2, S_OK, > TRUE }, > + { &IID_IDirect3DRM, &IID_IDirect3DRM, S_OK, > FALSE }, > + { &IID_IDirect3DRMDevice, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMObject, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMObject2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMDevice2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMDevice3, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMViewport, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMViewport2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMFrame, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMFrame2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMFrame3, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMVisual, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMMesh, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMMeshBuilder, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMMeshBuilder2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMMeshBuilder3, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMFace, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMFace2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMLight, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMTexture, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMTexture2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMTexture3, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMWrap, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMMaterial, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMMaterial2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMAnimation, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMAnimation2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMAnimationSet, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMAnimationSet2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMObjectArray, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMDeviceArray, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMViewportArray, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMFrameArray, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMVisualArray, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMLightArray, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMPickedArray, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMFaceArray, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMAnimationArray, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMUserVisual, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMShadow, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMShadow2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMInterpolator, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMProgressiveMesh, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMPicked2Array, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DRMClippedVisual, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirectDrawClipper, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirectDrawSurface7, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirectDrawSurface4, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirectDrawSurface3, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirectDrawSurface2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirectDrawSurface, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DDevice7, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DDevice3, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DDevice2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DDevice, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3D7, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3D3, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3D2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3D, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirectDraw7, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirectDraw4, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirectDraw3, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirectDraw2, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirectDraw, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IDirect3DLight, NULL, > CLASS_E_CLASSNOTAVAILABLE, FALSE }, > + { &IID_IUnknown, &IID_IDirect3DRM, S_OK, > FALSE }, > }; > HRESULT hr; > IDirect3DRM *d3drm; > > - hr = pDirect3DRMCreate(&d3drm); > + hr = Direct3DRMCreate(&d3drm); > ok(hr == D3DRM_OK, "Cannot get IDirect3DRM interface (hr = %x)\n", > hr); > > test_qi("d3drm_qi", (IUnknown *)d3drm, &IID_IDirect3DRM, tests, > sizeof(tests) / sizeof(*tests)); > @@ -1806,9 +1845,6 @@ static void test_d3drm_qi(void) > > START_TEST(d3drm) > { > - if (!InitFunctionPtrs()) > - return; > - > test_MeshBuilder(); > test_MeshBuilder3(); > test_Mesh(); > @@ -1823,6 +1859,4 @@ START_TEST(d3drm) > test_d3drm_load(); > test_frame_mesh_materials(); > test_d3drm_qi(); > - > - FreeLibrary(d3drm_handle); > } > -- > 1.9.3 (Apple Git-50) > >

1 0

Re: winemenubuilder - MIME type handling GSoC - bad idea
by Rosanne DiMesio 17 Mar '15

17 Mar '15

On Sun, 15 Mar 2015 16:03:21 +0100 Michael Müller <michael(a)fds-team.de> wrote: > > Maybe Rosanne can share her opinion on this topic, since she has more > contact with users complaining about this "feature". > I'm not the least bit qualified to say what would or wouldn't be a good GSoC project, but if you're asking whether I think users would benefit from adding elaborate controls to winecfg that duplicate functions already provided by the desktop environment's tools, the answer is no. I agree with Damjan that those settings should be controlled through the host system, not Wine, and users need to learn how to use the configuration tools provided by their DE. I also see a significant downside to trying to control mimetype associations in winecfg: configuring would have to be done individually for each and every wineprefix. That's more work, not less, and speaking as a user with multiple wineprefixes, a headache I'd rather not have. As for bug 19182, the OR never asked for the complicated controls people have been proposing lately; all he wanted was a user-friendly way to completely disable mimetype associations and menu entries. A simple checkbox on the desktop integration tab to disable winemenubuilder would accomplish that.

5 6

GSoC Implement OpenMP
by lijianwei 17 Mar '15

17 Mar '15

HI I'm a graduate student of Northwestern Polytenical University.I have been studing on paralle for two year.So,I can fix the bug Implement OpenMP. But,How can I attend your program. Best Regard Jianwei

1 0

Re: [quick-hack] Sims 2 launch fix, vertex shaders from 256 to 4096
by Henri Verbeet 17 Mar '15

17 Mar '15

On 17 March 2015 at 10:03, Chris Giles <drathian(a)gmail.com> wrote: > Originally idea by Robert Showalter, adapted to later wine versions by Luke > Horwell, altered by me. Windows emulates 8192 vertex shaders, sims 2 > requires at least half that to launch properly (although it is only supposed > to ask for 1024), the blue texture glitches exist with this, can be futher > debugged. Bug 8051, discussion previewed in > https://appdb.winehq.org/objectManager.php?sClass=version&iId=2633 > As it is, the patch is just wrong. But if it actually works, and you can write the corresponding tests to show that it's correct, just not applying the D3D9_MAX_VERTEX_SHADER_CONSTANTF clamp on SWVP devices would probably be fine.

1 0

Re: [PATCH] vbscript: Implemented GetLocale(try 2)
by Marvin 17 Mar '15

17 Mar '15

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://testbot.winehq.org/JobDetails.pl?Key=12234 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === w2003std (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: user32/tests: Add tests for removing already seen messages from the queue.
by Marvin 17 Mar '15

17 Mar '15

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://testbot.winehq.org/JobDetails.pl?Key=12229 Your paranoid android. === w7u (32 bit msg) === msg.c:12230: Test failed: unexpected hwnd 0017014A msg.c:12252: Test failed: bad time 309b0/309c0

1 0

An issue with msvcp110 test's design
by YongHao Hu 16 Mar '15

16 Mar '15

Hi, all Thanks for Piotr's comment on my GSOC ideas. In order to have a good knowledge of functions from tr2 namespace, I had made a test and written some functions' implementation. However, I had an issue with msvcp test's design when I need to free library of msvcp90 and load msvcp110. 619 static HMODULE msvcr, msvcp; 620 #define SETNOFAIL(x,y) x = (void*)GetProcAddress(msvcp,y) 621 #define SET(x,y) do { SETNOFAIL(x,y); ok(x != NULL, "Export '%s' not found\ n", y); } while(0) In my patch, I use a hmodule variable named msvcp90 to save msvcp90 hmodule and then reuse msvcp to save msvcp110. As far as I am concerned, the name msvcp90 or msvcp90_saver is not good enough. Could you give it a good name? And the other method I came up with is undefining SETNOFAIL and SET and using msvcp110 to define it again, which I think is ugly. By the way, my crosstest on all the testbots[1] show that msvcp110.dll or msvcrt110.dll not installed. It seems testbot doesn't install msvcp110. I will be grateful for any advice you can provide. [1]: https://testbot.winehq.org/JobDetails.pl?Key=12146&log_110=1#k110

5 6

Re: [PATCH] ddraw: Add validation and tests for DDBLT_ROP (v2).
by Marvin 16 Mar '15

16 Mar '15

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://testbot.winehq.org/JobDetails.pl?Key=12219 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 2/5] d3d9/tests: Add a test for UpdateTexture.
by Stefan Dösinger 16 Mar '15

16 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-03-10 um 19:29 schrieb Matteo Bruni: > + /* This works on AMD but fails on Nvidia (it draws black). > */ + /* {8, 8, 8, 8, 4, 4, D3DFMT_A8R8G8B8, D3DFMT_R5G6B5}, > */ /* Different format */ What does AMD draw in this case? Does it convert the format from A8R8G8B8 to R5G6B5 like StretchRect would? Or does it just memcpy? In the latter case I'd expect a memory corruption due to the size mismatch. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVAA/0AAoJEN0/YqbEcdMwKlcP/RVMf9nx/D4Emx4Viu9U3iGZ P1XV8AvAjKxJ/BNQ58HGCVH+9X3GXLLOJiv3H5CanOt7MxpwT+MX9hADYz9aZZTr lo45Gp5H4i2d9X2fNNNTcoY7y0lYV1R3YCEcSiQlick3o/0KTXPV5a6+m+Z1QDcV hlSjkj0SpZICVpzUwuU/FQuSyKE/ihcyZNGwtfxt+q+QdJDPzDp86QBV+s80snKD Yzsif4pAU2bLzrrM181qsRv0MB8mvfmfT25gPtjrZq5JekRe+WWhZ2uLrqQhkxAH y6A3TeVuIiRY0qwOMe05eEXAEZjLxDswJJDD7fLps3XcYYkpbIBLECjNqHhEFtK1 7DCjb7nQtJBFy+cX4ZBxRZ6X15Rsri6iQfP04e2/V44JWZrO6EHQvEybUw2i57+Y R1yLsf3KzDzpcy9At7gH4sFIvjDfuCROlblsdYmEwacwq+rO8kyRI6DhixPRtWDG beW6eMRUAVVyeQvXVCuLW6uPIpWuEdpmQZ7neug1YFfdqsG4YfR76RgQv6Gkj32V f3G/wGri8fF6PUWavZscdVdcD51LbkUQRyNy8CpRpxJe5AABGaecVj+nirskoKEo qFXcWxSUK5YHQ055WWn0UwQ2NabX62FNTki35tNqbZru/iivVbsEb4kcYeaYsMe9 TZrdk2aXSVrmHbd52LSi =xL1U -----END PGP SIGNATURE-----

2 7

Re: [PATCH 5/5] ddraw/tests: Add tests for DDBLT_ROP.
by Matteo Bruni 16 Mar '15

16 Mar '15

2015-03-16 14:48 GMT+01:00 Stefan Dösinger <stefan(a)codeweavers.com>: > --- > dlls/ddraw/surface.c | 16 ++++++++ > dlls/ddraw/tests/ddraw7.c | 98 +++++++++++++++++++++++++++++++++++++++-------- > 2 files changed, 98 insertions(+), 16 deletions(-) This patch also changes the implementation while the title suggests only additions to the tests. This might come as a surprise a few months down the line in the (admittedly unlikely) case this causes regressions or something similar, so I'd either change the name of the patch or split the implementation change from the test part. Again, it's not that important in this specific case so I don't care much.

2 1

Re: [PATCH] wine.inf: Add some knownfolders to the registry
by Alexandre Julliard 16 Mar '15

16 Mar '15

Andrew Eikum <aeikum(a)codeweavers.com> writes: > This time with a cleaned up win8 testbot. > > dlls/shell32/tests/shellpath.c | 212 ++++++++++++++++++++--------------------- > loader/wine.inf.in | 24 +++++ > 2 files changed, 129 insertions(+), 107 deletions(-) Shouldn't this be generated from the data we already have in shell32? -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH] dsound: Apply filters before sound is multipled to speakers.
by Andrew Eikum 16 Mar '15

16 Mar '15

On Sun, Mar 15, 2015 at 05:51:32PM +0000, Mark Harmstone wrote: > - for (i = 0; i < count; i++) > - for (channel = 0; channel < dsb->mix_channels; channel++) > - dsb->put(dsb, i * ostride, channel, get_current_sample(dsb, > - dsb->sec_mixpos + i * istride, channel)); > + float* buf; > + > + buf = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, count * dsb->mix_channels * sizeof(float)); Is it necessary to zero this buffer? I think the whole thing gets overwritten in the following lines. I'm a bit concerned that splitting the processing out into another buffer will affect performance. Similarly in the resampling case below, you're adding another loop over every sample. We already have a performance issue introduced by the higher quality resampler: https://bugs.winehq.org/show_bug.cgi?id=30639 Could we take the slower path in each case only if we have filters to apply? BTW do you have an application that uses DMOs? I'd be curious to take a look and add it to my list of dsound test applications. Andrew

1 0

Re: d3drm: Add tests for querying between IDirect3DRM interfaces
by Stefan Dösinger 16 Mar '15

16 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-03-15 um 11:45 schrieb Aaryaman Vasishta: > + hr = IUnknown_QueryInterface(base_iface, tests[i].iid, (void > **)&iface1); It looks like your mail client line-wrapped the patch. Unfortunately it won't apply this way :-( . > + if (!GetProcAddress(GetModuleHandleA("d3drm.dll"), "Direct3DRMCreate")) > + { > + win_skip("Direct3DRMCreate not available, skipping test.\n"); > + return; > + } You should not need this. If Direct3DRMCreate is not available InitFunctionPtrs() will return false and your test is never run. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVBWQHAAoJEN0/YqbEcdMwq/IP/20pRxWk3tYXzbZmKILCNH65 JRTlm/fvqtO/Q+Q1C57WkOMiusE2w4i25/AQNsaIYOW/e8nATIGni3PPRlK6v9gT /JzzntJLD0I4mEOBxrZvnQhQ3iZ91YMla+Sg326b3PkwONEfkWhORP4YGrkt75is 5YNCKVZG/msPT7IxUIbZji7K8McDEX/OsLLFEFDr3mg4i5z7WMxAJVBIxOGuN8re 2N2TKGfcWLEIaE5Hpyh+r9xYbS8x7JyIN5md5EdQrnBR/9KMn18VFLWX3u+4jfm3 o8uGOjhhOUqjjtzYomRe317l3ujtqjora6xNZ5upGrcxwBWSZKDB5gk233o/62W4 FJuHGeHnCaUgctBUYQstFHr9FsBFt3KkgFqhds3nnSz4MF3/I46+X7KprCiAIaMZ q/YNasm8lGGAdNZp5DkViq9K06umOG7iz+21XY+dP9hRrTVqq11eEqEmveqRHU2+ GuOiNcKeo45Sj+4yl+r78fD3JNN2Ltki3O/z/KVjfE2aE+e5cHKn1oGAEFUaGzDl zHd2KcI6W6e6eDy3qgo8TezfiQYogQzTriyVd9Kyxi9CxKAVnZOrskKoFj2tT3M4 PEn2qX13OtcBcIaO83QJdHtwxg1g3yQ771uIPK0MHU1zjSHAz2sHf+amn6/gF8N+ MT9amN40cQrxGXpaplzm =d/6Z -----END PGP SIGNATURE-----

3 2

Re: vcomp: Add _vcomp_enter_critsect, _vcomp_leave_critsect, omp_init_lock stubs
by Michael Stefaniuc 16 Mar '15

16 Mar '15

Hello Andrey, On 03/14/2015 03:00 PM, Andrey Gusev wrote: > Based on an old patch from Dan Kegel with the addition. > Fixes https://bugs.winehq.org/show_bug.cgi?id=36457 > > vcomp-Add-_vcomp_enter_critsect-_vcomp_leave_critsec.txt you can't just stub out locking functions. It is far superior to have a program crash straight ahead than to silently corrupt data. That's the reason the initial submission by Dan was rejected. I don't find any documentation on a quick search for this functions. But they look to me just like wrappers around the standard EnterCriticalSection / LeaveCriticalSection functions. You could try that out and see if your application is happy with that. bye michael > > > From b4c7617b344ee0dcdb058030b19ede5101787824 Mon Sep 17 00:00:00 2001 > Message-Id: <b4c7617b344ee0dcdb058030b19ede5101787824.1426341234.git.andrey.goosev(a)gmail.com> > From: Andrey Gusev <andrey.goosev(a)gmail.com> > Date: Sat, 14 Mar 2015 15:53:29 +0200 > Subject: [PATCH] vcomp: Add _vcomp_enter_critsect, _vcomp_leave_critsect, > omp_init_lock stubs > > --- > dlls/vcomp/main.c | 15 +++++++++++++++ > dlls/vcomp/vcomp.spec | 6 +++--- > 2 files changed, 18 insertions(+), 3 deletions(-) > > diff --git a/dlls/vcomp/main.c b/dlls/vcomp/main.c > index ab2a372..3c43a4e 100644 > --- a/dlls/vcomp/main.c > +++ b/dlls/vcomp/main.c > @@ -71,6 +71,11 @@ double CDECL omp_get_wtime(void) > return GetTickCount() / 1000.0; > } > > +void CDECL omp_init_lock(int lock) > +{ > + TRACE("(%d): stub\n", lock); > +} > + > void CDECL omp_set_dynamic(int val) > { > TRACE("(%d): stub\n", val);

1 0

Re: [PATCH 1/2] riched20: Implement IOleWindow interface.
by Nikolay Sivov 16 Mar '15

16 Mar '15

On 16.03.2015 10:36, Jactry Zeng wrote: > + create_interfaces(&w, &reOle, &txtDoc, NULL); > + hres = IRichEditOle_GetClientSite(reOle, &clientSite); > + ok(hres == S_OK, "IRichEditOle_QueryInterface: 0x%08x\n", hres); > + refcount1 = get_refcount((IUnknown *)clientSite); > + todo_wine ok(refcount1 == 1, "got wrong ref count: %d\n", refcount1); > + > + hres = IOleClientSite_QueryInterface(clientSite, &IID_IOleClientSite, (void **)&clientSite1); > + ok(hres == S_OK, "IOleClientSite_QueryInterface: 0x%08x\n", hres); > + ok(clientSite == clientSite1, "Should not return a new pointer.\n"); > + refcount1 = get_refcount((IUnknown *)clientSite); > + todo_wine ok(refcount1 == 2, "got wrong ref count: %d\n", refcount1); Hi, Jactry. Do we have a test somewhere showing that IRichEditOle cannot be queried directly for IOleClientSite and IOleWindow?

2 2

Re: [PATCH 2/2] riched20: Implement IOleWindow::GetWindow.
by Nikolay Sivov 16 Mar '15

16 Mar '15

On 16.03.2015 10:36, Jactry Zeng wrote: > static HRESULT WINAPI IOleWindow_fnGetWindow(IOleWindow *iface, HWND *phwnd) > { > IOleClientSiteImpl *This = impl_from_IOleWindow(iface); > - FIXME("not implemented: (%p)->(%p)\n", This, phwnd); > - return E_NOTIMPL; > + TRACE("(%p)->(%p)\n", This, phwnd); > + *phwnd = This->reOle->editor->hWnd; > + return S_OK; > } Could you add a test for NULL argument too?

1 0

GSoC WINE -Deep Learning with Caffe & OpenCV Proposal
by Yida Wang 16 Mar '15

16 Mar '15

Posted by Yida Wang Passion with OpenCV and other Open Source Communities Hello, I am Yida Wang, a first year Master Student in Pattern Recognition of PRIS Lab in SICE school of BUPT. I have wonderful experience with OpenCV and several other open source communities. I have won the 1st prize in Scilab Open Source Contest 2014 and Excellent Developer in CSDN Summer of Code 2014 in BladeRF commmunity. All certificate could be provided if it is necessary. As for WINE project, I have developed a PCANet structure to automatically match opencv source figures with Microsoft figures sot that the editor in linux platform could match the correct figure copied from Microsoft Office. This time I think it is convenient to use Caffe and OpenCV for deep learning and other CV issues for some pattern recognition applications. I have also own an Nvidia K40 GPU donated by Nvidia for research, I think I can extend the package for GPU calculation! Motivation for Proposal Framework in Computer Vision- Deep Learning Project I’m Concentrating on Deep Learning coding with OpenCV and other open source project like Caffe and cuDNN for a period of time. My project contains two meaningful contents, the 1st one is a BP algorithm eliminated CNN structure which is far less time consuming than traditional CNN and the 2nd one is an entire Deep Leaning structure on image recognition based on Caffe. New Idea for a Fast CNN My idea is based on the thriving pattern recognition method called ’Deep Neural Networks ’ which has been used by Google to build the amazing recognition structure last year. As Deep Neural Network behaves amazingly in pattern recognition, there are already useful tools such as Caffe being implemented for research. Some of the useful codes could be modified and embedded in OpenCV for the development of DNN. But at the same time, the problem lies in the dependence on hardware such as powerful GPU which is not easy to be got by ordinary people. The time consuming process is mainly caused by 2 points: the Randomness of the convolutional kernel and the countless back propagation step. I have been studying on a powerful single direction fast CNN called PCANet for research and commercial use. Here are some benefit in such structure: 1. Such structure hasn’t the BP algorithm used in DNN which cost much operation. 2. It has some tiny PCA filters instead. The filters’ shape is just like the shape in the training results of normal CNN. 3. My structure could be used in initiating the CNN in the future to optimize the training time in CNN. 4. Combination of Caffe and PCANet in WINE The ‘blob’ structure defined in Caffe is clear for the layer based CNN and the input data of convolution kernel and bias in one layer could be replaced by the PCANet filter for initialization. So the modified structure combined with Caffe and PCANet could be powerful both in speed of convergence and recognition stability with the help of OpenCV. So my idea consists 2 stage: PCANet implementation and Caffe modifying for OpenCV. The 1st direction called Fast-CNN(CellNet) My 1st idea is an implementation of PCANet which has different structure of local filters learning from different databases while holding the stability and generality of general CNN at the same time. Here is the General model of PCANet: I have been using this algorithm in one of the most difficult face database called ‘LFW’ and achieves 92% recognition rate with just this algorithm alone. My friend Qian Hong, has guild me to help him solve the general figure recognition problem recently to reduce the human labor cost in selecting the most likely figure in open source figure database to the Microsoft official figure. I use PCANet for such problem with particular parameters and got the result partly shown below: Target database Open source database The matching result shows the accuracy of PCANet, they are all extract from raw database, and there are many shape alike matches. My algorithm just could select the best substitute. Now I have modified the structure for general visual object classification problems and join the Detection-Feature extraction-Classification process together into an entire extension neural network both for my study and the project itself. By attempting to modify my previous Matlab codes about CellNet into C++ codes with the help of OpenCV(especially in Matrix operations), I could get some raw features extracted from a photo through the network these days. The performance is still as excellent as I mentioned last few weeks, but I am concerning about another confusion related to what you have told me. The 2nd direction: Modifying Caffe with OpenCV in WINE In fact besides studying in artificial architecture, I am also research in normal neural networks at the same time, so came the 2nd content I just showed. Deep learning is powerful indeed, it could exceed the human capabilities in the future due to Big Data and fast 2-D computation (including GPU). But the complex back and forth process cost really much even in the future. So I am still searching the better solution between one-way network and two-way network. I noticed that OpenCV has posted that it would be cool if OpenCV could load and run deep networks trained with popular DNN packages like Caffe or Torch. I am glad to hear that because I am also doing some experiment on CNN with Caffe. Than there are some main task to be done in the future: 1. Modify the Caffe’s data structure with OpenCV, especially the ‘blob’ structure defined in Caffe. The layer really appears more clear with the help of ‘blob’, but the basic element could be more flexible with the OpenCV data structure. 2. Some prerequisites should be simplified including BLAS & Boost. We may just need some basic dependencies to form a CNN. 3. Whether including GPU calculating process is under consideration due to the short time. Conclusion Just as described in detail, my idea is composed of a fast DNN which is almost completed and a Caffe based DNN. I attached the paper describing the fast DNN called “PCANet”. The source code is published on Github with the name of CellNet with the URL: https://github.com/Wangyida/CellNet As for the Caffe based DNN, I thought it is much more easy to develop a CPU version rather than a GPU version at first. I am worried about that the time might not be enough to apply OpenCV on Caffe without bugs from now on though there are already some utilizations of OpenCV in Caffe. I wonder if the idea is meaningful enough? Especially the 1st part.

2 1

GSOC-2015 Tools - Implement resource editor and / or dialog editor
by Rukshan Chathuranga 16 Mar '15

16 Mar '15

Hi Marcus Meissner and André Hentschel, I'm rukshan chathuranga from university of moratuwa, Sri Lanka. I'm hope to apply to GSOC 2015 with Wine project. For that i hope to work with "Tools - Implement resource editor and / or dialog editor" project. Because i have C/C++/QT/QML programming experience. Also i am seeking more information and requirement about this topic. Can you help me to understand the scope well? Thanks and regards. *Rukshan Chathuranga.* *Department Of Computer Science & Engineering,* *Faculty Of Engineering,* *University Of Moratuwa. **Sri Lanka.* *WEB: http://www.rukspot.com/ <http://rukspot.com/>*

1 0

Re: winemenubuilder - MIME type handling GSoC - bad idea
by Damjan Jovanovic 16 Mar '15

16 Mar '15

Hi I welcome this discussion. Of course manually deleting files in ~/.local is not user friendly, and it was never intended to be done that way. I did not write the part of the Wiki entry suggesting that applet :-). If you install a Windows app on Windows, and it creates menus and file associations, you don't get to opt out, and have to use a 3rd party tool to edit or delete those afterwards. If you install a Linux app on Linux, and it creates menus and file associations, you also don't get to opt out, and have to use a 3rd party tool (a Freedesktop menu/association editing tool) to edit or delete those afterwards. Why is Wine so special? What are people actually looking for? For Wine not to create menu/associations when running on a non-"~/.wine" WINEPREFIX? For a way to stop the annoying use of Wine's "Internet Explorer" to open jpeg files? Anything else? BTW you don't need distro binfmt handlers to double-click .exe (and .msi and .lnk) files: Wine's tools/wine.desktop handles those. You only need binfmt handlers to run .exe directly from the command line - when you aren't in a desktop where you can use "xdg-open /path/to/file.exe". I suspect the Ubuntu package installs a binfmt handler because it doesn't know that. Regards Damjan On Sun, Mar 15, 2015 at 5:03 PM, Michael Müller <michael(a)fds-team.de> wrote: > Hi Damjan, > > the idea of the GSOC project is to make the mime type association more > user friendly for ordinary users. Manually deleting files in > ~/.local/share/mime/ (which some users don't even find because it is a > hidden folder) or requiring a 3rd party program is not user friendly. If > Wine creates these associations it should also provide you with a way to > get rid of them. Even the wiki entry mentions that an applet would be > useful to manage these associations. > > There is also no obvious way to disable the integration, there is no > checkbox or something like this in winecfg, you will need to lookup that > winemenubuilder is the component responsible for this and disable it > manually with library overrides. We are talking about users who use wine > by double clicking on an executable (using the binfmt handler installed > by their distro) or by using a menu entry and who wonder why all their > txt files now open with notepad and how to get rid of this. > > There is also no easy and obvious way to create mime types only for a > specific program, i.e. disable the integration but later decide to > enable it only for Word and .doc* files. There might be different > solutions for this problem, but I think you can't deny that there is > something going wrong if you get a bug report with 72 comments and 4 > duplicates. Arguing that providing a way to disable the integration > again would be a new feature and not a bug fix doesn't help us in this > case. If you have better ideas how to make the integration more user > friendly, feel free to share them with us, but your comments didn't > convince me so far that this GSOC idea is bad. > > Maybe Rosanne can share her opinion on this topic, since she has more > contact with users complaining about this "feature". > > Regards, > Michael > > Am 15.03.2015 um 11:02 schrieb Damjan Jovanovic: >> Hi >> >> As the author of most of winemenubuilder, I am disappointed at how >> poorly understood it remains. >> >> The "Winecfg / winemenubuilder - enhance MIME type handling" GSoC idea >> suggests "The idea of this task is to provide a GUI (most probably as >> part of winecfg) to control the creation of such MIME type assignments >> and therefore making Wine more user friendly." >> >> If you read about the design of winemenubuilder's file associations on >> http://wiki.winehq.org/FileTypesIntegration you'll see that >> winemenubuilder logs each file association mapping to the registry on >> creation, and doesn't recreate it if it's already in the registry and >> the .desktop file is gone. This allows you not just to customize and >> delete file associations by editing the registry, but also by editing >> the Freedesktop associations (and menus btw) with Freedesktop tools - >> .desktop files you've deleted in those tools won't be recreated by >> Wine (unless you uninstall and reinstall the Windows app). >> >> I believe people have been spoiled by installing everything through >> their distro package manager, and thus don't know about/use >> Freedesktop menu/association editing tools, so they now expect Wine to >> do something that even Windows doesn't. >> >> If Freedesktop tools don't let you edit file associations, surely >> that's a missing feature in those tools, not a GSoC project in Wine? >> Additionally Windows apps for editing menus and file associations >> (example list at http://forums.techarena.in/tips-tweaks/989159.htm) >> should work under Wine. >> >> Thank you >> Damjan >> >

2 1

Re: [2/2] ws2_32/tests: Check the OOB mark in the right place
by Marvin 15 Mar '15

15 Mar '15

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://testbot.winehq.org/JobDetails.pl?Key=12177 Your paranoid android. === w2008s64 (64 bit sock) === No test summary line found

1 0

Re: d3drm: Add tests for querying between IDirect3DRM interfaces
by Marvin 15 Mar '15

15 Mar '15

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://testbot.winehq.org/JobDetails.pl?Key=12174 Your paranoid android. === build (build) === Patch failed to apply

1 0

Subtle Denial of Medical Treatment by the Singapore Government for Mr. Teo En Ming (Zhang Enming)
by Teo En Ming (Zhang Enming) 15 Mar '15

15 Mar '15

Dear Sir/Madam, Please refer to the following PDF document: http://oss.clusterlabs.org/pipermail/pacemaker/2015-March/023574.html It is a very important letter. Please read the letter very carefully, word by word. The letter details how the Singapore Government led by Prime Minister Lee Hsien Loong has *subtly* denied me medical treatment for ***suspected*** coronary heart disease. Thank you very much. -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore Citizen

1 0

Testing
by Teo En Ming (Zhang Enming) 15 Mar '15

15 Mar '15

Testing -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore Citizen

1 0

Re: combase: implement WindowsSubstring
by Marvin 15 Mar '15

15 Mar '15

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://testbot.winehq.org/JobDetails.pl?Key=12173 Your paranoid android. === w8 (32 bit string) === string.c:258: Test failed: Duplicated string created new string

1 0

Re: [PATCH] vbscript: Implemented GetLocale
by Nikolay Sivov 15 Mar '15

15 Mar '15

> +static HRESULT Global_GetLocale(vbdisp_t *This, VARIANT *arg, unsigned args_cnt, VARIANT *res) > +{ > + return return_int(res, GetACP()); > +} This looks completely wrong. Docs say it should return locale id (as name suggests), not a codepage value.

2 1

Re: [PATCH] d3d9/tests: Extend the colorfill test (v2).
by Alexandre Julliard 15 Mar '15

15 Mar '15

Stefan Dösinger <stefan(a)codeweavers.com> writes: > This supersedes patch 109855. > > Version 2: Don't check the fill value of D3DFMT_P8. The testbot deviates > from real HW. I could mark it broken, but it doesn't seem worth the > effort because the format is essentially useless. It can only be used > for ColorFill and StretchRect between P8 surfaces. It doesn't work here (GeForce 320M, Nouveau driver): ../../../tools/runtest -q -P wine -T ../../.. -M d3d9.dll -p d3d9_test.exe.so visual && touch visual.ok visual.c:904: Test failed: Failed to color fill, hr 0x8876086c, fmt=D3DFMT_YUY2. visual.c:910: Test failed: Failed to color fill, hr 0x8876086c, fmt=D3DFMT_YUY2. visual.c:916: Test succeeded inside todo block: Got unexpected hr 0x8876086c, fmt=D3DFMT_YUY2. visual.c:904: Test failed: Failed to color fill, hr 0x8876086c, fmt=D3DFMT_UYVY. visual.c:910: Test failed: Failed to color fill, hr 0x8876086c, fmt=D3DFMT_UYVY. visual.c:916: Test succeeded inside todo block: Got unexpected hr 0x8876086c, fmt=D3DFMT_UYVY. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: d3drm: Add tests for querying between IDirect3DRM interfaces
by Marvin 15 Mar '15

15 Mar '15

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://testbot.winehq.org/JobDetails.pl?Key=12171 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH] vbscript: Implemented GetLocale
by Marvin 15 Mar '15

15 Mar '15

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://testbot.winehq.org/JobDetails.pl?Key=12170 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === w2003std (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

GSoC 2015 project
by TARUN GUPTA 14 Mar '15

14 Mar '15

Hi, I am an aspirant of GSoC 2015 and interested in tools project. I have good C knowledge. I am ready to put in my best in these projects. How should i get started?

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel