April 2015 - Wine-Devel - list.winehq.org

Re: locale: [1/1] patch - 0x10000000 flag is NORM_STOP_ON_NULL (plus test fix)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://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

April 7, 2015

Re: CoInternetParseUrl and concepts explanation.

by Jacek Caban

Hi Philippe, On 04/05/15 22:04, Philippe Groarke wrote: > Hello, > > I am currently exploring Wine code base looking for low hanging fruits > I can contribute to. I think CoInternetParseUrl and other URLMon stubs > seem*ed* 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. You should learn about COM interfaces and how they are used in C. > 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? All this is for pluggable protocols. Applications may define and register their own protocols, other than standard ones like http or file protocols, and have them transparently used by urlmon, which abstracts protocol-specific tasks. In this case, default parsing action may not be the right thing to do for given custom protocol and may be changed by implementing protocol-specific IInternetProtocolInfo. You may read more about it on MSDN [1]. Cheers, Jacek [1] https://msdn.microsoft.com/en-us/library/aa767743%28v=vs.85%29.aspx

April 6, 2015

Re:Re: [PATCH 2/4] ntdll/test: Add ntdll test function test_file_full_size_information

by Jianqiu Zhang

At 2015-04-04 16:15:54, "Nikolay Sivov" <bunglehead(a)gmail.com> wrote: >On 04.04.2015 11:07, Jianqiu Zhang wrote: >> At 2015-04-04 15:17:13, "Nikolay Sivov" <bunglehead(a)gmail.com> wrote: >> >> >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. >> Hi~ Nikolay I tried to use wine_dbgstr_longlong to print LONGLONG values the code is shown below: trace("TotalAllocationUnits 0x%s\n", wine_dbgstr_longlong(fsi.TotalAllocationUnits)); trace("CallerAvailableAllocationUnits 0x%s\n", wine_dbgstr_longlong(fsi.CallerAvailableAllocationUnits)); trace("ActualAvailableAllocationUnits 0x%s\n", wine_dbgstr_longlong(fsi.ActualAvailableAllocationUnits)); And then when I run make test , the process occurs some errors ,the error log is shown below: dlls/ntdll/tests/file.c:1232: undefined reference to `wine_dbgstr_longlong' dlls/ntdll/tests/file.c:1233: undefined reference to `wine_dbgstr_longlong' dlls/ntdll/tests/file.c:1234: undefined reference to `wine_dbgstr_longlong' I think it's because there is no compiled object file that contain wine_dbgstr_longlong function. and i try to include wine/debug.h in file.c . But the problem still exists. And error log like this n file included from file.c:40:0: ../../../include/wine/debug.h:31:2: error: #error This file should not be used in Wine tests #error This file should not be used in Wine tests ^ ../../../include/wine/debug.h:181:27: error: redefinition of ‘wine_dbgstr_w’ static inline const char *wine_dbgstr_w( const WCHAR *s ) ^ In file included from file.c:36:0: ../../../include/wine/test.h:69:27: note: previous definition of ‘wine_dbgstr_w’ was here static inline const char *wine_dbgstr_w( const WCHAR *s ) { return wine_dbgstr_wn( s, -1 ); } ^ In file included from file.c:40:0: ../../../include/wine/debug.h:186:27: error: static declaration of ‘wine_dbgstr_guid’ follows non-static declaration static inline const char *wine_dbgstr_guid( const GUID *id ) ^ In file included from file.c:36:0: ../../../include/wine/test.h:68:20: note: previous declaration of ‘wine_dbgstr_guid’ was here extern const char *wine_dbgstr_guid( const GUID *guid ); ^ file.c: In function ‘test_file_full_size_information’: file.c:1233:5: error: incompatible type for argument 1 of ‘wine_dbgstr_longlong’ trace("TotalAllocationUnits 0x%s\n", wine_dbgstr_longlong(fsi.TotalAllocationUnits)); ^ In file included from file.c:40:0: ../../../include/wine/debug.h:215:27: note: expected ‘ULONGLONG’ but argument is of type ‘LARGE_INTEGER’ static inline const char *wine_dbgstr_longlong( ULONGLONG ll ) ^ file.c:1234:5: error: incompatible type for argument 1 of ‘wine_dbgstr_longlong’ trace("CallerAvailableAllocationUnits 0x%s\n", wine_dbgstr_longlong(fsi.CallerAvailableAllocationUnits)); ^ In file included from file.c:40:0: ../../../include/wine/debug.h:215:27: note: expected ‘ULONGLONG’ but argument is of type ‘LARGE_INTEGER’ static inline const char *wine_dbgstr_longlong( ULONGLONG ll ) ^ file.c:1235:5: error: incompatible type for argument 1 of ‘wine_dbgstr_longlong’ trace("ActualAvailableAllocationUnits 0x%s\n", wine_dbgstr_longlong(fsi.ActualAvailableAllocationUnits)); ^ In file included from file.c:40:0: ../../../include/wine/debug.h:215:27: note: expected ‘ULONGLONG’ but argument is of type ‘LARGE_INTEGER’ static inline const char *wine_dbgstr_longlong( ULONGLONG ll ) Could you please give me an explaination on why I cannot use wine_dbgstr_longlong ? Thanks~

April 5, 2015

Re: [PATCH 1/2] ws2_32: Fix compile on OS X.

by Philippe Groarke

> On Apr 5, 2015, at 7:29 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > > On Sun, Apr 5, 2015 at 4:07 PM, Socapex <philippe.groarke(a)gmail.com <mailto: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 No problem! I wasn't sure if wsnwlink.h would cause issues. I'll resend the patch with that solution instead.

April 5, 2015

Re: [PATCH 1/2] ws2_32: Fix compile on OS X.

by Bruno Jesus

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

April 5, 2015

CoInternetParseUrl and concepts explanation.

by Philippe Groarke

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

April 5, 2015

Re: [PATCH 2/2] ws2_32: Remove trailing white-spaces.

by Stefan Dösinger

-----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-----

April 5, 2015

Re: [PATCH 1/2] ws2_32: Fix compile on OS X.

by Stefan Dösinger

-----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-----

April 5, 2015

Re: [PATCH 3/3] d3drm/tests: Split tests between different versions, initially adding frame QueryInterface tests.

by Stefan Dösinger

-----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-----

April 5, 2015

Re: locale: [1/1] patch - 0x10000000 flag is NORM_STOP_ON_NULL (marvins test fix)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://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

April 4, 2015

Re: Problem receiving UDP broadcast on wxppro and w2008s64

by Francois Gouget

On Fri, 3 Apr 2015, Bruno Jesus wrote: [...] > Thanks for the test, so disabling in 2008 solves too or not? I'll try to test that next week. > Would it be too bad to keep the firewall disabled by default? If think that as much as possible it's up to the test to adjust to how Windows behaves so that it does not become a test of whether Windows was configured just right for the test. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Stolen from an Internet user: "f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng !"

April 4, 2015

Re: [PATCH 1/7] advapi32: Initialize buffer length to zero in LsaLookupSids to prevent crash.

by Qian Hong

Hi Nikolay, On Sun, Apr 5, 2015 at 2:36 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > Maybe it's better to hide this in RtlInitUnicodeStringEx(..., NULL) ? Good idea, thanks for suggestion ;-) -- Regards, Qian Hong - http://www.codeweavers.com

April 4, 2015

RE: mshtml: Removed return to ensure AddRef is called on an internal interface

by Alistair Leslie-Hughes

Hi Jaceb, > > I think it's just a marker, so gecko knows that this node is included > > in collection business. > > Yes, it is a special case, see [1]. It's used to cannonicalize interface > pointer so that it may be used as an identifier in cycle collector > graph. It's not a real interface and it should not cause reference change. > > Alistair, your bug is probably somewhere else. If your patch "fixed" it, > it indeed suggests a refcount-related problem somewhere else. Yes, the patch appeared to "fix" the issue. I'll see if I can track the problem down. Best Regards Alistair Leslie-Hughes

April 4, 2015

Re: locale: [1/1] patch - 0x10000000 flag is NORM_STOP_ON_NULL

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://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

April 4, 2015

Re: [PATCH 1/7] advapi32: Initialize buffer length to zero in LsaLookupSids to prevent crash.

by Nikolay Sivov

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) ?

April 4, 2015

Re: msvcrt: improve accuracy of exp/pow/cosh and sinh

by Ruslan Kabatsayev

Hi, Are you sure this will be of any use if one selects SSE instead of x87 instruction set to handle doubles (like -mfpmath=sse)? No one guarantees the functions like sinh will be evaluated on x87 FPU and even that this legacy instruction set will used at all. Regards, Ruslan On Sat, Apr 4, 2015 at 7:40 PM, Zheng Chen <chanchengcc(a)gmail.com> wrote: > The default fpu_cw = 0x27f makes the exp/pow/cosh/sinh functions producing > less accurate results. This patch temporally changes fpu_cw to 0x37f in > these functions for more accurate results. > > Thanks to Qian for his ideas. > > This patch fixes parts of these two bugs: 37149, 37150 > > >

April 4, 2015

Re: [PATCH 7/7] advapi32/tests: Add more tests for LsaLookupSids and LsaLookupNames2.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://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

April 4, 2015

Re: msxml3: Explicitly list acceptable libxml2->msxml node types for unknode (try 2)

by Nikolay Sivov

On 04.04.2015 16:51, Jacek Caban wrote: > 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? It's only to 'fix' a clang warning about assignment of different enum types. I just listed all types that map directly to msxml types, it's not about fixing any runtime problem. > > Jacek > >

April 4, 2015

Re: msxml3: Explicitly list acceptable libxml2->msxml node types for unknode (try 2)

by Jacek Caban

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

April 4, 2015

Re: mshtml: Removed return to ensure AddRef is called on an internal interface

by Jacek Caban

On 02/04/15 11:26, Nikolay Sivov wrote: > On 02.04.2015 12:23, Piotr Caban wrote: >> On 04/02/15 11:16, Alistair Leslie-Hughes wrote: >>> But "*ppv·=·&This->IHTMLDOMNode_iface" does. Without an AddRef it >>> causes >>> an imbalance of AddRef/Release. >>> >>> So, should it be returning IHTMLDOMNode_iface then? >> I'm not sure if I understand this code correctly but I think that >> nsCycleCollectionISupports is an empty class that only needs a pointer. >> There's no imbalance of AddRef/Release because Release will be never >> called in this case. >> > > I think it's just a marker, so gecko knows that this node is included > in collection business. Yes, it is a special case, see [1]. It's used to cannonicalize interface pointer so that it may be used as an identifier in cycle collector graph. It's not a real interface and it should not cause reference change. Alistair, your bug is probably somewhere else. If your patch "fixed" it, it indeed suggests a refcount-related problem somewhere else. Cheers, Jacek [1] http://hg.mozilla.org/mozilla-central/file/944fb6e682b8/xpcom/glue/nsCycleC…

April 4, 2015

Re: [PATCH 2/4] ntdll/test: Add ntdll test function test_file_full_size_information

by Nikolay Sivov

On 04.04.2015 11:07, Jianqiu Zhang wrote: > At 2015-04-04 15:17:13, "Nikolay Sivov" <bunglehead(a)gmail.com> wrote: > > >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. > > Hi~ Nikolay > In fact , this is my first time to submit a patch to wine community :) > I have a few questions to ask That's perfectly normal, and you're welcome to ask. > > What does a test do? > I thought test functions is a kind of implementation of WinAPI . > I write test function and build cross test executable file and then run > on Windows > to get some data I need . Then I can write the FileFsFullSizeInformation > based on these data Test calls some function or a set of functions, then checks for function output (could be return value or out arguments, or something indirectly affected by this call) using ok() statements. Then like you said, you make sure test works on Windows and then you make it work on Wine. > > And you said that what I wrote is not a test.Does it mean I should test > whether my new function works well? > Should I use ok and todo macro to make my test convincing? What I mean is that your test is supposed to actually check what function returns, not just print a result. Because if it only prints something we don't know if it's working or not, and tests output is not supposed to be visually examined. Basically you should use ok() for that.

April 4, 2015

Re:Re: [PATCH 2/4] ntdll/test: Add ntdll test function test_file_full_size_information

by Jianqiu Zhang

At 2015-04-04 15:17:13, "Nikolay Sivov" <bunglehead(a)gmail.com> wrote: >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. Hi~ Nikolay In fact , this is my first time to submit a patch to wine community :) I have a few questions to ask What does a test do? I thought test functions is a kind of implementation of WinAPI . I write test function and build cross test executable file and then run on Windows to get some data I need . Then I can write the FileFsFullSizeInformation based on these data And you said that what I wrote is not a test.Does it mean I should test whether my new function works well? Should I use ok and todo macro to make my test convincing? If I doesn't make my self clear enough~ would you please let me know and I will try to make myself clear enough. Thanks~

April 4, 2015

Re: [PATCH 3/4] ntdll/test: Add test_file_size_information

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://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"

April 4, 2015

Re: ntdll: Return STATUS_SUCCESS from SetInformationJobObject

by Andrew Cook

On Sat, 2015-04-04 at 10:10 +0300, Nikolay Sivov wrote: > 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. Long term would there be any interest in actually implementing job limits? most are security or resource limits, not expected in normal execution. process breakaway, the exception, is implemented.

April 4, 2015

Re: [PATCH 2/4] ntdll/test: Add ntdll test function test_file_full_size_information

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://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"

April 4, 2015

Re: [PATCH 2/4] ntdll/test: Add ntdll test function test_file_full_size_information

by Nikolay Sivov

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.

April 4, 2015

Re: ntdll: Return STATUS_SUCCESS from SetInformationJobObject

by Nikolay Sivov

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.

April 4, 2015

Re: [PATCH] gdiplus: Avoid unnecessary pre-multiplied alpha conversions in GdipDrawImagePointsRect

by Vincent Povirk

Looks good to me.

April 3, 2015

Re: winecfg: improve user experience by adding all Windows versions and accompanying error message

by Andrew Eikum

On Fri, Apr 03, 2015 at 12:12:53AM -0700, Jason Overland wrote: > Is there anything I can do to improve this patch? > Something is messed up with your patch. Every unchanged line appears to have an extra space in it after the first 'diff' column, so neither git-am nor patch(1) will apply it. My guess is your mail program screwed it up. http://source.winehq.org/patches/data/110308 > This patch is a resubmission of and supersedes my previous patch > "winecfg: add note about 32 bit prefixes to dialog". Thanks to > everyone who provided feedback on that one. > > In this patch, winecfg's Application settings tab now includes all > Windows versions in the combobox. If the user is running from a 64 > bit prefix and selects a version of Windows that requires a 32 bit > prefix, the selection will revert to the previous selection and a > modal dialog containing an error message will appear: > >""" >This Wine prefix is built to support 64 bit applications. Because the Windows version you selected does not support 64 bit applications, this prefix cannot be configured to mimic that version of Windows. > >Please refer to "How do I create a 32 bit wineprefix on a 64 bit system?" in the "Using Wine" section of the Wine FAQ (http://wiki.winehq.org/FAQ) for instructions on how to create a 32 bit Wine prefix. >""" > I don't know Wine's policy about referring to documentation not included in Wine itself. It strikes me that the FAQ may be updated at some point, making this message incorrect. That's why I typed out that long message in my earlier reply. Maybe we prefer a shorter message with the Wiki link? I don't know. > In addition, I noticed two File Open dialogs in winecfg which should > be modal but are not modal. I made these modal by setting the > appropriate owner window. While a separate issue, this seemed like a > trivial enough change to include in this patch. > We prefer changes to be as discrete as possible. Since they're unrelated to your Windows version patch, you should make these changes in a separate patch. Andrew

April 3, 2015

Re: Problem receiving UDP broadcast on wxppro and w2008s64

by Bruno Jesus

On Friday, April 3, 2015, Francois Gouget <fgouget(a)free.fr> wrote: > On Wed, 1 Apr 2015, Bruno Jesus wrote: > > > 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. > > I have tested this in two Windows XP VMs and indeed, disabling the > firewall fixes the issue. Also I did not see any predefined setting > could be flipped to change this behavior. My understanding is that with > SP3 installed by default the firewall blocks everything except what is > allowed. So by default broadcasts do not get it. > > Adding ws2_32_test.exe as an exception to the Windows firewall also > solves the problem but I don't think it can be automated which would be > mostly needed for the testbot. > > What's strange is that Windows 2003 is ok but not Windows 2008 > although both are server editions. > > Can the test work with 127.0.0.1 + 127.255.255.255? Thanks for the test, so disabling in 2008 solves too or not? Would it be too bad to keep the firewall disabled by default? I wonder how utorrent adds itself to firewall free list, maybe i could try the same. Using the loopback interface is not good because the test would not work on linux nor freebsd, i don't know if it would work in windows or not, but i guess no. Best wishes, Bruno

April 3, 2015

Re: [PATCH] comctl32: Do not resize windows when giving an updown control the same buddy.

by Anton Baskanov

Hi. I'll try. On Fri, Apr 3, 2015 at 7:55 PM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > On 03.04.2015 16:41, Anton Baskanov wrote: >> >> 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. >> > > Hi, Anton. > > Could you submit a patch that adds this test case? >

April 3, 2015

Re: Problem receiving UDP broadcast on wxppro and w2008s64

by Francois Gouget

On Wed, 1 Apr 2015, Bruno Jesus wrote: > 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. I have tested this in two Windows XP VMs and indeed, disabling the firewall fixes the issue. Also I did not see any predefined setting could be flipped to change this behavior. My understanding is that with SP3 installed by default the firewall blocks everything except what is allowed. So by default broadcasts do not get it. Adding ws2_32_test.exe as an exception to the Windows firewall also solves the problem but I don't think it can be automated which would be mostly needed for the testbot. What's strange is that Windows 2003 is ok but not Windows 2008 although both are server editions. Can the test work with 127.0.0.1 + 127.255.255.255? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Any sufficiently advanced Operating System is indistinguishable from Linux

April 3, 2015

Re: [PATCH] comctl32: Do not resize windows when giving an updown control the same buddy.

by Nikolay Sivov

On 03.04.2015 16:41, Anton Baskanov wrote: > 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. > Hi, Anton. Could you submit a patch that adds this test case?

April 3, 2015

Re: [PATCH] comctl32: Do not resize windows when giving an updown control the same buddy.

by Anton Baskanov

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(+) > > > > >

April 3, 2015

Re: [PATCH 4/4] d3drm/tests: Add vtable comparison tests in test_frame_qi

by Aaryaman Vasishta

I realized that it might not be as easy as it seems to implement that approach - as including the todo's there is complicated. I've added another field called vtable_todo in the test, and done something like this, similar to how I did in the test_d3drm_qi tests: if (tables[i].vtable_todo || tables[j].vtable_todo) todo_wine ok(...); else ok(...); The problem with this approach is that if the tests fail on wine no matter what boolean combination I use. It's because we can't explicitly set which vtable should have a todo against another vtable in this case. If the vtable_todo is set to true for an entry, it'll do a todo_wine for every other interface it is checked against, which is undesirable and causes the fails or successful todo_wine(s). On Fri, Apr 3, 2015 at 2:41 AM, Aaryaman Vasishta <jem456.vasishta(a)gmail.com > wrote: > > > On Fri, Apr 3, 2015 at 2:10 AM, Stefan Dösinger <stefandoesinger(a)gmail.com > > wrote: > >> -----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. >> > I've tried this and it works too. I'll use this on the patch try, and > along with it also keep vtable_todo as some tests won't work on wine until > they're fixed. > > >> >> 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. >> >> I'll keep this in mind the next time I come across it. Thank You! > > jam > >

April 3, 2015

Re: kernel32: Stub out GetFileMUIPath.

by Nikolay Sivov

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

April 3, 2015

Re: advapi32: Handle NULL DACL in SetSecurityInfo

by Piotr Caban

On 04/03/15 01:56, Erich E. Hoover wrote: > On Thu, Apr 2, 2015 at 4:54 PM, Piotr Caban <piotr(a)codeweavers.com> wrote: >> ... >> the patch restores old SetSecurityInfo behavior. It also works around a >> crash in current implementation when NULL DACL is passed. It's as close to >> native behavior as it currently can be. Setting NULL DACL means: allow every >> permission on windows. Your test shows that we should get NULL while asking >> about DACL but there's no way of correctly supporting it in wine currently >> (and I'm not sure if it can be cleanly supported in future, as far as I can >> see nor POSIX ACL, nor NFSv4 ACL supports anything like this). >> ... > > This is one of the reasons why in our implementation we stored the > security descriptor in an extended filesystem attribute. Samba > encountered the same problems with a lot of the win ACLs, they found > that for some things the only way to provide full support is to store > a perfect copy of the security descriptor. Doing so works around a > lot of these issues where there's no equivalent Unix permission. The problem is that reporting permissions that we don't really support leads to other problems. Hopefully NFSv4 (richacls) will get popular in Linux soon so it will be possible to fix it properly (currently only available on OSX and Suse 11.3). Thanks, Piotr

April 3, 2015

Re: winecfg: improve user experience by adding all Windows versions and accompanying error message

by Jason Overland

Is there anything I can do to improve this patch? Thanks, Jason On 03/26/2015 10:03 PM, Jason Overland wrote: > Hi, > This patch is a resubmission of and supersedes my previous patch "winecfg: add note about 32 bit prefixes to dialog". Thanks to everyone who provided feedback on that one. > > In this patch, winecfg's Application settings tab now includes all Windows versions in the combobox. If the user is running from a 64 bit prefix and selects a version of Windows that requires a 32 bit prefix, the selection will revert to the previous selection and a modal dialog containing an error message will appear: > > """ > This Wine prefix is built to support 64 bit applications. Because the Windows version you selected does not support 64 bit applications, this prefix cannot be configured to mimic that version of Windows. > > Please refer to "How do I create a 32 bit wineprefix on a 64 bit system?" in the "Using Wine" section of the Wine FAQ (http://wiki.winehq.org/FAQ) for instructions on how to create a 32 bit Wine prefix. > """ > > In addition, I noticed two File Open dialogs in winecfg which should be modal but are not modal. I made these modal by setting the appropriate owner window. While a separate issue, this seemed like a trivial enough change to include in this patch. >

April 3, 2015

Re: user32/tests: Avoid side-effect in an assert.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://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

April 3, 2015

Re: advapi32: Handle NULL DACL in SetSecurityInfo

by Erich E. Hoover

On Thu, Apr 2, 2015 at 4:54 PM, Piotr Caban <piotr(a)codeweavers.com> wrote: > ... > the patch restores old SetSecurityInfo behavior. It also works around a > crash in current implementation when NULL DACL is passed. It's as close to > native behavior as it currently can be. Setting NULL DACL means: allow every > permission on windows. Your test shows that we should get NULL while asking > about DACL but there's no way of correctly supporting it in wine currently > (and I'm not sure if it can be cleanly supported in future, as far as I can > see nor POSIX ACL, nor NFSv4 ACL supports anything like this). > ... This is one of the reasons why in our implementation we stored the security descriptor in an extended filesystem attribute. Samba encountered the same problems with a lot of the win ACLs, they found that for some things the only way to provide full support is to store a perfect copy of the security descriptor. Doing so works around a lot of these issues where there's no equivalent Unix permission. Best, Erich

April 2, 2015

Re: [1/3] server: Allow to open a directory without any permission bits.

by Sebastian Lackner

On 02.04.2015 11:24, Piotr Caban wrote: > 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 > You are right, the check for directories should probably be removed, and instead the access flags should be checked. I'll submit a v2 soon. Having a unix_fd is not really required, but basically all parts of the current wineserver file/dir management code depend on it at the moment - this could be changed of course. If someone else has a better idea or you guys prefer to have more tests first, for me it would also be fine when just the tests http://source.winehq.org/patches/data/110470 and http://source.winehq.org/patches/data/110473 are accepted instead. They leave the wine prefix in a broken state (undeletable directory), but the directory names are randomized, so it shouldn't really cause any problems. My main goal right now is mainly to document the behaviour, there are a lot of corner cases where noone thought about yet... ;) Best regards, Sebastian

April 2, 2015

Re: advapi32: Handle NULL DACL in SetSecurityInfo

by Sebastian Lackner

On 03.04.2015 00:54, Piotr Caban wrote: > the patch restores old SetSecurityInfo behavior. It also works around > a crash in current implementation when NULL DACL is passed. It's as > close to native behavior as it currently can be. Setting NULL DACL > means: allow every permission on windows. Your test shows that we > should get NULL while asking about DACL but there's no way of > correctly supporting it in wine currently (and I'm not sure if it can > be cleanly supported in future, as far as I can see nor POSIX ACL, > nor NFSv4 ACL supports anything like this). I didn't say that I have any problem with your solution, but I would really like to have all the differences to Windows documented in the form of tests. You probably know even better than me that the current ACL implementation of Wine is still terrible broken in a lot of situations, and its very easy to break things again, while trying to fix a different issue. Honestly, I would have really preferred to have more tests for everything before accepting a huge change like the DACL inheritance patch, but I think we should at least document all future changes a bit better. In this case the test is trivial and just a couple of lines long, so there is no good excuse to leave it out. ;) Best regards, Sebastian

April 2, 2015

Re: advapi32: Handle NULL DACL in SetSecurityInfo

by Piotr Caban

Hi, On 02/04/15 19:42, Sebastian Lackner wrote: > 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 the patch restores old SetSecurityInfo behavior. It also works around a crash in current implementation when NULL DACL is passed. It's as close to native behavior as it currently can be. Setting NULL DACL means: allow every permission on windows. Your test shows that we should get NULL while asking about DACL but there's no way of correctly supporting it in wine currently (and I'm not sure if it can be cleanly supported in future, as far as I can see nor POSIX ACL, nor NFSv4 ACL supports anything like this). There's following code in server to handle NULL DACL case: mode_t sd_to_mode( const struct security_descriptor *sd, const SID *owner ) ... if (present && dacl) ... else /* no ACL means full access rights to anyone */ new_mode = S_IRWXU | S_IRWXG | S_IRWXO; Cheers, Piotr

April 2, 2015

Re: [PATCH 3/4] d3drm/tests: Split tests between different versions, initially adding frame QueryInterface tests

by Aaryaman Vasishta

On Fri, Apr 3, 2015 at 1:45 AM, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > -----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. > I did set the editor to UTF-8 encoding, also that character does appear properly on my vim but it's still giving this odd behaviour while copying it over. > > You can add your own name there if you want. > I'm satisfied enough with my name being in the authors list. I don't mind whether my name is in those files or not :).

April 2, 2015

Re: [PATCH 4/4] d3drm/tests: Add vtable comparison tests in test_frame_qi

by Aaryaman Vasishta

On Fri, Apr 3, 2015 at 2:10 AM, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > -----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. > I've tried this and it works too. I'll use this on the patch try, and along with it also keep vtable_todo as some tests won't work on wine until they're fixed. > > 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. > > I'll keep this in mind the next time I come across it. Thank You! jam

April 2, 2015

Re: [PATCH 4/4] d3drm/tests: Add vtable comparison tests in test_frame_qi

by Stefan Dösinger

-----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-----

April 2, 2015

Re: [PATCH 3/4] d3drm/tests: Split tests between different versions, initially adding frame QueryInterface tests

by Stefan Dösinger

-----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-----

April 2, 2015

Re: [PATCH] undefined symbols compiling for macosx >10.8

by Ken Thomases

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 >>>> >>> >> >

April 2, 2015

Re: advapi32: Handle NULL DACL in SetSecurityInfo

by Sebastian Lackner

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

April 2, 2015

Re: [PATCH] vbscript: Fixed Hex(try 3)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://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

April 2, 2015

Re: [1/4] windowscodecs: Add test for PNG gAMA metadata.

by Vincent Povirk

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: >

April 2, 2015

Re: [PATCH] findstr: Added test for findstr. (try 2)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Am 2015-04-01 um 16:37 schrieb Kaipeng Zeng: > Excuse me,can anyone have a look at this patch? I appreciate for > any comment. Thanks！ I think the main issue is that the test alone doesn't do much. It should either be part of a series that gets the actual implementation started, or a series of tests that test more than the very minimum functionality. Wrt the code itself, I found a few more issues: > + wcmd = HeapAlloc(GetProcessHeap(), 0, strlen(cmd) + 1); > + strcpy(wcmd, cmd); Please check the return value. > + DWORD dwBytesToWrite = (DWORD)strlen(text_for_test); Is the cast necessary? Do you get a warning without it? > + while (ReadFile(hRead, output, GetFileSize(hRead, NULL), &bytesRead, NULL)) > + ; This can overflow your output buffer. > + file = CreateFileA("test.txt", GENERIC_READ|GENERIC_WRITE, 0, NULL, > + CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL); Here it's a good idea to check for errors as well. Same for WriteFile. > +void test_without_arg(void) > +{ > + char buffer[2048] = {0}; > + > + init_env(); > + todo_wine ok(!runcmd("findstr free test.txt", buffer), "'findstr free test.txt' fails\n"); > + todo_wine ok(!strcmp(buffer, "Wine will always be free software.\n"), > + "Return wrong string.\n"); > + DeleteFileA("test.txt"); > +} > + > +START_TEST(findstr) > +{ > + test_without_arg(); > +} init_env seems like something that should be called from the main function, not from the first test function. We want the individual tests to be independent of each other. The output written by the ok() lines could be improved. At least print the string and the return value findstr.exe reported. You do not have to print the expected result if the expected result is always the same - - ok() will print the line number. You could also consider skipping the string comparison if findstr.exe returns an unexpected error. It's quite unlikely the output is correct in this situation. Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVHU/bAAoJEN0/YqbEcdMwz+MP/izSwfPKUmGpXmA4k7q4ZTm/ XlNDuuPk4kfMaGNsO8gguYZgO4p24GOkL9weEPlB7+ny9ATXUpZIUSyNs7Gw292j YFWlfRUsyYHst8XfCkdDD7cy9EGQBCx3LLmZV1uhGKB2xWHPvQOKY/0fJPahBzEY TlZBkJWHbk7042wP3wmfcgbSupEw3QjmOqs1qymANqfIoDrJnD5qNsO2+DIbUdQq EiBclOWjE3YIw5yqkrN3YEoorNi/MKdLyWRalcyW/c95CoW2IdjQoHkMSyWmaU61 mPHiDli2j+EB0UtU/EaCB2LhevB1trh9DtrjGziQ6NfFq29g7Hzh9vgid8PhWGhP NS4bvvU5c3jGGsEAu4DmGSEqnueRtZj7lsaIMpdF8Hltigj0Z5j4AJIsq2hqlEW7 wIqLfJNPpuiqbaxv1OCAxbjWROYzufTowFUd3V8Yq8yzjfabsu1mXT6OQA4FRpTU HNo1sZBEIujbK+Es8tSAYOxjUbk4MmswXEuxoYq66libc5AAKLZEpUMa3uwZo/9n PC1Ro5G+UPJoz4xnBaZtyMi2kNnEySelvyb9/oba7X9v2rY3yAeAOSgUufUXN4Rq MlttxVM79ExbyhtLFKEIcbC5T9/eN7ZCVa3TiyVXxQ2d2Eeld4YHcTlBW7MWUYxD mPmsiQyDcRY8ZDqi6QwC =kPaj -----END PGP SIGNATURE-----

April 2, 2015

RE: mshtml: Removed return to ensure AddRef is called on an internal interface

by Alistair Leslie-Hughes

Created a bug. https://bugs.winehq.org/show_bug.cgi?id=38340 Best Regards Alistair Leslie-Hughes

April 2, 2015

Re: mshtml: Removed return to ensure AddRef is called on an internal interface

by Nikolay Sivov

On 02.04.2015 12:23, Piotr Caban wrote: > On 04/02/15 11:16, Alistair Leslie-Hughes wrote: >> But "*ppv·=·&This->IHTMLDOMNode_iface" does. Without an AddRef it causes >> an imbalance of AddRef/Release. >> >> So, should it be returning IHTMLDOMNode_iface then? > I'm not sure if I understand this code correctly but I think that > nsCycleCollectionISupports is an empty class that only needs a pointer. > There's no imbalance of AddRef/Release because Release will be never > called in this case. > I think it's just a marker, so gecko knows that this node is included in collection business.

April 2, 2015

Re: [1/3] server: Allow to open a directory without any permission bits.

by Piotr Caban

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

April 2, 2015

Re: mshtml: Removed return to ensure AddRef is called on an internal interface

by Piotr Caban

On 04/02/15 11:16, Alistair Leslie-Hughes wrote: > But "*ppv·=·&This->IHTMLDOMNode_iface" does. Without an AddRef it causes > an imbalance of AddRef/Release. > > So, should it be returning IHTMLDOMNode_iface then? I'm not sure if I understand this code correctly but I think that nsCycleCollectionISupports is an empty class that only needs a pointer. There's no imbalance of AddRef/Release because Release will be never called in this case.

April 2, 2015

Re: mshtml: Removed return to ensure AddRef is called on an internal interface

by Alistair Leslie-Hughes

On 02/04/15 19:58, Piotr Caban wrote: > The patch is wrong, nsCycleCollectionISupports doesn't support > AddRef/Release. > > But "*ppv·=·&This->IHTMLDOMNode_iface" does. Without an AddRef it causes an imbalance of AddRef/Release. So, should it be returning IHTMLDOMNode_iface then? Best Regards Alistair Leslie-Hughes.

April 2, 2015

Re: [1/3] server: Implement job limit flags (try 2)

by Nikolay Sivov

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.

April 2, 2015

Re: mshtml: Removed return to ensure AddRef is called on an internal interface

by Piotr Caban

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

April 2, 2015

Re: [1/3] server: Implement job limit flags

by Alexandre Julliard

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

April 2, 2015

Re: msctf: Always return FALSE in DllCanUnloadNow

by Qian Hong

Hi Alistair, Thanks for working on this bug! > If you created any of the other interfaces in the dll, there would be > chance it would still crash since the DLL could be unloaded since > MSCTF_refCount would be zero. Right, I tried to test more interface and tried to implement MSCTF_refCount based on information from all related interfaces refcounts, but it turns out too complicate and then I gave up. On Thu, Apr 2, 2015 at 2:51 PM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > My patch is consistent with other dlls, i.e. msxml3, mshtml, atl, > to ensue that the DLL isn't unloaded while an interface may exist. Seems a good solution to me, sadly I didn't know these examples, if I know I'd prefer this solution as well. -- Regards, Qian Hong - http://www.winehq.org

April 2, 2015

RE: msctf: Always return FALSE in DllCanUnloadNow

by Alistair Leslie-Hughes

Hi Sebastian, The patch on the bug only fixes a crash when using the ITfThreadMgr interface. If you created any of the other interfaces in the dll, there would be chance it would still crash since the DLL could be unloaded since MSCTF_refCount would be zero. My patch is consistent with other dlls, i.e. msxml3, mshtml, atl, to ensue that the DLL isn't unloaded while an interface may exist. Best Regards Alistair Leslie-Hughes > Date: Thu, 2 Apr 2015 03:37:48 +0200 > From: sebastian(a)fds-team.de > To: leslie_alistair(a)hotmail.com > CC: wine-devel(a)winehq.org > Subject: Re: msctf: Always return FALSE in DllCanUnloadNow > > 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. >

April 2, 2015

Re: comctl32/tests: Fix couple of metrics tests that fail on some systems (try 3)

by Nikolay Sivov

On 04/02/2015 02:15 AM, Marvin wrote: > 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 > Yes, this is expected.

April 2, 2015

Re: [PATCH (try2)] gdiplus: Avoid unnecessary pre-multiplied alpha conversions in GdipDrawImagePointsRect

by Vincent Povirk

It may make sense for now to say that if do_resampling is TRUE, we should still do the conversion, removing the need to modify resample_bitmap_pixel. If we do make resample_bitmap_pixel aware of pixel format, we also need to modify sample_bitmap_pixel so that it converts outside_color. I'd forgotten how complicated drawing images was. It was nice while it lasted. On Wed, Apr 1, 2015 at 12:53 PM, Vincent Povirk <madewokherd(a)gmail.com> wrote: > 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 >> >> >>

April 1, 2015

Re: msctf: Always return FALSE in DllCanUnloadNow

by Sebastian Lackner

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.

April 1, 2015

Problem receiving UDP broadcast on wxppro and w2008s64

by Bruno Jesus

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

April 1, 2015

Re: comctl32/tests: Fix couple of metrics tests that fail on some systems (try 3)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://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

April 1, 2015

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

by Stefan Dösinger

-----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-----

April 1, 2015

Re: [PATCH] uxtheme: Load MUI file when theme loaded.

by Nikolay Sivov

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.

April 1, 2015

Re: comctl32/tests: Fix couple of metrics tests that fail on some systems (try2)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://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

April 1, 2015

Re: d3dx9_36: Add D3DXFrameFind stub.

by Nikolay Sivov

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.

April 1, 2015

Re: [PATCH] undefined symbols compiling for macosx >10.8

by Ken Thomases

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 >> >

April 1, 2015

Re: [PATCH 3/4] d3drm/tests: Split tests seperately for IDirect3DRM{1-3} interfaces

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-04-01 um 19:43 schrieb Aaryaman Vasishta: > I agree that we should keep version independent tests in d3drm.c, > and the rest in their respective files. No, the idea is to have only d3drm1.c, d3drm2.c and d3drm3.c. I don't expect many version independent tests that deal with IDirect3DRM. I think this test is the only one, since everything else can be accessed through IDirect3DRM, IDirect3DRM2 and IDirect3DRM3. There are some math and vector helper functions that are independent of the d3drm COM interfaces and are thus not versioned. They are in vector.c, and I think that's a good place for them. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVHDPEAAoJEN0/YqbEcdMwR9wQAJBsW5LD/M8d9JYIlakkxyq6 wjbZkfhpI2Sgjj6lnUpuTmBl2pVm4kqbzu2kMdGsbV6//9+zRRF1cfN/8XE/ypgc uL/RwjdzM+hhzlq5p9KlLHg+UsMTjS3X2XrtA5h8p7T4iZ9enLFo7w9SAzM5hg6i xf+RhkkJn3rsW16H85C4QyceF7FClHWVjk7GZ7+3e/2LpgwSsheul3es+xfIGKwE m/h8Tv7YYQDncT3koRjvIBXrvTks6bcRaJA1+CArLL7xbGuBk9u0YTQXPZnAaKXu LdmMKn/QWndE4mL3+pPk1Gq1JcmaCdDudCAo02QsVBd97zCVjwNUG5joanm8T1bs lKZmehqQZYaX2YNN6u7W6XlEDAP2snrRktBkvqoqyLJlo2FPnlZElw2h3QABAWkR nEd3R3nRfEVmHXV46Un5cWAFSnN8gnQ3CXj4KQ1UWf68V7NBItUFSoEGc2Oq79B3 rvyfgz5hF5DbjrklPK7SfxYbvKbj1lbFXEoKEyBkJZdZrsH5/ASXd/D+6vg4LggQ JCIAJaA0JPh0IPTWPcxiG9GsEWBm7mC+UI6Fr3pxpVm6PitP/cb1sVh/CtSc6nYW sjZ+hmjyMgJGGfDCbuYPqDl7TrWhIeK4O1lIXsdSOfPESPQWC++POTF0os+M2MuM q4DbIpzgp8i3I1ppdUuy =6EYr -----END PGP SIGNATURE-----

April 1, 2015

Re: [PATCH 3/4] d3drm/tests: Split tests seperately for IDirect3DRM{1-3} interfaces

by Henri Verbeet

On 1 April 2015 at 19:34, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: >> +* Copyright 2012 Andr� Hentschel > This shows up wrong in my mail client. It may be a setup issue on my > side. It's not. It only looks correct on the patches site because it gets the encoding wrong, if you force it to utf-8 it's broken there as well.

April 1, 2015

Re: [PATCH (try2)] gdiplus: Avoid unnecessary pre-multiplied alpha conversions in GdipDrawImagePointsRect

by Vincent Povirk

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 > > >

April 1, 2015

Re: [PATCH 3/4] d3drm/tests: Split tests seperately for IDirect3DRM{1-3} interfaces

by Aaryaman Vasishta

> > 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. > I was planning in removing them from the start - but I must've forgotten to remove them while sending the patch over. I'll do the same and resend the patches. > > + 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. > So I should remove this test from d3drm1.c, d3drm2.c and d3drm3.c aswell? I'll keep this test in d3drm.c as it is. I agree that we should keep version independent tests in d3drm.c, and the rest in their respective files. > > --- 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? > I might've modified them a couple weeks ago. I'll resend the patch with the proper ordered Makefile.in > > +* 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. > > I used visual studio to copy these lines from d3drm.c. I'll fix it accordingly and resend the patch.

April 1, 2015

Re: [PATCH 3/4] d3drm/tests: Split tests seperately for IDirect3DRM{1-3} interfaces

by Stefan Dösinger

-----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-----

April 1, 2015

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

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=12593 Your paranoid android. === build (build) === Patch failed to apply

April 1, 2015

Re: [PATCH 3/4] d3drm/tests: Split tests seperately for IDirect3DRM{1-3} interfaces

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=12592 Your paranoid android. === build (build) === Patch failed to apply

April 1, 2015

Re: [PATCH] undefined symbols compiling for macosx >10.8

by Ken Thomases

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

April 1, 2015

Re: [PATCH] findstr: Added test for findstr. (try 2)

by Kaipeng Zeng

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() >

April 1, 2015

Re: [PATCH] vbscript: Implemented Oct(try 4)

by Piotr Caban

On 03/30/15 17:28, Shuai Meng wrote: > Hi, anyone who comment on this patch to improve it will be greatly > appreciated. This patch also looks good for me.

April 1, 2015

Re: Wine on Javascript

by Bruno Jesus

On Wed, Apr 1, 2015 at 7:25 AM, Jesse Litton <wine(a)eternaldusk.com> wrote: > This is why I try to avoid the internet on April 1st. I believe Zhenbo is telling the truth, since the kernel already boots from javascript [1] it's perfectly plausible that any application can run over it. [1] http://bellard.org/jslinux/ Best Regards, Bruno > On 04/01/2015 04:05 AM, Zhenbo Li wrote: >> 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… >> > > >

April 1, 2015

Re: [PATCH] vbscript: Fixed Hex(try 2)

by Piotr Caban

On 04/01/15 08:17, Shuai Meng wrote: > Hi all, is there anything to do to improve this patch? The patch looks good for me. Thanks, Piotr

April 1, 2015

Re: Wine on Javascript

by Jesse Litton

This is why I try to avoid the internet on April 1st. On 04/01/2015 04:05 AM, Zhenbo Li wrote: > 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… >

April 1, 2015

Wine on Javascript

by Zhenbo Li

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

April 1, 2015

Re: [PATCH] vbscript: Fixed Hex(try 2)

by Shuai Meng

testbot： https://newtestbot.winehq.org/JobDetails.pl?Key=12562 Hi all, is there anything to do to improve this patch? Thanks in advance. 2015-04-01 12:21 GMT+08:00 Marvin <testbot(a)winehq.org>: > 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 >

April 1, 2015

Re: [PATCH] vbscript: Fixed Hex(try 2)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://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

March 31, 2015

Re: [1/6] kernel32/tests: Extend IsProcessInJob tests (try 2)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=12559 Your paranoid android. === w7u (32 bit process) === prprocess.c:2496: Test failed: WaitForSingleObject returned 258

March 31, 2015

Re: [4/6] ntdll: Implement IsProcessInJob

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://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

March 31, 2015