[RESOLVED] Bypass TimeGetTime 49.7 limit

[Fazi]

hai folks,

http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx

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

	' 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

[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.

[Fazi]

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.

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.

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

here is his full code from that page located here
i dont understand why he using TickEnd

#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

[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?

[Fazi]

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.

[Fazi]

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

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

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

For the maximum difference, look at the value -1& which would be the value of the API the millisecond before it gets reset.

[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

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.

[Fazi]

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

[LaVolpe]

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.

[Fazi]

ok ok.
hope now i can fix my problem.

[Fazi]

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

Let me mark the thread as resolved.

*volpe, i can't spread rep any more to you until i spread few to others