Unix has long had an EDITOR environment variable whose value would be used by many programs whenever the user was expected to edit a hunk of text. For example, CVS or Subversion use the program specified by EDITOR to edit commit messages.

bzero, my new weblog rendering/publishing tool, uses EDITOR to edit weblog posts.

Given our modern desktop environments, it seems kind of silly to limit EDITOR to just command line tools. It would be nice to be able to use TextEdit, Xcode, or BBEdit to edit files normally edited from EDITOR. Emacs or vi are perfectly capable editors, but they simply don’t have the level of integration with the system that a GUI level editor has (yes, there are .app implementations of Emacs, but it is still not exactly “user friendly” in the classic Mac OS application sense).

While open can be used to easily open any random file in any random GUI application, it doesn’t work in the context of EDITOR. When something like bzero, cvs, or subversion invokes the EDITOR, it expects the command to not exit until the editing is completed. open exits immediately after it has successfully passed the file off to the GUI app, long before editing has even started.

BBEdit provides a command line tool that does exactly that. With the –wait option, the command line tool will not exit until the associated editing window is closed in within the BBEdit application. Exactly what is needed.

If you happen to have BBEdit installed, you can install the command line tool by going to the “Tools” subsection of Preferences and click the Install “bbedit” tool.

It will install both the bbedit tool and a very nice man page.

Once installed, you can set EDITOR to bbedit –wait –resume and most things will work correctly. However, there are a handful of apps that don’t like it when EDITOR is set to something other than just an executable. As such, you’ll probably want to set EDITOR to point to a little shell script that invokes bbedit with the appropriate arguments. I created as script called bbeditwait with the following contents and shoved it in the bin directory within my home account:

bbedit --resume --wait $*

Then set EDITOR to ~/bin/bbeditwait. Unlike the suggested script found on the BBEdit site, this one will allow you to edit multiple files. There is a bug, though, in that it will literally edit each file one after the other, opening the next after the previous has been closed. It should just open all files at once and exit from bbedit when all requested files have been closed.


Ben Hines mentioned that this would make a good Mac OS X Hints submission. There is already such an entry in OS X Hints, but it was rather generic and the suggested shell script in the comments doesn’t quite work the way I wanted in that it only accepts single files.

This isn’t new. Under OpenStep, I patched TextEdit such that an accompanying command line tool could edit files in the same fashion as ‘bbedit –wait’. It also allowed one to edit files remotely. So, if I were logged into a Solaris or Linux dev box from my OS X Server / OpenStep machine, EDITOR based sessions would pop up on my local machine as a regular TextEdit document.

I probably still have the code around somewhere. I should probably dig it up and post it.

So, BoingBoing and others are already starting to criticize TiVO’s new TiVo to Go service because it uses a proprietary DRM technology to lock content to a particular computer/TiVo combination (or something like that), thereby eliminating the ability for the user to edit or archive the content. It isn’t really clear that archival is disabled, but flexible archival is certainly limited.

In any case, Cory says Not delivering the products your customers demand is not good business. It never has been. as a way of criticizing what TiVO is delivering as not being what the customer wants.

Cory seems to have missed the point. As a long time TiVo user, I can tell you exactly what I and most other TiVo users want.

I want to know that my TiVo will have the accurate scheduling information required to resolve scheduling conflicts such that the TiVo will record the content I desire without me having to constantly double check the TiVo’s schedule of recording events.

To do that requires accurate scheduling information delivered in a timely fashion (i.e. ahead of lineup changes) by the various content distribution agents. Given the vast and ever increasing number of cable providers (San Jose has at least 6, maybe 8, different cable lineups depending on your location) and the control with which the local cable company can now exert over the broadcast schedule, having access to accurate information in a timely fashion is paramount to the TiVo unit’s ability to record the rights shows at the right time.

Being able to play a show on my computer is a “nice to have”. Being able to edit and share that content with others would be even nicer.

But if editing and sharing the content threatens the ability for the TiVo to fulfill its primary function, then what would be the point?

Cory asks Where does this bizarre idea — that the dinosaur industry that’s being displaced gets to dictate terms to the mammals who are succeeding it — come from?

It seems abundantly clear that this “bizarre idea” comes directly from the fact that the newcomers are dependent upon the dinosaurs not deciding to crush them. The newcomers are dependent upon cooperation from the dinosaurs or else the newcomers will not survive.

The dinosaurs are not only TiVo’s eventual competition, but also TiVo’s only means of achieving success.

Historically, the original ISPs were in a very similar situation and were pretty much completely crushed when the telcos decided there was money to be me made. The telcos could undercut the ISPs by simply eliminating the cost of two local loops (you -> ISP, ISP -> [telco] -> Internet vs. you -> [telco] -> Internet). TiVo is in a similar situation in that the cable companies could decide to roll out their own PVR with a claim that their PVR’s scheduled recordings are much more accurate/reliable because they are directly integrated with the scheduling stupidity at the head end.

So, TiVo walks a fine line and has been doing so very well. Witness ReplayTV (who? Gone.). They threw the 30 second skip and content distribution in the face of the broadcasters and the end result was the complete lack of strategic partnerships and the eventual death [twice] of the platform.

Radio has effectively handed me a blank slate. It is as if I’m creating a weblog for the first time only this time I have 2+ years (**double take**) of weblogging experience at the start.

I could either batch move all the old “content” into the new client environment. To Radio’s credit, it makes doing so very easy.

The alternative is to cull through all the gunk posted over the last few years and use this as an opportunity to update a bunch of content.

You might notice a distinct lack of content here.

That is because my Radio UserLand installation exploded one time too many. I’m going through the pain of moving to something new.

At the moment, I’m using bzero. However, there is a bug that prevents it from working when bzero itself is installed on a different volume than your home account. I had to drop in an ugly little hacque in place to redirect the location of bzero’s per-user configuration

In looking for a replacement, one key feature is to continue to be PyCS compatible in that it must implement the xmlStorageSystem protocol.

I’m quite comfortable with continued hosting at PyCS. Phillip Pearson has been extremely generous and helpful– I’ll take this opportunity to publicly thank him for his efforts!

An old friend from our mutual NeXT days contacted me. He now works at Sleepycat and gave me a pointer to Syncato.

One of the reasons why I write a weblog is so that there is a google-indexed record of some thoughts/notes/tricks that I have had/taken/discovered over the years. It is more efficient and effective to find information via Google than it is to grep through a bunch of text files on my own system.

Through XSL and XQuery, Syncato offers a compelling set of features that might effectively address the need to find information and certainly offers a wide variety of interesting ways to cross cut the data.

With all that said, it is hard to beat the simplicity of bzero and bzero’s use of Python source as templates is particularly interesting.

In the comments, PyDS has been mentioned as a possible candidate. PyDS is a really cool collection of technologies, but it does not fulfill the desire to have a simple weblogging client that is compatible with Python/Radio Community Servers.

PyDS and Radio share a particular trait that is at the heart of a pet peeve of mine. In particular, why do I need a desktop web server to publish a weblog? Both tools are extremely complex, though in different ways. Radio is a closed, proprietary, pile of antiquated complexity that no longer behaves well on the modern Macintosh desktop. PyDS is an open, well behaved, desktop server infrastructure with a boatload of dependencies on other open source projects. If it were a choice between the two, I would be posting from PyDS right now.

But both platforms are eliminated by the complexity factor. In their own right and for different reasons, each are fragile, hard to manage, and complete overkill for solving the relatively basic problem of publishing a WebLog.

The Syncato solution mentioned above is also relatively complex and hard to install (compared to something like bzero or your basic Blogger client [NetNewsWire again]), but it offers a lot of direct benefit for that complexity in the form of a powerful/flexible database containing your content. In other words, the complexity is focused on solving one problem and not solving a bunch of different problems in a loosely connected desktop server. I’m just not sure I care — I’m not sure that Syncato offers enough value over the knowledge that Google is going to index what I publish sufficiently for my needs. Maybe if I wanted to have a personal log of private notes. For that,I use Note Taker and SBook.

Big Nerd Ranch was kind enough to send me a copy of their new book Core Mac OS X and Unix Programming in gratitude for editing the original Cocoa Programming for Mac OS X book.

The book is effectively the course materials for the Big Nerd Ranch course of the same name.

Co-authored by Mark Dalrymple and Aaron Hillegass, the book covers many advanced topics in the same clear/concise manner as Aaron’s original Cocoa programming book.

The book is focused on relatively advanced topics such as memory management, the run loop, multiple processes, rendezvous and many other topics. Instead of focusing on the high level details, each topic is investigated from the perspective of documenting the technical details– often non-obvious– through the use of examples, diagrams and discussions.

Two bits that immediately grabbed my attention–and are examples of the approach found in the rest of the book– where the discussion of malloc() behavior and the discussion of the run loop.

In the case of malloc(), the book precisely discusses the fact that malloc() does not necessarily return the number of bytes that you think it does — it often returns more based on certain internal optimizations. The end result is that quite a number of memory size reduction related optimizations are a complete waste of time! Instead, you might be able to consume a few extra bytes by not compressing the data structures and gain raw performance in terms of the # of CPU cycles needed to access the data.

The discussion of the run loop was also of great interest. It clearly diagrams the run loop and the exact point during the run loop — both CFRunLoop and NSRunLoop — that the various events and timers will be handled.

Excellent, excellent stuff.

The $100 price tag is a bit higher than most developer books, but the content is of an advanced and highly refined nature. $100 is a heck of a lot cheaper than $3,500 — the entrance fee to the class for which the book was written.

Big Nerd Ranch has also made a set of resources and forums available online.

So Apple’s new music store sells songs for 99¢ per track. That sounds suspiciously like a micropayment (or at least a “minipayment”) system to me. Lots of excellent insite into CC based payment systems deleted — seriously, go read the article! [ Tales from the Red Shed]

I had been wondering the same thing since Apple launched the store– how did the work out a reasonable mini/micropayment system. Having actually purchased a couple of items now, I have noted a significant delay– upwards of 10 hours– between purchase and arrival of the email “for your records” receipt.

That delay may simply be due to the overwhelming purchase traffic through the store (let us all hope so!) or it may be because of some of the purchasing scenarios described in the aforementioned article. I have no idea.

In the Fortune article it is mentioned that the record company takes an average of 65 cents per track sold. That leaves an average of 34 cents per track to cover expenses and make some money. Likely, a big expense is bandwidth and one of the best ways to eliminate rampant consumption of bandwidth is to limit the customer to one-download-per-purchased-item (as they currently do). However a 34 cent/song margin is large — large enough to support a big chunk o’ transaction charge being shipped off to the CC company.

However, there is a another reasonable scenario under which Apple may be operating to support a micro/mini-payment based store.

In particular, the credit card companies have long recognized that micro/mini-payments are a potentially huge market. Not only does the customer desire the convenience of being able to use a CC to make small goods/services purchases, but micropayments often lead to the customer decoupling the act of making a purcahse from the act of paying the bill. This has long been a powerful marketing ploy — if you can successfully get the consumer to stop considering consuming your goods/services with paying a quantitative amount of money, there is less hesitation to consume.

The credit card companies have been investing billions of dollars in building huge networks that can handle potentially 10s of billions+ transactions/day where every transaction must be cleared in a matter of seconds. (There was a really interesting article on all of this in a recent Forbes, but I can’t find an URL.)

Clearly, it would have been in Apple’s best interests to have approached the credit card clearing companies with a proposal to work out a deal that would support the implementation of a micropayment based purchase/payment model. Any reduction in the extremely high transaction costs that are the tradition– the very same costs that are designed to discourage people from making lots of small transactions– would contribute greatly to Apple’s profit margin on goods sold through the music store.

Similarly, the launch of the Apple Music Store has the unique characteristics of making a really huge amount of media noise while being accessible only to a niche market [Macintosh owners with a US billing address]. At least initially. This provides an excellent opportunity for the companies involved to gauge the public’s reaction without actually having to commit to a stupendously large potential market.

If the reaction to the Mac specific store is good [and it seems to be], then the entrance into the much larger Windows (and others) markets can be done with the confidence that the micropayment model– something that is very attractive, yet very scary, to the conservative consumer credit industry– has been proven both from an implementation and a public-relations standpoint.

I have no doubt that rolling out a Windows version of the Apple Music Store is rife with technical uncertainties that are way more difficult to deal with than on the Mac side, but that does not out weigh the potential business advantages to doing so. As well, choosing– consciously or by circumstance– not to address the insanely difficult/complex/political issues associated with distribution of music-by-wire into non-US markets has significant potential business advantages, as well.

If the Apple Music Store is successful in its focused initial incarnation, it will provide a tremendous source of negotiating leverage when it comes time to open up new markets. Obviously, the Windows market in the US was already announced “before the end of the year” and is on the path to release.

However, there are certainly still some legal & technical issues to be resolved. Will Apple continue to use their own DRM or will they integrate tightly with Microsoft’s DRM APIs and policies? If they choose to go with the Microsoft based DRM, how much can they affect the provided rights prior to release?

If the Mac/U.S. store is a rip-roaring success, said negotiations can be carried out with a result much more in Apple’s favor.

Likewise, solving the overseas distribution problem will be far easier if the interested parties– media, religious, and political– can see that profit is just a matter of implementation and not a question of whether or not anyone will buy the product.

It will be very interesting to see how the Apple Music Store evolves. It is amazing that Apple was able to negotiate all of the different distribution rights and payment rights that must have been required for even the 200,000 songs that are in the store now. Of those albums for which only partial downloads are available or for which a number of songs can be bought only with the full album, I wonder how much of that decision was actually dictated by the rights/distribution deals that had been worked out?

Slight digression: In particular, every unique performance of a song is an individual sound recording that may carry its own intellectual property characteristics that can be different than the other songs on the album. Every time a song is performed at a live show, that performance of that song is a new sound recording. Given guest musicians, union rules and venue, the set of property rights associated with a particular sound recording may be quite complex to resolve and achieving the rights to distribute might be prohibitively expensive. The ℗ symbol means “sound recording copyright” and implies that the particular performance of the particular song carries its own set of intellectual property rules that may be different than any other performance of that song. To further complicate matters, the song’s lyrics and score may have different copyrights that affect the sound recording copyright. Playing live ain’t all about jamming on stage with your closes friends– if some random person hops on stage from the audience to play two notes on a harmonica and you suddenly might find yourself without the ability to actually sell a recording of that portion of the performance. (Yes, I did spend some time in the distribution end of the recording industry).

Apple has certainly solved a bunch of problems that no other company had solved in a single package (a number of other products exist in this space– and some have seen some success… it is way too early to tell how Apple’s track record might compare). However, a lot has not been said. Historically, it will be interesting to see how the store contributes to the corporate balance sheet– to see how successful the Music Store really is. Looking ahead, it will be fascinating to see how the success of the store is leveraged by Apple into more opportunities and used to open new markets.

Of course, Apple is not the first to make a foray into a digital delivery based media market. Nor will they be the last. How other companies leverage Apple’s success– be it fiscal or purely technical, in the end– will make for some very interesting markets and business models in the coming years.

What is prebinding and when does it need to updated?

Bill Bumgarner

Really Short Answer

Under 10.1, prebinding never needed to be updated on anywhere as regular of basis as a lot of people assumed.   The only time prebinding information would be out of date is if you installed an application on the boot volume via drag-n-drop.  In that case, only that application’s prebinding information would be out of date and updating the prebinding would only affect the freshly installed app’s launch time.

Under 10.2, prebinding information is automatically updated as a normal part of system operation.  There is no need to ever manually update prebinding information.

Currently, most of my day is spent in OpenStep 4.2 working on porting a Very Large Body of Code from NeXTSTEP 3.3 to OS X / Cocoa. My current task is converting the NIB files from NS to OS as OS X can open OpenStep NIBs, but not NeXTSTEP NIBs. To complicate matters, the apps to be ported made relatively heavy use of InterfaceBuilder Palettes that are not going to be ported (obsoleted by new API). So, the port from NS->OS of the NIBs is actually not just a straight conversion as I’m also converting objects on the fly from one object model to another.
Very interesting stuff, really.

As we no longer have any Intel hardware that can run OpenStep, I’m running OS 4.2 under VPC for windows. It is faster than the native OpenStep-on-Until box I used 5 years ago. By jumping to full screen mode, you can’t even tell that Windows is the host OS!

Furthermore, it is possible– even easy– to configure VPC to allow the OpenStep box to have its own separate IP address. Once done, configuring OpenStep is exactly the same process it has always been (i.e. easy).

So, I’m no logged into an OS 4.2 box running under VPC that is mounting my home account, has all of the environment variables and defaults, etc.

Works flawlessly. Quite the retro-computing experience!

This is a response to a message posted to the cocoa-dev mailing list. It contains a bunch of URLs that I need to remember across new environments and, as such, I thought I’d blast it into Radio so it goes on my “permanent record”

On Saturday, April 27, 2002, at 07:54 AM, Mark Weinstein <markfoo; wrote:

I am a software developer in the Seattle area and have recently moved from the Windoze platform over to the Mac and have several observations that I would like to make. Please understand that I am not flaming Apple (or anybody else for that matter), but it makes it much easier to understand why software developers don’t flock to develop for the platform.

Heh… I would imagine that whole ‘other 95%’ thing might has something to do with it, as well. Having been a long time NeXT developer, the Macintosh software market seems positively huge in comparison. Kind of like the difference between potential Windows customers and potential Macintosh customers.

(I stuck with NeXT and, now, OS X because– frankly– sitting in front of a Windows box makes me nauseous in fairly short order. I would have to replace far too many keyboards to even ship a single app.)

1) I have been a software developer for a little over 20 years, and never in my life have I seen such poor documentation. I have attempted to work with Cocoa, Carbon and even WebObjects and have found that any documentation that I have found that was even worth reading was not from Apple. In addition to the quality of the documentation, it is nearly impossible to even find anything more than quick samples here and there. If people are being actively recruited as developers, why aren’t they getting any support or training out of the recruiter?

Microsoft’s documentation and their developer program is certainly impressive in both the sheer volume of materials they ship you and the quality of a lot of the documentation. My experience over the last 20 years of development work has been a bit different. Microsoft provides excellent documentation, Apple provided excellent docs up until the introduction of Carbon, Rhapsody and the precursors to OS X.

In the early days, NeXT provided excellent documentation, as well. Not only did you have reams of straight reference materials, but NeXT provided excellent concept and architecture documentation.

As OS X has evolved, the documentation has improved immensely. These days, finding the appropriate documentation is more of a challenge than anything else. There is actually a fairly good reason why the docs have been lagging for some time and are just now starting to catch up (not that I’m attempting to make excuses for the state of the docs, simply that I can understand and even sympathize with the state they are in).

Namely, the Cocoa, Carbon, and WebObjects SDKs had been moving sideways until relatively recently. Cocoa is fairly solid these days, but Carbon and WebObjects is changing and evolving in fairly significant ways. Because of this, any documentation written against these APIs often must be massively revised with any major release.

Given the nature of the documentation– highly technical documentation that requires heavy engineering involvement to produce– it consumes a tremendous amount of engineering effort to keep everything up to date. Unfortunately, engineering resources are not cheap and time is not plentiful. I can understand (but don’t necessarily like) that Apple would make the decision to let the documentation slip a bit until it stops moving sideways.

This is exactly what appears to be happening. The Cocoa APIs are solid– there have been additions, but no major architectural revisions recently. As of the April development tools seed, executing the command….

find /System/Library/Frameworks -name '*.html' -exec grep -l 'forthcoming' {} \;

…reveals that there is not a single ‘description forthcoming’ left in the documentation for any of the Cocoa related frameworks. Likewise, as of WebObjects 5.1 [update whatever], the WO documentation has been moved forward to a similar state.

Core and Carbon– less so Carbon than Core– still has a number of ‘description forthcoming’ bits throughout the docs, but both of those APIs are still evolving.

On the non-reference front, there is quit a lot of examples and taks/concepts guides available. Again, the challenge is largely one of finding them.

For Cocoa:




Excellent starting points for figuring out where all the useful Cocoa documentation lives. The second document is particularly useful to those new to the Cocoa development platform. Scan through the last document to gain an understanding of some of the vocabulary used throughout the rest of the documentation.


Contains a tremendous wealth of examples that exercise particular chunks of API or implement particular concepts



This is the book to read to gain a relatively deep understanding of Objective-C. However, it is also of value to programmers of other OO languages as it provides an awesome overview of OO architecture and implementation methodologies. This is a very mature document; I believe one of the first version shipped with, at least, NeXTSTEP 1.0– maybe earlier– in 1990. However, it is not obsolete/out of date!

The first link leads to the Apple Developer Connection site– likely not news to anyone here– from which you can access any number of very useful resources. If you haven’t done so, register for a free ADC account as that will give you access to various software seed (though not as many as the $500/year select membership) and give you the ability to file bug reports and feature requests via the third URL. (And do file bug reports / feature requests. As long as your report or request is clearly written and contains the appropriate information– version # of the system, build # of the PBX tool suite– Apple really does read the things and really will fix the problems or add the feature (if it makes sense to do so, obviously).

The gateway to all of Apple’s mailing lists. Well, not all, but to a vast majority of the lists that are pertinent to developers. Obviously, you have already subscribed to cocoa-dev, but there may be some other lists that are of interest. If you aren’t sure whether or not a list is useful to you, subscribe in Digest mode. This will limit the # of emails/day you receive from the list– for cocoa-dev, I typically receive somewhere around 3 to 6 digests a day– and will reduce the clutter in your mailbox.

The Omni Group (awesome company — buy their stuff! — they offer the mailing lists completely voluntarily and, beyond the, in each post, I have never seen Omni use the lists for marketing purposes) also has a number of mailing lists of interest to developers. The Omni lists tend to have more traffic and, for whatever reason, tend to have a bit more rampant advocacy then the Apple Lists. Digest mode is definitely the way to go on these lists as macosx-dev alone often has well over 100 messages posted per day (many more, in some case). WebObjects-dev is likewise– I have seen digests with up to 120 messages in it.

The first three links all lead to a boatload of information about Cocoa and OS X development (and OS X development, in general). The last link leads to a page full of links to man0y other sites.

Apple offers a bunch of excellent Cocoa training. Big Nerd Ranch offers excellent Cocoa training, as well, and I hear that their training facilities is quite cool. Aaron– the primary dude behind BNR– has been doing Cocoa and Cocoa related training for a long, long time.

Finally, there are some excellent books out there for Cocoa development. Aaron Hillegas’ “Cocoa Programming for Mac OS X” is available now and does a wonderful job of teaching the developer how to write real world Cocoa apps in an effective manner. On the horizon, Simson Garfinkel and Mike Mahoney have rewritten what was the definitive how to program NeXTSTEP book in the early 90s. The new version is title “Building Cocoa Applications : A Step by Step Guide” is quite excellent.

Of the two, I would actually recommend picking up both. I had the opportunity to act as technical editor on both books and, as such, had a close look at the content. They are really two very different books; the Hillegas book tends to focus on higher level APIs and architectures while the Garfinkel/Mahoney book is oriented more to building a complete application that exercises everything from the unix command line through to high level features. The two books complement each other extremely well.

For WebObjects:


Combining the last software updater update of WO 5.1 with the recent update of the JDK, Apple now ships relatively complete reference documentation with WebObjects. It is hard to find because– unlike Cocoa, Carbon and the Core– there isn’t an index into the documentation available from within PBX (that I have discovered).

I have found three quite workable solutions:

– configure JavaBrowser correctly and it will display javadoc style docs inline as it does the classes. Out of the box, JavaBrowser is nearly useless. I wrote a shell script that will rewrite all of the path preferences for JavaBrowser such that the next time JB is launched it’ll basically have every class and piece of documentation either shipped with the system or installed in the standard extensions directory. The second link leads to a page that describes the script and provides a link for downloads.

– LaunchBar (can be had via the third URL). With LaunchBar installed and correctly configured, I can type (cmd)-(space)WOTF(cr) and LaunchBar will open the WOTextField.html documentation. Very useful.

– If you happen to have a decent Internet connection, searching the documentation is as easy as plugging the class name into the field at the top right of the fourth URL’s page. If someone were motivated, it would be trivial to rip out that form such that you had a minimal version of it on the local hard drive, thus saving the initial round trip to load a page where 95% of the content has nothing to do with the desired search.

Of course, all of this has pertinence to Cocoa development to varying degrees.

The OmniGroup hosts the quintessential development mailing lists related to WebObjects. webobjects-dev and the eof developers mailing list are likely the two most relevant lists. Apple has an announce list, but that’s it. There is also a ‘WebObjects-newbies’ list hosted at yahoo– as its name implies, the questions tend to be more novice in nature.

For Carbon / Core:

Basically, Carbon/Core documentation can be found from the same general locations as the WebObjects and Cocoa documentations and resources. The one big difference with Carbon/Core is that the header files often provide a lot of additional information about the APIs that haven’t made it into the documentation. Unfortunate but, as mentioned earlier, the APIs are still somewhat in flux which greatly impedes the creation of documentation.

The Core differs from Cocoa/WebObjects in that the source for parts of the Core is available within the Darwin CVS repository. Follow the instructions at the first URL to obtain the source.

2) Now, I admit that I am not a strong C programmer, but I can certainly get by. I have started to work with Cocoa and found that in general, it seems really nice and stable. What I find annoying is that there is no documentation on the very few frameworks that currently exist for Cocoa. I have been scraping help off of a few web pages here and there, but I certainly don’t have enough information to build a full application. I have searched Apple’s web site and tried to go through their sample code, but have found few Cocoa samples that did me any good.


(Assuming you did find all the docs mentioned above along with the concepts guides, etc…)

It sounds like you might be looking for something that isn’t there. When learning Cocoa, developers with a lot of deep experience using any of the myriad of APIs available for application construction are actually at a disadvantage until the epiphany happens.

In particular, +the Cocoa Epiphany+ is the moment when the developer realizes that, yes, in fact, the Cocoa frameworks really will do all the work for you.

One key difference with Cocoa development over a lot of other GUI toolkits is that the developer’s code is written in a more passive context.

In Carbon (more old style than new, but the new style stuff is still really hairy to set up), you typically have to write your own event loop and take care of all of the event dispatching within that loop– even for functionality (such as the functionality associated with a Quit or Hide menu item).

With Cocoa, the only event handling code you ever write is for features that deviate from ‘standard application behavior’. Have a look at the TextEdit source for a decent (though there is some cruft that could go away) example of this; fonts, rulers, cut/copy/paste, text selection, text editing, multiple document management, save as/to, revert, printing, hiding, services, spelling, speech, open recent, a basic about panel, handling of graphics in editable text, etc. are all given to you by the AppKit. There is very little custom code in TE and what is there is basically only the code necessary to make the AppKit behave like a text editor.

Another key to success: Don’t pick a fight with the APIs. It is generally unnecessary and you will lose. If something seems like it is a whole heck of a lot harder than it “should” be, it is extremely likely that you are attempting to make the APIs behave in a fashion that is not natural to their architecture. Step back, read some docs, do some googleresearch, and re-approach the problem. A large part of the time, you’ll discover that there is a much better way to solve the problem at hand without writing tons and tons and tons of code.

3) Is Carbon a permanent or temporary technology? I ask because while I want to develop applications for the Mac, I do not want to use Carbon if time is not on my side in the long run. In addition, the majority of the sample code on Apple’s site is still built in CodeWarrior! I have been working with and learning how to use Project Builder and Interface Builder from every bit of documentation I find! Why are code samples still being distributed in CW?

Rephrase the question: How long until all of the software that sells mac systems– Office, PhotShop, Illustrator, etc.etc.etc.– no longer has any dependencies or ties to Carbon?

Until that happens, Carbon is here to stay.

Most of the examples on Apple’s site are still in CodeWarrior because even porting them straight to PBX requires more work than is warranted. Most of the sample code presented as CW projects would need to be rewritten to properly exemplify whatever APIs they are supposed to demonstrate.

This is another case where the samples will improve in quality over time as the APIs stop moving sideways and start moving forward.

In any case, there is a lot of very useful functionality in Carbon and Core. It is easily accessed from Cocoa. Almost all of the recent ‘train hacks’ (I write little apps on the commute to/from the office) have a handful of calls into Carbon/Core to take advantage of APIs that don’t yet have an ObjC wrapper.

Which brings us to the next point….

4) How long will it be before we actually see Cocoa frameworks for the applications like QuickTime? I have a client right now that wants some software developed to process video and due to the lack of documentation and support that I have been able to find, I had to refer back to the PC. Nobody hates doing this any more than me, but I didn’t really feel that i had an out.


QuickTime is a cross platform API/implementation and, as such, it needs to have an API that is easily integrated into many different development platforms. An ANSI-C compliant procedural API is about as cross-platform as you can get.

However, don’t let this stop you from using QuickTime in Cocoa applications. Cocoa provides an NSMovieView and NSMovie class. These classes are simple wrappers around the display of a QT movie and a QT movie itself. The NSMovie object implements the method -QTMovie that returns an opaque pointer to the QuickTime movie encapsulated within the object. With this pointer, you can manipulate the movie’s contents via the standard QuickTime framework’s API.

Again, this is a case of APIs that are still shifting a bit impeding certain other solutions from coming to fruition. As well, wrapping a complex, general purpose, procedural API with a set of ObjC classes that intelligently provide access to that functionality in a general purpose fashion is actually very hard.

Even once done, maintaining the OO wrappers can be costly in that the wrappers have to be modified to track any changes made in the underlying procedural APIs. Certainly, this is also an issue when you have built your own specific purpose wrapper, but to a much lesser degree in that your specific case solution doesn’t exercise the entire underlying API and is not trying to express all functionality possible.

However, it is trivial to hide the procedural calls behind opaque data types and a decent set of classes to wrap the APIs in the fashion you need.

It is likely that Apple will make an ObjC accessible version of the QT APIs available someday. Until that happens, don’t let the lack of it stop you from using Cocoa / OS X!

Again, I do understand that migrating to a new technology like OSX can be frustrating. I would love nothing more than to literally throw my Windoze boxes out the window, but until I can successfully develop a useable application on the Mac, I am stuck with it.

That’s the key; Apple is still migrating to OS X. There are still chunks of API and functionality that need to moved across. Even with the rock solid (I haven’t had a machine crash in months), totally kick butt, 10.1 release we have in our hands now, it is– by no means– a complete migration!

WWDC should be very interesting this year as I believe we are going to see huge strides on the migration front. Overall, the OS “feels” like most of the core issues– stability, performance, etc– have been addressed to the point where Apple is focusing a lot of effort on new development.

Keep in mind, as well, that Apple has “bet the farm” on Cocoa (and WebObjects)! iPhoto is a Cocoa-only application; it doesn’t even run on OS 9. As well, most of the applications that ship with the operating system are written primarily against Cocoa with the few odd calls into Carbon/Core/Hidden APIs. The one notable exception is the Finder. Unfortunate in that the Finder still has some fairly serious usability issues about it.

If anyone has any ideas or suggestions for me, I would love to hear them and
am very excited about being a new member of the Mac community!

Hopefully there’ll be one or two nuggets above that you haven’t stumbled across elsewhere…


Wake up. Breathe….
…. keep breathing.

Paul Boutin writes: I see this slow surfing every time I fire up the aging Windows laptop with just 64 megs of RAM that I need to use now and then to do some work with my Lycos job. This old machine can load pages faster than my newer PowerBook running OS X 10.1.4 on 192 megs of RAM (Yeah, I know my RAM is still too low to get the most out of OS X…). But with OS X’s true multitasking capabilities and my work style – I flip between applications and tasks frequently – the slower browsing speed is not a deal breaker.

Gee, that’s funny, on all of the machines I use– from G3 iMacs through to my powerbook G4, I don’t suffer from this problem. I use LaunchBar to switch between apps and, as such, my hands area already on the keyboard and ready to go and the delay between app switching takes about the same time it takes for my brain to focus on the various windowsthat just popped forward.

First– get more memory. Memory is cheap, even with the recent price increased. 512MB is my minimum. Not because OS X, in itself, is a memory hog (though the graphics layer certainly is), but because the operating system will take advantage of every last byte of available memory to buffer access to the disk.

Virtual memory is great, but only hitting the disk once to bring in a hunk of data is far, far superior.

On a powerbook, this is especially crucial as portable hard drives are slow, Slow, SLOW! Any virtual memory activity on a powerbook is guaranteed to be noticeable simply because the drives are slow.

(I would suspect sticking a bunch of memory in your ‘book will also increase battery life by decreasing page swaps… but I haven’t remotely qualified this at all.)

I also try to avoid slow applications. I find that a lot of the carbonized applications out there are not very well engineered. The same can be said for Cocoa apps, but the very nature of Cocoa means that the core still plays well with the rest of the operating system.

Instead of IE, use OmniWeb 4.1b4. It is faster than IE by leaps and bounds. It doesn’t pause very often, either– something that drives me batty with IE.

Chimera– though very alpha– is blazingly fast, as well.

Obviously, it isn’t OS X that makes browsing slow. It is a combination of bad engineering or good engineering for a completely different system [OS 9] that has been ported, but not fully optimized, for OS X. iCab, Opera, and Mozilla all suffer from this– they are all nice browsers and each has their attractive strenghts, but they all feel like they have not been optimized properly.

I have also found that some applications– all Carbon so far– have a nasty habit of consuming a bunch of CPU when doing basically nothing. Microsoft Word will “idle” at 50% CPU utilization unless you turn off live word count, for example.

Certainly, there is a great need for optimization throughout OS X. Given the history of the operating system from the NeXT day, it very much appears that history is repeating itself. Every release of the NeXT operating system very much followed the ‘Make It Work, Make It Right, Make It Fast’ philosophy of software development.

It seems that some of the third party developers are stopping the Carbon parts in between Right and Fast. It works Right, but it isn’t Fast because the code still assumes an OS 9 – like operating environment.