http://bugs.winehq.com/show_bug.cgi?id=656
*** shadow/656 Tue May 7 17:10:18 2002 --- shadow/656.tmp.24609 Thu May 9 16:30:38 2002 *************** *** 41,43 **** --- 41,72 ---- 080e42d8:Ret kernel32.GlobalAlloc() retval=4037c4a6 ret=0040239b
Which means that one of those *Time*To*Time* functions are broken. + + ------- Additional Comments From vberon@mecano.gme.usherb.ca 2002-05-09 16:30 ------- + FileTimeToLocalFileTime takes a FILETIME (which is UTC) and converts it into + another FILETIME, this time in the current TZ. + + FileTimeToSystemTime seems OK: both the input and the output are supposed to be + UTC, so no TZ conversion going on. + + Now, the program takes a UTC time (from GetFileTime), transfers it to local (via + FileTimeToLocalFileTime), then takes that local time (at least the pointer + address seems to indicate that) and transforms it into a SYSTEMTIME (which is + supposed to be just another representation of a UTC time). + + The problem seems to lie in the call to FileTimeToSystemTime: the program sends + an "illegal" time (local time) rather than a real file time (which is UTC). + + I'll have to play a bit on a real Windows computer to try some stuff, and verify + what those 2 functions actually do on Windows. + + I assume you're in CDT (-500 from UTC), which explains the 0500 difference in + the strings. Could you try again with a +0000 TZ? It might help to further + target the culprit... + + Are there other calls you could try to trace, like the pointers from which the 2 + strings are made of? It might help knowing what is the code path leading to one + and the other strings. Right now, my guess is that the first one (164848) is + constructed from the local time (pointer 0x40566650), and the second one + (214848) from a UTC time (pointer 0x40566648). The pointer 0x40566658 is just + another representation of 0x40566650. \ No newline at end of file
-
wine-bugs＠winehq.com