October 2007 - Wine-Devel - list.winehq.org

Re: crypt32: Remove a test because of a Windows 2003 SP1 bug

by Juan Lang

> I was basing it on what you said in the commit - both the heading and > the comment in the patch. That's dangerous here. The details are small, but they matter: > 1. This patch is applied to remove the test for this feature^Wbug > in CertGetCertificateChain; No, the feature/bug is in CertGetIssuerCertificateFromStore. And the test tested for a single bit being cleared. In Windows 2003 SP1, that bit is instead set. So leaving the test as-is is misleading: it fails on at least one Windows platform (Windows 98 is unknown, because the crypt32 tests aren't running there for some reason that I don't know.) Changing it to cover both possibilities is my usual tactic, but in the case of a single bit, there are only two possibilities. Hence the comment in the patch: the bit being either set or cleared is acceptable on some system on which the test is run. How, then, is the test meaningful? > 2. Someone in the future submits a patch to fix the 'bug' in > CertGetCertificateChain for Wine; No - wrong function, and one which is not inconsistent in at least this detail on different versions of Windows. > Even if this is a deprecated API, there will still be applications > that are dependent on it. Of course, and the tests for the behavior of this API that is consistent remain. I just remove the test of this single bit, and document why. --Juan

Oct. 25, 2007

Re: bug 9986

by Reece Dunn

On 25/10/2007, Juan Lang <juan.lang(a)gmail.com> wrote: > Hi Tom, > > > Exchanged interpretation of XON and XOFF. > > It might help if you wrote the same explanation about their meanings > being reversed in your email that you did in the patch: Alexandre's > not likely to go check up on bugzilla. Tests would also be useful here as well, so that there is not a regression. - Reece

Oct. 25, 2007

Re: crypt32: Remove a test because of a Windows 2003 SP1 bug

by Reece Dunn

On 25/10/2007, Juan Lang <juan.lang(a)gmail.com> wrote: > > The test being removed is correct and valid. > > Are you certain? Remember that I wrote it ;) :) > > While a 100% pass rate is ideal, on Windows 2003 SP1 that test *is* > > failing due to a bug. > > Again, are you sure? Or are you just saying that because I said it is > in the commit? I was basing it on what you said in the commit - both the heading and the comment in the patch. > The definition of "bug" is sort of fluid here. I > wrote the test to check a fairly strange phenomenon: a cert that is > time valid is asked for its issuer, which happens *not* to be time > valid. The time valid flag is cleared in the process. It's not > entirely clear which cert the flag is supposed to apply to, and the > result surprised me when I wrote the test. Going on what you say here would make XP have the bug, and Windows 2003 SP1 containing a fix for the behaviour. > I call it a bug because the behavior is one way on Windows 2003 SP1, > but different on XP. It could be that it was in fact a bug in Windows > XP, which was fixed in Windows 2003, but reverted because some app > depended on the behavior. I agree that the differing behaviour is due to a bug. It also makes sense that the bug is in XP, and the fix was reverted because of application compatibility. > Furthermore, this function (CertGetIssuerFromStore) has been > deprecated in favor of CertGetCertificateChain, which I have > implemented and tested rather extensively. There appears to be no > disagreement over which cert the time valid flag applies to with > CertGetCertificateChain. That is good :). Based on what you are saying above, it looks as if MS created CertGetCertificationChain in part to address this bug, and are moving applications over to the corrected behaviour API, while retaining the old behaviour. > So I'm not sure that I share your reservation about removing the test. I know nothing of the API you are implementing, apart from what you mentioned here and in the patch. You clearly have a solid understanding of what is involved here. That said, imagine the following scenario: 1. This patch is applied to remove the test for this feature^Wbug in CertGetCertificateChain; 2. Someone in the future submits a patch to fix the 'bug' in CertGetCertificateChain for Wine; 3. A user attempts to run an application that is dependent on CertGetCertificateChain an d its broken behaviour, which fails to work and they start complaining. Based on what you said above, it looks as if something like this happened with Windows 2003. Thus, if the results from this test highlight a bug in Windows, surely the test should remain so that Wine can be bug-for-bug compatible. Even if this is a deprecated API, there will still be applications that are dependent on it. That is my rationale for keeping the test. Keep up the great work, - Reece

Oct. 25, 2007

Re: bug 9986

by Juan Lang

Hi Tom, > Exchanged interpretation of XON and XOFF. It might help if you wrote the same explanation about their meanings being reversed in your email that you did in the patch: Alexandre's not likely to go check up on bugzilla. --Juan

Oct. 25, 2007

Re: crypt32: Remove a test because of a Windows 2003 SP1 bug

by Juan Lang

> The test being removed is correct and valid. Are you certain? Remember that I wrote it ;) > While a 100% pass rate is ideal, on Windows 2003 SP1 that test *is* > failing due to a bug. Again, are you sure? Or are you just saying that because I said it is in the commit? The definition of "bug" is sort of fluid here. I wrote the test to check a fairly strange phenomenon: a cert that is time valid is asked for its issuer, which happens *not* to be time valid. The time valid flag is cleared in the process. It's not entirely clear which cert the flag is supposed to apply to, and the result surprised me when I wrote the test. I call it a bug because the behavior is one way on Windows 2003 SP1, but different on XP. It could be that it was in fact a bug in Windows XP, which was fixed in Windows 2003, but reverted because some app depended on the behavior. Furthermore, this function (CertGetIssuerFromStore) has been deprecated in favor of CertGetCertificateChain, which I have implemented and tested rather extensively. There appears to be no disagreement over which cert the time valid flag applies to with CertGetCertificateChain. So I'm not sure that I share your reservation about removing the test. --Juan

Oct. 25, 2007

Re: user32: Fix a test that now passes in Windows

by Reece Dunn

On 25/10/2007, James Hawkins wrote: > Hi, > > Changelog: > * Fix a test that now passes in Windows. Looking at the code, it looks as if they are now passing in Wine :). > dlls/user32/tests/dde.c | 13 ++++++++++--- > 1 files changed, 10 insertions(+), 3 deletions(-) > + str = (LPSTR)DdeAccessData(hdata, &size); > + ok(!lstrcmpA(str, "requested data\r\n"), "Expected 'requested data\\r\\n', got %s\n", str); Shouldn't there be quote marks around the %s (i.e. '%s', to match the expected value)? > + ok(size == 19, "Expected 19, got %d\n", size); > + > + ret = DdeUnaccessData(hdata); > + ok(ret == TRUE, "Expected TRUE, got %d\n", ret); These are new test cases. Since these are not fixes to existing test cases, they should really be in a separate patch. - Reece

Oct. 25, 2007

Re: Wine Gecko packaging

by Jacek Caban

Scott Ritchie wrote: > > What license is the gecko package under? Can I just bundle it with the > Wine package and have it work out of the box? > It's tri-license: MPL, GPL and LGPL, so as far as I understand it, it should be fine from license point of view (see http://www.mozilla.org/MPL) I think it could work. Thanks, Jacek

Oct. 25, 2007

Re: crypt32: Remove a test because of a Windows 2003 SP1 bug

by Reece Dunn

Juan Lang wrote: > - /* Now check just the time */ > - flags = CERT_STORE_TIME_VALIDITY_FLAG; > - parent = CertGetIssuerCertificateFromStore(store, child, NULL, &flags); > - ok(parent != NULL, "CertGetIssuerCertificateFromStore failed: %08x\n", > - GetLastError()); > - /* Oops: the child is not expired, so the time validity check actually > - * succeeds, even though the signing cert is expired. > + /* Checking time validity is not productive, because while most Windows > + * versions return 0 (time valid) because the child is not expired, > + * Windows 2003 SP1 returns that it is expired. Thus the range of > + * possibilities is covered, and a test verifies nothing. > */ The test being removed is correct and valid. Removing it could lead to a regression in Wine as this case is not being covered when this patch is applied. While a 100% pass rate is ideal, on Windows 2003 SP1 that test *is* failing due to a bug. However, this is the correct behaviour, and the bug is detected by this test. - Reece

Oct. 25, 2007

Re: Wine Gecko packaging

by Scott Ritchie

Jacek Caban wrote: > Hello, > > As you probably have noticed, downloading Gecko on first use confuses > users. Now, with last week patches, there is an other way to do it, > transparent for users. MSHTML code looks for cab file in $data_dir/gecko > (that is usually /usr/share/wine/gecko). Alternatively, if you run Wine > from build dir, it looks for $build_dir/../gecko. Wine checks it both in > wineprefixcreate and, if Gecko is not installed, on first usage. It > means that if you download wine_gecko-0.1.0.cab from SourceForge and put > it in the right place, you will no longer have to care about installing > Gecko. > > Now, it's time to consider Linux packages to simplify its use. In Gentoo > it may be a separate USE flag, but for other distributions that don't > support such things, we'll need a separate package. Such package will > need only one file placed in the right place, so it should be easy to do > and maintain (I don't expect versions to change often). Are Wine > packagers interested in creating Gecko packages? > What license is the gecko package under? Can I just bundle it with the Wine package and have it work out of the box? Thanks, Scott Ritchie

Oct. 25, 2007

ddraw:d3d tests failing consistently

by Reece Dunn

Hi, Looking at the ddraw:d3d tests, they are failing consistently on many Windows platforms: d3d.c:1039: Test failed: IDirect3DViewport_SetViewport returned 80070057 d3d.c:1050: Test failed: Vertex 2 differs. Got 129.000000 127.000000 1.000000 1.000000, expexted 133.000000 123.000000 1.000000 1.000000 d3d.c:1050: Test failed: Vertex 3 differs. Got 127.000000 129.000000 -1.000000 1.000000, expexted 123.000000 133.000000 -1.000000 1.000000 d3d.c:1050: Test failed: Vertex 4 differs. Got 128.500000 127.500000 0.500000 1.000000, expexted 130.500000 125.500000 0.500000 1.000000 d3d.c:1050: Test failed: Vertex 5 differs. Got 127.500000 128.500000 -0.500000 1.000000, expexted 125.500000 130.500000 -0.500000 1.000000 d3d.c:1050: Test failed: Vertex 6 differs. Got 127.500000 128.500000 0.000000 1.000000, expexted 125.500000 130.500000 0.000000 1.000000 d3d.c:1060: Test failed: IDirect3DViewport_SetViewport returned 80070057 d3d.c:1071: Test failed: Vertex 1 differs. Got 128.000000 128.000000 0.000000 1.000000, expexted 138.000000 148.000000 0.000000 1.000000 d3d.c:1071: Test failed: Vertex 2 differs. Got 129.000000 127.000000 1.000000 1.000000, expexted 143.000000 143.000000 1.000000 1.000000 d3d.c:1071: Test failed: Vertex 3 differs. Got 127.000000 129.000000 -1.000000 1.000000, expexted 133.000000 153.000000 -1.000000 1.000000 d3d.c:1071: Test failed: Vertex 4 differs. Got 128.500000 127.500000 0.500000 1.000000, expexted 140.500000 145.500000 0.500000 1.000000 d3d.c:1071: Test failed: Vertex 5 differs. Got 127.500000 128.500000 -0.500000 1.000000, expexted 135.500000 150.500000 -0.500000 1.000000 d3d.c:1071: Test failed: Vertex 6 differs. Got 127.500000 128.500000 0.000000 1.000000, expexted 135.500000 150.500000 0.000000 1.000000 d3d.c:1134: Test failed: Cliptest 3 differs. Got 00000020 expexted 00000026 d3d.c:1134: Test failed: Cliptest 4 differs. Got 00000010 expexted 00000019 d3d.c:1143: Test failed: IDirect3DViewport_SetViewport returned 80070057 d3d.c:1157: Test failed: Cliptest 1 differs. Got 00000000 expexted 00000002 d3d.c:1157: Test failed: Cliptest 2 differs. Got 00000000 expexted 00000001 d3d.c:1157: Test failed: Cliptest 3 differs. Got 00000020 expexted 00000022 d3d.c:1157: Test failed: Cliptest 4 differs. Got 00000010 expexted 00000011 d3d.c:1166: Test failed: IDirect3DViewport_SetViewport returned 80070057 d3d.c:1195: Test failed: IDirect3DViewport_SetViewport returned 80070057 d3d.c:1206: Test failed: Offscreen is 0 d3d.c:1217: Test failed: Offscreen is 0 d3d.c:1231: Test failed: Offscreen is 2 Does anyone know if this is a change in ddraw:d3d behaviour on Windows between versions/graphics drivers or has this test always failed? - Reece

Oct. 25, 2007