Hi,
yesterday a patch of mine was committed to test more profile stuff from kernel32. When I have a look now at test.winehq.org I see that some test(s) crash on win98 but not on others.
Although I could use a if(0) construction (as is done in several other tests), I'm wondering if we should just not run specific tests on specific Windows versions. It's a shame that one OS version blocks the running of several other tests.
I have no idea yet how to achieve this without building in GetVersion style things, as logic and return values don't always make a good distinction.
Any ideas, thoughts?
Cheers,
Paul.
Paul Vriens paul.vriens.wine@gmail.com writes:
yesterday a patch of mine was committed to test more profile stuff from kernel32. When I have a look now at test.winehq.org I see that some test(s) crash on win98 but not on others.
Although I could use a if(0) construction (as is done in several other tests), I'm wondering if we should just not run specific tests on specific Windows versions. It's a shame that one OS version blocks the running of several other tests.
In general, if a feature crashes on Windows it's unlikely that an app would depend on it, so it's not a problem to disable or remove the test.
Alexandre Julliard wrote:
Paul Vriens paul.vriens.wine@gmail.com writes:
yesterday a patch of mine was committed to test more profile stuff from kernel32. When I have a look now at test.winehq.org I see that some test(s) crash on win98 but not on others.
Although I could use a if(0) construction (as is done in several other tests), I'm wondering if we should just not run specific tests on specific Windows versions. It's a shame that one OS version blocks the running of several other tests.
In general, if a feature crashes on Windows it's unlikely that an app would depend on it, so it's not a problem to disable or remove the test.
But in this case we're dealing with win98 which new apps will not support anymore!
I'll create a new patch to disable (with comments) the failing tests.
Cheers,
Paul.
Paul Vriens paul.vriens.wine@gmail.com writes:
But in this case we're dealing with win98 which new apps will not support anymore!
Of course the alternative is to simply stop worrying about test failures on win98...
Alexandre Julliard wrote:
Paul Vriens paul.vriens.wine@gmail.com writes:
But in this case we're dealing with win98 which new apps will not support anymore!
Of course the alternative is to simply stop worrying about test failures on win98...
I agree with that one.
So if we only have crashes on win9x we don't care. If we can avoid crashes/failures on win9x (by skip or other means) we don't run them on win9x. And if they crash on something higher then win9x we disable them totally.
Does that make sense?
Cheers,
Paul.
Paul Vriens paul.vriens.wine@gmail.com writes:
So if we only have crashes on win9x we don't care. If we can avoid crashes/failures on win9x (by skip or other means) we don't run them on win9x. And if they crash on something higher then win9x we disable them totally.
Does that make sense?
Sure; the thing we want to avoid is version checks in tests, because then things don't get tested on Wine when the version is changed. But as long as win98 is detected by its missing features then skipping things is fine.
Sure; the thing we want to avoid is version checks in tests, because then things don't get tested on Wine when the version is changed. But as long as win98 is detected by its missing features then skipping things is fine.
Shouldn't then the wine code do a version check too and behave differently if the winver is set to win98?
Stefan Dösinger stefandoesinger@gmx.at writes:
Shouldn't then the wine code do a version check too and behave differently if the winver is set to win98?
Only if there is an app that does the same version check and depends on both behaviors. It's very unlikely that an app would want to crash when the version is win98, so we don't need to replicate that behavior.
On 30.03.2007 09:14, Alexandre Julliard wrote:
Stefan Dösinger stefandoesinger@gmx.at writes:
Shouldn't then the wine code do a version check too and behave differently if the winver is set to win98?
Only if there is an app that does the same version check and depends on both behaviors. It's very unlikely that an app would want to crash when the version is win98, so we don't need to replicate that behavior.
Wasn't there some weird installshield behaviour where we had to crash like windows to make installshield happy?
Regards, Carl-Daniel
Alexandre Julliard wrote:
Paul Vriens paul.vriens.wine@gmail.com writes:
So if we only have crashes on win9x we don't care. If we can avoid crashes/failures on win9x (by skip or other means) we don't run them on win9x. And if they crash on something higher then win9x we disable them totally.
Does that make sense?
Sure; the thing we want to avoid is version checks in tests, because then things don't get tested on Wine when the version is changed. But as long as win98 is detected by its missing features then skipping things is fine.
Ok, I've got an example attached. I'm currently cleaning up the registry tests before I can/will start doing stuff with RegDeleteTree.
It turns out we had a lof of failures with this test on win98. It looks like win98 doesn't assign a new handle when the same registry key is opened. This means that the close test close the main handle and we thus have an issue in the first test after that (which assumes to have a valid handle).
The attached file uses the GetVersion to check for win9x, is that acceptable in this case? Or is just an extra RegOpenKey (with comments) enough?
The todo_wine is only there btw. to don't have an error when run in win9x emulated mode. That brings up another question. Should all test succeed in Wine regardless of the emulated mode?
Cheers,
Paul.
Paul Vriens paul.vriens.wine@gmail.com writes:
It turns out we had a lof of failures with this test on win98. It looks like win98 doesn't assign a new handle when the same registry key is opened. This means that the close test close the main handle and we thus have an issue in the first test after that (which assumes to have a valid handle).
The attached file uses the GetVersion to check for win9x, is that acceptable in this case? Or is just an extra RegOpenKey (with comments) enough?
The todo_wine is only there btw. to don't have an error when run in win9x emulated mode. That brings up another question. Should all test succeed in Wine regardless of the emulated mode?
That's precisely why we don't want to add version checks in the tests. It requires todo_wine, then to fix the todos we need to add version checks in the code, which adds complexity and extra code paths, for no benefit. There are a gazillion differences between NT and win9x, and we don't want to replicate them unless strictly necessary. The tests should simply be written in a way that works on all platforms without version checks.
Alexandre Julliard wrote:
Paul Vriens paul.vriens.wine@gmail.com writes:
yesterday a patch of mine was committed to test more profile stuff from kernel32. When I have a look now at test.winehq.org I see that some test(s) crash on win98 but not on others.
Although I could use a if(0) construction (as is done in several other tests), I'm wondering if we should just not run specific tests on specific Windows versions. It's a shame that one OS version blocks the running of several other tests.
In general, if a feature crashes on Windows it's unlikely that an app would depend on it, so it's not a problem to disable or remove the test.
Unfortunately, these days apps are coded for NT only and I would expect new applications to only be supported on XP upwards. However, I guess until we see a real application that confirms this, it is all hand-waving theory.