Re: [user32/tests/sysparams.c] Check for availability of SPI_GETICONTITLEWRAP

> 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

[user32/tests/sysparams.c] Check for availability of SPI_GETICONTITLEWRAP

[Paul Vriens]

On Tue, 2005-01-25 at 05:29, jchevrier(a)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.

[user32/tests/sysparams.c] Check for availability of SPI_GETICONTITLEWRAP

[Justin Chevrier]

Paul Vriens wrote:
> On Tue, 2005-01-25 at 05:29, jchevrier(a)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

[user32/tests/sysparams.c] Check for availability of SPI_GETICONTITLEWRAP

[Paul Vriens]

> > jchevrier(a)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

[user32/tests/sysparams.c] Check for availability of SPI_GETICONTITLEWRAP

[Justin Chevrier]

Paul Vriens wrote:
> > > jchevrier(a)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

[user32/tests/sysparams.c] Check for availability of SPI_GETICONTITLEWRAP

[Paul Vriens]

> > > > jchevrier(a)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.

[user32/tests/sysparams.c] Check for availability of SPI_GETICONTITLEWRAP

[Paul Vriens]

On Wed, 2005-01-26 at 14:30, Paul Vriens wrote:
> > > > > jchevrier(a)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.