Re: Another one from last night: fix for dlls/kernel/tests/time.c on Windows 98

[Alexandre Julliard]

Jakob Eriksson  writes:
> - /* Windows 98 is a bit broken around these parts, it doesn't return FALSE as it should. */
> - /* If the resulting time is about 10000 AD, I consider the result invalid. */
> - ret = DosDateTimeToFileTime(0,0,&ft);
> - years = ((unsigned)ft.dwHighDateTime * 120) / 24 / 365;

That formula doesn't seem right to me. Could you please explain what
you are doing here?

Another one from last night: fix for dlls/kernel/tests/time.c on Windows 98

[Jakob Eriksson]

Alexandre Julliard wrote:
> Jakob Eriksson  writes:
> > - /* Windows 98 is a bit broken around these parts, it doesn't return FALSE as it should. */
> > - /* If the resulting time is about 10000 AD, I consider the result invalid. */
> > - ret = DosDateTimeToFileTime(0,0,&ft);
> > - years = ((unsigned)ft.dwHighDateTime * 120) / 24 / 365;
>
> That formula doesn't seem right to me. Could you please explain what
> you are doing here?

I  may be totally long but this is what I figured:

the low parts unit is 10 nanoseconds.  So one full dwLowDateTime is
2^32 10 nanoseconds, which is 120 hours.

I guess one dwHighDateTime is 2^32 dwLowHighDateTimes, ie 120 hours.

So multiply dwHighDateTime by 120 to get hours, divide by 24 to get days
and divide that by 365 to get years.

The "epoch" of ft began january the first 1601, so it's not really 10000 AD,
more like 8400 AD.

Or maybe I got things very wrong.

Or maybe we shouldn't test this particular corner case at all. As you said
before, if it differs so wildly between different Windows versions, probably
no real application depends on the behaviour.

I just did this trick to ignore obvious bogus values from Windows 98, and
doing so with an air of credibility. ;-)

Would you accept a patch along the style of:

if (ft.dwHighDateTime < 0) then ignore_stuff();

Another one from last night: fix for dlls/kernel/tests/time.c on Windows 98

[Alexandre Julliard]

Jakob Eriksson  writes:
> I  may be totally long but this is what I figured:
>
> the low parts unit is 10 nanoseconds.  So one full dwLowDateTime is
> 2^32 10 nanoseconds, which is 120 hours.

I think you are off by a factor of 1000 (and the unit is 100
nanoseconds BTW).
> Or maybe we shouldn't test this particular corner case at all. As you said
> before, if it differs so wildly between different Windows versions, probably
> no real application depends on the behaviour.

Yes, I think the test is useless. Its whole point is to make sure the
function detects bogus input, but if it doesn't under Windows then
there is nothing to test.