Apple

On Nov 16, 2015, at 4:46 AM, Bill Cheeseman <email@hidden> wrote:

The CGEvent.h header does reveal several oddities about the new Pid function:

1. The "new" Pid function is listed as CG_AVAILABLE_STARTING in Mac OS X v10.4, not v10.11. Apparently it has been around since the beginning after all, despite what the API Diffs document says. Is this really true, or is it just a sign that the comments were not updated?

Looks like it was a copy-paste error. The function is truly first available in 10.11.

2. The callback and userInfo parameters are not marked __nullable in the new Pid function, although they are marked __nullable in the old PSN function. Why the change?

Looks like the Pid function wasn’t completely marked up when the headers were analyzed for nullability. However, see comments later...

In my free developer utility Event Taps Testbench <http://pfiddlesoft.com/eventtapstestbench>, I call the old PSN function to create an "empty" event tap, then I let the user set the parameter values in the application's GUI and click an Install button to configure and install it. It works perfectly. I convert the temporary Pid value of 0 to the equivalent PSN value using GetProcessForPid(), and the old PSN function returns a real CFMachPortRef.

So you call GetProcessForPID(0, &psn) and you get back noErr and a valid PSN? That surprises me. I’m not sure that’s really a supported configuration, but we’d have to ask some other Apple folks to be sure. Or maybe I’m misunderstanding what you’re actually doing. If you are passing 0 for the pid, why?

In the new version of Event Taps Testbench that I am developing now, I call the new Pid function instead when running under El Capitan. It does not work. Either the Pid value of 0 or the two null parameters (which are not marked __nullable) result in a CFMachPortRef return value of 0. That in turn prevents me from creating the run loop source that I need in order to install the tap.

The implementation of the Pid function does not appear to support a pid value of 0. That’s probably the primary reason for your NULL return value.

The implementation also definitely returns NULL if you pass a NULL callback. So the callback parameter to the PSN function should not be marked __nullable (that’s a bug), and the lack of nullability on the callback parameter to the Pid function is correct.

The refcon param should be marked __nullable, since that’s a valid value.

The fix is easy: I'll just keep using the old PSN function. But why is there a new Pid function that doesn't work the same?

I think it primarily works the same, modulo the misleading (incorrect) __nullable on the callback param of the PSN function, and possibly the unintended ability to pass the result of GetProcessForPID(0) to the PSN function.

And how long will the old PSN function stick around?

No one here can tell you that - we don’t know ourselves. In general, API isn’t removed while still used by existing supported apps. There are very few examples of API actually being entirely removed from OS X.

References:
	>CGEventTapCreateForPid() questions (From: Bill Cheeseman <email@hidden>)