[FR] [IT]
  [INFO] [ACQUIRE] [MAP] [RESOURCES]


CARBON CORNER

What is this Carbon thing anyway?
[Or, A Few Pips from the History of Apple]

If I started this logically by describing in detail Apple’s trials, tentatives and tribulations to build a replacement for the Mac OS -- or System as we had called it ever since the first day back in 1983 when someone first switched on a Mac, and it smiled ‘Welcome’ -- I could probably write 5 episodes before we got near Carbon. And even then I’d have to simplify things a little... so I’ll go very quickly; fasten your seat belts.

First an aside: There is also the important and not negligible question of, Why change?... I mean most Mac owners were happy with a System that they knew, mastered, and that did most everything they told it to do. Well, to an extent, that depends... each successive System release performed voodoo to get everything working smoothly and have the rabbits popping out of the hats in the right places at the right time. As software engineers say, the OS was getting ‘crusty’. Overlapping hacks began -- occasionally -- to come apart at the seams. Serious doubts circulated about how long Apple could keep slipping in new features without the whole house of cards tumbling down at the first puff of wind. Especially when the wind blew down from Redmond. There were also other issues, the Mac’s cooperative multitasking was seen as bad, and its memory protection could sometimes be a joke when a rogue app brought down application after application like a victory sprint at a domino fest. But hey, we’d lived with all this for years, hadn’t we? It was part of the Mac experience, no?

Apple had decided that they wanted to offer a ‘modern OS’. Most people agreed that such a beast included industrial-strength protected memory. Also on in the cards was preemptive multitasking, necessary to stop an impolite application from hogging all the processor power. And all this must be a solid but flexible base on which to build the future. As we all know, before buying up NeXT they dallied with the likes of [they sure have some strange code names at Apple] Pink, Copland, Taligent... sinking lots of sweet green dollars into ventures that were abandoned one after the other. As to why they finally decided to go shopping and buy-in an OS -- and why they preferred NeXT over Be -- only Gil Amelio knows.

So having acquired NeXT they found in the delivery truck not only the OS, but all the tools, the staff and the other assets and a beaming Steve Jobs.

The new guys and gals settled in and started getting to work to port the NeXTSTEP code to the PPC. Not forgetting to stick a Mac ‘Picasso’ face on the front end either. Mac OS X, although it wasn’t called that at the time, was born.

As the road to Mac OS X got clearer, the question of how to bring existing applications to this new environment started to raise its head. While different compilers had existed for creating NeXTSTEP applications, the blessed path was Interface Builder, a framework-come-RAD-tool on steroids, built around an elegant competitor to C++ called Objective-C. While Objective C -- Smalltalk extensions to ANSI C is the best quick summing up -- was conceived and developed by one Brad J.Cox, NeXT had acquired the rights to the language, so it arrived at Apple with the rest of the NeXT assets.

It was decided to port all this as it was so ‘cool’ and ‘modern’. Combined with the fact that Steve Jobs had decided on all this at NeXT and determined that it was ‘the right way of doing things’. He wasn’t going to turn round now and say: Forget it, I was wrong. Well, not in this universe.

The code name for the object-orientated environment was the Yellow Box, but it got christened Cocoa at some point [perhaps because Cocoa is a sweeter beverage than Java...]. The privileged languages for this environment are Objective-C and Java -- this language having borrowed its Object Model from Objective C.

The ported code started to run. Builds were distributed to developers. This began to start looking real.

Then, one day, Apple announced that, in order to run on OS X, all programmers need only rewrite their applications in Objective-C. “Not bloody likely!” was probably the only printable reaction that they got.

After furious discussion, and most likely the prospect of a shiny new OS with only two or three applications ported from NeXTSTEP to run on it, Apple decided that it would probably be an insanely great idea -- after all -- to provide an easier path for existing Mac apps to get ready for the big day.

Legacy apps were already being taken care of. Apple’s engineers were at the same time busily creating a special environment code-named the Blue Box [and now known as Classic]. This is where most well-behaved applications written for the old System would run, but without the advantages of Mac OS X [that is, they could still hog processor time, and crash other apps, but only within that part of the Mac that they controlled... Classic].

Now, Apple’s engineers aren’t dumb. And they have experience in emulating one environment in another, think of the path to PPC from 68K code. But this had been a port to new, faster, optimized code on the new processors. Care even had to be taken to emulate the same quirks and bugs on the new machines as so many existing applications had code that took these into account. Mac OS X doesn’t pretend to be an old Mac, and there’s Classic for that anyway. What was needed was a way to bring the Mac Toolbox -- the large set of fundamental routines that Mac programmers use in their applications, and that make the Mac a Mac -- into Mac OS X as native citizens on an equal footing with Cocoa.

Which is how we got Carbon.

Carbon -- the name was chosen as being the basic building block of life, no less -- first appeared as part of the Appearance Manager. This, in turn, was an attempt to bring Themes -- user-changeable aspects of the User Interface -- from the never-made-it-out-of-the-sandpit Copland to the Mac OS. In order to do this, parts of the Toolbox had to be rewritten. Interface items were spread across a series of Managers: the Control Manager, the List Manager, the Window Manager, the Menu Manager...

Along the way these Themes [Gizmo, Techno, etc.] were also abandoned or, more exactly, reduced to a set of inoffensive variations of the Platinum Interface [supposedly when Steve Jobs, back at the helm, was given a demo of Kaleidoscope and saw some of the raw hell that users could bring forth when setting themselves to Interface design. The demo, incidentally, was supposed to have been set up by the Interface group to show how ‘cool’ Themes could be!].

Whatever, the Appearance Manager had arrived and, having no legacy applications to maintain, was the first occasion Apple had to replace old Toolbox calls with new ones. It was thus an ideal candidate as the foundation for porting to Mac OS X.

Now we have Mac OS X publicly available and running on our machines. And on them, the System sees a Cocoa app and a Carbon app as different processes running in the same protected environment. As such they get all the benefits, including protected memory, if another app runs amok. Because of the NeXT connection, and also because playing with Objects gives you added geek points, there are some folks who see Cocoa as being ‘the only true environment for Mac OS X’. As an anecdote, according to Apple, parts of the Cocoa Toolbox are just wrappers to functions in the Carbon Toolbox. So anyone who says that Cocoa is the privileged environment for Mac OS X is suffering from prolonged exposure to a Reality Distortion Field®.

While I will admit there is some nice stuff built for Cocoa, this is probably due to the expertise of the NeXT programmers. Because here you principally find applications that have been ported from there. You will find a few new applications when programmers have decided to tryout these tools.

The road to Carbon was the old Mac OS and the Appearance Manager. So over here you will see the apps that you have known, loved [or perhaps hated, in the case of MS Office... :-)] and used over the years on your Mac. And to keep a level playing field, Apple provides calls in Carbon that allow programmers access to the Interface Builder files [‘.nib’, for Next Interface Builder].

Because of the separate origins of Carbon and Cocoa, and time considerations in pulling all this together, there exist minor differences in the feature set of each. Apple has promised that in time everything in one environment will be made available in the other. Until then, drawer windows -- those rounded-corner ones that slide out the side of a parent window -- are not available to Carbon apps...

A developer who has come from the old Mac System will tend to use Carbon to bring a project to X. By following the Cocoa path there are no advantages to be gained; you must learn a new language, a new IDE and throw away the code base. All of which seem to be more disadvantages than advantages...

FutureBASIC currently provides you with two roads to Mac OS X and both of these are through Carbon. FutureBasic applications are no more and no less Mac OS X applications than Office, iPhoto or Photoshop.

Carbon presents another advantage: not everyone wants or feels the need to move on to Mac OS X. Using Carbon, your applications will run natively under Mac OS X, but they will also run as good citizens on Mac OS 9, and if CarbonLib is installed they will also work on Systems as far back as 8.6, with a few minor exceptions. So your users really get the best of all worlds.



the gnome
2002/02/26

[return to top]

So What Does Carbon Change For FutureBasic Programmers?

Well, not much. But that ‘not much’ can keep you occupied a little while...

Let’s look at three situations:


  • Legacy applications

    Applications that you have made with a previous version of FutureBASIC will run in the Classic compatibility box. There may be minor issues, but in 99% of cases everything will work fine.

    What will not function in Classic under X?

    Classic does its best to fool your application into thinking that it is running on an ordinary Mac under Mac OS 9. Mostly it just works. There are occasional screen redraw issues as the Classic apps do get pushed to the screen through the new Quartz display engine. You will probably also find that an app runs a mite more slowly in Classic under X than on a comparable machine running only Mac OS 9. A few extensions and control panels will no longer work. And you may find that the Dock obscures parts of your windows in an irritating manner from time to time.

    All these changes are no worse than the usual gremlins that appear with any new System release. And on a personal note, I still have some applications dating back to my 128K Mac in 1984 that run with no problems whatsoever in Classic under Mac OS X!


  • Legacy applications that you want to bring to Mac OS X

    In this case your application has been written in the Standard Runtime, or in PG. Good News! Both of these have been rewritten to generate Carbon code. In the easiest scenario this just means a recompile and voilš, you’re up and running in Mac OS X.

    Andy Gariepy, aided and abetted by some of the more nimble-fingered members of the beta team -- we have the names! -- has done a masterful job of porting the Standard Runtime to generate Carbon Code transparently. He even emulates certain calls that Apple has abandoned in Carbon without any need for a change on your part! This Carbonization process has also taken a side swipe at some obscure bugs and ‘critical situation’ errors [the sort that only rear their little green heads on the second Thursday in a month, or when you don’t follow the rules exactly like so]. Very few calls could not be revived in this manner.

    Alain Pastor of the euro.futurebasic network has prepared a detailed document on moving to Carbon with the Standard Runtime and you can access that by following this link.

    There are two points that he doesn’t make in his document [or at least, that he hadn’t when I proofread it]:

    • In Mac OS X you no longer set the memory requirements for your application. This is now allocated dynamically by the System as your app needs it. This will make detecting a memory leak more difficult as you won’t know there is a problem until your app eats up so much memory that continual paging [the swapping of memory from RAM to disk; this is Virtual Memory under Mac OS X and is always there as part of its Unix heritage] slows your machine to a halt. So it will be wise to undertake some debugging of Carbon apps in Mac OS 9.

    • There is another factor that you will need take into account here, the hardest one of all for a programmer: applications in Mac OS X, using the new Aqua interface, don’t look like the apps you are used to. It is almost certain that you will need to redesign your user interface. The good news here is that there are plenty of new widgets to use!


  • Programming for X

    You want to start a new project, or carry out a major rewrite of an existing product; in this case your best bet is to head for the new Appearance Runtime.

    Here is some advice. Be warned, this short list cannot cover everything and yours may be a special case, but in any case nothing here will do you any harm!

    First steps:

    1 :: Read through the FutureBASIC docs
    I don’t believe anyone but a mutant will retain all the changes but this should give you an overview and help you remember where specific points are when you need to come back to them. [Tip: One secret method for ferreting out new keywords in the manual is to search the electronic document for "Release 6."]

    2 :: Get in some practice on the new Appearance Runtime
    Take example files, get them running, twiddle them, add functions, remove others. As you will see it is the same FutureBASIC code you know with a whole team of new keywords. It’ll probably take you some time to get used to them...

    3 :: Find yourself a small framework where you can try out new widgets
    I have one up and running; it doesn’t do much yet but at least I know that I can add in code and the problems - if any - are in the additions not in the framework, this is a really useful test bed for new features and functions.

    4 :: Read through as many Aqua and Carbon docs as possible
    Again, you can’t possibly remember it all but it will create a mental mind map allowing you to see the possibilities, giving you ideas of where to look further and so on. I’ll be including a list of URLs at the end.

    So far, all of this hasn’t helped your project but it should get you familiar with Appearance/Carbon/Aqua, and it should prove useful for anyone trying out this path.

    If you want to start a new project you must be tearing at the leash by now: So go ahead, use your framework and start adding features until you start getting close to where you want to be.

    If you are porting to the Appearance Runtime, read on.

    1 :: Start off by making a secure backup of your code. It’s amazing the number of people who forget this step. If something goes seriously wrong at some point you will need to come back to this. And make a regular backup each time you successfully add a new feature.

    2 :: Most applications collect data either from the user [a paint application, a word processor, an accounting app...] or from an outside source [a web browser...], or sometimes both [collecting and displaying weather data for a zone chosen by the user...]. The organization of the data in your application is the business of the back end. The display of this data and the interaction with your user is the front end’s affair. It is wise to have these two parts separated. [If you created your app using PG then they already are, Staz was surprisingly prescient with this!]

    You will find in most cases that the changes that the Appearance Runtime and Aqua bring about are at the front end, in collecting the information from your user and in preparing information for display. The back end will not change fundamentally.

    3 :: One of the most important things with Carbon is not to create or move a widget during an update event. Under Carbon everything that is displayed is first buffered, and then zapped to the screen during an update event. This is how Quartz does things like putting the shadows on windows and the translucency on menus when they appear in front of your windows. If you draw a control, for example, during an update event you risk going into an infinite loop! So verify that you have clearly separated all code that does the behind-the-scenes work from the interface code. Staz has been warning us about this for years, but the Standard Runtime did such a great job of hiding the consequences of our actions from us that we keep forgetting...

    4 :: Make a list of all your windows and dialog boxes. Take a block of checked graph paper and redraw them all as they should appear under Aqua/Appearance/Carbon. New widgets will allow you to present things differently. You’d be surprised at the possibilities you now have; previously you had to fluff it, or needed to create your own CDEFs. But beware, Aqua widgets take up far more space than you are used to, your windows will either need to be bigger, or to contain fewer elements.

    If you have a large application, you will find that you can probably break windows down into families bearing common traits. It is best to work on a representative member of each family and get each working. Then all you have to do is copy and adapt these for the other windows in the same family. Use your framework to make dummies of the windows and test them. When they display and react correctly, save the code in a safe place.

    5 :: By this time you should have a working alpha version of your port to Appearance. Time to connect in the back end and all the other features... You will be surprised at how much easier everything is with the Appearance Runtime: you now have ‘canned’ functions for details like reading and writing preference files, scanning folders, even integrating the new Carbon Clipboard is largely a matter of cut and paste. In the past this sort of work could take considerable time to integrate and debug.

    We will also be putting together Workshops on Carbon programming with the Appearance Runtime, and a mess of new documents. We also count on running Q&A sessions, so send in your questions.

    URLS:


  • [return to top]

    The opinions expressed and the advice offered in the documents in the Carbon section are those of the authors and do not engage STAZ Software. Especially when written with stubby gnome fingers.
    All trademarks mentioned are the property of the respective owners.

    Happy Coding.

      © 2000 Pix&Mix  
      All Rights Reserved
    INFO  |  ACQUIRE  |  MAP  |  RESOURCES

      FutureBASIC is a registered trademark of Staz Software, Inc and is used with permission.