Tag Archives: Michael Ash

OS X Internals

It’s been pointed out to me recently that my blog has nothing at all on it about my work on the book Mac OS X Internals: A Systems Approach, by Amit Singh. So, here’s all the info I have that I can give right now, in the form of a FAQ:

Is it true you’re updating the book?

Yes. As of November 2012, I was contracted by Pearson to author a second edition of Mac OS X Internals, which in keeping with Apple’s change in naming, will now be titled “OS X Internals: A Systems Approach”. A big shout-out and thanks to Michael Ash for letting me guest-write on his blog and to Kirby Turner for putting me in touch with Pearson!

What is the release date?

Update: It’s taking quite a while to get this book into its proper shape. I’m sorry to everyone for the delays, but it’s important to make it the best reference it can be in an era when the material can change faster than it can be written down. My current target for release is late 2014 – as always, this is not a promise; only a guess.

At this time, I have no solid release date to offer. My best guess for a release is late in 2013.

Are you working with Amit Singh on the second edition?

No. To the best of my knowledge, Amit is not involved in the second edition in any way as of this writing. Should he change his mind about having a role, I will be nothing but grateful for his help!

Are you working with anyone else?

Update: Yes! As of September 2013, Sam Marshall has signed on to co-author the book with me. Their enthusiasm for the project is as great as mine, and I hope to bring you an even better book with their help!

Not at this time.

Will the second edition contain information about iOS as well?

Yes, I am planning to include information on iOS. Some details of iOS’ implementation are, of course, internal to Apple and unavailable, but I will be adding as much public information as I can.

Will the second edition cover the latest OS releases?

Update 2: As time moves forward and more possible OS releases come forward, a more generic answer is needed to the original question; see the (edited) original answer below.

Update: Yes!

I will do my best to include any changed information from any OS versions which are publicly released before the final manuscript delivery date. I can’t make any guarantees, and due to NDA restrictions, I can not include information on versions which are still in beta at the time of delivery.

If I’ve left out anything, don’t hesitate to shoot me an email and ask!

Guest post on Michael Ash’s blog

I am honored to announce that I’ve done a guest spot regarding assembly language on the blog of well-known Mac developer Michael Ash. You can find my post at his blog. I highly recommend every one of his posts for OS X and iOS developers of all kinds. Thanks for the opportunity, Mike!

Missions of the Reliant: Cleaning up the wreckage of the train crash

I’m back, and I didn’t give up on Missions! I’m sure there must be exactly one person out there who cares :-).

But seriously. I don’t have any new features to show at the moment, unfortunately. When I went to implement the laser cannon for the player, I realized I’d never be able to test it without something to fire at. I also realized the cannon itself would be useless without the target scanner since it has to lock onto a target. The scanner is also useless without something to scan. So, it was time to implement the base code for mobile enemies. Probably should’ve done that long ago, and here’s why…

As we all know, I’m using Objective-C to write this code. That means, among other things, that my code is object-oriented in nature. Up until this point, things like planets, starbases, and the player had all been entirely separate implementations. This is what Mike did with the original code. As always, what he did then was only sensible for the time and environment, but I can avoid a hell of a lot of code duplication by giving everything that exists in space a common superclass: a “Presence”. (Presences are themselves subclasses of the even more general “Responder”, which is used for everything that needs to process game happenings in any way, but that’s only a side note). As one can imagine, since I didn’t have the foresight to design the code this way to begin with, implementing it now required some significant refactoring.

Another issue cropped up halfway through the refactoring: The severe limitations of Apple’s built-in Key-Value Observing, which I use extensively throughout the code to avoid having to call “update this” and “update that” manually for every single affected object whenever something changes. For example, KVO doesn’t let you use blocks for callbacks, and if a superclass and a subclass both register for the same notification, there’s no way to manage the two independantly. Fortunately, Michael Ash noticed these problems some time back, and created a replacement, his MAKVONotificationCenter. Unfortunately, even the updated version published by Jerry Krinock didn’t do everything I needed, at least not in a way that I found usable with blocks added to the equation. Managing observations by tracking the resulting observation objects means having lots of instance variables to hold the observations, and since I’m building for Leopard, I can’t use the new associated objects for the purpose.

“Wait a minute,” you’re saying! “Leopard? Then why are you talking about using blocks?” Answer: I’m using PLBlocks.

So, armed with PLBlocks on one side, and Michael Ash’s typically brilliant code on the other, I dove in and pretty much rewrote the entire MAKVONotificationCenter to do three things it didn’t before:

  1. Block callbacks.
  2. Tagging observations with a simple integer value.
  3. Several alternative ways of specifying groups of observations to remove, based on observer, target, key path, selector, tag, or most combinations thereof.

With that done (and unit tested, and Doxygen-documented), I’m now integrating them into my revised class heirarchy for Missions itself. With any luck, I’ll have at least a screenshot of a fighter flying around before the week is out. Stay tuned, those of you who are crazy enough to stick around for all this :-).

Footnote: I was finally able to find a way to access the original model files for the game’s graphics; with some luck and a bit of help from Mike (I’m clueless when it comes to this stuff), there may be higher-quality graphics to be seen in the screenshots soon.