Regression Test - kernel atom test
dmitry at baikal.ru
Thu Oct 3 18:40:33 CDT 2002
"Alexandre Julliard" <julliard at 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
> 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
> > 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)?
More information about the wine-devel