List process start dates
I just wrote a test app that prints the name and start-date of every process that the Process Manager will tell it about. Here it is:
It’s a command-line tool, so you’ll need to run it from a terminal. Alternatively, you could wrap the executable in a service using ThisService, then use the service to insert the listing into a text document.
The code to convert the start-date of each process is ugly: Process Manager provides those dates as numbers of ticks since system startup, and I currently go through NSDate to convert those to numbers of seconds since 1970-01-01. I’m fairly sure that this answer is imprecise.
I’d prefer to get the startup time as a number of ticks since some epoch (probably 1904-01-01), so that I can do a more precise conversion. If you know of a way, please post a comment.
February 11th, 2008 at 08:19:37
Process Manager ticks are pretty large: 60.15 ticks per second = roughly 16.625ms each. So you’re not going to get any more precise than that. There also aren’t any APIs to do Ticks since any other reference point; Ticks overflowed too soon to be useful for anything else.
TickCount() will return the number of ticks since system startup. You can use “now” as the common reference point to map ticks to a more precise date value like NSDate. Just call TickCount twice, once before and once after, and make sure you get the same value. Something like this:
UInt32 tc = 0; NSDate *d = nil; do { tc = TickCount(); d = [NSDate date]; } while (tc != TickCount()); // try again if we've rolled over to the next tickAfter this code executes both tc and d will contain equivalent times: tc will be the time in Ticks since system startup, and d will be a corresponding NSDate (within the 16.6ms window). Since you know that the Tick frequency is 60.15Hz, a little math should do the trick from there.
Note that if your machine’s uptime is greater than the TickCount wrap time (about 27 months, iirc) then I think the values in processLaunchDate will start wrapping.
February 11th, 2008 at 08:53:35
Huh. I didn’t know about the .15 part before; the Carbon TickCount documentation says simply “approximately 1/60th”. Apparently it’s an artifact of the original Macs’ refresh rate being 60.15 Hz.