Learning to live with Mac OS X Mac OS X's Finder: love it or loathe it, the two points that unite almost everyone who has used Apple's next-generation operating system are that it's not up to scratch and that Apple's reason to write it using OS X's Carbon API is the chief reason why.
No, say so many observers, Apple should have written Finder using OS X's other API, Cocoa. But is that really the case? Certainly Carbon seems to be getting all the bad press, while Cocoa is being held up as some sort of shining beacon lighting the way to 'true' Mac OS X native apps.
Mac OS X is designed as both a desktop operating system and as a server operating system. It is a replacement for Mac OS 9, and a foundation for new technologies and new applications. This operating system has been in development, in its current form, for over 3 years, though Apple has been actively developing and promising a next generation. Mac OS X Internal Edition - (Download #1) Mac OS X Public Beta System clock must be set before May 2001. Mac OS X Cheetah 10.0 - (Download #2 - #5) 10.0?
Bollocks, says one ex-Apple software engineer of our acquaintance who has no small knowledge of the beast. 'Carbon is at the same level as Cocoa, and they are both built on the same underlying foundation. They are absolutely true peers of each other,' he says. 'One can do things that the other can do and vice versa, but there's no reason why a well written Carbon app can't be just as good as a well written Cocoa app.
'Rewriting the Finder in Cocoa is not the answer.'
Apple of my API
Carbon and Cocoa are OS X's two Application Programming Interfaces (APIs). Both are frameworks around which coders can weave applications and utilities that are able to take full advantage of the new operating system. Cocoa's origins lie in NeXT's NeXTSTEP operating system, later reborn as a cross-platform programming framework called OpenStep. It's an object-oriented framework programmed in Objective C or, since Apple bought NeXT, Java.
With almost all of Apple's senior software staffers ex-NeXT, it's nor surprising that Cocoa has gained a reputation as the way of producing native OS X applications.
![Park (2001) mac os catalina Park (2001) mac os catalina](https://www.versionmuseum.com/images/operating-systems/mac-os-x/mac-os-x^2018^10.14-mojave-system-preferences-maps.jpg)
Carbon, on the other hand, has often been portrayed as Cocoa's lesser sibling. Carbon was only developed because some of the biggest Mac software developers balked at being forced to rewrite their code from scratch. That's what they would have had to do under Apple's original next-gen operating system plan: rewrite their apps to work with Cocoa, then called Yellow Box, or leave them as classic Mac OS apps but have the run without any of the benefits the new, Unix-based OS brings.
No wonder, then, that Carbon has always seemed little more than a kludge to shoehorn OS 9.x code into OS X, done to allow software vendors to port their apps over quickly with just a few modifications.
Carbon ain't no kludge
That's the wrong way to look at it, says our correspondent: 'The Carbon engineers have done an amazing job. The fact that you can run the same application on both OS 9 and OS X is a really amazing thing that should be celebrated, not called a kludge.'
Digging into the details of both Carbon and Cocoa and you can soon see what he means. If you're interested, check out O'Reilly's Learning Carbon and Learning Cocoa. Written by Apple, they're not the most friendly of programming manuals (what I want is a Carbon-specific answer to Jim Heid's great but now very dated Programming Starter Kit for Macintosh) but right now they're the best there is and the certainly provide a good introduction to the two APIs.
Cocoa provides a solid development framework, particularly when supported by the developer tools Apple ships with Mac OS X. Getting your head around object-orientation isn't easy. But if you've spent some time with RealSoftware's RealBasic, which works broadly like Apple's Project Builder but operates in a much more intuitive way, you'll have a good idea how it works.
OOPs upside your head
Object orientation programming (OOP) is an approach to coding that essentially breaks applications down into self-contained modules that contain not only data but the code to manipulate that information. A Mac OS window is ultimately just data (size, position, style, content, etc.), but in a OOP world, it's an self-contained object that knows not only what it looks like (the data) but how to behave - how to close, how to hide, that kind of thing.
Actually, a lot of Mac OS apps are already built around an OOP framework, Metrowerks' PowerPlant and written using C++, like Java and Objective C another object-oriented programming language.
PowerPlant was, of course, designed for the Toolbox, the classic Mac OS' own API, adding an object-oriented layer to Toolbox's traditional, linear framework. Since PowerPlant now supports Carbon coding it's perfectly possible to do build object-oriented Carbon apps. And Carbon is essentially just a modified version of the Toolbox API, it's immediately familiar to anyone who has written Toolbox apps in C.
And, as our correspondent points out, 'Carbon is evolving'. Toolbox was developed for systems running one application at once. Multifinder and later kludges to allow multiple apps to run alongside each other aside, that's essential what Toolbox is: a one-app-at-time system.
Event horizons
OS X isn't. Based on Unix, it expects to have to support umpteen processes running in parallel, often for multiple users working on the system at the same time. That requires a very different approach to interacting with the user, one where apps don't look out for your clicks and key presses but wait for the OS to tell them what the user has done.
Carbon can work with both of these 'event models', but to get the most from it code needs to be written with the OS X event model in mind. 'The new Carbon Events API is very powerful and as applications adopt it, rather than just doing straight ports of their old apps, we'll see very nimble applications appearing,' says our correspondent.
'What you should be pushing developers to do is not to throw away their existing apps and rewrite them in Cocoa, but to get them to embrace the modern Carbon APIs. It doesn't make any financial or engineering sense to start again from the beginning when they are 90 per cent of the way there already.
'The key thing is, Carbon is designed to be a compromise on OS 9, not a compromise on OS X. It's designed for OS X first, and then things are brought back to OS 9 and made to work the best they can.'
Park (2001) Mac Os Update
Carbon and Cocoa: peer to peer
So much for Carbon being unequal to Cocoa. Actually, the reverse may be true, whatever the ex-NeXTers may think. 'I've used both, and I've found I'm much more productive writing code using Carbon and CodeWarrior rather than Cocoa and Project Builder.'
In short, if there's a problem with Finder, it's not that it's written using Carbon. No, it's that it needs tuning and optimising. And, credit to Apple, that was the company's key message at last May's Worldwide Developers Conference. Recompiling an application to support Carbon is only the first step - next comes the real work: reworking it to support OS X's design philosophy and thus making at true Carbon - and a true Mac OS X - application. ®
To be continued...
Related Links
O'Reilly's Mac books site
RealSoftware's RealBasic homepage
RealSoftware's RealBasic homepage
Earlier Episodes
Park (2001) Mac Os Download
3. Windows XP hits where Apple's Aqua misses?
2. Mac OS X crashes: Radeon not guilty
1. Mac OS X: Reg box stable - at last...
2. Mac OS X crashes: Radeon not guilty
1. Mac OS X: Reg box stable - at last...
Park (2001) Mac Os Catalina
Get ourTech Resources
Park (2001) Mac Os X
by Kyle D'Addario & Wincent Colaiuta The Best Way To Optimize Mac OS X... May 25th, 2001 Mac OS X is a wonderful operating system; it has a raft of innovative new features (like the dock), easy access to the power of Unix and all its industrial-strength serving applications (like Apache), the famous Mac ease of use, and some of the most delicious eye candy ever seen outside of a science fiction movie (hmmm... Aqua). But all is not perfect just yet. One of the biggest and most oft-voiced criticisms of the new OS is its lack of speed and responsiveness. Despite all the good things about Mac OS X many users find themselves switching back to Mac OS 9 because they are frustrated. 'Things are simply faster in 9', they say. 'I spend half of my time watching the spinning rainbow (busy) cursor,' they say. In this edition of Hot Cocoa I will talk about some ways in which I personally have overcome these frustrations. The tips I offer here won't work for everybody, although they certainly will help some. I offer them to illustrate a larger point and hopefully to encourage people to persist with Mac OS X even if they feel that it is a barrier to their productivity at first. The point is this: often the best way to optimize a system is not to install the latest software shortcut, or upgrade to the latest hardware; rather, it is the optimization of usage habits that a user can make as he or she becomes more familiar with the operating environment. This takes time. Use Mac OS X for a week and you might decide that you hate it; use it for a month and you'll find dozens of ways to work around the things that annoy you; use it for three months and you'll have forgotten what it was like to work under 9 -- you'll be working in ways that you never even thought of before, and perhaps you won't even be seeing that dreaded spinning rainbow cursor at all. So now, on with the show... I'll list the various things that I initially found frustrating about Mac OS X and then provide explanations of how I addressed the issues. Complaint: I thought this thing had preemptive multitasking! One of Mac OS X's selling points is that it has fully preemptive multitasking. This means that the machine will keep on chugging along even if one process wants to be greedy and hog the CPU. Movies will keep playing smoothly while files are decompressing; progress bars continue to update while menus are down; you can switch to other applications and work with them while other applications are launching. Why this rainbow busy cursor all the time? This is the cursor that Mac OS X displays while the front most application is busy doing something and is not ready to receive user input. Users get frustrated waiting for it to go away because it impedes their workflow. 'So much for preemptive multitasking; I seem to spend most of my time waiting!' Solution: do some multitasking yourself! Notice that even when the rainbow cursor appears that other apps continue to run smoothly under Mac OS X. Even if the Finder locks up for minutes at a time, you can mouse over the dock and note that the textual labels still pop up instantly and you can switch to other apps. Unlike under OS 9, the machine as a whole rarely locks up; it's mostly only individual apps that become unresponsive. So the solution is to take care of the multitasking yourself. If one app is busy, switch to another and do something else. Run a lot of apps at once. Keep multiple tasks in progress at any one time. This might require a bit of adjustment to your usage habits, but it will be worth it. When I was using Mac OS X a few months ago I think I spent about a quarter of all my time waiting for the busy cursor to go away. Nowadays I spend only a few seconds each day waiting for it. Complaint: The Finder is slowwwww! Many people complain about the Finder's speed: Window resizing is slow; there are a lot of busy cursors; there are delays before new windows appear, and so forth. Given that the Finder is one of the most heavily-used applications in any user's arsenal this presents a bit of a problem. Many of the Finder's problems stem from the fact that it is written using Carbon rather than Mac OS X's much more mature Cocoa API. Apple wanted to show that it could 'eat its own dog food' and code something major with Carbon; unfortunately for us, they chose one of the apps that we rely on the most. So how do we tackle the problem? Solution: Reduce your dependency on the Finder Painful but true: we have to reduce our reliance on the Finder. Learn to use all of Mac OS X's shortcuts and tricks for opening and organizing files. Use the 'Recent items' submenu in the Apple menu as much as possible, or the recent items menus offered within individual applications. Put shortcuts in the dock (you could put applications in the dock, or a folder containing shortcuts to all of your favorite items). Learn to use the command line interface (the Terminal) -- some operations are much faster in it. Make the most of docklings -- these are little apps which run in the dock and handle simple tasks like going to specific panes in the System Preferences application. Learn about third party tools, like the excellent DragThing -- some of these can be real time savers. Finally, and most obviously, take the time to set up the Finder exactly as you want it. The first few weeks (and even months) you'll be rearranging icons, resizing columns and windows, agonizingly copying files and folders, and customizing toolbars. But once this is done, using the Finder should become more and more pleasant; especially seeing as you'll have developed so many other strategies for performing tasks that you won't need the Finder much anyway. Complaint: Apps take ages to launch Under Mac OS 9 the really big applications -- Adobe Photoshop, Illustrator and the like -- took a long time to launch but pretty much everything else launched very snappily. Under Mac OS X things are different. Apps like Photoshop are Classic apps and they can take more than a minute to launch if the Classic environment is not already running. Other (non-Classic) apps still entail seemingly interminable waits at times. People pass the time counting the number of dock bounces an app takes to launch. Solution: Think 'Unix' Mac OS X runs on a Unix core and this has several implications. One is that many apps are slow to launch. I have used many Unix operating systems over the years, and although they boast amazing stability and reliability, their launch times are often disappointing. But what do they offer in return and how can we take advantage of it? Obviously, if apps take ages to launch then we shouldn't launch them often. 'Launch 'em and leave 'em,' I say. Unlike Mac OS 9, Mac OS X's modern virtual memory system should enable you to leave as many apps running at once as you please. And because each app operates in a protected memory environment there are no stability issues to be fearful about with so many apps running at the same time. If it takes a long time to launch an app, why not launch several at once? Under Mac OS 9 you could tell the Finder to open several apps and it would open then one at a time, in sequence. Mac OS X actually launches all of them concurrently, with very little speed penalty. Because Mac OS X offers a preemptively multitasked environment you can also switch to another app while you are waiting for another to finish launching. Try doing that with Adobe Illustrator under Mac OS 9... The final aspect of Unix mentality that will be beneficial to adopt is 'don't reboot.' Once your system is up and running it will happily continue on for a long, long time. There's no need to worry about the system degrading and becoming unstable the longer it runs. Get your system up and then keep it up, if you can. I have a laptop, so unfortunately I have to shutdown whenever I am moving between locations -- but for other people, leave the machine up as long as you can bear it and you'll find your productivity increases (and as for electricity, er... what can I say?) Conclusion These are just some of the strategies that I have found myself using over the last few months living with Mac OS X as my full-time OS. I don't think I would've discovered them unless I had stuck with the OS despite all of its little annoyances. Persist. Be bold -- try new things. Open your mind to new ways of working and don't cling to your old habits. Learn keyboard shortcuts. Try new software. Share your knowledge with others (a great way to start is by leaving a comment on this article). One of the most exciting things about Mac OS X is that it is only a beginning and is still a work in progress. I wrote this article because one of the shortcomings of the OS is that it is less responsive and speedy than we all hoped it would be. But thankfully for us, the future is bright: machines are getting faster, graphics cards are getting better, and Apple is working long, long days for us optimizing and improving the code of Mac OS X. Other developers too, are getting more familiar with the OS and are writing better and better code for it. If you're even mildly happy with the way Mac OS X is right now, imagine what you'll think of it this time next year... -Wincent Colaiuta You are encouraged to send Richard your comments, or to post them below. Most Recent Hot Cocoa Columns Mac OS X & Firewalls: Part One - The Basics August 17th Console Yourself: Understanding Mac OS X Logs August 3rd Making NFS Work On Mac OS X July 23rd Hot Cocoa Archives Back to The Mac Observer For More Mac News! Kyle D'Addario is the assistant editor of The Mac Observer and has logged about as much time on Mac OS X as is humanly possible. Kyle studies Computer-Mediated Communication, whatever that is, at the graduate level, and was a founding member of the original Webintosh team. Wincent Colaiuta runs Macintosh news and criticism site, wincent.org, and joined The Mac Observer team as a contributor in March 2001. He has worked with computers since 1984, and his interests in that area include Macs, PHP programming and security. |