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

Re: [PATCH 3/5] ddraw/tests: Handle a backbuffer palette misbehavior on Windows 8.

by Henri Verbeet

On 28 April 2014 15:21, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + * reference crashes. The primary has an extra reference after creation call, making > + * it tricky to destroy. Creating the primary adds 5 references to the ddraw interface, This is because of the 8 bpp display mode, I have a patch.

April 29, 2014

Re: [PATCH 01/10] vbscript: Fixed CBool(try 3)

by Shuai Meng

2014-04-21 17:18 GMT+08:00 Jacek Caban <jacek(a)codeweavers.com>: > Hi Shuai, > > On 04/21/14 03:45, Shuai Meng wrote: > > - > > - return return_bool(res, val); > > + V_VT(res) = VT_EMPTY; > > + return VariantChangeType(res, arg, VARIANT_LOCALBOOL, VT_BOOL); > > You can't assume that res is not NULL. If result of the function is not > used, it will be NULL. A simple test case is like this: > > call CBool(0) > > Also, are you sure we want VARIANT_LOCALBOOL here? Did you test it > (probably by running tests on localized Windows with translated string > "False")? > > Looking at CBool tests: > > +Call ok(CBool(Empty) = False, "CBool(Empty) = " & CBool(Empty)) > +Call ok(getVT(CBool(Empty)) = "VT_BOOL", "getVT(CBool(Empty)) = " & > getVT(CBool(Empty))) > +Call ok(CBool(1) = True, "CBool(1) = " & CBool(1)) > +Call ok(getVT(CBool(1)) = "VT_BOOL", "getVT(CBool(1)) = " & > getVT(CBool(1))) > +Call ok(CBool(CLng(0)) = False, "CBool(CLng(0)) = " & CBool(CLng(0))) > +Call ok(getVT(CBool(CLng(0))) = "VT_BOOL", "getVT(CBool(CLng(0))) = " & > getVT(CBool(CLng(0)))) > +Call ok(CBool(CSng(0.5)) = True, "CBool(CSng(0.5)) = " & CBool(CSng(0.5))) > +Call ok(getVT(CBool(CSng(0.5))) = "VT_BOOL", "getVT(CBool(CSng(0.5))) = " > & getVT(CBool(CSng(0.5)))) > +Call ok(CBool(-0.56) = True, "CBool(-0.56) = " & CBool(-0.56)) > +Call ok(getVT(CBool(-0.56)) = "VT_BOOL", "getVT(CBool(-0.56)) = " & > getVT(CBool(-0.56))) > +Call ok(CBool(CCur(8.55)) = True, "CBool(CCur(8.55)) = " & > CBool(CCur(8.55))) > +Call ok(getVT(CBool(CCur(8.55))) = "VT_BOOL", "getVT(CBool(CCur(8.55))) = > " & getVT(CBool(CCur(8.55)))) > +Call ok(CBool(CDate(0)) = False, "CBool(CDate(0)) = " & CBool(CDate(0))) > +Call ok(getVT(CBool(CDate(0))) = "VT_BOOL", "getVT(CBool(CDate(0))) = " & > getVT(CBool(CDate(0)))) > +Call ok(CBool(CDate(3.33)) = True, "CBool(CDate(3.33)) = " & > CBool(CDate(3.33))) > +Call ok(getVT(CBool(CDate(3.33))) = "VT_BOOL", "getVT(CBool(CDate(3.33))) > = " & getVT(CBool(CDate(3.33)))) > +Call ok(CBool("6666.78") = True, "CBool(""6666.78"") = " & > CBool("6666.78")) > +Call ok(getVT(CBool("6666.78")) = "VT_BOOL", "getVT(CBool(""6666.78"")) = > " & getVT(CBool("6666.78"))) > +Call ok(CBool(CByte(-0.1)) = False, "CBool(CByte(-0.1)) = " & > CBool(CByte(-0.1))) > +Call ok(getVT(CBool(CByte(-0.1))) = "VT_BOOL", "getVT(CBool(CByte(-0.1))) > = " & getVT(CBool(CByte(-0.1)))) > > Those look mostly good. However I'd like to see some more tests. > Interesting case is for example empty string and a "false", "False" and > "#FALSE#" string. These strings can't pass tests in testbot, I have tried. And I find a line in http://msdn.microsoft.com/en-us/library/2k9sfx3c(v=vs.84).aspx says that "If *expression* can't be interpreted as a numeric value, a run-time error occurs." Also I'd really like to see tests on object default > values. See the attached patch for an example. > I copied the example, and found that though tests on object default values passed in testbot, they can't pass in wine. I think this is because VariantChangeType function can't change an object into a VT_BOOL. So I delete them. > Those comments apply also to other patches in the series. It may be > easier to proceed if you resent just the first patch fixed and include > tests that don't depending on other patches in the series in the patch > itself. > > Cheers, > Jacek > > > >

April 29, 2014

Re: [PATCH 2/5] ddraw: Implement D3DOP_STATERENDER on top of IDirect3DDevice3_SetRenderState().

by Henri Verbeet

On 29 April 2014 12:10, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 2014-04-29 10:41, schrieb Henri Verbeet: >> + if (FAILED(IDirect3DDevice3_SetRenderState(&device->IDirect3DDevice2_iface, > Is the use of IDirect3DDevice2_iface intentional? > No, that is wrong, although this will work.

April 29, 2014

Re: [PATCH 2/5] ddraw: Implement D3DOP_STATERENDER on top of IDirect3DDevice3_SetRenderState().

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-04-29 10:41, schrieb Henri Verbeet: > + if (FAILED(IDirect3DDevice3_SetRenderState(&device->IDirect3DDevice2_iface, Is the use of IDirect3DDevice2_iface intentional? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTX3qrAAoJEN0/YqbEcdMwtacP/jW2hvsXFttAPKuQPjK1nLqI /EOKHK2V7p8kf9WrjvJfcy3WosiNVR3Z6WW0yF/EuF5rrqLw1zSGG0Go4WBTw5h3 DA7xDfnCZhIR9eNOnaxF9OWYaUzDI18/iEMlAVdxrVdpIJJBcrG5x/tWkklFzP9n gIS/LO3msAlTq3xeV96rXty+BYVt+iET2h49Iauw8NKJp9XGfn1a1DtSnY/LCBLV xzgTaKy1nym0Y8zI7xswzmqBsB2F0Mo8Rm7KlzHQz83lltFXS6Q1n/OyX/aVUg6R y8iM3H3gDpaeuykob+HuoEGU96JlYskPZFs94SYpdI0g5O2khM2znQ+qakJiI3ar KSa1DnudgN3eK8a735MUylas4P1IrwMRyMa8BXj5U7qN99WPkHyL0WeF+8JGD5JA A0d1Z/Ox+nA0V+4jFW6aSPeyIFI5BXSROltsDAztF4tjO16QPzMl9/tWOS8NeK23 9VEn/xqbg06oyHrTc5KKhi3u5NhUcoB5wXiTWUfmUftWEd91sUmwnvA/OHYPnAz3 xU1Fy/5E73LR1x5BJNRqZMmtKQxbRnmdMB7mf8wBJNqzt4oxzsqtVkVj1k5QOG/L WFUUmN6bL2iecLunNLo4jH8oPRujjUDW5kZHm4UCBPwtB+GecUMtP8rsSLVj++bu znfeqwAijofsnfpAL9Fa =Egcb -----END PGP SIGNATURE-----

April 29, 2014

Re: [PATCH 01/10] vbscript: Fixed CBool(try 3)

by Shuai Meng

2014-04-29 0:04 GMT+08:00 Piotr Caban <piotr.caban(a)gmail.com>: > On 04/28/14 17:26, Shuai Meng wrote: > >> >> >> >> 2014-04-21 17:18 GMT+08:00 Jacek Caban <jacek(a)codeweavers.com >> <mailto:jacek(a)codeweavers.com>>: >> >> >> Hi Shuai, >> >> On 04/21/14 03:45, Shuai Meng wrote: >> > - >> > - return return_bool(res, val); >> > + V_VT(res) = VT_EMPTY; >> > + return VariantChangeType(res, arg, VARIANT_LOCALBOOL, >> VT_BOOL); >> >> You can't assume that res is not NULL. If result of the function is >> not >> used, it will be NULL. A simple test case is like this: >> >> call CBool(0) >> >> Also, are you sure we want VARIANT_LOCALBOOL here? Did you test it >> (probably by running tests on localized Windows with translated string >> "False")? >> >> I don't quite understand what this parameter means, in fact I just >> copy it from to_string(). If not VARIANT_LOCALBOOL, waht esle should be >> filled here? >> > > I've checked what happens on non-english locale and CStr(True) = "True". > So the flag is used incorrectly in CStr implementation. CBool is also > failing when localized string is passed. > > You can use 0 as flag in VariantChangeType. > I've fixed this, but another problem appears. I put my new patch in the attachment, along with the test result of wine. It fails when tested in wine, while normal in my windows. I can't understand, this patch is almost the same with the previous one.

April 28, 2014

Re: wtsapi32: Partial implementation of WTSEnumerateProcessesW (try 4)

by Stefan Leichter

Hello, after this patch has left http://source.winehq.org/patches/ without any comment, i like to know what needs to be change to get this patch commited. Regards Stefan --- dlls/wtsapi32/tests/wtsapi.c | 1 - dlls/wtsapi32/wtsapi32.c | 65 ++++++++++++++++++++++++++++++++++++++++-- 2 files changed, 63 insertions(+), 3 deletions(-)

April 28, 2014

Re: [PATCH 5/5] ddraw/tests: Test mipmap GetDC behavior.

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=6629 Your paranoid android. === w2008s64 (64 bit ddraw7) === ddraw7.c:6376: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw7.c:6376: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw7.c:6376: Test failed: Test 6: Got unexpected pitch 252, expected 256. === w864 (64 bit ddraw7) === ddraw7.c:6115: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:6376: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw7.c:6376: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw7.c:6376: Test failed: Test 6: Got unexpected pitch 252, expected 256. ddraw7.c:6428: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:6493: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:6558: Test failed: Failed to create surface, hr 0x80004002.

April 28, 2014

Re: Fixing conflicts between WineD3D and WGL

by Ken Thomases

On Apr 28, 2014, at 11:25 AM, Bruno Jesus wrote: > On Mon, Apr 28, 2014 at 12:27 PM, Ken Thomases <ken(a)codeweavers.com> wrote: >> ... >> Thanks. Somebody else already reported something like that in private email and I have a fix already. I've uploaded that fix here <http://www.codeweavers.com/xfer/ken/wgl_wine_surface/wgl_surface_fix_list_m…> if you want to test. It applies on top of the original patch set plus the additional patch I linked in my previous email on this thread. I hope to have a revised consolidated patch set soon, too. > > That links shows an access forbidden patch requesting an unlock code. Sorry, yes. The access code was mentioned in the email where I first linked to my patch set. It is "wgl_wine_surface". I'll try to remember to mention that each time I post such a link. -Ken

April 28, 2014

Re: [PATCH 4/5] ddraw/tests: Add a test for getdc palette handling.

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=6628 Your paranoid android. === w2008s64 (64 bit ddraw7) === ddraw7.c:6376: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw7.c:6376: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw7.c:6376: Test failed: Test 6: Got unexpected pitch 252, expected 256. === w864 (64 bit ddraw7) === ddraw7.c:6115: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:6376: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw7.c:6376: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw7.c:6376: Test failed: Test 6: Got unexpected pitch 252, expected 256. ddraw7.c:6428: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:6493: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:6553: Test failed: Failed to create surface, hr 0x80004002.

April 28, 2014

Re: Fixing conflicts between WineD3D and WGL

by Bruno Jesus

On Mon, Apr 28, 2014 at 12:27 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > ... > Thanks. Somebody else already reported something like that in private email and I have a fix already. I've uploaded that fix here <http://www.codeweavers.com/xfer/ken/wgl_wine_surface/wgl_surface_fix_list_m…> if you want to test. It applies on top of the original patch set plus the additional patch I linked in my previous email on this thread. I hope to have a revised consolidated patch set soon, too. That links shows an access forbidden patch requesting an unlock code. > -Ken Bruno

April 28, 2014

Re: [PATCH 01/10] vbscript: Fixed CBool(try 3)

by Piotr Caban

On 04/28/14 17:26, Shuai Meng wrote: > > > > 2014-04-21 17:18 GMT+08:00 Jacek Caban <jacek(a)codeweavers.com > <mailto:jacek(a)codeweavers.com>>: > > Hi Shuai, > > On 04/21/14 03:45, Shuai Meng wrote: > > - > > - return return_bool(res, val); > > + V_VT(res) = VT_EMPTY; > > + return VariantChangeType(res, arg, VARIANT_LOCALBOOL, VT_BOOL); > > You can't assume that res is not NULL. If result of the function is not > used, it will be NULL. A simple test case is like this: > > call CBool(0) > > Also, are you sure we want VARIANT_LOCALBOOL here? Did you test it > (probably by running tests on localized Windows with translated string > "False")? > > I don't quite understand what this parameter means, in fact I just > copy it from to_string(). If not VARIANT_LOCALBOOL, waht esle should be > filled here? I've checked what happens on non-english locale and CStr(True) = "True". So the flag is used incorrectly in CStr implementation. CBool is also failing when localized string is passed. You can use 0 as flag in VariantChangeType.

April 28, 2014

Re: [PATCH 3/5] ddraw/tests: Handle a backbuffer palette misbehavior on Windows 8.

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=6626 Your paranoid android. === w2008s64 (64 bit ddraw7) === ddraw7.c:6376: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw7.c:6376: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw7.c:6376: Test failed: Test 6: Got unexpected pitch 252, expected 256. === w864 (64 bit ddraw7) === ddraw7.c:6115: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:6376: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw7.c:6376: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw7.c:6376: Test failed: Test 6: Got unexpected pitch 252, expected 256. ddraw7.c:6428: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:6493: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:6553: Test failed: Failed to create surface, hr 0x80004002.

April 28, 2014

Re: Fixing conflicts between WineD3D and WGL

by Ken Thomases

Hi, On Apr 28, 2014, at 6:53 AM, Jerome Leclanche wrote: > Your patchset causes X11 errors with the Battle.net client. 100% > reproducible, and also crashes within explorer.exe with +synchronous. > > I thought it was something else at first due to a bad revert and filed > the details here: https://bugs.winehq.org/show_bug.cgi?id=36141 Thanks. Somebody else already reported something like that in private email and I have a fix already. I've uploaded that fix here <http://www.codeweavers.com/xfer/ken/wgl_wine_surface/wgl_surface_fix_list_m…> if you want to test. It applies on top of the original patch set plus the additional patch I linked in my previous email on this thread. I hope to have a revised consolidated patch set soon, too. -Ken

April 28, 2014

Re: [PATCH 01/10] vbscript: Fixed CBool(try 3)

by Shuai Meng

2014-04-21 17:18 GMT+08:00 Jacek Caban <jacek(a)codeweavers.com>: > Hi Shuai, > > On 04/21/14 03:45, Shuai Meng wrote: > > - > > - return return_bool(res, val); > > + V_VT(res) = VT_EMPTY; > > + return VariantChangeType(res, arg, VARIANT_LOCALBOOL, VT_BOOL); > > You can't assume that res is not NULL. If result of the function is not > used, it will be NULL. A simple test case is like this: > > call CBool(0) > > Also, are you sure we want VARIANT_LOCALBOOL here? Did you test it > (probably by running tests on localized Windows with translated string > "False")? > > I don't quite understand what this parameter means, in fact I just copy it from to_string(). If not VARIANT_LOCALBOOL, waht esle should be filled here? > Looking at CBool tests: > > +Call ok(CBool(Empty) = False, "CBool(Empty) = " & CBool(Empty)) > +Call ok(getVT(CBool(Empty)) = "VT_BOOL", "getVT(CBool(Empty)) = " & > getVT(CBool(Empty))) > +Call ok(CBool(1) = True, "CBool(1) = " & CBool(1)) > +Call ok(getVT(CBool(1)) = "VT_BOOL", "getVT(CBool(1)) = " & > getVT(CBool(1))) > +Call ok(CBool(CLng(0)) = False, "CBool(CLng(0)) = " & CBool(CLng(0))) > +Call ok(getVT(CBool(CLng(0))) = "VT_BOOL", "getVT(CBool(CLng(0))) = " & > getVT(CBool(CLng(0)))) > +Call ok(CBool(CSng(0.5)) = True, "CBool(CSng(0.5)) = " & CBool(CSng(0.5))) > +Call ok(getVT(CBool(CSng(0.5))) = "VT_BOOL", "getVT(CBool(CSng(0.5))) = " > & getVT(CBool(CSng(0.5)))) > +Call ok(CBool(-0.56) = True, "CBool(-0.56) = " & CBool(-0.56)) > +Call ok(getVT(CBool(-0.56)) = "VT_BOOL", "getVT(CBool(-0.56)) = " & > getVT(CBool(-0.56))) > +Call ok(CBool(CCur(8.55)) = True, "CBool(CCur(8.55)) = " & > CBool(CCur(8.55))) > +Call ok(getVT(CBool(CCur(8.55))) = "VT_BOOL", "getVT(CBool(CCur(8.55))) = > " & getVT(CBool(CCur(8.55)))) > +Call ok(CBool(CDate(0)) = False, "CBool(CDate(0)) = " & CBool(CDate(0))) > +Call ok(getVT(CBool(CDate(0))) = "VT_BOOL", "getVT(CBool(CDate(0))) = " & > getVT(CBool(CDate(0)))) > +Call ok(CBool(CDate(3.33)) = True, "CBool(CDate(3.33)) = " & > CBool(CDate(3.33))) > +Call ok(getVT(CBool(CDate(3.33))) = "VT_BOOL", "getVT(CBool(CDate(3.33))) > = " & getVT(CBool(CDate(3.33)))) > +Call ok(CBool("6666.78") = True, "CBool(""6666.78"") = " & > CBool("6666.78")) > +Call ok(getVT(CBool("6666.78")) = "VT_BOOL", "getVT(CBool(""6666.78"")) = > " & getVT(CBool("6666.78"))) > +Call ok(CBool(CByte(-0.1)) = False, "CBool(CByte(-0.1)) = " & > CBool(CByte(-0.1))) > +Call ok(getVT(CBool(CByte(-0.1))) = "VT_BOOL", "getVT(CBool(CByte(-0.1))) > = " & getVT(CBool(CByte(-0.1)))) > > Those look mostly good. However I'd like to see some more tests. > Interesting case is for example empty string and a "false", "False" and > "#FALSE#" string. Also I'd really like to see tests on object default > values. See the attached patch for an example. > > Those comments apply also to other patches in the series. It may be > easier to proceed if you resent just the first patch fixed and include > tests that don't depending on other patches in the series in the patch > itself. > > Cheers, > Jacek > > > >

April 28, 2014

Re: [PATCH 2/5] ddraw/tests: Skip the ddraw7 primary palette test if 8 bpp mode doesn't work.

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=6625 Your paranoid android. === w864 (32 bit ddraw7) === ddraw7.c:5635: Test failed: Got unexpected refcount 3. ddraw7.c:5654: Test failed: Got unexpected refcount 3. ddraw7.c:5661: Test failed: Got unexpected hr 0. ddraw7.c:5664: Test failed: Got unexpected refcount 3. ddraw7.c:5666: Test failed: Got unexpected refcount 2. ddraw7.c:5672: Test failed: Got unexpected hr 0. ddraw7.c:5675: Test failed: Got unexpected refcount 2. ddraw7.c:5679: Test failed: Got unexpected refcount 6. ddraw7.c:5796: Test failed: Failed to set cooperative level, hr 0x8876023b. === w2008s64 (64 bit ddraw7) === ddraw7.c:6352: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw7.c:6352: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw7.c:6352: Test failed: Test 6: Got unexpected pitch 252, expected 256. === w864 (64 bit ddraw7) === ddraw7.c:6091: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:6352: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw7.c:6352: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw7.c:6352: Test failed: Test 6: Got unexpected pitch 252, expected 256. ddraw7.c:6404: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:6469: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:6529: Test failed: Failed to create surface, hr 0x80004002.

April 28, 2014

Re: [PATCH 1/5] ddraw/tests: Test P8 to RGB blits (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=6624 Your paranoid android. === w864 (32 bit ddraw2) === ddraw2.c:5096: Test failed: Got unexpected refcount 3. ddraw2.c:5115: Test failed: Got unexpected refcount 3. ddraw2.c:5122: Test failed: Got unexpected hr 0. ddraw2.c:5125: Test failed: Got unexpected refcount 3. ddraw2.c:5127: Test failed: Got unexpected refcount 2. ddraw2.c:5133: Test failed: Got unexpected hr 0. ddraw2.c:5136: Test failed: Got unexpected refcount 2. ddraw2.c:5138: Test failed: Got unexpected refcount 1. === w864 (32 bit ddraw1) === ddraw1.c:3991: Test failed: Got unexpected refcount 3. ddraw1.c:4010: Test failed: Got unexpected refcount 3. ddraw1.c:4017: Test failed: Got unexpected hr 0. ddraw1.c:4020: Test failed: Got unexpected refcount 3. ddraw1.c:4022: Test failed: Got unexpected refcount 2. ddraw1.c:4028: Test failed: Got unexpected hr 0. ddraw1.c:4031: Test failed: Got unexpected refcount 2. ddraw1.c:4033: Test failed: Got unexpected refcount 1. === wxppro (32 bit ddraw7) === ddraw7.c:5652: Test failed: Got unexpected palette 00000000, expected 00247AE8. ddraw7: unhandled exception c0000005 at 0045EB6B === wvista (32 bit ddraw7) === ddraw7.c:5652: Test failed: Got unexpected palette 00000000, expected 00264A78. ddraw7: unhandled exception c0000005 at 0045EB6B === w2008s64 (32 bit ddraw7) === ddraw7.c:5652: Test failed: Got unexpected palette 00000000, expected 005CFE60. ddraw7: unhandled exception c0000005 at 0045EB6B === w7u (32 bit ddraw7) === ddraw7.c:5652: Test failed: Got unexpected palette 00000000, expected 007ABEB8. ddraw7: unhandled exception c0000005 at 0045EB6B === w864 (32 bit ddraw7) === ddraw7.c:5629: Test failed: Got unexpected refcount 3. ddraw7.c:5648: Test failed: Got unexpected refcount 3. ddraw7.c:5655: Test failed: Got unexpected hr 0. ddraw7.c:5658: Test failed: Got unexpected refcount 3. ddraw7.c:5660: Test failed: Got unexpected refcount 2. ddraw7.c:5666: Test failed: Got unexpected hr 0. ddraw7.c:5669: Test failed: Got unexpected refcount 2. ddraw7.c:5673: Test failed: Got unexpected refcount 6. ddraw7.c:5790: Test failed: Failed to set cooperative level, hr 0x8876023b. === w2008s64 (64 bit ddraw7) === ddraw7.c:5652: Test failed: Got unexpected palette 0000000000000000, expected 0000000000732980. ddraw7: unhandled exception c0000005 at 0000000000454891 === w864 (64 bit ddraw7) === ddraw7.c:5652: Test failed: Got unexpected palette 0000000000000000, expected 00000000006C77A0. ddraw7: unhandled exception c0000005 at 0000000000454891 === w864 (32 bit ddraw4) === ddraw4.c:5756: Test failed: Got unexpected refcount 3. ddraw4.c:5775: Test failed: Got unexpected refcount 3. ddraw4.c:5782: Test failed: Got unexpected hr 0. ddraw4.c:5785: Test failed: Got unexpected refcount 3. ddraw4.c:5787: Test failed: Got unexpected refcount 2. ddraw4.c:5793: Test failed: Got unexpected hr 0. ddraw4.c:5796: Test failed: Got unexpected refcount 2. ddraw4.c:5798: Test failed: Got unexpected refcount 1. ddraw4.c:5800: Test failed: Got unexpected refcount 6. ddraw4.c:5920: Test failed: Failed to set cooperative level, hr 0x8876023b. ddraw4.c:5959: Test failed: Failed to attach surface, hr 0x887600e1. ddraw4.c:5962: Test failed: Got unexpected hr 0. ddraw4.c:5964: Test failed: Failed to detach surface, hr 0x887601c2. ddraw4.c:5967: Test failed: Failed to attach surface, hr 0x887601c2. ddraw4.c:5970: Test failed: Got unexpected hr 0x887601c2. ddraw4.c:5972: Test failed: Failed to detach surface, hr 0x887601c2. ddraw4.c:5975: Test failed: Failed to attach surface, hr 0x887601c2. ddraw4.c:5977: Test failed: Failed to detach surface, hr 0x887601c2. ddraw4.c:5980: Test failed: Got unexpected hr 0x887600e1. ddraw4.c:5982: Test failed: Got unexpected hr 0x887601c2.

April 28, 2014

Re: mshtml: Renamed nsIDOMHTMLSelectElement::Remove to select_Remove to avoid conflict with nsIDOMElement.

by Jacek Caban

On 04/28/14 14:06, Zhenbo Li wrote: > Thanks, Jacek > This patch should fix that problem, but would it hide the problem in widl? > > I tried midl.exe with VS, and got > #define nsIDOMHTMLSelectElement_Remove(This,index) \ > ( (This)->lpVtbl -> Remove(This,index) ) > > Then why widl can't handle this situation? I tested midl on a simpler case and it will output two different macros for that as well as two entries in vtbl. This will cause a conflict during compilation (in C, it's perfectly fine for C++). widl produces only one macro (see commit 65f418493683d96d4fd625ab019ea400eec4c19a), so that the header is at least valid in such case. There is not much more we can do. Jacek

April 28, 2014

Re: mshtml: Renamed nsIDOMHTMLSelectElement::Remove to select_Remove to avoid conflict with nsIDOMElement.

by Zhenbo Li

Thanks, Jacek This patch should fix that problem, but would it hide the problem in widl? I tried midl.exe with VS, and got #define nsIDOMHTMLSelectElement_Remove(This,index) \ ( (This)->lpVtbl -> Remove(This,index) ) Then why widl can't handle this situation? 2014-04-28 18:17 GMT+08:00 Jacek Caban <jacek(a)codeweavers.com>: > Spotted by Zhenbo Li. > > --- > dlls/mshtml/nsiface.idl | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > -- Have a nice day! Zhenbo Li

April 28, 2014

Re: Fixing conflicts between WineD3D and WGL

by Jerome Leclanche

Hi Ken Your patchset causes X11 errors with the Battle.net client. 100% reproducible, and also crashes within explorer.exe with +synchronous. I thought it was something else at first due to a bad revert and filed the details here: https://bugs.winehq.org/show_bug.cgi?id=36141 You can download the Battle.net Client here: https://us.battle.net/account/download/ J. Leclanche On Thu, Apr 24, 2014 at 4:29 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > Hi, > > On Apr 23, 2014, at 4:13 PM, Stefan Dösinger wrote: > >> I tested this a little bit sooner than expected, thanks to a >> regression in Starcraft and Age of Empires 2. (Looks like bugs 35950 >> and 35655). > > Thanks for testing! > >> The good news is that your patches fix the regressions in those games. > > Nice. > >> Am 2014-04-21 17:49, schrieb Ken Thomases: >>> * Full-screen games are actually full-screen, appearing in front >>> of other apps, docks, panels, menus, taskbars, etc. >> Kde 4.11.5 here. The fullscreen apps indeed appear fullscreen. But >> once Starcraft was shifted down and only showing the top ~50 pixels at >> the bottom of the screen. > > Strange. The only positioning of the full-screen windows that the code ever does is moving it to get_primary_rect() converted from Win32 virtual screen coordinates to root coordinates. > >> Inside a virtual desktop Age of Empires 2 seemed to snap into place >> after a resolution change. It first rendered at the bottom of the >> screen and after ~0.5 seconds the rendering was correct. > > Yes, the code watches for root window configuration changes and repositions itself when that happens. It tries to keep itself filling the screen. The delay was probably because the app didn't return to processing events for a bit. I think I can improve that by hooking into X11DRV_resize_desktop(). > > When it's managed (not in a virtual desktop window), it also sets _NET_WM_STATE_FULLSCREEN which should lead the window manager to keep it in position. > > >>> * But you can switch to another app as well/easily as you could >>> without these patches. Full-screen games don't take over your >>> whole display such that you can't escape without drastic measures. >> Alt-Tab does not work. The game loses focus and stops redrawing, but >> my other apps don't show up. Switching to a different virtual desktop >> works. I don't know if this worked in the past with those two games, >> probably not. I'll retest with plain Wine, as far as the regressions >> allow. > > My understanding is that most window managers only keep _NET_WM_STATE_FULLSCREEN windows over everything else as long as they have focus. Did the desktop environment's panels, docks, taskbars, etc. show up when the game lost focus? > > The problem may be that I also set _NET_WM_STATE_ABOVE. That's what happens for a WS_EX_TOPMOST window, which wined3d used to use prior to my patches, so I emulated that. > > >>> * After switching away, you can switch back successfully. >> I have to select the Wine window. If I select the game window, Wine's >> rendering window does not take over. > > I have an additional patch that may fix that. Please try applying <http://www.codeweavers.com/xfer/ken/wgl_wine_surface/wgl_surface_fixes_and_…> on top of the other patches. > > The main thing it does for this issue is set WM_HINTS.window_group to be the device window. That should convince KDE to allow it to "steal" focus from the device window. (I think what you were encountering is KDE's focus stealing prevention feature.) > > I've also reordered setting focus vs. raising the window. And I'm trying a _NET_ACTIVATE_WINDOW request on top of all that. > > It also adds a bunch of additional logging for diagnosing other issues. > > -Ken > > >

April 28, 2014

Re: [draft patch] atl100/tests: Added more tests for AtlAxWin{, Lic} procedure.

by Qian Hong

Hello, Please ignore this, there is one bug in the code. I've had more tests recent days, I'll update my new result later. Now I found even more incompatible between atl80 and atl100.. The ATL_PROPMAP_ENTRY struct is different between atl80 and atl100, but it is undocumented... What a crazy fun black box testing to figure out this! :)

April 28, 2014

Re: mshtml: Added IHTMLTable::width property implementation. (try 5)

by Jacek Caban

Hi Zhenbo, This looks better, but there are two more things I didn't catch earlier. On 04/27/14 15:08, Zhenbo Li wrote: > + nsres = nsIDOMHTMLTableElement_GetWidth(This->nstable, &val); > + if (NS_FAILED(nsres)){ > + ERR("Get Width(%s) failed!\n", debugstr_variant(p)); You can't access output argument (p) here. This will be undefined. > + nsAString_Finish(&val); > + return E_FAIL; > + } > + > + hres = nsstr_to_truncated_bstr(&val, &bstr); > + > + V_VT(p) = VT_BSTR; > + V_BSTR(p) = bstr; > + return hres; You leak val here. Jacek

April 28, 2014

Re: [RFC 1/11] Linux FF: Joystick control panel program

by Elias Vanderstuyft

Hi, I've got an additional question about EnumEffects(): Why does the JoystickWImpl_EnumEffects() variant add the additional code (in contrast with the 'A' function variant)? : int xfd = This->joyfd; -- snip -- /* return to unacquired state if that's where it was */ if (xfd == -1) IDirectInputDevice8_Unacquire(iface); Elias

April 27, 2014

Re: winex11.drv: merge the clipboard and drag-and-drop import functions

by André Hentschel

Am 27.04.2014 11:20, schrieb Damjan Jovanovic: > * Merges the X selection import functions used by the clipboard and > drag-and-drop, now allowing files to be copied-and-pasted from X11 > apps into Wine apps, and new types (eg. images) to be > dragged-and-dropped from X11 apps into Wine apps (instead of just > files and text like before). Also has the benefit of now allowing > drag-and-drop to use INCR for large data transfers. > * Fixes several memory leaks in xdnd.c > * Uses GlobalAlloc() instead of HeapAlloc() for STGMEDIUM's hGlobal. > * De-duplicates considerable shared code. Cool work, but this sounds like "needs splitting"...

April 27, 2014

Re: Advice fixing #13683 (DirectX mouse overlay?)

by Christopher Thielen

Do you know of a method to watch texture load like this? I am able to find the spot in the executable where the cursor resource is loaded into a heap (and the address of that heap in the running process), but I am unable to link it to any particular texture create call. Perhaps there's a debugger which watches for memory access at certain locations? On 4/23/2014 1:59 AM, Stefan Dösinger wrote: > > Am 23.04.2014 um 09:15 schrieb Christopher Thielen <christopher(a)thielen.co>: >> Once the cursor data is loaded from bitmap16.flx to a heap, I never see a reference to that memory again, at least in an API trace. After various initializations, there are a lot of CreateTexture calls followed by LockRect ... UnlockRect. From reading around online, my guess is the game uploads textures using memcpy() while the rect is locked. Can anyone who knows a bit more about D3D confirm that's a probable method of uploading textures? > Correct. This is a common way to load textures. There are others, but they all involve LockRect and UnlockRect at some point. >

April 26, 2014

Re: mshtml: Added IHTMLTable::width property implementation. (try 4)

by Jacek Caban

On 04/26/14 16:38, Zhenbo Li wrote: > Hi Jacek, > > 2014-04-26 21:33 GMT+08:00 Jacek Caban <jacek(a)codeweavers.com>: >> On 04/26/14 15:20, Zhenbo Li wrote: >>> 2014-04-26 20:44 GMT+08:00 Jacek Caban <jacek(a)codeweavers.com>: >>>> Hi Zhenbo, >>>> >>>> This is better, but: >>>> >>>> On 04/26/14 05:12, Zhenbo Li wrote: >>>> >>>> + hres = var2str(&v, &val); >>>> + >>>> + if (hres != S_OK){ >>>> + ERR("Set Width(%s) failed when initializing a nsAString!\n", >>>> + debugstr_variant(&v)); >>>> + nsAString_Finish(&val); >>>> >>>> >>>> Again, this is not initialized in the error case. >>> As I've added >>>> + default: >>>> + nsAString_Init(nsstr, NULL); >>>> + FIXME("unsupported arg %s\n", debugstr_variant(p)); >>>> + return E_NOTIMPL; >>>> + } >>> Isn't it enough? >> I missed that change, but I think it's wrong. There are other error >> cases as well. nsAString_Init failure also leaves the string >> uninitialized (and it's on my TODO list to make sure that we may make >> nsAString_Init infailable, but that's a different story). It's also >> generally sane to expect that if a function fails, it's output parameter >> is not initialized. Please remove this new nsAString_Init call and >> nsAString_Finish in error case. >> > Thank you for your explanation. > How about this solution: > > + return nsAString_Init(nsstr, V_BSTR(p))? > + S_OK : E_OUTOFMEMORY; > + case VT_R8: > + hres = VarBstrFromR8(V_R8(p), 0, 0, &str); > + break; > + case VT_R4: > + hres = VarBstrFromR4(V_R4(p), 0, 0, &str); > + break; > + case VT_I4: > + hres = VarBstrFromI4(V_I4(p), 0, 0, &str); > + break; > + default: > + FIXME("unsupported arg %s\n", debugstr_variant(p)); > + hres = E_NOTIMPL; > + break; > + } > + if (FAILED(hres)) > + return hres; > + > + ret = nsAString_Init(nsstr, str); > + SysFreeString(str); > + return ret ? S_OK : E_OUTOFMEMORY; > +} This looks good. >>> Or you mean here? >>>> + ret = nsAString_Init(nsstr, str); >>>> + SysFreeString(str); >>>> + return ret ? S_OK : E_OUTOFMEMORY; >>> Should I free a string which failed when initializing due to out-of-memory? >> Which one? The way it's done currently is right. >> >>>> + >>>> + hres = nsstr_to_truncated_bstr(&val, &bstr); >>>> + if (FAILED(hres)) { >>>> + SysFreeString(bstr); >>>> >>>> >>>> And bstr is not initialized in error case. >>> The error case comes from >>>> + ret = end ? SysAllocStringLen(str, end-str) : SysAllocString(str); >>>> + if(!ret) >>>> + return E_OUTOFMEMORY; >>> I have the same question. >> Please read the code again. bstr is not initialized in this case, so you >> can't free it. > Sorry, I made a mistake. > When SysAllocString failes, should we mark bstr as NULL? > Like this: > > static HRESULT nsstr_to_truncated_bstr(const nsAString *nsstr, BSTR *ret_ptr) > { > //.... > ret = end ? SysAllocStringLen(str, end-str) : SysAllocString(str); > > *ret_ptr = ret; > return ret ? S_OK : E_OUTOFMEMORY; > } You don't need this... > static HRESULT WINAPI HTMLTable_get_width(IHTMLTable *iface, VARIANT *p) > { > //.... > hres = nsstr_to_truncated_bstr(&val, &bstr); > if (FAILED(hres)) > return hres; > //... > } ...once you change this. Jacek

April 26, 2014