How long has an application been running? - Smalltalk

should read "...how long a DST (v6) application has been running?"

my proof reading's not what it should be...

Ian

Ian wrote:
> Aside from the "take a timestamp when the app starts up" answer does
> anyone know whether you can determine how long a DST (v6) has been
> running? If there's no DST way of determining this does anyone know the
> underlying MS structure/function?
The info you are searching should be available using the Toolhelp API
(http://msdn.microsoft.com/library/de...lp_library.asp
and http://www.codeproject.com/threads/enumprocnt5.asp). If I remember
correctly Steve Waring's SWSysUI package contains wrappers for this
(http://www.stevewaring.net/dolphin/SWSysUI/index.html).

CU,

Udo

Ian wrote:
> Aside from the "take a timestamp when the app starts up" answer does
> anyone know whether you can determine how long a DST (v6) has been
> running? If there's no DST way of determining this does anyone know the
> underlying MS structure/function?
The info you are searching should be available using the Toolhelp API
(http://msdn.microsoft.com/library/de...lp_library.asp
and http://www.codeproject.com/threads/enumprocnt5.asp). If I remember
correctly Steve Waring's SWSysUI package contains wrappers for this
(http://www.stevewaring.net/dolphin/SWSysUI/index.html).

CU,

Udo

Ian wrote:

> Aside from the "take a timestamp when the app starts up" answer does
> anyone know whether you can determine how long a DST (v6) has been
> running? If there's no DST way of determining this does anyone know the
> underlying MS structure/function?

I don't know of a record of the start time in the image. The Kernel32.dll has
two functions which I think should suffice:

GetCurrentProcess()
http://msdn.microsoft.com/library/en...entprocess.asp

GetProcessTimes()
http://msdn.microsoft.com/library/en...ocesstimes.asp

-- chris

thanks Udo and Chris. I guess I'll try and re-use Steve Waring's work
rather than re-invent the wheel.

Ian

Ian,

> thanks Udo and Chris. I guess I'll try and re-use Steve Waring's work
> rather than re-invent the wheel.

Dumb question to keep in mind: does the clock wrap at any point? If so,
you might be better off saving a time stamp that you can trust.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
bills@anest4.anest.ufl.edu

Ian wrote:
> thanks Udo and Chris. I guess I'll try and re-use Steve Waring's work
> rather than re-invent the wheel.
After taking a look at the MSDN stuff Chriss sent I would take the way
Cris proposed.

Add the following method to KernelLibrary:
getProccessTime: hProcess lpCreationTime: lpCreationTime lpExitTime:
lpExitTime lpKernelTime: lpKernelTime lpUserTime: lpUserTime
"The GetProcessTimes function retrieves timing information for the
specified process.

BOOL GetProcessTimes(
HANDLE hProcess,
LPFILETIME lpCreationTime,
LPFILETIME lpExitTime,
LPFILETIME lpKernelTime,
LPFILETIME lpUserTime
);"

<stdcall: bool GetProcessTimes handle FILETIME* FILETIME* FILETIME*
FILETIME*>
^self invalidCall


You should now be able to execute the following code:
lpCreationTime := FILETIME new.
lpExitTime := FILETIME new.
lpKernelTime := FILETIME new.
lpUserTime := FILETIME new.
KernelLibrary default
getProccessTime: KernelLibrary default getCurrentProcess
lpCreationTime: lpCreationTime
lpExitTime: lpExitTime
lpKernelTime: lpKernelTime
lpUserTime: lpUserTime


The different FILETIMEs should now contain the times you are searching for.

CU,

Udo

Bill,

> Dumb question to keep in mind: does the clock wrap at any point?

With GetProcessTimes() everything's expressed as FILETIMEs, which overflow
after about 6000 years. Ian should be /fairly/ safe ;-)

-- chris

Chris,

>>Dumb question to keep in mind: does the clock wrap at any point?
>
>
> With GetProcessTimes() everything's expressed as FILETIMEs, which overflow
> after about 6000 years. Ian should be /fairly/ safe ;-)

True. Linux could run that long, but _Windows_!!!!

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
bills@anest4.anest.ufl.edu