[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <200409242146.i8OLkooc014172@ns.wcd.se>
From: mcw at wcd.se (bashis)
Subject: Windoze almost managed to 200x repeat 9/11
>
> > C:\WINDOWS\system32>find "GetTickCount" kernel32.dll
> >
> > ---------- KERNEL32.DLL
> > GetTickCount
>
> Umm yeah. That would be the DLL that exports the function. :o)
Yes, perhaps, but do a search in \windows and \windows\system32 and you will
find several program using (or exporting;) this function. ;-)
> Anyway, even if it is used, if used with understanding of the data value
> range it can used safely. I have used it safely (as have many coders) many
> times in the past when manipulating 64 bit numbers associated with
> QueryPerformanceCounter would have been overkill.
Yes, offcores it can be used safely.
My wild guess about that "incident" is that the programmer(s) who coded the
application didn't get that it will wrap to zero after 49.7 days, and as
workaround they told the customer to reboot their servers with the reason
"Windows, it's crappy.. you know.."
We can argue about if the return is right or wrong from "GetTickCount()",
even if the function was well documented and the coders was missing the
magic word "49.7 days", i realy don't care.
But, my personally opinion is that a "The return value is the number of
milliseconds that have elapsed since the system was started." function should
return more than 49.7 days, but hey.. M$ perhaps dont expect more uptime on their
OS'es.. ;-)
Well, i dont know if the "GetTickCount()" is the cause to the "incident", it
was only a notice when i was searching and reading about functions/bugs with
the magic word "49.7 days" ;-)
I am glad that the "incident" was turned out w/o any human losses.
Have a nice day
/bashis
Powered by blists - more mailing lists