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

Jakob Eriksson jakov at vmlinux.org
Tue Mar 22 12:08:01 CST 2005


Alexandre Julliard wrote:

>Jakob Eriksson <jakov at vmlinux.org> 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();





More information about the wine-devel mailing list