Apple

Unix has all kinds of pessimizations that seemed really cool in the 1970s when they were introduced. One of them is ATime.

When we last left off, we were able to cook up a service name of our choosing, and resolve it from a client. If we hooked up launchd stuff, we could also make it demand-launch (maybe that’s for another day). But we didn’t actually do anything with that resolution. There are several reasons for that, first, because actually crafting a message and sending/receiving it was covered by a prior article. But even more than that, there are actually a substantial number of design decisions around this task, and plowing ahead requires a lot of text.

I’ll start with the previous server/client, and flesh it out in small steps. In between the steps, I’ll outline design decisions, maybe some history, and pitfalls/sharp edges to be aware of.

(This is a sort of simplified retelling of http://fdiv.net/2011/01/14/machportt-inter-process-communication with some added lore. You should probably start there.)

Much of the magic behind macOS and iOS (and all the derived xOSs - watch, appleTV, the stripped down versions in cables and touch bars and wherever else these things invariably end up) is performed with the assistance of other processes (including the kernel). Communicating between them is accomplished by various ways, but for macOS, the underlying mechanism is a client/server IPC mechanism powered by Mach, and the underlying currency is the mach port (mach_port_t).

During my time at Apple, I dealt with a lot of rather low-level systems treachery. It’s poorly documented, even internally, and asking for help has roughly even odds on getting a passive aggressive non-answer.

The cool trick for today is creating a “memory object.” A memory object is one or more physical pages that are wrapped in a mach port. With this, you can pass the port to another process, who can map the pages, creating shared memory. Or you can map the pages again in your own address space, to create a mirror, or with different permissions so you can expose read-only pages at an interface boundary while still having the pages be writable at a different address.

A couple weeks ago, Apple posted a note that says:

In an upcoming release of macOS, Gatekeeper will require Developer ID–signed software to be notarized by Apple.

Being a developer of Developer ID-signed (i.e., non-App-Store) software, I set out to vault Apple’s latest hurdle.

Xcode includes a command-line utility called altool that manages the notarization process. That seems appropriate since my app isn’t built using Xcode’s build system.

I’ve been researching issues regarding serving HTML5 video content to iOS devices this past week. Here’s an outline the issues and some concise answers as to how iOS Mobile Safari 6 will handle HTML5 video. This post won’t touch on video encoding.

Mobile Safari’s QuickTime component does not handle HTTP requests the same as it does normally, say for a web page. Instead

I recently filed an Apple Bug Report, which was marked as a duplicate. The actual bug isn’t terribly important, but the difference between the serial number of the bug I filed (10426480) and the serial number of its alleged duplicate (3323328) – about 7 million – surprised me. Just how old was this still-unfixed bug?

I slogged through the lists.apple.com archives and the bugs users have manually posted on openradar.appspot.com to compile a list of Radar Numbers and the dates they were filed, and ended up with this:

It’s a wonderful fact about the world that humans have thousands of living languages. And a wonderful fact about many software development environments that they provide ways to create versions of applications localized into the most common of those languages. But before localization (or should I say world-readiness) sweeps you off your feet, let me tell you about some unexpected difficulties with Kineme’s first localized application.

The IOSurface framework lets you pass a reference to an IOSurface — a kind of pixel buffer — from one process to another. Here’s an example of how to pass an IOSurface through a mach port using the functions IOSurfaceCreateMachPort and IOSurfaceLookupFromMachPort.

Mach ports are a way for processes to communicate in Mac OS X. (Other mechanisms for inter-process communication include distributed objects and sockets.) A mach port is an endpoint of a communication channel. If 2 processes hold endpoints to the same communication channel, then one process can send messages to the other.

Mac OS X provides wrappers around mach ports — NSMachPort and CFMachPort. But sometimes you have to drop down to the native mach_port_t API.

Don’t do this on whim.