Core Mac OS X and Unix Programming 212
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.
Whoa (Score:5, Funny)
Microsoft port (Score:2, Interesting)
Re:Microsoft port (Score:3, Insightful)
Re:Microsoft port (Score:5, Informative)
Re:Microsoft port (Score:4, Informative)
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.
Open Carbon? (Score:2)
Wait a minute - if I had my modpoints now, I'd surely give you an "insightful" just for this. Are there any attempts to create something like free carbonlib compatibility environment? This could bring much more than just MS Office to Linux and other free OS'es. After all, majority of games
Re:Open Carbon? (Score:2)
Re:Microsoft port (Score:2, Insightful)
Re:Microsoft port (Score:2, Insightful)
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.
Why Would MS Encourage Migration to Linux? (Score:2)
Re:Microsoft port (Score:2)
Most equate open aource to being free of charge. To quote other
Re:Microsoft port (Score:3, Insightful)
Re:Microsoft port (Score:2)
Re:Microsoft port (Score:1)
Re:Microsoft port (Score:3, Informative)
Re:Microsoft port (Score:3, Insightful)
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 machi
Re:Microsoft port (Score:2)
Re:Microsoft port (Score:2)
Re:Microsoft port (Score:1)
But if they developed Office for x86 Linux, Linux popularity on the destkop would rise enough to hurt Windows sales.
ah, no (Score:1)
Most of the work is most certainly not done. It's not like we run
Re:ah, no (Score:1)
ah, yes (Score:1)
That makes them even less portable.
Re:Microsoft port (Score:5, Interesting)
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 (Score:2)
Actually, a program using Windows APIs is much closer to Linux because of winelib.
Re:Microsoft port (Score:2)
Jokes aside, how much PCODE is still left in Mickeysoft products?
Re:Microsoft port (Score:2, Funny)
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?
keychain (Score:3, Informative)
Re:keychain (Score:4, Insightful)
So how did the keychain suddenly become "unixized"? It's still a part of the Carbon API.
Does look unixized to you?
Re:keychain (Score:1)
#include
Re:keychain (Score:2, Funny)
#include <make_it_look_like_unix.h>
Re:keychain (Score:2)
Where do you think the inspiration for the MFC came from, anyway? The Mac toolbox (which has since evolved into Carbon) had this awful, awful style long before Microsoft adopted it for their Win32 APIs.
Re:keychain (Score:2)
Re:keychain (Score:2, Interesting)
Nice KeyChain Obj-C wrapper (Score:2)
C'mon! (Score:4, Funny)
You can't be "unfamiliar with the command line" and a programmer. Pick one.
Re:C'mon! (Score:2, Insightful)
Re:C'mon! (Score:3, Interesting)
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 w
Re:C'mon! (Score:2)
Agreed.
I work for a company that makes "enterprise" client-server apps, and out customers demand we have a complete command-line interface, along with a standard GUI and an API interface. All interfaces are actually running the same client commands, so we have some kind of interface parity. (No, our GUI is not a wrapper around the CLI! The "client" is abstract, and can only be accessed via your choice of inte
Re:C'mon! (Score:2)
I don't think this will be the case. I, while not an old-timer @ 23 years, love the CLI. I continue to see a need for both. I use both, and use them when they should be used. The CLI is great for scripting and such, and can be indispensable when speed is important. Sure, the CLI has a steeper learning curve, but once you get to know the commands, options, etc., most people favor the command
Re:C'mon! (Score:2)
Now I think that in some ways Apple is still a little too dependent upon the CLI in OSX. Lots of things don't have a GUI that should. But that doesn't mean the CLI isn't welcome. After Sys9, having a full sophisticated CLI is a dream. Further with Applescript integrating the two is possible in a way not dreamt of in Windows or Linu
Re:C'mon! (Score:1)
There are many examples. For instance, I once had a program bug that actually rolled the last access times of many, many files in many, many directories forward, causing a serious amount of grief for the OS.
Re:C'mon! (Score:5, Funny)
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! (Score:2)
Try doing a global find and replace through over 80 sub-projects in Visual Studio, and you'll find that the command line and sed are your two new best friends.
I try to use the command line as rarely as possible, but I refuse to avoid it if it's the best/fastest solution to a problem. I don't think that makes me "elite", but I do think you'd have to be pretty stubborn to expressly avoid
Re:C'mon! (Score:3, Interesting)
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 k
Re:C'mon! (Score:1, Insightful)
Yeah, but you can do the same thing in any decent GUI-based dev environ for Windows or Mac.
I think my point was not so much that you should always use the mouse, but that people who immediately assume that any one developing under a GUI is any less of a skilled programmer are assholes. This whole thread stinks of tha
Re:C'mon! (Score:2)
Dear God, I hope you were being sarcastic.
Re:C'mon! (Score:1)
Anyway, you're the AC doing the Delphi to AS/400, right? That's great stuff. AS/400 is one of my favorite systems, and I'm real handy with RPG, systems programming, etc. Alas, these days, 99% of what I work on is UNIX.
Getting back on topic, that is what I always perceived as Mac's weakness: integrating with other systems. Granted, that is an outsiders point of view since, as I said, I've never worked on Mac as a programmer.
Th
Re:C'mon! (Score:3, Informative)
Re:C'mon! (Score:3, Insightful)
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 avai
Re:C'mon! (Score:1)
You can't be "unfamiliar with the command line" and a programmer. Pick one.
Well, I suppose you could write VB code, but calling that programming is quite a stretch.
Re:C'mon! (Score:1)
Re:C'mon! (Score:3, Insightful)
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! (Score:2)
</QUOTED TEXT>
Hmm. 16 years. Commercial software. Let's see, that would (assuming the first time was five minutes before your post) put you at 1987, not usi
Re:C'mon! (Score:2)
'85, actually.
assuming you were a DOS programmer
Nope, just Mac.
on the Mac, your choices were - Mac Pascal or MPW
Au contraire!
Started out in MacFORTH, then Consulair C, then THINK (later Symantec) Pascal and C, then CodeWarrior. Never touched Mac Pascal ever, and only extremely rarely had anything to do with MPW -- certainly not enough to be any reasonable definition of "familiar" with it.
Heck, I wouldn't even call myself "familiar" with the OS X command line yet
Re:C'mon! (Score:2)
If most of them do change, how brilliant/functional is the one-button mouse?
Re:C'mon! (Score:2)
First, add the necessary qualifier here "to the complete novice who thinks of a computer as no more important to them than a screwdriver and they figure should be as easy to use -- which is Apple's default target for a new buyer." (As anyone who isn't in that category can go pick themselves up a Logitech MX700 and get eight buttons, like I did.)
Next, if this clarification still leaves you in any doubt that one is the proper number of buttons for a defau
Re:C'mon! (Score:2)
2. Tech support jobs would also be simplified if keyboards had one button. Not very useful is it?
Re:C'mon! (Score:2)
I was happy to see that replacing the hockey puck mouse on my G3 with a $15 3 button + wheel optical mouse worked flawlessly in MacOSX, even way back at X.0. I needed to install drivers for both Linux and macOS 9 (both had non-functional wheel although 9 in emulation mode worked).
Re:C'mon! (Score:1)
$97.95?! (Score:5, Funny)
Re:$97.95?! (Score:1, Insightful)
They really should've considered three different books here: the main book that's already available and two other books (the main book split into two volumes). I'd actually buy a volume that's geared toward networking and threading even if I'm paying for unwanted info (I can let it slide to a degree). Instead, I'll likely skim the Rendezvous section with
Haha! Nice Try! (Score:3, Funny)
Re:Haha! Nice Try! (Score:3, Funny)
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 [macminute.com]. Commie mutant traitors!
Aaron Hillegass as an instructor (Score:5, Informative)
Oh...and do yourself a FAVOR and download Cocoa Browser [nifty.com] before you even lay down a single line of Objective-C. The ONLY way to access the frameworks references.
blakespot
AppKiDo (Score:2, Informative)
I much prefer AppKiDo [mac.com] 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 ... (Score:3, Funny)
That's gonna make it harder to code in the nude
Just wondering... (Score:5, Interesting)
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... (Score:3, Interesting)
Re:Just wondering... (Score:2, Insightful)
It's expensive. Very expensive. With my current budget situation, I had to figure out what else I wasn't go
Confused (Score:4, Funny)
Re:Confused (Score:2, Funny)
SCO was too busy imagining a beowolf cluster of these.
Good News... (Score:4, Informative)
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.
Re:Good News... (Score:1, Offtopic)
Please, please, please...?
Wrong URL to Buy the Book (Score:3, Informative)
Re:Wrong URL to Buy the Book (Score:1)
...SCO lawyers start your engines... (Score:2, Funny)
the price (Score:2, Informative)
price is $104 -- am I making a mistake? (Score:2)
Also, is it showing up on Amazon? I looked and didn't see it.
Clues gratefully accepted...
Weird Times (Score:3)
Does Cocoa (and this book) relate to GNUStep? (Score:2)
Re:Does Cocoa (and this book) relate to GNUStep? (Score:2)
I haven't read it but judging from the title and review, I don't think it will do you much good right now. It appears to be talking about some of Apple's own custom frameworks and lower level UNIX stuff. Somebody on the GNUstep list mentioned recently that they're interested in cloning Rendezvous but it's still just vapor.
Now, Aaron Hillegass' previous book, Cocoa Programming for Mac OS
Good book. Good review (Score:2)
I agree with the reviewer about the lack of pointers for further info. I hope that the authors might fix this at the excellent site for the book.
For close to $100 this is an expensive book, but if you want to learn to write professional Mac apps then it's probably worth the price. Th
Re:Paragraph Intros (Score:5, Insightful)
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.
Re:Paragraph Intros (Score:3, Funny)
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'.
Re:Paragraph Intros (Score:2, Troll)
Re:weird (Score:2, Funny)
When you buy an Apple you get what you pay for, so that's a bad example anyway.
Who mods this stuff?
Re:weird (Score:3, Funny)
Wow, so we didn't even RTFS (summary), did we?
heh i saw Debugging with GWB (Score:2)
man Pages (Score:3, Insightful)
Re:man Pages (Score:1)
Re:man Pages (Score:4, Informative)
Re:man Pages (Score:1)
Re:man Pages (Score:2)
From the ReadMe that comes with ManOpen:
"ManOpen should run on MacOS X 10.x, MacOS X Server 1.2, and OPENSTEP/Mach machines. Source c
Re:man Pages (Score:2)
Re:man Pages (Score:1)
Re:man Pages (Score:1)
comes with pretty much any distro i know.
Re:weird (Score:5, Informative)
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.
Re:amazing (Score:2)
But I will tell you -- I have used Macs in the past for desktop publishing work, and I have used a colleague's G4 machine before, and I've taken a close look at the hardware and software of modern Macs while considering whether or not to purchase one.
I decided that for my own needs, a Mac wasn't going to cut i
Re:amazing (Score:2)
I'm not so sure about this. I don't think that Apple is trying to deceive anyone in this matter. I think it simply boils down to not having the resources to do what they really want to do. You compare what IBM has done to what Apple has done... look at the difference in size between the two companies. Of course IBM can afford to have a
Re:amazing (Score:2)
1. Why doesn't Apple open source more of their software, like QuickTime?
2. Why doesn't Apple open source more of OS X than just Darwin? An OSS version of the GUI would be a big boon to the community.
3. Why does Apple cling so tightly to its patents? Why does it STILL apply for software patents (i.e., Expose). If they truly support OSS, surely they would see that software patents harm the OSS community.
Answer those three questions and you'll most likely arrive at the same con