I like experimenting and tinkering with software. A lot like how a circuit bender tries to get electronics to emit beautiful music, I attempt to coerce software into doing things it wasn’t designed to do. Often, like my recent Windows Phone Hackathon, I fail spectacularly. But rarely, I do make notable progress. Cue Audible. (Audible for short) is a service owned by Amazon that provides digital audio books. They put out software that works across a slew of devices such as the iPod, Kindle Fire, Blackberry, and even PC. Old hats may even recall that Audible supported Windows Mobile 5 devices such as the HP iPAQ Pocket PC. One platform void of support, however, is Windows Phone.

We – along with our readers – have been keeping the pressure on Audible for quite some time now, to no avail. Support technicians would say an app is in the works but has no ETA. Now they're saying this month. Who knows when this is really coming out? More importantly, what’s taking so long?

Best VPN providers 2020: Learn about ExpressVPN, NordVPN & more

I sat down one day and decided to figure out why this was taking so long, or at least try. I started by downloading the old Windows Mobile 5 software. In the dusty CAB were a number of skins and resources, to support the fragmented Windows Mobile market, along with some key application files. Disassembling the Audible Player executable revealed they all relied on a single dynamic link library (DLL) to perform all the needed functions: AAXSDKWin.dll.

AAXSDKWin.dll is a library compiled for devices containing a StrongARM processor, like the iPAQ mentioned earlier. Without going too deep, it was compiled using an instruction set (ARM4i) that is still used in today’s ARM (e.g. Cortex) processors. At this point, you’re probably thinking “Hey… doesn’t Windows Phone sit on top of ARM too?” Yep, it sure does.

I took the library and started weeks of disassembly, study, and boozing, excruciatingly dissecting bit after bit until I had enough of their APIs worked out to use the damn thing in a proof of concept. I jiggered it into a Silverlight for Windows Phone application project and deployed it onto my Samsung Focus test phone. I was able successfully parse an Audible book and light up my UI with relevant metadata (e.g. title, author, etc.). I remember thinking “Holy crap, it worked.” (The app shot below is not a functional application.)

Audible for Windows Phone (concept)

How Audible for Windows Phone could look like.

I continued my research efforts, with the goal of playing a book in mind, but stopped short for two reasons: One, Audible’s books are protected with a DRM scheme. This meant I needed to reverse engineer their account activation, authentication, and decryption logic – something I wasn’t keen on doing. Two, we reported that Audible was warming up for a late March release. I had no intention of busting hump to later be superseded by a better and official application. But with the success of the concept application, I couldn’t answer the original question – What’s taking Audible so long to put out an app?

I can only surmise as to why. We know getting legitimate native access on Windows Phone is easy and possible. I also know that all the APIs they need are there. So from a technical perspective, an Audible app is possible. But perhaps Amazon, in a move to increase Kindle interest, decided to not continue porting Audible to newer mobile devices. Or maybe there’s some behind-the-scenes political or logistical clashing we’re not privy to. Or more likely, Audible just didn’t have the Windows Phone marketplace numbers to justify paying a team to rework their ancient source code into something usable on Windows Phone.

Regardless, an Audible application official or otherwise is coming.