Core Mac OS X and Unix Programming

Michael McCracken writes "Finally, a new OS X programming book that isn't just another introduction to Cocoa. This book adds a lot to the available references by covering the system as a flavor of Unix, presenting information on important topics like sockets, multithreading and pipes, which other OS X books leave out. It also includes coverage and sample code for some of the unfamiliar new technologies that have been introduced recently, such as the Keychain, Rendezvous (aka Zeroconf), and using the Security framework to authorize users." Read on for the rest of his review. Core Mac OS X and Unix Programming author Mark Dalrymple and Aaron Hillegass pages 541 publisher Big Nerd Ranch rating 9 reviewer Michael McCracken ISBN 0974078506 summary A developer's guide to the Unix foundations of Mac OS X, including coverage of recently added technologies. Includes complete source code and online companion material.

If you've been learning Mac OS X Cocoa programming, you might already know Aaron Hillegass through his excellent book Cocoa Programming for Mac OS X, which was one of the first good introductory books on the topic, and is still one of the best available. Information about this earlier book can be found at bignerdranch.com/Book/. Both Aaron and Mark are instructors at the Big Nerd Ranch, which offers courses in Mac OS X programming. More information about them and the courses can be found at http://www.bignerdranch.com/Company/Who.html. This book is based on the course with the same name at the Big Nerd Ranch. The book's website and a link to order it online can be found at borkware.com/corebook/ . Discussion and further information for both books can be found at cocoadev.com/index.pl?CocoaBooks.

Audience and Writing Style This book is not an introduction to programming on OS X. It doesn't explicitly cover how to use Apple's Project Builder or Interface Builder, or much of the Cocoa or Carbon APIs, except during discussion of code examples. So if you're entirely new to programming or to using Mac OS X, start with a different book such as Hillegass' earlier Cocoa Programming for Mac OS X to get up to speed with using the development environment. This book will leave you behind at times if you are unfamiliar with using the command line, however, the examples are complete enough to follow along by just typing in what's in the book.

Core Mac OS X and Unix Programming does have some very basic material in its first few chapters. They focus on the details of C programming, using the compiler, memory management, and debugging. These chapters will be mostly review for anyone who's developed in C on Unix before, but will be invaluable for programmers who learned to program using Java, for instance. They should also be required reading for programmers who started programming with Objective-C and Cocoa and are still unsure about using "plain" C. If you've ever complained about having to use a C API from CoreFoundation in your nice pure Cocoa application, don't avoid this book -- you need to read it even more.

The book is clearly written and easily understood. The writing is occasionally conversational, in keeping with its history as a course textbook. In the grand history of well-written technical books, it is also occasionally funny. The authors don't try to sell the technologies they discuss, instead giving practical advice that's useful to a programmer who is trying to actually build something. For example, the authors discuss bugs and inconsistencies in the system, clumsy API design and other problems that aren't great ad copy but you will need to know to develop robust applications.

I found this aspect of the book one of the most appealing, that it felt as though I was actually getting down to business. Gems of practical advice that can cut short frustrating problems appear throughout the book, so be sure to read carefully, don't just skim.

Hits Here I'll discuss a few examples of where I think this book really shines. First, the level of detail of the standard Unix APIs and the development tools is excellent -- I learned many immediately useful things in the first 13 chapters. For example, chapter 8, "Debugging With GDB," was not simply a repeat of the online help, but also contained useful tips about how to use GDB more effectively, from using Objective-C specific features to tracking subtle memory errors. Programmers who had only used Project Builder's interface to GDB will benefit greatly from this chapter.

Next, there is pervasive sample code. Each chapter had a complete sample program demonstrating the topic at hand. Much of this code is also available online: see "Online Supplements" below.

Finally, as I mentioned before, the text contains tips and reminders throughout about potential mistakes, tricky problems, and differences between Mac OS X, OS 9, and other Unix flavors. A particularly useful example of this is in chapter 24, "CVS." There is a small but important paragraph that discusses using CVS 1.11 (as used in Sourceforge) with Interface Builder .nib files that can really save some grief. In other chapters, they even include workarounds for system bugs in some of the sample code. This pragmatic approach is really appealing.

Misses In this section I'll mention a couple potential disappointments. You will have to be willing to learn by just reading code at times. Most of the code examples are not explained line-by-line as is the custom in tutorial books. Comments explain tricky code, and the text covers the areas most relevant to the chapter topic, but for other sections, understanding is up to you. I mentioned this because although I feel the code is clear and a fair trade-off was made to fit in a lot of information, the amount of explanation you like is a matter of personal preference, and so you should know what to expect.

Pointers to further reading is another problem. Aside from referring to man pages, there is little attempt to point to good external documentation on any of the more complicated topics. One chapter is not enough to completely cover BSD Sockets, for example, and so a reference to a Unix network programming book would be useful. In fact, every chapter could be improved by a references section, even if it only collected links to Apple online documentation or Unix community websites. With all the practical knowledge in this book, the lack of clues on where to look to answer your own questions was disappointing.

Finally, the cost of the book, at $97.95, is higher than you might expect. I admit that as a student, I would have to think twice about paying this price, although I am sure it would be easily justifiable for professional programmers. I believe that it is worth the price, however, because you would have to buy several other books to cover the same range of topics, and you still wouldn't get the Mac OS X specific information.

Online Supplements

The authors have set up a promising resource for the book at http://borkware.com/corebook/ . The site includes the sample code, errata, reader comments indexed by the chapter and topic they refer to, and a general discussion board. There are already some errors listed, and a few pointers to useful documentation and interesting external discussions on mailing lists. The sample code is not complete at the time of this review, but more is being added. This site looks like it will be a useful addition to the book, especially if many good chapter-indexed comments are added. The site could be kept open as a reading companion while going over a chapter in the book. This site's organization is, in my opinion, much more useful and usable than other books' companion websites, including the site for "Cocoa Progamming," which hid its information from you unless you knew which page number was relevant to your topic.

Conclusion Core Mac OS X and Unix Programming is a very useful book, and even if you've been developing on Unix systems for years, you can probably learn a few immediately useful things by reading it. I recommend it for any serious Mac OS X programmer who wants to know what to read next after all the tutorials that have come out in the last year or so. I suspect it'll become a canonical reference, and may even be in need of a clever nickname. Congratulations to Mark and Aaron on a job well done.

Michael McCracken is a grad student and Mac OS X developer; he says "I have not attended any Big Nerd Ranch courses, nor have I met either author, although I did see Aaron Hillegass in a crowd once." Update: 07/02 17:36 GMT by T : According to publisher AtlasBooks, bn.com won't actually be carrying this book, but you can get it right now from Atlas. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Whoa

[Anonymous Coward]

Be careful, you might actually teach them some good programming techniques.

Microsoft port

[SolidGold]

It is interesting to note that Microsoft in a previous article said that they had no intention of porting Office to Linux right now, but being that they have ported it to OS X most of the work has already been done.

Re:Microsoft port

[christurkel]

It would think its closer to a FreeBSD port with you port to Mac OS X. I could be wrong, however.

Re:Microsoft port

[Halo1]

MS Office is a Carbon app. There's no carbonlib for any *nix except Mac OS X out there. Porting it to Linux would mean either porting carbonlib (i.e. a cleaned up version of the legacy Mac OS api + extensions) to Linux, or rewriting it from the ground up (just like the Mac OS X version is almost a complete rewrite compared to the Windows version).

Re:Microsoft port

[PhysicsExpert]

Yes but have you ever used MS office on OSX, it is slow and incredibly buggy (jokes about microsoft aside office on XP is rock solid) and that's with standard hardware and a fast RISC processor to work on, imagine what it would be like under Linux with all sorts of random hardware thrown in there. The real reason they won't port office to Linux however, isn't about speed or reliability but simply because Office on Linux just wouldn't sell. Most Linux users realise that there are good free alternatives like star office and open office which are just as good as Microsoft without needing you pay extortionate prices. Office on Linux would be a commercial nightmare.

Re:Microsoft port

[Graff]

Microsoft in a previous article said that they had no intention of porting Office to Linux right now, but being that they have ported it to OS X most of the work has already been done.

Actually that's not quite true. Microsoft programmed Office for the Mac using the Carbon API and libraries which are part of MacOS. This is a set of APIs which are completely proprietary to MacOS and which bring a program no closer to Linux than a program which uses the Windows API program does.

The only way in which doing a MacOS port of a program brings it closer to doing a Linux port is most programmers doing a port tend to separate out the parts of the program which rely on a particular operating system from the parts that are platform-agnostic. Thus you will most likely end up with a large chunk of the code which can be re-used to add a front end for any particular system type. This is not a requirement for a port however, it is just smart programming. In fact, it is even smarter programming to do this in the first place. Microsoft may or may not have done this, but I'm doubting that they did. From what I understand they basically program the Mac versions of their programs from nearly the ground up.

In programming the Myth series of games, it was often said by the developers at Bungie that the platform-agnostic parts of the games took up about 90% of the code, while each port took up 10% more. So for a 10% investment in additional coding you could sell the game to a another platform. This requires a bit of planning but it is a much better way to program than to do one version for one platform and then have to completely redo you work to get it to run on another. Finally, there is another great advantage to doing multi-platform programming. Often a bug which doesn't show on one platform will show up on another, allowing you to clean up any possible problems before they get you into trouble later on.

Re:Microsoft port

[Coward the Anonymous]

"The real reason they won't port office to Linux however, isn't about speed or reliability but simply because Office on Linux just wouldn't sell."

It would sell more than you think. For companies that want to move the corporate desktop over to GNU/Linux but feel that OpenOffice and the other alternatives aren't fit, it would sell like hotcakes.

Re:Microsoft port

[Anonymous Coward]

I would think that porting Office to Linux would validate the platform, it would be a message from Microsoft that they believe enough in Linux to support it. Porting Office would allow even more people to switch FROM Windows; and that would be the start of Micrsoft loosing control.

Re:Microsoft port

[jeremyp]

I use it every day. With the current patch level (10.1.3) it's not slow (any more so than any other OS X app) and it's not buggy - well I've not seen any.

Re:Microsoft port

[Mr. Show]

The real reason they won't port office to Linux however, isn't about speed or reliability but simply because Office on Linux just wouldn't sell.

Microsoft has an effective monopoly in two areas: operating systems and office software. They are also the only two divisions within Microsoft that are profitable, and support all of their other ventures into PDAs, game consoles, set top boxes, smartphones, and on and on. Office on Linux might not sell to college kid hackers running Linux on their Alienware machines, but Office on Linux would be a powerful incentive for corporate customers to seriously consider rolling out Linux desktops in the enterprise. Therefore, Microsoft will never port Office to Linux.

Re:Microsoft port

[larry bagina]

how the fuck do these "it runs on MacOSX so it could run on linux" posts get moderated up?

Last time I checked, MS Office, QuickTime, PhotoShop, et alia were not command-line only, posix-only applications.

Anyhow, shouldn't you be spouting that gimp, open office, and mozilla are better applications?

Re:Microsoft port

[Anonymous Coward]

Worse than just a Carbon app. MS Office for Mac is written using WLM (Windows Compatibility Layer for Mac - pronounced "will am"). This was Microsoft's idea for single sourcing office for Mac and Windows back in the early 90s.

They have long since given up the single source idea. The Mac BU has their own copy of Office Source. However, it is still written using bastardized Windows API on top of a Carbonized WLM.

The whole thing is a mess. There is basically a zero chance that they are going to pick that up and port it to Linux. If they decided they wanted to port it to Linux, they would be better off buying something like ThinkFree Office to be the basis of the port (for several reasons). In fact, *if* they were going to port to Linux, they'd probably do just that.

I used to be a Mac developer there.

keychain

[el stevo]

keychain has been a part of the mac os since OS 8, albeit not it it's current unix-ized form

Re:keychain

[scrod]

albeit not it it's current unix-ized form

So how did the keychain suddenly become "unixized"? It's still a part of the Carbon API.

Does

OSStatus KCFindAppleSharePassword (
AFPServerSignature * serverSignature,
StringPtr serverAddress,
StringPtr serverName,
StringPtr volumeName,
StringPtr accountName,
UInt32 maxLength,
void * passwordData,
UInt32 * actualLength,
KCItemRef * item
);

look unixized to you?

Re:keychain

[Creepy Crawler]

Dammit SLASHDOT.

#include <make_it_look_like_unix.h>

Re:keychain

[markd]

The Keychain API shown in the book is the Security Framework version (SecKeychain*)

Re:Paragraph Intros

[sporty]

No, we won't mod you down. We'll tell you. You are nit picking. All it says about his writing qualitiy is, that he was nice enough to review the book. This is slashdot. It's relaxed and depends on contributions from people.. a lot.

Unless you have something nice to say, say nothign at all. And unless he made a flagrant error, I suggest just commenting on the book. /trogdor

C'mon!

[Anonymous Coward]

You can't be "unfamiliar with the command line" and a programmer. Pick one.

Re:C'mon!

[Anonymous Coward]

Sure you can. Mac people haven't needed a "command line." Converts from Windows don't need one either. I'm a professional Windows programmer, and I don't use the command line.

Re:C'mon!

[bladernr]

I have found the command-line essential, even when programming Windows. Even though the Mac (a system I have never been a developer on, but may learn) has a terrific UI, leaving out the command-line would be a mistake, and the author was right to include that content.

When programmers are beginning, it is easy to avoid the command-line altogether, since their projects are probably simpler. I imagine that the author's previous books on introductory topics focused on the GUI.

I am a software professional as well, and specialize in large distributed systems and massive-parallel (I can never spell that word) processing. No matter how good the tools, you can never escape from the command-line for complex systems.

Its been a long time since I've developed single-tier, single-user apps, so perhaps my knowledge of tools in those areas is dated, and you can develop those without command-line usage. Someone else will have to educate me on that.

Re:C'mon!

[Just Some Guy]

If anything, people who don't use a command line are smarter than you because they're cutting down on keystrokes, thus improving their productivity.

Oh, they're so cute when they're first learning!

Seriously, if your idea of "productive" is "uses fewer keystrokes", then your teacher needs to boot you in the butt. Grow, learn, expand your mind.

Re:C'mon!

[redtoade]

"If anything, people who don't use a command line are smarter than you because they're cutting down on keystrokes, thus improving their productivity."

As a new emacs user I'd disagree.

GUIs have their place... sure. For example, it is much easier to do simple "drag and drop" style data mangement in MSAccess, than it is to write UPDATE queries in straight SQL.

But, emacs has tons of shortcut features that puts it on the same playing field as "point and click." Tab completion, lisp routines bound to Ctrl keys, split windows/mulitple buffers, etc...

You'll find that you actually save time by your fingers never leaving the keyboard than you will with the standard move mouse, type keys, move mouse, type keys...

And you can run a shell (command line) within emacs. In fact I think my RH 8/bash install uses emacs as it's default shell editor. So most of these features are available on the command line.

You can run bash in OSX right? So I would think that all of these features would also be available to Mac users now.

In fact it's not just emacs... MSWindows has shortcuts in all of it's Office programs. They may not be used as frequently as the pull down menus, but they exist for those people who have gained a familiarity with the program. I've been using them for years in Excel and Word, frankly because it's easier to Ctrl+F to open the search dialog than it is to pull it down with the mouse.

I would have agreed with your point (although not with your tone) a few months ago, but now that I've had some experience with keyboard only shortcuts... I can see why the alpha geeks view "point and click" as too damn slow.

Re:C'mon!

[MisterFancypants]

As a long-time UNIX (many flavors) programmer who has worked professionally as a Windows programmer for the past 4 years, I agree with the anonymous, to a degree.

IMO it is more correct to say that you cannot be a competent programmer and not be able to figure out, if needed, how to use a command-line.

I rarely have to worry about using the command-line for programming (though it is there), but when I do have to worry about it (for example -- in Visual C++ 6.0, some compiler and linker options weren't available directly from the UI, one would have to specify them as command-line options to the compiler/linker), I could. Knowing how to use command-lines also allows you to set up nice pre/post build scripts in Visual Studio that can really simplify things (copying DLLs to a shared location after being built, or whatever).

Though I'm generally against the silly minimalist approach many UNIX zealots take with regards to computer use and programming (for example, those who think anyone who uses an IDE is inferior, or whatever), given the choice I'd always prefer to work with programmers who are at least somewhat comfortable using command-lines. Anyone who has no clue in that area has probably not built a serious application. Even on the classic Mac, someone who has created a large application has probably done some scripting in MPW which is a form of command-line.

Re:C'mon!

[Snocone]

You can't be "unfamiliar with the command line" and a programmer.

Then what do you call those things that ran on Mac OS X and the people who wrote them, if they weren't "programs" and "programmers" respectively? Took me 16 years of shipping commercial software products before I had to use a command line at all, personally.

Re:C'mon!

[Maserati]

Adaptors have been available to use PC monitors on Macs since 1991. Current Mac desktops have two digital video ports, including a DVI port. they also come with a DVI-SVGA adaptor. This isn't changing on the G5s. The other connector is an ADC port, which is basically DVI+USB+Power; only Apple LCD screens use that one.

$97.95?!

[yumyum]

That'd put a major dent in my crack usage...

Aaron Hillegass as an instructor

[blakespot]

I am approaching the end of Aaron's previous book, Cocoa Programming for Mac OS X, and can say that throughout, it's as though he is sitting there beside you, casually instructing you as you move through the work. An excellent introduction to Cocoa, it has given me a fairly solid graps of the concepts that make up Cocoa development (which began in the late 80's with NeXT) and I have made some real strides on my own, veering from the courework in the book. Goes far beyond some of Apple's cryptic guides I've encountered.

Oh...and do yourself a FAVOR and download Cocoa Browser before you even lay down a single line of Objective-C. The ONLY way to access the frameworks references.

blakespot

Just wondering...

[rampant mac]

Those WWDC people who have access to Apple's upcoming OS, Panther...

How relevant will this information be with Panther merging to BSD 5.0 userland and the new Xoode environment?

I can't seem to justify the price for this book ... yet.

Re:Just wondering...

[markd]

From what I saw at WWDC, only a couple minor points here and there will need to be updated (like the new exception mechanism in objective-C replacing the setjmp/longjmp one that currently exists). The tech addressed by this book is more at the plumbing level which doesn't change a whole lot release to release. We don't dwell a lot on the IDE, figuring that folks will know what they're doing in their IDE of choice. (I personally use emacs for my day-to-day work)

Re:Just wondering...

[Anonymous Coward]

I bought it anyway. Sure, Panther will change things, but there is still a lot of stuff in there. I'm still using Aaron's Cocoa book despite many changes to Project Builder that can sometimes make it difficult to follow the examples. I expect the same of Xcode. Much of the book is good reference for things that I've seen before as a Unix C programmer, but forget because I don't look at them every day.

It's expensive. Very expensive. With my current budget situation, I had to figure out what else I wasn't going to be buying before I could get it. But cheaper than going to the classes, for which I've gotten several unsolicited glowing recommendations merely for walking around WWDC with a copy of the book.

The authors are great guys, they know what they are talking about and are not stuffy at all. I hung out at their booth a while looking at the book before I bought it and later they both cheerfully signed it for me.

Re:Paragraph Intros

[Creepy Crawler]

If you can "read" a EULA, I'm sure this is cake.

I understood is point, I didn't say "huh", nor did I otherwise get confused. Sheesh. Even the "Hacker Exploit Papers" have jokes and innuendos spiced about. And they're considered 'professional'.

Confused

[Anonymous Coward]

I see Unix in the title but there is no mention of SCO. Just what in the hell is going on around here?

Re:Confused

[nacturation]

I see Unix in the title but there is no mention of SCO. Just what in the hell is going on around here?

SCO was too busy imagining a beowolf cluster of these.

Re:weird

[dema]

This got a funny mod? Um, flamebit?

When you buy an Apple you get what you pay for, so that's a bad example anyway.

Who mods this stuff?

Re:weird

[carpe_noctem]

For example, chapter 8, "Debugging With GDB," was not simply a repeat of the online help...

Wow, so we didn't even RTFS (summary), did we? ;)

Good News...

[DoctorPepper]

... If you have a Barnes & Nobel reader's advantage card:

List Price: $97.95
Our Price: $78.36
You Save: $19.59 (20%)

Readers' Advantage Price: $74.44

(OUCH!) This looks to be one book I'm going to have to skip. Bummer.

man Pages

[The Jonas]

On a side note, I have wanting to see a program developed for the *nix desktop that allows a user to select from all available "man" pages and display them in the active window. This would minimize some time I spend on the command line - not that I mind the command line, but for document viewing, editing, and note-making I would rather have a graphical interface. Let's call it "RTFM" ;) . This may be able to be done through another program and I may just be unfamiliar with its operation. Anyone???

Re:man Pages

[krray]

You mean something like: ManOpen

Wrong URL to Buy the Book

[BigNerdChris]

You can't (currently) get the book at bn.com. Use this web page to buy the book: http://www.atlasbooks.com/marktplc/00981.htm

Re:weird

[Surak]

Uh, did you even read the summary?

First off, glibc doesn't have a man page. The book isn't $60, it's like $98 and even discounted it's going to be around $75-$80. Secondly, the guy specifically states that the GDB stuff isn't a regurgitation of the man page, which I assume would hold true for other pieces of the book as well.

Secondly, although I have publically stated my fundamental disagreements with Apple about their policies on patents and their general disregard for some of the fundamental concepts behind open source software, Apple makes *great* hardware -- it's *much* better stuff than you can find in value-priced x86 machines. A little overpriced, yes, but you expect that from a strong brand like Apple.

...SCO lawyers start your engines...

[the_webmaestro]

will they sue these guys for having Unix as part of the Book title?

Haha! Nice Try!

[Greyfox]

Thought you could pass yourself off as an Apple user did you? We all KNOW that Apple users are pot smoking hippies, not crack smoking executives! Go back to your windows desktop, poser!

Re:Haha! Nice Try!

[qengho]

We all KNOW that Apple users are pot smoking hippies

Don't forget that the company itself is so constrained by the political views of its corporate leadership and board, which now includes Al Gore, that it's accepting lower sales. Commie mutant traitors!

the price

[Anonymous Coward]

I plan on buying this book when I get the cash, but from talking to Aaron last week at WWDC, the price is that high is because it's basically the course material for the classes they have at the Big Nerd Ranch. Of course...I can't afford the classes, so I'm going to get the book.

AppKiDo

[hayne]

do yourself a FAVOR and download Cocoa Browser before you even lay down a single line of Objective-C. The ONLY way to access the frameworks references.

I much prefer AppKiDo since it allows searching and it shows you a list of all methods of a class (including those from super classes) as well as a list of just those provided by the class itself.

beside me? uh oh ...

[Heisenbug]

"It's as though he is sitting there beside you, casually instructing you as you move through the work."

That's gonna make it harder to code in the nude ...

Weird Times

[SomeOtherGuy]

I know OS X is all unix central nowadays...Yet to see a book about core Unix programming on a Mac still has me to a doubletake the same if I saw a book called "A vegetarians guide to cooking steak."