PureBasic Forums - English

Posted: **Sat Mar 21, 2009 5:18 pm**

What makes you so sure this gives the correct results ? I cannot find any documentation specifying that the performance counter is linked to the uptime. It could be anything.

Posted: **Sat Mar 21, 2009 5:29 pm**

@freak, yes it does actually work. I'll look for docs on it. He's just using it wrong.

@PB: You're using it wrong. You can't use FormatDate on it. Here's an example of correct (if clumsy) usage:

Code: Select all

QueryPerformanceFrequency_(@perSec.q) 

QueryPerformanceCounter_(@currTime.q) 

seconds = currtime/persec
days = seconds/86400
seconds - days*86400
hours = seconds/3600
seconds-hours*3600
minutes = seconds/60
seconds-minutes*60

thisresult$ = "QPF System Up Time:                         "+Str(days)+" days, "+Str(hours)+" hours, "+Str(minutes)+" minutes, "+Str(seconds)+" seconds"



program = RunProgram("systeminfo.exe","","",#PB_Program_Open|#PB_Program_Read|#PB_Program_Hide) 
While ProgramRunning(program) 
  If AvailableProgramOutput(program) 
    a$=ReadProgramString(program) 
    If FindString(a$, "System Up Time", 1) 
      uptime$ = a$ 
      KillProgram(program) 
    EndIf 
  EndIf 
  Delay(1) 
Wend 
MessageRequester("","OS returned "+uptime$+#CRLF$+thisresult$)

Here the results are equal within 2 seconds, which accounts for processing time.

Posted: **Sat Mar 21, 2009 5:42 pm**

netmaestro wrote:@freak, yes it does actually work. I'll look for docs on it. He's just using it wrong.

@PB: You're using it wrong. You can't use FormatDate on it. Here's an example of correct (if clumsy) usage:

For info the code of FREAK and the code of NETAMESTRO works perfectly

He give the same result, i have try the two in the same time, but the code of netmaestro stop the code of freak when it run, it's surely normal

Thanks at the GREAT FREAK and NETMAESTRO for sharing

Posted: **Sat Mar 21, 2009 5:45 pm**

Ok nice to hear, but I don't think freak posted any code...

btw, all my code contains a procedure which stops any code freak is running. I'm sure he wonders why

Posted: **Sat Mar 21, 2009 5:47 pm**

PB wrote:Thanks to Freak I was able to come up with this, which works perfectly:
Code: Select all
QueryPerformanceFrequency_(@perSec.q)

For a=1 To 10
  QueryPerformanceCounter_(@currTime.q)
  Debug FormatDate("%hh:%ii:%ss",currTime/perSec)
  Sleep_(1000)
Next
No need for program outputs, Registry, COMate, etc. Many thanks must
go to netmaestro and Sparkie for taking the time to post their solutions.

(BTW: I know this only works for 24 hours, but should be easy to enhance).

It's not me who have say that MASTER

It's PB the culpable

Posted: **Sat Mar 21, 2009 6:13 pm**

> @freak, yes it does actually work. I'll look for docs on it. He's just using it wrong.

I know it works, thats not the point. The point is that no documentation guarantees it to work this way (that i am aware of). So this is just a hack that relies on undocumented behavior, and not a solid way of doing things. The actual source for the performance counter is determined by the hardware abstraction layer, so a different cpu, a different bios or a different motherboard could easily change this behavior and you're screwed.

Why take that risk with a method like that when there are probably more solid (read: documented) ways to get this information ?

Posted: **Sat Mar 21, 2009 6:36 pm**

Code: Select all

Import ""
  GetTickCount64()
EndImport
Debug FormatDate("%hh:%ii:%ss", GetTickCount64() / 1000)

Requires Vista or Server 2008

Posted: **Sat Mar 21, 2009 6:40 pm**

@freak: Your point is a good one, and well taken. I will try to find docs on it. In the meantime, here are two theories I have that I'm setting out to prove/disprove:

1) The performance counter is started when the OS starts and it keeps incrementing at its frequency intervals as long as the OS is up.

2) The Windows APIs GetSystemTime and GetSystemTimes actually read the performance counter to come up with their values. This is how they achieve hi-res accuracy unavailable in timeGetTime, etc.

If these theories are true, then this should be as safe a method as any. I'm not saying that they are, just that I think they are. I will search..

Posted: **Sat Mar 21, 2009 7:42 pm**

http://msdn.microsoft.com/en-us/library ... S.85).aspx would appear to support Freak.

On a multiprocessor computer, it should not matter which processor is called. However, you can get different results on different processors due to bugs in the basic input/output system (BIOS) or the hardware abstraction layer (HAL). To specify processor affinity for a thread, use the SetThreadAffinityMask function.

Posted: **Sun Mar 22, 2009 4:43 am**

> What makes you so sure this gives the correct results ?

Direct comparison with other UpTime apps on the net. Their results match
the results of my code snippet, to the second. So, it seems reliable to me.

> Why take that risk with a method like that when there are probably
> more solid (read: documented) ways to get this information ?

Well, I can probably use Sparkie's COMate code then, if that's a better way.
But that's a hell of a lot of includes and extra code, compared to a few lines.
And you know how much I hate bloatware!

But, if all that extra code gives
correct results on all PCs, then that's the most important thing to consider.

I will test my few lines on my work PC, my brother-in-law's, my library's,
and my Eee PC. If they all give correct results, then I will be very reluctant
to use COMate or any other method. (Well, until I get a bug report from a
user, and then I will release a bug-fixed version that uses COMate).