Hi,
SPI_{GET,SET}ICONTITLEWRAP is not implemented on a standard Win98 SE.
Changelog Check for availability of SPI_GETICONTITLEWRAP
Cheers,
Paul.
Hi Paul,
I agree we definately should not be leaving keys/values in user's registries that weren't there originally after the test has been run. Ideally all should be returned to exactly the way it was before the test was run. Unfortunately this patch won't correct the issue. This patch implies that SPI_{GET,SET}ICONTITLEWRAP is not a supported call on Win98 which it is. As a result it will always pass and the registry will still get a new value added. Try the following patch. It was just put together quickly and only covers this one test, but testing here shows it does stop a new value from being added if it did not exist to begin with. I would like to create something that covers the entire sysparams suite of tests to stop this across the board.
Thanks for the heads up on this!
Justin
On Tue, 2005-01-25 at 05:29, jchevrier@nexicom.net wrote:
Hi,
SPI_{GET,SET}ICONTITLEWRAP is not implemented on a standard Win98 SE.
Changelog Check for availability of SPI_GETICONTITLEWRAP
Cheers,
Paul.
Hi Paul,
I agree we definately should not be leaving keys/values in user's registries that weren't there originally after the test has been run. Ideally all should be returned to exactly the way it was before the test was run. Unfortunately this patch won't correct the issue. This patch implies that SPI_{GET,SET}ICONTITLEWRAP is not a supported call on Win98 which it is. As a result it will always pass and the registry will still get a new value added. Try the following patch. It was just put together quickly and only covers this one test, but testing here shows it does stop a new value from being added if it did not exist to begin with. I would like to create something that covers the entire sysparams suite of tests to stop this across the board.
Thanks for the heads up on this!
Justin
Hi Justin,
it appears we should do both then? If I put in an extra trace:
trace("testing SPI_{GET,SET}ICONTITLEWRAP\n"); rc=SystemParametersInfoA( SPI_GETICONTITLEWRAP, 0, &old_b, 0 ); trace("rc=%d err=%ld\n",rc,GetLastError());
the result on my Win98 box is:
sysparams.c:693:testing SPI_{GET,SET}ICONTITLEWRAP sysparams.c:695:rc=1 err=120
doesn't this mean ERROR_CALL_NOT_IMPLEMENTED?
I installed Win98SE from the CD and just ran Windows Update.
Cheers,
Paul.
Paul Vriens wrote:
On Tue, 2005-01-25 at 05:29, jchevrier@nexicom.net wrote:
Hi,
SPI_{GET,SET}ICONTITLEWRAP is not implemented on a standard Win98 SE.
Changelog Check for availability of SPI_GETICONTITLEWRAP
Cheers,
Paul.
Hi Paul,
I agree we definately should not be leaving keys/values in user's registries that weren't there originally after the test has been run. Ideally all should be returned to exactly the way it was before the test was run. Unfortunately this patch won't correct the issue. This patch implies that SPI_{GET,SET}ICONTITLEWRAP is not a supported call on Win98 which it is. As a result it will always pass and the registry will still get a new value added. Try the following patch. It was just put together quickly and only covers this one test, but testing here shows it does stop a new value from being added if it did not exist to begin with. I would like to create something that covers the entire sysparams suite of tests to stop this across the board.
Thanks for the heads up on this!
Justin
Hi Justin,
it appears we should do both then? If I put in an extra trace:
trace("testing SPI_{GET,SET}ICONTITLEWRAP\n"); rc=SystemParametersInfoA( SPI_GETICONTITLEWRAP, 0, &old_b, 0 ); trace("rc=%d err=%ld\n",rc,GetLastError());
the result on my Win98 box is:
sysparams.c:693:testing SPI_{GET,SET}ICONTITLEWRAP sysparams.c:695:rc=1 err=120
doesn't this mean ERROR_CALL_NOT_IMPLEMENTED?
I installed Win98SE from the CD and just ran Windows Update.
Cheers,
Paul.
It appears that for whatever reason that call isn't implemented there. I did a clean install of Windows 98SE here from CD to make sure my install wasn't tainted and the test passes fine (save for the non existant Registry value). I have not done any updates through Windows update however and it is as it was installed from the CD. Maybe this call was removed by some of the updates? I find that odd tho. I'm just taking wide guesses now but is it an English (North American) version of Windows? Colour depth?
I'll do the updates through Windows Updates next and see if that changes anything. Did you just do critical updates?
Justin
jchevrier@nexicom.net wrote:
It appears that for whatever reason that call isn't implemented there. I did a clean install of Windows 98SE here from CD to make sure my install wasn't tainted and the test passes fine (save for the non existant Registry value). I have not done any updates through Windows update
But that's exactly what's wrong. The current test doesn't check if the call is implemented. It then tries to read the entry (which is not there) and creates one afterwards. All subsequent test will succeed now, because the implementation is not checked and the key is left there.
Just add a trace after the call as I did to check if the call is implemented.
however and it is as it was installed from the CD. Maybe this call was removed by some of the updates? I find that odd tho. I'm just taking wide guesses now but is it an English (North American) version of Windows? Colour depth?
I'll do the updates through Windows Updates next and see if that changes anything. Did you just do critical updates?
Yep.
Justin
Paul
Paul Vriens wrote:
jchevrier@nexicom.net wrote:
It appears that for whatever reason that call isn't implemented there. I did a clean install of Windows 98SE here from CD to make sure my install wasn't tainted and the test passes fine (save for the non existant Registry value). I have not done any updates through Windows update
But that's exactly what's wrong. The current test doesn't check if the call is implemented. It then tries to read the entry (which is not there) and creates one afterwards. All subsequent test will succeed now, because the implementation is not checked and the key is left there.
Just add a trace after the call as I did to check if the call is implemented.
however and it is as it was installed from the CD. Maybe this call was removed by some of the updates? I find that odd tho. I'm just taking wide guesses now but is it an English (North American) version of Windows? Colour depth?
I'll do the updates through Windows Updates next and see if that changes anything. Did you just do critical updates?
Yep.
Justin
Paul
Yeah, you can't go wrong there (adding a trace after the call). I am more interested in finding out why a call isn't implemented in one copy of Windows 98SE but is in another. Currently in the tests a fair number are executed without checking for an error code. This is due to the assumption that they are implemented on all recent versions of Windows (95, 98, NT, 2000, etc). Finding calls here and there not being implemented on versions of Windows that should have them throws a wrench into that. We should probably just check the error code on all calls (whether they're expected to pass on all platforms or not).
Justin
jchevrier@nexicom.net wrote:
Yeah, you can't go wrong there (adding a trace after the call). I am more interested in finding out why a call isn't implemented in one copy of Windows 98SE but is in another. Currently in the tests a fair number are executed without checking for an error code. This is due to the assumption that they are implemented on all recent versions of Windows (95, 98, NT, 2000, etc). Finding calls here and there not being implemented on versions of Windows that should have them throws a wrench into that. We should probably just check the error code on all calls (whether they're expected to pass on all platforms or not).
Justin
If time permits (or if you beat me to it) I will create a patch that adds a check after each call. That way we can be sure we show actual info.
Cheers,
Paul.
On Wed, 2005-01-26 at 14:30, Paul Vriens wrote:
jchevrier@nexicom.net wrote:
Yeah, you can't go wrong there (adding a trace after the call). I am more interested in finding out why a call isn't implemented in one copy of Windows 98SE but is in another. Currently in the tests a fair number are executed without checking for an error code. This is due to the assumption that they are implemented on all recent versions of Windows (95, 98, NT, 2000, etc). Finding calls here and there not being implemented on versions of Windows that should have them throws a wrench into that. We should probably just check the error code on all calls (whether they're expected to pass on all platforms or not).
Hi,
for some bisar reason SPI_GETICONTITLEWRAP is now there on my win98 boxes! I've changed nothing on them as there sole purpose is running winrash/winetest.
I while have a look tonight or so.
Cheers,
Paul.
-
jchevrier＠nexicom.net -
Justin Chevrier
-
Paul Vriens