"Alexandre Julliard" julliard@winehq.com wrote:
May I see a log? Do I need to fix them, or someone with NT4 around should look at it?
Here's what I get (note that some of these already exist in the current version):
atom.c:55:Unicode APIs are supported atom.c:102: Test failed: succeeded adding c000 atom.c:111: Test failed: succeeded adding c000 atom.c:102: Test failed: succeeded adding c001 atom.c:111: Test failed: succeeded adding c001 [etc....] atom.c:102: Test failed: succeeded adding ffff atom.c:111: Test failed: succeeded adding ffff atom.c:136: Test failed: GlobalGetAtomNameA succeeded on short buffer atom.c:172: Test failed: succeded atom.c:203: Test failed: succeded atom.c:208: Test failed: succeded atom.c:257: Test failed: infinite loop atom.c:285: Test failed: delete atom succeded atom.c:303: Test failed: add succeded atom.c:308: Test failed: find succeded atom.c:322: Test failed: add succeded atom.c:324: Test failed: find succeded atom: 229529 tests executed, 0 marked as todo, 32778 failures.
Probably NT4 just doesn't set last error here. But we have to check for last error values, because it will be very hard to track down this problem if some application chokes on it. What do we have to do? Drop the test for last error? That's not an option IMO.
And this is what I get with your codepage test:
codepage.c:39: Test failed: should return an error and not touch buffer codepage.c:46: Test failed: should return an error and not touch buffer codepage: 4 tests executed, 0 marked as todo, 2 failures.
This should be investigated. Win2000 apparently has more strict tests for parameter validation and I don't see a reason why we shouldn't do the same.
I asssume we should adhere win2000 behaviour. Am I right? I'll remove redundant tests for unicode_OS and resubmit patch then.
We don't necessarily have to adhere to win2000. We can choose the behavior that makes the most sense, or that is the fastest.
One more question: should we add a point out in the test that tests are platform specific?
Not sure what you mean; the tests must not be platform specific, they must work on all platforms. Things that only work on a given platform don't need to be tested for, since it's very unlikely that apps depend on them (and we can add a test once we find such an app).
I have a suggestion then. How about removing conflicting tests but make Wine behave as win2000 (and actually as described in MSDN)?