Working on The Witness, Part 2: Finding and fixing a five-second stall

I've tried to write correct CoreAudio software for instance (part of writing audio code for a portable app). It turns out to be pretty much impossible. The libraries are immature; they post events to non-existant code long after the audio device is stopped and closed. Pretty much it only works if you write the same app everybody else is writing (which I am not). SO you add timeouts and use handles instead of pointers everywhere and vet all the callbacks to weed out the stale ones.

And there's nowhere to look to figure these things out, because everything you try in any deep library, you're the 1st one to try it. Because there's 1% the dev going on on that platform.

In general, APIs like this are pretty undesirable. They're rigid and not really orthogonal to any other API, so they're difficult to combine with existing or new APIs. They can't ever really change behavior either, because people are going to rely on specific implementation details. If you're a game, you might be able to use them (assuming you don't want to do anything out of the norm), and you can't if you aren't. Problem is, the platform isn't just a gaming platform, it's a platform for pretty much everything, and the platform developer probably isn't a game developer either. This means he or she probably doesn't have the expertise to write the exact APIs game developers want, that will be flexible in just the right ways, etc, and whatever API they did write would only be for a subset of the platforms "customers".

The real problem here is that the APIs that do exist sound like they are poorly documented and not necessarily thought-out with respect to the rest of the system. Ideally, all of the options needed for a full screen game should be well-documented and orthogonal, so they can be combined to achieve what each of the various apps wants without having to write a "BeginFullScreen$APPTYPE" function. Then, if there truly is a common setup games want, it can be built as a separate library on top of these APIs, either by the platform maker or by a 3rd party.

> They might try to hire and cultivate good API designers, and have real, talented developers who do nothing but work on the APIs to the internal systems.

There are teams at these companies that do this. This is exactly what the Android Frameworks team does at Google, which includes people like Dianne Hackborn and Romain Guy (until a few months ago), to name a couple of the better known members. They're in charge of designing and implementing a lot of APIs exposed to third party developers, but also spend time each release reviewing all of the APIs that are being made public.

First it was a freebie, then I added blocking for Caps, Num and power keys and made it a shareware. It was even featured on TechTV by Leo Laporte (great for the bank account!).

Fun times...

[1] http://www.bytegems.com/ihatethiskeydeluxe.shtml