February 2013 - Wine-Devel - list.winehq.org

Re: [PATCH 7/8] vbscript: Added tests for invalid parameters in regular expression functions

by Piotr Caban

On 02/19/13 12:48, 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 > http://testbot.winehq.org/JobDetails.pl?Key=24455 > > Your paranoid android. > > > === WINEBUILD (build) === > Patch failed to apply > Testbot failed to update wine. Here are the result of manual run: http://testbot.winehq.org/JobDetails.pl?Key=24449

Feb. 19, 2013

Re: [PATCH 7/8] vbscript: Added tests for invalid parameters in regular expression functions

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

Feb. 19, 2013

Re: [PATCH 5/8] vbscript: Added RegExp.Execute tests

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

Feb. 19, 2013

Re: [PATCH 5/8] vbscript: Added RegExp.Execute tests

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

Feb. 19, 2013

Re: IE 6 related urlmon:protocol failures

by Francois Gouget

On Mon, 18 Feb 2013, Jacek Caban wrote: [...] > > wininet:http has the exact same problem. > > http://wiki.winehq.org/WineTestBotVMs#wininet > > > It seems to me like those tests could be simply removed. The part that > is failing is just a preparation for tests reading from cache. I'm not particularly attached to these tests so you'll get no objection from me. Thanks for looking into this! -- Francois Gouget <fgouget(a)codeweavers.com>,

Feb. 18, 2013

Re: Failing tests in the Japanese and Hebrew languages

by Francois Gouget

On Mon, 18 Feb 2013, Akihiro Sagawa wrote: > Did you change ANSI codepage? As you may know, Japanese (codepage > 932) is not compatible with Windows 1252 except for 7-bit ASCII > characters. So you have to change codepage settings, Language for > Non-Unicode Programs, in the Control Panel. Not specifically no. My understanding is that Windows 7 has essentially three separate locales. In this case we see that the test ran with: http://test.winehq.org/data/c41f6add0563252a5809c3c83cbb6a6e6f81c2d9/win7_f… * SystemDefaultLCID = 409 This is the system locale and it is set to English. http://www.sisulizer.com/_img/codepage-problems/w7-region-and-language-admi… * UserDefaultLCID = 40c The user locale here is set to French and determines the date / time format, number format, currency, etc. http://www.sisulizer.com/_img/codepage-problems/w7-regions-and-languages-fo… * UserDefaultUILanguage = 411 And this is the 'Display Language' which determines which language will be used for the GUI. Here it is set to Japanese. http://www.sisulizer.com/_img/codepage-problems/w7-region-and-language-lang… It's important for Wine to know which setting each API is impacted by. That's why I normally try to use different locales and display languages. I must admit I did not particularly pay attention to the system locale setting so all my VMs have it just set to English. But I'd like to keep it set differently from the others. I'd further argue that it's up to Wine's conformance tests to skip tests that don't make sense in the current environment. For instance there are tests where compare a result against a known English string, so these tests are skipped if running in a non-English locale (and here checking the right locale out of the three is crucial). Do you know of a specific test that fails because the system locale is currently set to English? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ It really galls me that most of the computer power in the world is wasted on screen savers. Chris Caldwell from the GIMPS project http://www.mersenne.org/prime.htm

Feb. 18, 2013

Re: [PATCH 1/2] wininet: Address string should never be converted to UNICODE in status notifications

by Jacek Caban

On 02/18/13 15:50, 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 > http://testbot.winehq.org/JobDetails.pl?Key=24441 > > Your paranoid android. That's because TestBot still can't update to current Wine version: http://testbot.winehq.org/JobDetails.pl?Key=24423 Jacek

Feb. 18, 2013

Re: [PATCH 1/2] wininet: Address string should never be converted to UNICODE in status notifications

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

Feb. 18, 2013

Re: IE 6 related urlmon:protocol failures

by Jacek Caban

On 02/18/13 12:49, Francois Gouget wrote: > On Sat, 16 Feb 2013, Jacek Caban wrote: > >> On 2/16/13 1:28 AM, Francois Gouget wrote: >>> However I think the test should still not fail. So I'm looking for a >>> volunteer to either get the test to succeed with urlmon 6.0, or find a >>> way to detect it and skip these three tests. >> I believe it's time to skip those tests on IE6 then. I will send a patch. >> Thanks for the analyze. > wininet:http has the exact same problem. > http://wiki.winehq.org/WineTestBotVMs#wininet It seems to me like those tests could be simply removed. The part that is failing is just a preparation for tests reading from cache. And the important part of those tests always fail on Windows (the comment says that they fail on new Windows, but AFAICS on both testbots, they always fail). Those tests are also marked todo_wine. It would be great to make proper use of cache in our http implementation, but that will require writing more tests anyway. > /me trying to push my luck<g>. Don't hesitate to push more if needed :) Cheers, Jacek

Feb. 18, 2013

Re: Failing tests in the Japanese and Hebrew languages

by Akihiro Sagawa

Did you change ANSI codepage? As you may know, Japanese (codepage 932) is not compatible with Windows 1252 except for 7-bit ASCII characters. So you have to change codepage settings, Language for Non-Unicode Programs, in the Control Panel. Most of wine test try to run ANSI version of APIs. Language specific texts (e.g. error messages, startup folder name, day of week names, font face name) aren't represented properly in other codepages. On Sun, 17 Feb 2013 10:52:06 +0100 (CET), Francois Gouget wrote: > * comctl32:listview (Hebrew and Japanese) > listview.c:3822: Test failed: Expected 96, got 112 > listview.c:4751: Test failed: Expected 96, got 112 > > Both correspond to the use of GetDeviceCaps(LOGPIXELSX) so something > must be wrong there: > todo_wine expect(((GetDeviceCaps(hdc, LOGPIXELSX) + 15) / 16) * 16, rect.right); > todo_wine expect(((GetDeviceCaps(hdc, LOGPIXELSX) + 15) / 16) * 16, ret); It seems that this size depends on window appearance. I changed font size of "Icon" in "Window Color and Appearance" window. The test was passed in "Tahoma 8", but failed in "Meiryo 9", Japanese default settings in Windows 7. The default settings were "Tahoma 8" in Windows XP era, thus the testbot doesn't complain about this. (skip Hebrew topic...) > * rpcrt4:rpc (Japanese only) > rpc.c:171: Test failed: DceErrorInqTextA(deviation...) > > Based on the comment it does not seem surprising that this would > be language-specific: > /* One for which FormatMessage should succeed but > * DceErrorInqText should "fail" > * 3814 is generally quite a long message > */ Yes, I verified DceErrorInqTextA returned language-specific message on native Windows. I guess this caused by ANSI conversion error. But it is curious why test on line 164 was succeeded. Anyway, these tests succeeded on my PC, Japanese Windows 7 (x64). > * shell32:progman_dde (Hebrew and Japanese) > progman_dde.c:377: Test failed: Window "?????" was not created in 45 seconds - assumed failure. [S_G:11] > > Based on the 'S_G:11' this would correspond to this line: > ShowGroupTest(instance, hConv, "[ShowGroup(Startup,0)]", DMLERR_NO_ERROR, "Startup", StartupTitle, TRUE, DDE_TEST_SHOWGROUP|testnum++); Ditto. There is ANSI conversion error, too. I guess "?????" is localized startup folder name that didn't convert into Windows 1252 characters. This test also succeeded on my PC. Regards, Akihiro Sagawa

Feb. 18, 2013