A while back I did
Timing and timing out Unix commands
to run commands, timing how long they took to run.
Now they want a Windows version. I don't think fork
or signals will cut it on Windows, so I have basically
rewritten it, as shown below.

Though simpler than the Unix version, it's currently unable
to compute the child process CPU time. :-(
This is because the Benchmark module on Windows always returns
zero for this. I'm pretty sure the root cause of this is the
lack of the Unix times function on Windows;
its emulation in the win32_times function in
win32/win32.c always returning zero for
tms_cutime and tms_cstime.
I'd like to work around this by calling the Win32
GetProcessTimes function, but that function
is not supported by Win32::Process.

It gets a little complicated obtaining a process handle from the object returned by Win32::Process. You have to ask it for the process id, and then use the Kernel API OpenProcess() to convert that back to a native process handle so that you can call GetProcessTimes().

Once you have the times, they come back as 64-bit values of 100 nano second periods since 1/jan 1601. Unpacking and formating the these time into something reasonable is awkward. My formatting routine is very lazy and doesn't do leading zeros, and you'll need to check the math on the conversion of the kernel and user times. There may be APIs available to do the formatting and converting.

Thankyou very much for providing example code! I may yet take this approach. I was also thinking it may be cleaner to submit a patch for Win32::Process to allow it support GetProcessTimes natively (though this is a bit of a pest because this Win32 call is not supported on Win95 lineage).

Try Win32::GetTickCount(). It should give a crude estimate(compared to UNIX time)but should do what it to do you need to Here is the documetaion . It is a function of the WIN32 module and is just a wrapper for the GetTickCount API in Windows.

Update: I really need to read more carefully. As Roger said this was in a thread last week.