Ladies and gentlemen, please welcome Carbon Technology Manager, David Wright. Welcome everybody. I just wanted to see how many stayed because this is the first time this hall has competition with other sessions. Alright. As you can tell, we are so ready for all of you to bring your applications to Mac OS X by carbonizing them. And this session is the kickoff for that, so I want to just bring Scott Forstall up. He's the Director of Application Frameworks in Apple Software Engineering Group. Please welcome Scott Forstal.

Is everyone ready to learn about Carbon? No, come on. Is everyone ready to learn about Carbon? Okay, a couple years ago we came up with this Carbon strategy and we were incredibly excited about it and we gave you the direction. But it was a little bit fuzzy. The strategy made sense, and you all told us that. But some of the details weren't quite there yet. We needed to fill in exactly what were the Carbon APIs. We certainly needed to fill in the implementation. And so last year, we took Carbon and we brought it into sharp focus.

And no, I did not name my daughter Carbon. As tempting as that may have been to me, it wasn't tempting to my wife. So last year we really filled out the details of Carbon. We gave you a complete Carbon spec. We gave you a lot of tools that helped with Carbonization. We gave you this thing called the Carbon Dater that you've heard about, which is an amazing thing. The tool creates custom documentation to tell you how you can Carbonize your application.

So over the last year, it's been really exciting for me and the Carbon effort to watch how many of you have started taking advantage of Carbon. It's been fabulous. Every few days, every week, I see a new Carbon application appear. But I know that some of you last year, you looked up and you said, I like Carbon. I like the direction, I like the strategy, the details make sense, but it looks a little bit fragile.

You know, it can't even hold its head up by itself, right? And so you waited a little bit. Well, over the last year, Carbon has matured a ton. And Carbon is now ready. It is not fragile anymore. And this year, it's time for all of us and all of you to dig in.

and I've been working all the time so I have to work in pictures of her so I know what she looks like. It's time for you not to worry about being dirty, getting your hands dirty, getting your face dirty. You've got to dig in. It's time to really get started with Carbon. So let's do that.

At the end of this hour of bliss, I could pull the junior high school trick of having a pop quiz, right? Telling you to close your books, put them under the desk, those frightening words. And I'd have five simple questions on this quiz. And it'd be easy because I'm going to tell you the answers right now.

So the questions would be, first of all, What are the user benefits of Carbon? So when we went and designed Carbon, we did it with the user in mind. With a laser, we looked at how can we better benefit the user? Next, what exactly is Carbon? So you've heard about the benefits. You've heard a lot about Carbon. But what exactly makes up Carbon? We want to keep the user happy.

And of course, you're all our friends. We want to keep you happy as well. So what are the developer benefits? How do you build a great Carbon application? Not how do you just build a Carbon application, but how can you go that step beyond and get a great Carbon application? And last, when should you carbonize? All right, let's dig in.

Two years ago, when we came up with the Carbon Strategy, I had this dream. And to this day, I still think this dream best illustrates the user benefits of Carbon. So I've been thinking a lot about this dream recently, and I had it again. A little updated version.

So sit back and psychoanalyze me as I tell you my Carbon dream, or my Mac OS X dream. So here's how the dream goes. Apple is throwing this huge party. It's the Mac OS X party. And outside this part is a big sign. And it says, Mac OS X, all of your apps are invited.

An app started arriving at this party. Now, the first group to come are these Cocoa folks. Because the Cocoa folks, they're pretty hip to the whole Mac OS X idea. They're old friends with Mach. They came into the party, and they said they came in through the 20th floor. And they're a dynamic bunch. They're walking around the party. They're enjoying themselves. They're throwing messages at each other. And they're having a good time.

The second group that came was a little strange. It was this big cluster, like a rugby scrum. And they're all like attached to the hip and they walked in together and they couldn't separate from each other. And it was a bunch of old friends in there. I mean, we recognized everyone.

It was all these old friends. But, you know, they're sitting there partying and they're drinking and they're having fun. And, God, one guy in the middle, he drinks way too much. Boom! Falls in his face. And the entire group, boom! Falls in their face. Turns out, I just looked at that and I said, you know, that's classic.

And that's what that was. That's the classic apps. They're all these old friends and they're invited to the party. But even at the Mac OS X party, they're no more stable, they're no more independent than they were before. They're all, they're stuck together at the hips. The next group that came in, they came running in, they came running up to the door and they ran in and they said, hey, I'm Java. And this guy said, hey, I'm Java too. Hey, I'm Java. Hey, I'm Java too. And they ran across the room and they ran, they grabbed a beer, you know, they claimed they were on everywhere.

And the last group to come were these real hipsters. And these were the Carbon apps. They came up and, you know, they were old friends, but they looked slightly different. They were wearing nicer clothes. Their posture was a little bit better. They all talked about this little surgery they'd had a little while ago.

They've been separated from that other group. They were still friends with those guys, but they were separated and they were individuals and they weren't tied to others. And in fact, there were some real cows in this group, cash cows. And these cash cows, they looked as healthy as possible.

So that's what we're doing with Mac OS X. We're throwing a party. And it's the Mac OS X party. And all of your apps are invited. But if you have a classic app, you really want to make it an individual and break it off and make it into a Carbon app. All right, done with psychoanalysis. What does this mean? When we looked at building Carbon in Mac OS X, there were three main user benefits that we were shooting for.

First, stability. We'd like a more stable platform with more stable applications. Next, performance and responsiveness. So we want the whole system to perform incredibly well. We want it to be fast. We want applications to respond to you. And third, we really want to improve user experience. So let's start with stability.

Stability comes in the form of protected memory. On Mac OS 9, there's a single address space. And all of your applications run within this single address space. The weird thing is you sort of run on the honor system for Mac OS 9, right? You promise you're not going to write over other applications' memory. Turns out most apps are honorable. Some in the back aren't.

And when those aren't honorable, those are the ones that drink too much, aren't responsible, they fall down, pull the entire system down. Now we want those apps to still run on X, and so what we've done is we've slid Darwin in underneath the Mac OS system, and then those apps run in the classic environment. But they still run within a single address space for all of those applications.

Next we have Carbon applications, Java and Cocoa. All of these get their own address space. So each Carbon application, Carbon applications are the party, they're not affected by each other, they live as individuals and aren't affected with the memory space of other applications. So let's go ahead and demo this for you.

This morning, Steve in his keynote showed a BOM app. Can we bring this machine up? In his BOM app, it was a Carbon BOM app, and this is an equal application. And this BOM app, its whole goal is to write all over memory and take down other applications. So he did it as a Carbon application, and when that Carbon application ran, it just crashed itself.

What we've done here is we have a classic BOM app. So that BOM app is running in the classic environment, and when it runs, it's going to try to write all over memory. Of course, it's allowed to do that. This is the drunk of the party. And he's going to take down other applications. Now what you can see is on the left-hand side, we have a couple applications, QuickTime and Text Editor or something. And they're running as Carbon applications, as modern applications. On the other side, we have two apps that are classic applications. Go ahead and light the BOM.

All the classic apps go away. The Carbon apps, Cocoa apps, Java apps are still running. The question is, where do you want to run your browser? Where do you want to run your fetch? Where do you want to run your applications? You want to run them on the side that's not going to go away. Thanks, Dave.

So the next thing we looked at is improving the performance and responsiveness of the system. So there's a bunch of ways of doing that. The main thing we get is with preemptive scheduling. So what does that mean? The OS on Mac OS X will preemptively schedule different tasks, which means it'll actually choose to give a little bit of time to one app, a little bit of time to another, a little bit of time to another, and it'll be fair about this. This isn't like Lord of the Flies where you have to have the conch to speak and you have to give it up to let someone else speak.

The OS steals the conch and gives it to the next person. So it allows things to preemptively schedule against each other. What that means is if one task is taking a ton of CPU and it's just trying to hog it, it doesn't matter. The OS will still give other tasks some time, so the user interface will be more live. One application can't stop another application's UI from responding.

Now it turns out this also improves stability. Why is that? Well if you get a ill-behaved application, which just starts spinning and spinning and spinning, On Mac OS 9 right now, that could hang the whole system, right? The system feels like it's hung because that application isn't giving up time to anything else. On Mac OS X, the OS will still time slice between it and other applications. So other applications will still get time to do stuff.

We also with Carbon wanted to make the entire system PowerPC native. So we took anything that was 68K, we rewrote it, and everything now is PowerPC native. So last, we really wanted to improve the user experience. We really wanted to rededicate ourselves to creating a world-class user experience.

And I'm not just saying-- I'm saying user experience because we care about the user interface, right? We care about the elegance and the cleanliness and the imagery, but we also care about the behaviors. What does it feel like to use this whole system? So the first thing we did is we improved stability and performance. If your system stays up longer, if your applications don't crash, then you have a better user experience. We could have stopped there.

Next, we got rid of fixed size heaps. So virtual memory is always on. Now what does that mean? You know this panel? Who loves this panel? Okay, who wants this panel to die? Alright. Dead. You never again have to explain to someone in your user documentation Go to the app, not the link, go to the application, do get info on it, go to the memory part of that, and then set a number which makes sense. What makes sense for a user on how much memory they should use? They have, say, 64 meg of RAM. They want to use 64 meg of RAM. They have a gig, which is all you guys I know. You want to use a gig.

This hit home for me this weekend when I was working on this presentation. I kept on getting this panel over and over. PowerPoint was telling me there's not enough memory. There's not enough memory. And so I'd increase the partition. And then it would work fine for a while. And then I'd add some images of my daughter. And then suddenly it was telling me there's not enough memory again. Again. Gone. So the last way we want to improve the user experience is, of course, with Aqua. So let's talk through that.

When the Mac was born years ago-- and no, I didn't name my daughter Mac either. It was an incredibly fresh face, right? The user experience, the user interface was great, and everyone really liked it. And as the Mac has aged, it's remained a great user interface, but we looked at it recently and we said, "As good as the user interface is, it's extremely hip still, but it's slightly dated maybe." You know, hip, but dated. Now don't get me wrong, it's still light years ahead of the competition.

So we thought we could do better. And I believe with Aqua, we really have. The amount of polish and attention to detail and elegance in Aqua is extreme. Now, as I said before, you can still run your classic apps on top of Mac OS X. But your classic apps do not get the Aqua interface.

So they're going to look slightly old. They'll play within the same system, but they're going to have the Platinum controls. So your users will know whether or not you've gone to the work to give them a stable, polished Aqua app, or you're just relying on the classic experience.

Alright, so those are the user benefits that we are striving for. Now what exactly is Carbon? So when we looked at the Mac OS, there's a whole set of APIs, this large set that makes up, that defines the Mac OS. A lot of these APIs are great, and it's what you depend on for your applications.

And we really wanted to move those forward. Our goal isn't to force you to rewrite your entire application. In fact, our goal was quite the opposite. But some of these APIs prevent progress. So when we looked at these APIs, we said we can really split it, in marketing terms, into the good and the bad.

And the bad APIs are the ones that prevent protection. So for instance, low memory globals. Everyone writes wildly to low memory globals. You can't do that in a protected memory environment. So we had to get rid of those. Anything that prevented preemption, we had to get rid of. And any 68K specific APIs. So Trap Manager, Segment Manager, anything that was 68K specific, we had to remove as part of the bad APIs. So Carbon is the good APIs from the Mac OS.

Carbon is a living entity. Carbon is growing. Carbon is not freeze-dried at some point in time, but we're adding on to it. So for instance, we added on Aqua. So as we add APIs, Carbon over time will grow to encompass those. Carbon is our vehicle for adding those APIs.

So where does your app fit in here? Well, we've done a ton of measurements. We built all these tools. We built a lot of databases. And we ran application after application after application through here, thousands of applications. And what we found is an application is typically about 95% Carbon compliant or Carbon ready.

What that means is 95% of the APIs you're calling are fully Carbon supported. So there's no change for those. But there is a subset, 5% of the APIs, that are calling into globals, that are calling into data structures that we've hidden now. And for those, you have to do a little bit of work to move your application to be 100% Carbon compliant. And when you do that, then you'll have a full Carbon application.

We didn't go crazy here, right? We didn't change the application model. We're not telling you you have to start from scratch and rewrite your entire application. We didn't go create an object-oriented Java API set. If you want a great object-oriented Java API set, go to Cocoa. Go to Java 2. There are Java APIs on the platform.

What we wanted to do here was take all the work you've invested in the Mac OS APIs and move it forward. Let's be honest here, right? We're not automatic. So you do have to do work to get a Carbon application. You have to recompile. It's not binary compatible. If you want it to be binary compatible, run it in Classic, but you don't get the advantages of Mac OS X.

All right, so the user's happy. Now you know what Carbon is. Why are you going to be happy? So there's a bunch of developer benefits that we've added into Carbon as well. First, we want to make sure that you can truly move onto Carbon without giving up the installed base. So we want you to be able to sell into both 9 and 10.

I know that most of you are lazy. Most of you work 168 hours a week, and we'd like you to work 80. So we want to do most of the work for you. We want, when you're carbonizing an application, when you're moving an application forward, that you do the work that's specific to your application, not the system's work. We'll do all the rest.

We really wanted to design this with future enhancements in mind. Carbon is a living entity. We want to advance it. And it turns out that developing a Carbon will enhance developer productivity. Let's talk through these. So first, where do you want to run your application? So you have a Carbon application, and there's two main platforms you care about.

And here I've listed Mac OS 9 to generically mean Mac OS 8, 1, 8, 6, Mac OS 8 and 9, and then Mac OS X. So it's obvious that you'll be able to ship your Carbon application on Mac OS X because Carbon is an intrinsic piece of Mac OS X. One of the main points of Mac OS X was to provide Carbon support. So boom, your application, Mac OS X, sits right there.

Now Mac OS 9 has a lot of the APIs that are part of Carbon, but it doesn't have all of them. So what we've done is provided this thin layer, this thin veneer, which is called CarbonLib, or the Carbon Library. The Carbon Library, for most APIs, just calls directly into Mac OS 9 because the API is there. But where we've added on APIs that are part of Carbon but weren't part of Mac OS 9 or weren't part of Mac OS 8.6, those APIs are implemented in and part of the Carbon Library. So on Mac OS 9, your application runs on top of the Carbon Library.

So next is, we know you have a lot of code that's based on the Mac OS APIs. What we wanted to do with Carbon is to preserve your investment in these APIs, make it easy for you to take advantage of new features, and quickly get on Carbon. And we think we've done that. In fact, we've asked a lot of you, you know, how hard do you think it's been to carbonize, those of you who have worked on it.

And consistently I've heard that it's about the same work as moving from 68K to PowerPC. For some of you who have really well-written code, it's a lot easier, just moved right over. For those of you who have a lot of skeletons in the closet, a lot of cruft in your applications, it's a little bit harder.

So the next thing we want to do with Carbon is design it for future enhancements. So as I said, Carbon is this living and growing thing. And in the future, we'd love to do more things with it. We'd love to make it so the toolbox is reentrant, so add more threading support.

We'd also love to advance and improve features. I'm sure this hasn't happened to any of you, but I've heard before when a new version of Mac OS has come out, sometimes some people's applications are doing something they shouldn't have, and the OS breaks them. A lot of that is because our data structures are all open.

And you guys love to get in there and dig and do funny things, right? You learned that this one data structure, if you twiddle the third bit of the second field, then, you know, windows stay on top or something. Instead of allowing you to manipulate these things in sort of a random manner with these open data structures, in fact, we have to hide those data structures if we want to make something reentrant because we can't count on when you're going to touch that data structure if we can't actually put a lock around it in another thread.

So because of that, we've made most of the data structures opaque, right? So you can't get directly at the data structures. Instead, we've added accessors, so semantic accessors that'll get exactly the information you're looking for. And then actually, it turns out your code reads a lot better because instead of just changing some part of some structure, you're actually calling a function that tells you what your purpose was with the toolbox at that point. So we're really designing... We're designing this so when we come out with future versions of Mac OS X and Carbon, we can advance the back end. We can advance our implementation, and you'll get the advantage without it affecting, without it damaging your application.

So developer productivity. Who here wouldn't want to make your application easier to develop? What we found is when people come to Mac OS X and to Carbon, they're finding it easier to develop the application and a little bit faster. So why is this? Well, first, you don't crash the machine when you're debugging it.

I've worked on code before where you're debugging it and you take down the whole system. Code I inherited, not mine. And on Mac OS X, that doesn't happen, right? You just take down the application you're writing, the one you're developing. You don't take down the whole system. So the debug, find something, fix it, and then go to the next bug cycle is much faster.

It also helps you to find your bugs on X. So you know those trickiest to find bugs are the memory smashers, right? It's the random little memory smasher where you wrote off to some random place in memory and then five minutes later the system starts behaving somewhat strangely.

And you have no idea why because when you wrote into that memory space and when your system or your application or system crashed aren't immediate, right? There's no causal connection that you can see. So what we, on Mac OS X, if you write someplace random, your app crashes immediately. You get a back trace, you find out, hey, I can't write to that segment. That's outside of my memory space. You can't write to null.

And we've actually had a lot of developers who have told us that they couldn't find some bug and then they pulled it over on Carbon and within five minutes they'd found the bug. It actually turns out that when we were Carbonizing some of our toolbox code, we found some memory smashers that were on 9 that we didn't know about. So there's no more bugs in the toolbox on 9.

So that's the developer benefits. Now how do you build a great Carbon application? Our goal here is not for you just to build a Carbon application, but really to build the best one you possibly can. The reason most of you are here and can afford to attend a conference and spend time and are getting paid isn't because you built some Mac OS application, just an arbitrary Mac OS application. It's because you built a best of breed Mac OS application.

You went above and beyond and you built something so good that it's better than the competition. So when you look at Carbon, you should think about it the same way. You shouldn't shoot just to build some Carbon application, but you should figure out how can you build the best possible Carbon application you can.

So let's talk about that. I'm going to go through a hypothetical application here. So this is not a real application, but just so we can talk about the carbonization process. So I got this group of people and they had read Kafka's The Metamorphosis. And so they wrote an application called iMetamorph.

And iMetamorph takes and it morphs one image into another, the same way that in Kafka's book a man turned into a bug overnight. So here's this application, and here's an example. You take a dirty kid, and you magically clean them up. So that's our slogan for Carbon, right? We clean you up.

So this application that takes and does this processing has a lot of things it needs to deal with when going to Carbon. So what are those things? Well, first of all, This company has a whole lot of code, right? They have lots and lots of different pieces of code, and they have to determine, well, what should they carbonize, right? What should this Kafka Enterprises, this company, what should they carbonize? They have applications and nits and plug-ins and device drivers and all sorts of things.

So first they need to determine what pieces of code are candidates for carbonization. So first of all, the answer is applications. Applications are absolutely candidates for carbonization. You should carbonize your applications, foreground and background. So if you have a faceless background application, absolutely you should carbonize that as well.

You should also carbonize plug-ins. Now there's two pieces of technology on the system that can really aid in this process. There's a technology called Core Foundation and it sits pretty low in the architectural stack. And Core Foundation has something called CFBundle and CF Plug-in and both of these will aid in your carbonization process of plug-ins, so you should check those out.

Now they shouldn't carbonize device drivers. By their very nature, a device driver is an OS specific piece of code. It's dealing with the OS and how the OS deals with devices. So instead of carbonizing those, they should continue on Mac OS 9 to do the same thing they were before with Device Manager. And on Mac OS X, you should look at I/O Kit and write an I/O Kit driver, which will provide the functionality you want on X. And lastly, they shouldn't carbonize their system in nits.

So it turns out, in its work counter to the goal of increased stability. Now there are some in it which by their nature are really just faceless background applications. And so those should actually be carbonized. Those should become Carbon applications and run as faceless background, you know, servers. But they shouldn't be carbonized as, you know, something which patches the whole system.

All right. So how do you carbonize? What's the process? So it turns out it's really simple. First, since we've taken and made all these data structures opaque, You have to go to work to adopt the accessors. And this is probably the bulk of your work carbonizing your application. And the great part of it is, it's the easiest part of carbonizing. It's really a grunge work, mundane, sit in your office from 1 p.m.

when you get into work until, you know, 6 a.m. the next day for a couple days. And you just walk through compiler errors. That's all it is. Because the compiler is going to tell you if you're accessing a data structure which isn't there anymore. So the first part is go ahead and adopt all the new accessor functions.

The next thing is to use the new toolbox UPPs. So what is this? We used to have generic functions for creating UPPs for callbacks. Now we have more type safe UPPs which are created per callback that you care about. So you have to go ahead and instead of using the generic ones, use the more specific ones now.

If your application opens or saves files, you want to use Nav Services. So go ahead and adopt the Nav Services APIs. And Apple Help is now the way to provide help for your application. Okay, so you do these four simple things. That's it. Right? We're done. So I'm wasting your time here. You could have done that while I was talking.

There's two really good talks that can teach you more about how to carbonize. The first one is really transitioning your application, so what is the carbonization process. That one will go through more of the exact steps you need to take, a lot more of the process, and I encourage you to go to that one. And then, of course, the navigation services talk, which will tell you about how to use Nav Services.

But that's not it, right? You can do more. And you really do. You really want to create the best of breed Carbon application. Because I don't know about you, but when I watch some of the demos that are coming out on Carbon, I get pretty excited because I'm not writing an application in the same field they are. I mean, they're looking great.

Okay, so what should you do? Well, if you look at... If you look at this iMetamorph application I talked about, they do this big operation where they take an image and then they morph it into another image. So there's a lot of computation that goes on in that.

It takes a while. So what they were doing before is they were using Thread Manager, right? So they'd take, and when you said start morphing these images, it would take and it would throw this into a Thread Manager thread so you could continue working with the UI and changing other things.

Now it turns out that Thread Manager is cooperatively scheduled. So what that means is-- As a thread's doing work, it is a separate thread, but every once in a while it has to say, okay, I'm going to take a break, right? Coffee break now, stop, someone else goes ahead, does some work, they come back, they take a coffee break, you get to work. And you go back and forth, and only one's working at a time, but it's up to them to decide when the other thread gets time to work.

So, the problem with that is, if you're working on this application, and this other thread's doing a lot of computation, if it decides not to give you time, then your UI feels a little stale. It freezes for a little bit, it's jittery, it isn't the smooth experience that you really want to have in a Carbon application on X.

Now, by the very nature of the Thread Manager APIs, on X we can't make them preemptively scheduled because you assume, based on the semantics of the APIs, that it will be cooperatively scheduled. Now, what we've done on X is, of course, there are the multiprocessing APIs, which we have on 9 as well. The MP APIs, the multiprocessing APIs, on X are preemptively scheduled against each other. So, the OS itself will go between the threads and time slice so no one gets starved out.

So this iMetamorph application, instead of sitting on Thread Manager and doing cooperative scheduling, it should go ahead and move to the MP APIs and do preemptive scheduling. Now the way we've implemented the MP APIs is on top of Pthreads. Pthreads are the POSIX threads. And if you wanted to, you could go straight to POSIX threads and use the POSIX threads directly. The MP APIs is just a thin layer for an API you may know that uses the Pthreads. All right.

So there's a session where you can learn a lot more about the threading and also shared memory and file systems and all the lower architectural levels of Carbon. Now each year at this conference, we get feedback forms from you. And you tell us you want five full days of conference. You say, don't cheat us out.

Don't give us four and a half days. We want five days. So our schedulers this year have outdone themselves. by taking one of the more important sessions and scheduling it in this room, which I'm sure will be packed at 5:00 PM on Friday, ending at 6:30. So I expect it to be packed.

All right, the next technology you should really take advantage of is Carbon Events. So Carbon Events is a way of sending user actions and other events throughout your application. So Carbon Events does a lot of things for you. It really improves your application. The first thing it'll do is improve performance. So that said, you should go and take advantage of it, because we want to have applications running as fast as possible on Mac OS X. So the way it does this is it sends events only when they're necessary.

It means you don't have to sit there and pull constantly to see the state of something. So what does that mean? So a year ago, when my wife and I were due with this baby-- well, when my wife was due with the baby and I was doing nothing-- The grandparents started calling, and they started calling once a week. And then they started calling once a day. And they started calling multiple times a day. And they were saying, you know, how long have you been born yet? How long have you been born yet? You know, they're constantly, constantly pulling us over and over again.

And at some point I said, you know, stop calling. I promise I will, you know, send you a Carbon event. Well, I mean, not that geeky. I said, you know, I'll call you. I promise I'll call you when she's born, right? I will send you an event. I will call you. There's no reason for you to constantly pull. Pulling was not only, you know, somewhat irritating, it tied up the phone lines. The phone was busy all the time.

The same thing happens right now on Mac OS 9 when you start saying, where's the mouse? Where's the mouse? Where's the mouse? Where's the mouse? And the mouse, you know, the cursor's just sitting there, right? You know, where's the mouse? It's sitting there. It hasn't moved at all. And you're tying up the whole CPU asking a question which doesn't change each time you ask it.

So what Carbon Events does is you sit back and you say, hey, mouse, just like that, hey, mouse, tell me when you move. And so then when the mouse moves, it'll tell you it's moved to another position. You don't need to tie up the CPU. by polling and asking it where it is.

The next thing Carbon Events does is it'll simplify and reduce code in your application. So instead of you having to have a lot of code when an action comes in to figure out where it was meant for, to figure out how do you direct it somewhere, the Carbon Events themselves will figure out who the event was meant for and direct it there. So it really simplifies your application.

Carbon events also allow you to customize toolbox behaviors. So again, generic patching was too large a mechanism to do some of what it wanted to do, right? It was this huge hammer where you had to, you know, patch an entire thing just to change a minor behavior. And in some cases, it worked against our goals of stability. So what we've done with Carbon events is we've provided a nice mechanism where you can intercept events, you can change them slightly. There's a lot more specific APIs meant for you to modify behaviors instead of patching an entire subsystem.

So there's a couple talks tomorrow about this and I really encourage you to go and learn all you can about Carbon Events. Now there's a lot more talks than what I'm pointing out. I'm just pointing out some of the highlights that I think you may or should attend. The entire conference is full of great Carbon talks that you should attend.

All right. What does an application look like? How do we package an application? You've built a Carbon application. Instead of packaging how you have today, is there a way we can make it so it's better for the user? Can we make it multilingual? We of course want it to run in both Mac OS 9 and 10. And let's make it very, very simple for the user. Again, we want to encourage simplicity. So multilingual.

We've certainly found that we make a lot of money by taking exactly the software we've written and just selling it in a different language, right? Localizing it to another language and selling it. Most of the work you do is to create your application. It's not to do the language specific part. So what we want is to support multiple localizations for an application extremely well.

Of course, the way to get to there is Unicode, the standard for multi-language text. And we have several things in the system that will help with that. One is CFString, so a technology also in Core Foundation, which deals with Unicode strings. We also have the Multilingual Text Editor, so a Carbon text editor that deals with Unicode.

And we really want to support single binary multiple localizations. What this means is you can have a single application, and that application, when run, will run in the language of the user's preference. So that means when I launch an application, it'll run in English. When my boss, who gave the last talk here, runs an application, it runs in French.

So the goal is to have a single application that different people in the same office can run, and it runs in the language of their choice. So next, of course, you want your application to be able to run on Mac OS 9 and 10. We want to have a single package, which itself, one SKU, you can have one box and one SKU, and that itself will run in multiple localizations.

And last is simplicity. See, this is what iMetamorph started-- looked like when it started years and years ago, right? Real simple. Single icon in a single folder. There's no question. Where's the application? I look at it now. And it's full of so much stuff, right? There's libraries, there's help files and plug-ins and everything. And when I look at this folder, I just see a bunch of trees. You know, I can't see the forest. I can't find out where's the application I'm looking to click, the application I want to run. So that's not what we want. We want something very simple.

So we've solved all three of those problems, making something multilingual, allowing it to run on Mac OS 9 and 10, 8, 9, and 10, and making it very simple with something called application packages. So application packages is where we take an application is represented by a single item in the finder. Right? So it's that one clickable thing.

Now behind that single item is an entire folder hierarchy. So there's lots of stuff in there. There's files and data and all sorts of things. But to the user, it's a single item, right? Very, very simple. And we have technology called CFBundle which helps to retrieve this data and the resources. Now here's the way I think of CFBundle.

CFBundle is your high-end shoe salesperson. Now what does that mean? You know when you go and you're shopping for shoes, and you go into a high-end store, not someplace where you walk in and there's boxes of shoes all over the place and you have to find your own shoes. But you go into a really fancy shoe place, and you sit down, and you point out and you say, I like that shoe in that size and in this color.

and this very friendly person walks back behind this door. And you have no idea what they do behind that door, right? You don't know where they go to look. They have some structure back there where they have racks and racks of shoes maybe. They have some way of knowing where to look for the right shoe. But they go and they find that right shoe and they bring it out and they put it on your foot. So CFBundle does the same thing for you except, you know, put the resource on your foot. You ask CFBundle, I'd like this resource in this language.

And CFBundle goes back behind this folder hierarchy and it finds that resource in that language and it brings it back to you. That whole folder structure could be reorganized and you don't care because CFBundle knows how to find it. Now sometimes, you know, the shoe sales person might come back and say, "We don't have it in that color, but we have it in another color." CFBundle can do the same thing. It might come back and say, "I don't have it in French," and you can say, "I'd like it in English," and it'll go back and find it and bring it back. So CFBundle will help find all these resources for you.

All right. So application packaging really allows us to have this very simple but very powerful way of-- Compacting and putting an application together. But you know what? That's a really ugly icon. And people do judge an app a little bit by the icon. You want a really nice icon, right? It's the face of your application when it's not running. And when it is, it's the face in the dock.

So we really want to encourage you, and Carbon and Mac OS X supports and encourages you to work on your applications and build really great applications. So what you should do is use 32-bit color. Use transparency and anti-alias your icon. And also, make sure your icon looks really good from small sizes, 16 by 16, all the way up to 128 by 128. Because if the docket's really big, it's 128 by 128 per icon, and you want your icon to look great. So spend some time making great icons.

So there's a talk on Thursday to go over exactly how do you get those icons into your application. All right, Aqua. The simple adoption of Aqua is very, very simple, right? We've retained the platinum metrics, which you requested, and we said, great, we can do that. So it's really not very hard for you to adopt the basics of Aqua, but you don't want to have an application which just adopts the basics. You want to have a great Carbon application, which has a great Aqua interface.

So some behaviors, like sheets, will take a little bit more time to adopt, but you should take that step to adopt them. You should make sure that your menu layout abides by the new Carbon menu layout guidelines. And you should be ready for the windows in your applications to be intermixed with other applications.

In fact, this is a perfect time for you to really polish your application. As we come out with Aqua and Mac OS X, there's going to be a lot of emphasis by our users and by reviewers on user interface, right? We're concentrating on it. And so it's a great time for you to really do a one over on your application and make it look great.

So there's a couple talks, there's actually more, but here's two of the more important talks on Aqua that you should attend. Right after this, there will be an overview, and then on Wednesday you can learn exactly how do you implement it. Okay, so how do you build your application? How do you build your UI, right? Inside you're going to do a great Aqua interface. How do you build this? We've provided a tool called Interface Builder which will help you build this. Interface Builder is a WYSIWYG UI builder so you visually build and you visually edit your user interface.

It'll actually import your current resource manager resources, so your diddles and the like, and turn those into an XML representation which it uses. The great thing about that is XML uses Unicode, so you can actually have a tool process which will localize your application just by editing these XML text files. So this is great.

Interface Builder will help with the Aqua guidelines. So it'll help you lay out your application correctly. And it also-- has a great concept of how Carbon Events should work and really builds that right into the Interface Builder tool. So it'll help you to take advantage of Carbon Events and really speed up the process of using Carbon Events in your app. This is a great talk on Thursday. You should attend to learn about that. All right.

So you know what Carbon is, you're ready to do it, and the question is, you know, exactly when do you do it? So the iMetamorph guys They were looking at two different scenarios. The first one was, let's come out with one more version of Mac OS 9. So one more iMetamorph on Mac OS 9. Take the next three, four months to do it. And then come out with a version on Mac OS X. Then come out with the Carbon version, which of course would go on 9 and 10.

The second scenario is to say let's go straight for Mac OS X. Let's go straight for Carbon, and we're going to get Mac OS 9 for free as well. Now if you look at this, The top one certainly gets you an app sooner, but the bottom one gets you the app sooner on 10. And never underestimate the value of being somewhere first.

I think about it this way. This fraternity brother of mine back in grad school, He saw this new platform, sort of like Mac OS X. He saw this new platform, and he thought it was a great thing. And he started building some apps for this. He built this one pretty good app.

And he and a friend, they worked on this app. They started adding content to this app. And he thought it was great. At some point, he dropped out of grad school to start a little company.

So the platform, of course, is the web. And the application, the company, is Yahoo.

So by being first, it wasn't necessarily the case that Yahoo was the best, but it was the place everyone went when they went to the web to find information. The same thing will be true with Mac OS X and Carbon. If your app is first to Carbon, it'll be the app of a given genre, of a given breed, of a given type, that is the Aqua version, which is the Carbon version of that application. And that's the one people are going to be looking for. So what I'd really like to do is challenge all of you to two things.

I challenge you to be beta with us. So you saw, you know, Steve said this morning, we're going to have a beta this summer. And I challenge you to come out with a beta of your application at the same time that we come out with a beta of Mac OS X.

Because then our beta testers will be testing your beta as well, right? It's the best way to get the most people testing it as early as possible. Secondly, I challenge you to be GM with us. So when we ship our final version, you ship your final version at the same time. And then people will see that is the app, the Carbon app of that type for that application.

So on Thursday, there's a talk about Carbon on Mac OS 9 and 8. All right. So I've talked a lot about what the carbonization process was like. What I'd like to do now is bring up some third party developers, some of you, to talk about the experience you guys had with Carbon and how far you've come. So I'd like to bring up John Wallace to talk about Now Up to Date. John? Great. Thank you very much.

All right, I'm John Wallace from Power On Software, and this is Bill Parr. I think Apple brought us up here to talk about this really for a couple reasons, one of which is being a Mac software developer. I'm admittedly one of the larger Mac software developers, but from Ohio. I mean, I think if an Ohio software developer can do this, then all of you folks can.

And also because now today in contact are a pretty popular calendar and contact manager for Macintosh. They've been around for a while and they're quite a challenge for us when we first looked into it and it got easier and easier as we went along. Let's talk about the products. Now today in contact, almost three quarters of a million lines of C and Pascal code.

Let's also take a look at time frames. That's a lot of code. That's a lot of code. But what we did was we first started carbonizing our now up to date product, which we're going to show here today. And we carbonized now up to date. It first started off as being Pascal.

We went through a week of a Carbon kitchen and got it along. And I would say that by the end of two weeks, we were 90% of the way done with the carbonization process. We also realized the tools were better in C, so we converted the product from Pascal to C, about 300,000 lines of code.

So what we're going to see right now is a product that's going to be a little bit more complex. So what we're going to see right now is a product that's undergone about two plus weeks of carbonization and probably about two weeks of conversion from Pascal to C. Let's go take a look at it.

What we've got is we've got the Caliber and Contact Manager up. It's all running under Mac OS X. We're able to make use of some of the things that are going on in Mac OS X. For example, if you take a look at being able to do Aqua-style banners and so forth, not too hard for us to take advantage of all the appearance things.

We haven't yet gone through the process of actually building on all of the new buttons and the rest of the appearance, but just getting up and running took us about two weeks. So what do we learn from all this? I would have to assume that most of you are in the same boat that we were in. We didn't know what to really expect, at least I didn't. Bill, we were lucky, Bill had done about 500,000 lines of carbonization before he came to Power On software, and this product was brand new to him.

What we found was number one, there will be a couple weeks of just grunt work. You've got to go through and you've got to modernize everything. You've got to use the accessor functions rather than getting directly into a member variable off of a port like the port.portbits.bounds. You have to go through an accessor function to get through that. So that's number one.

Number two is it was a great opportunity for us to modernize our code. There are a lot of things that we didn't do because there were multiple ways to do it. Do we use Mac TCP? Not anymore. Now it's all OT. And those kind of things, because of Carbon, it kind of put us in a position where we're now modernizing and making our software really aligned more with where Apple was going. I guess the third message that we got from all this was that this is real.

Last year we had the promise of Carbon and the promise that it would be easy. It is easy. And we had the promise that it was going to be complete. It is complete. And also from everything we're seeing this week, it's the future. So I would highly recommend everyone out there, first thing you do if you want an action step when you get back from the conference, go home and carbonize. It's not that tough. Within a few weeks, your app will be up most of the way. And I think you'll be up for the future. So I'd like to say really a big thanks for Apple. because I think it's great. Thanks a lot. Thank you.

One of the funnest things of my job is every few days, as I said, I get to see brand new apps coming to Mac OS X. And over the last year, for me, living on it has just felt more and more real. So now I'd like to bring up Mike Garcia from Quark to go through QuarkXPress.

Okay, I brought a few notes because I'm not as polished a speaker as some of the other guys up here. When I first thought about what I was going to talk about up here, I thought about what would I ask? And I would ask somebody, how difficult is it to carbonize your app? And really, the answer to that question depends upon your app.

How much code do you have that is non-standard, non-recommended? As you know, Express has been around for quite a long time. We run out of one source code base for all of our different versions, one byte, two byte, Mac, Windows. And we have some non-standard things there because we were doing things on OS 7 and 8 for efficiency purposes. We were mucking with fields that we really shouldn't have been mucking with. And now we can't because of opacity. Thank you.

The next thing you need to look at when you're carbonizing are what are the specific issues for your application. For Express, we have some specific issues. We need to run Express on OS 8, so that presents somewhat of a problem because we need to support all of our old 4.0 extensions on 8.

And if we're going to support all of our old extensions, we have to support our API on 8. And if you've used our API, you know we've got a lot of working directories, we expose the QD globals. There are some things that we do there that we just cannot do with Carbon. And so we had to branch our code for 4.0 extensions versus Carbon extensions.

The basic changes aren't that difficult. Opacity, it's a lot of monkey work, grunt work. That's what we call it. It took about two months for one engineer to do opacity on Express because it's so huge. It's over two million lines of code, about 20 libraries, and that's not including extensions. So there's a lot of work for us to do with opacity. And you just, like they said, you go in in the morning and you start it and you do it.

There are some other issues that you will probably hit depending on your app. For us, some of those issues examples are working directories. We use working directories all over the place and we give them to extension developers. So we have to remove that because that's no longer valid on Carbon and that presents a problem for our interface. We were doing things with the Viz region and clipping region for efficiency purposes where we draw. We can't do that anymore. You can't just go into the window pointer, graph pointer and mess with the fields in there.

There are a few other areas where we just did stuff like that, and you can't do that anymore. That's one of the great things about OS X is it allows us to go in and clean up some stuff that we really shouldn't have been doing in the first place. Let me go ahead and show you Express running on X.

As you can see, we're using Navigation Services here. And here's a great little document. I'll show the alien that we do to delete a box. It's one of our Easter eggs. And it's gone. So there we go. And that kind of illustrates, leads us into some of the great side effects, great benefits that we get from 10.

With that piece of code there, we can, and displaying the document, we're able to turn off a lot of excess code we had to deal with double buffering. OS X does it for us now. We don't have to have this huge chunk of code that does it. Other great side effects, we've been able to re-architect pieces of code that we've wanted to do, couldn't validate it to product management, and now we have to. We can go ahead, dig in, and let's redo this The last thing I want to say really is that going over to OS X has been really fulfilling and gratifying and it's really cool stuff.

When you start seeing your app go, it's a lot of fun. The guys at Apple have been great in helping us. The engineers are very helpful. They'll do whatever you ask them to do. They'll try and implement it for you or teach you how to do it. It's been great. I suggest you all start it now because it really is fun. Thanks a lot, Mike.

All right, last I'd like to bring up Scott Thompson from Macromedia to show us Freehand. These lights are so bright. It's really great for me to be here. You have no idea the carbonization of Freehand has been somewhat of a long process. Apple actually asked us to carbonize Freehand back in 1998 for the original WWDC.

We were trying to have it in for the Thursday keynote. We missed it by about two hours. So I've actually carbonized the Freehand code base three times since then, believe it or not. I did it for eight and I did it for nine twice. So I've had a lot of experience with this. This time, luckily, I had the help of a great partner, Kent Sorenson, who's over here taking photos. Helped me out a lot.

So for us, carbonization was -- and I realize I'm going to sound a lot like a broken record because a lot of the stuff the guys do and a lot of the stuff the guys have already said is perfectly up for Freehand, as it will be for your applications as well.

But for us, carbonization was largely a matter of modernization. Steve said in his keynote that you had to go through your application and clean out all the crud. Freehand, like Quark, is one of these applications that's very big. Ours is 1.2 million lines of code. And we had lots of stuff that was left over from System 6, creating our own GWorlds by hand, those sorts of things.

Going through the carbonization process really did let us clean up. Clean out a lot of the crud and get going. We did have the big buildup at the front where we had to go through and deal with the opaque data structures. Like they've said, it's a matter of sitting down, sitting down with a compiler, working through 1,000, 2,000, 3,000 compilers, getting them all squared away. But once you've got that done, you can get a few link errors maybe here and there. And then you'll be running up on 9.

Running on 9 was a great first step. Then we started trying to play with running on 10. Running on 10, we had a few crashes. We got to find some of our write-to-nil bugs. Those are there. Those sorts of things. But once you work through a couple of small crashing bugs, we got a whole lot of functionality.

A really big part of our app started working all at once. And that was really great. Now we do have some areas that we need to work on still. The big one that I don't have done is font support. We have to update from the old resource-based font manager to the new Carbon font manager APIs. That's yet to be done. I haven't done a whole lot with printing yet.

And you might think that for freehand printing would be a big part. But I know that coming down the line, we've got this new print stuff coming along. So rather than rework what we have now, I decided to just wait, see what the new print stuff is all about, and do it that way.

Overall, I think that the analogy that says that carbonizing your application is roughly equivalent to the PowerPC transition, I really believe in that. That is actually true, and it's been my experience in the three or four times that I've done freehand on Carbon. So why don't we go ahead and see what freehand looks like running. I see up here on the screen, now I'm a little disappointed in this. You'll notice that it's showing the 32 by 32 bit icon. I actually have a 128 by 128 icon. I don't know why it's not showing up, but we'll give it a shot.

So freehand launches, we hope. All right. Pay no attention to the man behind the curtain. We'll go ahead and go through this dialogue. Now I have to mention that this is a technology demo. It's not a product announcement. Product marketing made me say that. So here it is. Freehand is running. We'll go ahead and open the application. Go to our documents, freehand sample art.

Bring up the lovely fairy picture created by Delores Highsmith. You'll notice that we got a lot of the Aqua UI. Most of our Aqua UI came about as adopting the Appearance Manager. We haven't done much beyond that. Appearance Manager is really great. I urge you to get a look at that if you haven't done it yet.

Some of the great stuff that we get running on 10 besides the Aqua UI, the double buffering is really nice. You'll notice as I move the panel around, there's absolutely no redraw of the picture underneath it. If you're an artist and it takes you a long time to redraw that picture, if you have a really complex document, this will be an incredible time saver.

Beyond that, we do have basic drawing, those sorts of things working. You'll notice that the drawing is really smooth and lovely and stuff. I added a minimal amount of Carbon events into the tool tracking, and that got me, you know, it used to stutter a lot, but now it doesn't. It's really great. So moving to Carbon was actually quite easy, and I hope that you all get a chance to do it. Okay? Thanks, Scott. Thanks a lot, Scott.

So you don't have to take my word as an Apple employee. What we find is the developers who have moved over to Carbon have been really happy with it. And we're here for you to help the process for all of you be as easy as possible. So what are the take-home points? First of all, Carbon apps will get a bunch of user benefits, right? We're going to make them more responsive and more robust. Carbon is the way to take your classic app and get the Aqua interface. You won't get it in classic, but you will get it if you move it to Aqua.

We really believe in this and we live on it. So the Finder is a Carbon application, QuickTime Player, a bunch of other apps. They're Carbon applications. So our system is based on it and we tune it every day because we live on the whole thing. And now is the time to carbonize.

There's a lot more info you can get. On the website, there's a Carbon site. There's a new tech pub site, which is great. It has this new inside Carbon, which is inside Mac carbonized. So if we can carbonize Doc, you can carbonize apps. And the last one is interesting here. We actually have a list of consulting companies who, if you don't want to do it yourself, you can just throw out some cash, and they'll come and carbonize your application for you. So you can go ahead and check that out.

David Wright is the technology manager to talk to if you have questions. But the most important thing here is tonight, after you've partied with the people you see here once a year, and you're drunk, and you get back to your hotel room and you want to impress your boss, pull out your PowerBook, install DP4 on it, and carbonize your application. Thanks a lot.