kernel32: Fix a test that fails on all NT platforms

Paul Vriens at
Tue Apr 22 02:48:02 CDT 2008

James Hawkins wrote:
> On Tue, Apr 22, 2008 at 1:33 AM, Paul Vriens < at> wrote:
>> James Hawkins wrote:
>>> Hi,
>>> Changelog:
>>> * Fix a test that fails on all NT platforms.
>>>  dlls/kernel32/tests/toolhelp.c |   12 +++++++++---
>>>  1 files changed, 9 insertions(+), 3 deletions(-)
>>> ------------------------------------------------------------------------
>>  Hi James,
>>  I've been looking at some of the patches to fix the tests but I'm a bit
>> unsure if some of them are the correct way to go. Things like:
>>  +    /* win9x does not return a thread, NT does */
>>      te.dwSize = sizeof(te);
>>  -    ok(!pThread32First( hSnapshot, &te ), "shouldn't return a thread\n");
>>  +    ret = pThread32First( hSnapshot, &te );
>>  +    ok(ret || !ret, "You'll never see this\n");
>>  renders the whole test useless.
> That's the point; the test is useless.  If a test fails on one
> platform but succeeds in another, then we're testing a behavior that
> can't be relied on, or the test is not specific enough.  We leave it
> around for documentation of that fact.
>> It turns out that win9x in this case leaves
>> te.dwSize and XP-and-up set te.dwSize to 0. Shouldn't we make use of that
>> fact?
> You could, but it doesn't change the fact that the behavior is not
> reliable across different platforms.  If we knew an app that makes
> this exact check and depends on the results, then sure we should add a
> pickier test.  As it stands, it's just a bit too nit-picky.

But if it's just for documentation purposes (as for now we don't know an app 
that depends on it) isn't my example a bit better? (I agree about the nit-picky 

>>  On a sidenote (and this has been the case for a long time):
>>  I've seen patches where
>>  ok(function(a,b),"Failed");
>>  is turned into
>>  c = function(a,b);
>>  if (c)
>>  {
>>   .....
>>  }
>>  but done without a skip or such. So if Wine has a regression for 'function'
>> we won't notice.
> Tell that to the platforms that fail too.  Thus, this is a behavior
> that can't be relied on.  Wine strives to have compatibility with all
> the platforms we test on.  We don't stick to one specific version, and
> if we did, we could arbitrarily pick the version that fails this
> function, then failing would be the right behavior.

If a function consistently fails that's true but there are all kinds of 
circumstances that a function could fail. I agree we shouldn't care about the 
specific version but just ignoring failure because one of the versions fails is 
not correct in my opinion. We already had this 'discussion' with failures that 
only happen on win9x and the fact whether we should cater for that are just let 
it be. 'Let it be' was AJ's opinion back than, unless we have a nice way of 
catching it.

>>  We have loads of patches where we expect 3 or more different last errors.
>> This will make sure the tests always succeed of course but makes it
>> difficult to tell if we (Wine) are doing the correct/best thing.
> You're missing the broader picture.  If a function returns three or
> more different last errors, how can any app depend on that either?
> What is the definition of the "correct/best thing"?

Agreed, if versions pass different last errors an app could hardly be depending 
on it.

I agree on most of your points as we merely showing that versions return 
different errors or even succeed or fail depending on the OS. But I also think 
that the more we know about the circumstances the more we should document them.

Having a 1.0 soon will most likely broaden the numbers of users and hence apps 
that people are going to (try to) run with Wine. The chances will become bigger 
that there is an app out there that will make use of version differences by 
whatever means. I've seen several apps that do a whole lot of things just to to 
find out on what version/OS they are running on (and I'm not talking about copy 
protection apps).



More information about the wine-devel mailing list