[RESOLVED] Bypass TimeGetTime 49.7 limit
hai folks,
http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx
Quote:
The elapsed time is stored as a DWORD value. Therefore, the time will wrap around to zero if the system is run continuously for 49.7 days.
I found an example here to bypass 49.7 limit.
http://www.devx.com/tips/Tip/15355
but i dont undestand this part what he really doing
Code:
' Handle two's complement AND the case where
' timeGetTime/GetTickCount wraps at (2 ^ 32)ms,
' or ~49.7 days:
If (TickEnd < 0) Or (TickEnd < TickStart) Then
TickEnd = TickEnd + TwoToThe32nd
appricate if any one can explain above or give a diffrent solution.
tx
Re: Bypass TimeGetTime 49.7 limit
Fazi, this calc: TickEnd = TickEnd + TwoToThe32nd
is converting a negative (signed) Long value to positive (unsigned) value contained in currency/double vartype. Divide that result by 1000 as needed.
Regarding bypassing the ~49.7 day limitation, that posted code assumes 1 thing: You have a previous tickStart value to compare against and that that StartTick value was captured before timeGetTime was reset to zero. Otherwise, you cannot determine when the pc last rebooted before timeGetTime's most recent reset to zero.
Re: Bypass TimeGetTime 49.7 limit
Quote:
Originally Posted by
LaVolpe
Fazi, this calc: TickEnd = TickEnd + TwoToThe32nd
is converting a negative (signed) Long value to positive (unsigned) value contained in currency/double vartype. Divide that result by 1000 as needed.
Regarding bypassing the ~49.7 day limitation, that posted code assumes 1 thing: You have a previous tickStart value to compare against and that that StartTick value was captured before timeGetTime was reset to zero. Otherwise, you cannot determine when the pc last rebooted before timeGetTime's most recent reset to zero.
Quote:
Fazi, this calc: TickEnd = TickEnd + TwoToThe32nd
is converting a negative (signed) Long value to positive (unsigned) value contained in currency/double vartype. Divide that result by 1000 as needed.
yah volpe, i am using abs() for this purpose.
Quote:
value was captured before timeGetTime was reset to zero.
say a pc already running 55 days. now the user start the program, so we dont have any way to capture the reset event right :mad:
here is his full code from that page located here
i dont understand why he using TickEnd :confused:
Code:
#If Win32 Then
Private Declare Function GetTickCount _
Lib "kernel32" () As Long
#Else
Private Declare Function GetTickCount _
Lib "User" () As Long
#End If
Public Sub SampleLoop()
Dim TickStart As Currency
TickStart = GetTickCount()
' Loop for 5 seconds
Do While TickDiff(TickStart, GetTickCount()) _
< 5000
' loop code here
Loop
End Sub
Public Function TickDiff( _
ByVal TickStart As Currency, _
ByVal TickEnd As Currency) As Long
' CCur(2 ^ 32)
Const TwoToThe32nd As Currency = 4294967296@
' Handle two's complement for values larger than
' 2147483647&
If TickStart < 0 Then
TickStart = TickStart + TwoToThe32nd
End If
' Handle two's complement AND the case where
' timeGetTime/GetTickCount wraps at (2 ^ 32)ms,
' or ~49.7 days:
If (TickEnd < 0) Or (TickEnd < TickStart) Then
TickEnd = TickEnd + TwoToThe32nd
End If
' Return the result
TickDiff = TickEnd - TickStart
End Function
Re: Bypass TimeGetTime 49.7 limit
Fazi, two things
1. You cannot use Abs() and get a valid result. Let's say the API returned -2128334000, ok? You can see from the calcs below the results are vastly different.
Abs(-2128334000) = 2128334000 which is incorrect
-2128334000 + 4294967296@ = 2166633296 which is correct
Once a positive long hits 2147483647 or &H7FFFFFFF (max value), you cannot add more to it and keep it positive. The next bit that would get set would be &H8000000 or -2147483648 which is now a negative value for a Long. Abs() works on that value only. Add one more &H80000001 or -2147483647, using Abs() on that returns the wrong value because 2147483649 is correct, not Abs(-2147483647). Understand?
For the maximum difference, look at the value -1& which would be the value of the API the millisecond before it gets reset. If using Abs() on it, obviousy you get 1, but the correct value is 4294967295.
2. You cannot use the API to determine when the pc was last rebooted if it has been running longer than 50 days unless you were caching something before it reset to zero. It would be nice if there was something saved by the system that did not get reset. I don't know of any registry entry or system setting that can be returned via APIs. Maybe a system file can be queried? And if so, does that file exist and is it created the same for all operating systems?
Re: Bypass TimeGetTime 49.7 limit
Quote:
Originally Posted by
LaVolpe
Fazi, two things
1. You cannot use Abs() and get a valid result. Let's say the API returned -2128334000, ok? You can see from the calcs below the results are vastly different.
Abs(-2128334000) = 2128334000 which is incorrect
-2128334000 + 4294967296@ = 2166633296 which is correct
Once a positive long hits 2147483647 or &H7FFFFFFF (max value), you cannot add more to it and keep it positive. The next bit that would get set would be &H8000000 or -2147483648 which is now a negative value for a Long. Abs() works on that value only. Add one more &H80000001 or -2147483647, using Abs() on that returns the wrong value because 2147483649 is correct, not Abs(-2147483647). Understand?
For the maximum difference, look at the value -1& which would be the value of the API the millisecond before it gets reset. If using Abs() on it, obviousy you get 1, but the correct value is 4294967295.
2. You cannot use the API to determine when the pc was last rebooted if it has been running longer than 50 days unless you were caching something before it reset to zero. It would be nice if there was something saved by the system that did not get reset. I don't know of any registry entry or system setting that can be returned via APIs. Maybe a system file can be queried? And if so, does that file exist and is it created the same for all operating systems?
tx for the abs explanation. i need to read it again word by word bit lator.
in the latter case which a pc running more than +50 days,
good point. cmd> c:>systeminfo > result.txt would be a good option.
can grab that up time result that xp shows beyond +50 days. works on xp, not sure about above xp.
in this way, i can realize the pc is running more than 50days.
tx.
Re: Bypass TimeGetTime 49.7 limit
Quote:
Originally Posted by
LaVolpe
Fazi, two things
1. You cannot use Abs() and get a valid result. Let's say the API returned -2128334000, ok? You can see from the calcs below the results are vastly different.
Abs(-2128334000) = 2128334000 which is incorrect
-2128334000 + 4294967296@ = 2166633296 which is correct
Once a positive long hits 2147483647 or &H7FFFFFFF (max value), you cannot add more to it and keep it positive. The next bit that would get set would be &H8000000 or -2147483648 which is now a negative value for a Long. Abs() works on that value only. Add one more &H80000001 or -2147483647, using Abs() on that returns the wrong value because 2147483649 is correct, not Abs(-2147483647). Understand?
For the maximum difference, look at the value -1& which would be the value of the API the millisecond before it gets reset. If using Abs() on it, obviousy you get 1, but the correct value is 4294967295.
i am confused, i am confused http://www.vbforums.com/ http://www.vbforums.com/ http://www.pissupoosa.com/forum/imag...lies/smash.gif http://www.pissupoosa.com/forum/imag.../answerpls.gif
No problem in understanding the 2^32 limitations and the negative / positive brake. Thanks for the nice explanations.
but the real problem now is the counter value increase pattern from 0...
pls explain me the pattern if you could.
0 ......... 2147483647..-2147483648............4294967295
or
0 ......... 2147483647..-2147483646............-1
coz you specified
Quote:
Once a positive long hits 2147483647 or &H7FFFFFFF (max value), you cannot add more to it and keep it positive. The next bit that would get set would be &H8000000 or -2147483648
in another place you sad
Quote:
For the maximum difference, look at the value -1& which would be the value of the API the millisecond before it gets reset.
:p
Re: Bypass TimeGetTime 49.7 limit
Using signed Longs, the pattern will be
0 .>. 2147483647 (next change is to negative) -2147483648 .>. -1
When unsigned:
0 .>. 4294967295 (no negative values)
When using Hex...
&H000000 .>. &H7FFFFFFF, &H80000000, &H80000001 .>. &HFFFFFFFF
4294967295 = -1 when converting signed to unsigned or vice versa
Edited: Using Hex you can see that the Hex values are constantly being added. However, because VB uses signed Longs, &H80000000 becomes negative and each addition to the hex afterwards remains negative until you eventually get to -1&. The hex value &H80000000 is not a negative value, it is only negative with VB Longs. In a 64 bit variable, that hex value would be positive.
Re: Bypass TimeGetTime 49.7 limit
Quote:
Originally Posted by
LaVolpe
Using signed Longs, the pattern will be
0 .>. 2147483647 (next change is to negative) -2147483648 .>. -1
When unsigned:
0 .>. 4294967295 (no negative values)
When using Hex...
&H000000 .>. &H7FFFFFFF, &H80000000, &H80000001 .>. &HFFFFFFFF
4294967295 = -1 when converting signed to unsigned or vice versa
volpe, above calcuation / patterns you mean the long variable nature or timegettime() behavior :confused:
Re: Bypass TimeGetTime 49.7 limit
Both. The API returns Long. The operating system is storing the value as 32 bits (positive value). The API is returning 32 bits into a Long variable. VB's Longs are signed which means values > 2147483647 show as negative values.
Re: Bypass TimeGetTime 49.7 limit
ok ok.
hope now i can fix my problem.
:check:
Re: Bypass TimeGetTime 49.7 limit
sorry to bump,
with the help of LaVolpe's fantastic explanation given last few days, i fully visualized the problem and sorted out the bug in my program :D
Let me mark the thread as resolved.
*volpe, i can't spread rep any more to you until i spread few to others ;)
