I’m migrating some of my git repositories over from github.com/samdeane to github.com/elegantchaos.

Unfortunately that means a change of URL, and there’s no automatic redirection in place to ease this transition.

I’ll try to edit any URLs on this website to point at the new locations, but apologies if I get it wrong.

A while ago I blogged about an Objective-C logging system I’ve developed, called ECLogging.

Previously it was available on github as part of my ECFoundation framework, but recently I’ve been going through ECFoundation and splitting it up into modules, with each one stored as a separate git repository.

Some of these split-out modules still depend on each other, but luckily ECLogging isn’t one of them, which means that you can now adopt it a bit more easily, since you don’t have to take any other baggage with it.

You can find it on github. You can also find a wiki on there with some documentation in it. The github repo also contains a couple of example projects to help you get started.

In my recent post on OS X Helper Applications, I provided some sample code for installing and launching a helper application.

The host application and the helper communicated using distributed objects (NSConnection), running over mach ports (NSMachPort).

At the time, I was aware of the advice in Apple Tech Note 2083: Daemons and Agents which recommends against using mach ports, but I wanted to get something up and running, and the NSMachPort method was the one that seemed to be best documented.

However, after a lot of searching around and poring over some very sparse documentation, I’ve now got a version of the code working using NSSocketPort with unix domain sockets (AF_UNIX style sockets), which the tech note recommends as a good way to do IPC.

Tracking down all the details for this proved to be pretty hard work, and I had to glean various bits of information from a lot of disparate sources - tech notes, email threads and sample code.

The tough bits included:

• getting NSSocketPort to use unix domain sockets
• then getting NSConnection to work with them
• getting launchd to launch a task on-demand when a unix domain socket is hit
• getting the actual socket out of launchd in the server task

I’ve now updated my sample code to include all this good stuff - hopefully it will help someone else out in the future.

As a result of this the sample is a tiny bit more complex, and I’ve also taken the opportunity to refactor some stuff into utility classes. Because these are pretty useful I’ve pulled in my ECFoundation framework, and located some of them in there. However, the sample still doesn’t need the vast majority of ECFoundation, so I haven’t linked to the framework, I’ve just pulled in the source files that I need.

Check out the github repo for more details.

Whatever this time of year means to you, for us it means a few hard-earned days of rest, and probably far too much eating and drinking!

As a result, things will be quiet round here for the next week or two. If you happen to attempt to get in touch, please forgive us if we’re a bit slower than usual in responding.

If you’re on holiday too, we hope you have a good one! If not… well we hope you have a jolly nice time whilst it’s so quiet!

See you all in 2012 I hope.

Following on from my Helper Applications sample project, I’ve created another sample which focusses on how to do code-injection.

In particular this sample makes and installs a helper application who’s job is to inject some code into another application (by default the Finder).

The injected code adds a menu to the application’s menubar, with a single item in it that just logs stuff to the console.

Once again the project is based on existing examples, but attempts to present things in a slightly cleaner / simpler way.

It uses Wolf Rentzsch’s mach_star to do the heavy lifting for the injection task.

You can find it on github.

Once again I should point out that this example pretty much ignores security when it comes to the inter-process communication between the host application, the injection helper, and the injected code. Which isn’t to say that it’s not useful, simply that you’d have to batten it down far tighter if you want to avoid opening up some potentially horrible security holes.

In the sample, the helper is launched on demand, and only does the injection in response to a command from something else. In a real-world scenario, I guess it would make more sense for it to watch for the target app to launch and do the injection then. It would also make more sense if the various parameters were embedded into the helper to lock it down. However, in it’s current form, I guess the sample could form the basis of some sort of application-enhancer style system allowing multiple client applications to inject code into multiple targets.