How are you all doing? Good. You're awake? Yes. All right. A little bit late, but let's start. All right, you've seen the architecture diagram for Mac OS X, and I'm here to talk about the part of it that I am extremely passionate about, and that is the frameworks. Killer frameworks enable killer applications. People talk about killer graphics, they talk about killer apps, but it's really the killer frameworks that enable you to create this application with all this functionality. And we have a bunch of different frameworks to enable this.

Now a lot of you are asking, you know, how can you either, you know, write or bring a killer app to Mac OS X? So maybe you have a great Mac OS 9 application and you want to bring it over. Maybe you're interested in Java or Unix. Or, you know, you want to build a new killer application from the ground up. So how do you do that? And the answer, of course, is frameworks.

So the way I see it, there are five different framework stacks. So there's Classic. This is really the Mac OS toolbox from Mac OS 9. So that, of course, runs on Mac OS X as part of Classic. There's Java and the full Java 2 platform. There's BSD and all the Unix APIs, the POSIX APIs, which form the basis of Darwin. And there's Carbon for your Mac OS 9 applications to move this forward. And there's Cocoa. Let's start with classic.

So the purpose of Classic is to make it so Mac OS 9 applications just run. All right? No change whatsoever. Your Mac OS 9 application just brings it over. You get a great engineering team, they created a killer app, and that'll continue to run. So you should really consider investing time in developing an application for Mac OS X. In classic, if your engineering team now looks like this.

That is to say, if you no longer have an engineering team, then thank goodness your application continues to run. But the fact that you actually are here at the conference means you employ at least one person, and that means Classic is not for you. So there's really only four stacks. I'm sure the classic folks are going to beat me up in the parking lot later. All right, so let's talk about Java.

Java is there to bring cross-platform applications to Mac OS X. Java, as its very nature, is a cross-platform API set, and we have a great implementation on X, and the purpose is to bring those cross-platform applications to Mac OS X. So if you go out and do some market research and you try to figure out, you know, who are the people who have decided that Java fills the need for them for their application, the answer is, number one, it is people who want cross-platform to many different platforms, right? Not just two platforms, but many different platforms. And they're really looking for a common denominator between these platforms. And Java can solve it for these people. Enterprise customers. So Java has really taken off in the enterprise space, so Java on the server.

Then there's a set of people using Java as an intranet solution. So within a company, they know what the runtime is, they know they have really, really fast bandwidth, they can download the class files to the client. So these people are all using Java. If these describe you, then Mac OS X is the platform for you. And really, you can move over to Mac OS X. So on Mac OS X we start with the standard Java pieces, right? So we have Java 2 Standard Edition 1.3. So in Java parlance, 1.3 equals 2.

We have the full Swing UI toolkit. So this is their standard set of buttons and sliders and all that sort of thing. We have the Hotspot Client VM. Now the Hotspot Client VM is pretty interesting. It actually, while the bytecodes are running, tries to figure out what parts of the application are taking the most CPU and then compile those sort of dynamically.

The great thing is, since Sun is developing on a Unix-based system and they're developing technologies like this on a Unix-based system, we can pull that over to Mac OS X a lot faster. And in fact, now that we have Mac OS X, we'll be able to keep up in the Java space much, much better than we could before on 9. We have Java 2, so their whole 2D solution. Printing support, so Java supports printing, and after half a decade, they support drag and drop, and so do we.

All right, but we didn't stop there with Java. We wanted to get, you know, premium Java. We wanted to make it so when you ran a Java application on Mac OS X, it felt even better than running it on a different platform. So the first thing we did for that is we give it the Aqua look and feel. So when you run Java on Mac OS X, it won't look like, you know, Motif or other nightmare UIs. It will look like Aqua. And we don't want those applications to stand out as being different. It should just look like a standard application on our platform.

We also really care about performance in the desktop. Okay, so we really want Java to run well for applications you build on the desktop. Now I know that the Java community is interested in making Java run well, you know, on rings and in cards. At Java conference a couple years ago they gave out rings with Java. Extremely useful.

So we care about making Java run well on the desktop with an application. And so one thing we've done there is when you launch an application we try to share certain parts of the subsystems. So Swing, for instance, instead of having to load that several megabytes into every single application, every single Java application, we load it once and we share it between the different applications the same way we do with other application stacks.

QuickTime for Java. So we have this great technology in QuickTime, and we want to make sure that even Java developers can get access to it, and so we've provided full access through these great QuickTime for Java APIs. Double clickable applications. Here's an idea. A lot of time when people run Java applications, They go into this cool UI called the shell and they run a little script. This sucks, right? So on Mac OS X and even on Mac OS 9, we believe you should go to the finder, you should see something, you should double click it, it should run like an application. So we fully support that.

We're doing more than that in that we're opening up other parts of our system dynamically through Java beans. So we have a Java bean that will look at the Cocoa spell checker system and it will automatically add that functionality into your application. And as has been said previously, WebObjects 5.0 is written completely in Java. So not only are we trying to provide a great Java platform, we're actually using it as well.

Now, I said Java is there to bring cross-platform solutions to Mac OS X. My guess is most of you have cross-platform solutions and most of you don't use Java to do it. The standard way of providing cross-platform solutions is you take your application, you parse it out into a UI piece and a non-UI piece.

You make that non-UI piece portable, right? You write it in C++, you write it in C, you can compile it on any of the different platforms. And then on each of the platforms you go to, you try to take full advantage of that platform as a native application on that platform. So when you go to Windows, you know, you give it a bad UI, but you give it the Windows UI.

And then when you take it to Mac OS, you can use either Carbon or Cocoa to build a great Aqua UI on top of it. So this is the standard way, actually, most of you are doing it. But if you've decided that Java does solve your needs, and you're sold on the Java story, then we are investing very heavily to make it so Mac OS X is the place you go for your Java solution.

So we really have single stop shopping. And the first thing I mean there is we have a single Java runtime. So on many of the other platforms out there, there are multiple Java runtimes. In fact, since Windows doesn't even ship Java 2 as part of the platform, either the user has to download it or, in most cases, applications come along with their own version of the runtime. So you get tons and tons of versions of the runtime. This is nuts.

This means that some apps don't run because it's a slightly different version of the runtime. When the runtime changes, things get screwed up. So what we do is we have a single standard version of the runtime. We use it. All apps in the system that are Java use it as well.

It's a great development platform. You get all the benefits of having a Unix base on here, and the standard Java tools all work. And it's really a great deployment platform. So if you've decided you want to deploy a bunch of Java into a school, say, well, you can do this using Mac OS X, and they get this great Aqua user interface and the rest of Mac OS X as well. So that's Java. Let's talk about BSD. So, BSD is about bringing Unix apps to Mac OS X.

So I went around and did some research on this too. I said, you know, let's bring it on. There's a lot of Unix stuff out there. There are hundreds and hundreds of GNU projects with lots and lots of Unix-based code in there. There are thousands of POSIX-based applications, so applications that use the standard POSIX APIs.

And there's just millions and millions of lines of code that have been written to Unix-based operating systems. This is especially true in scientific and higher ed. So you go to universities and they have Unix across the board. They have a lot of different versions of Unix and they have a lot of old machines, but they have Unix across the board. Because the BSD layer is built into Mac OS X as a fundamental piece of Darwin, we can take all of those applications and move those to Mac OS X. This is amazing.

So if you look at our BSD, we base it on the BSD standard 4.4. And as you know, it's open source. So you can go, you can look at the code, you can check it out, you can provide free engineering for Apple by fixing bugs and submitting them.

Highly encourage that. But it's open source, right? So imagine a university now, which uses a lot of BSD code, can hand out an assignment which is go change the pager of Mac OS X. And that can be the assignment, right? You can have them really working on a true mass market operating system and manipulating things at the lowest level. And this is really exciting.

Now if you look at the BSD layer, it's more than just APIs. It's APIs and tools. So BSD really encompasses a really large piece. So the APIs you're probably, you know, many of you may be familiar with. So it's the POSIX APIs and we, you know, support most of those.

It's a set of BSD APIs, so the standard C library and standard I/O and P threads and all those sorts of things. So there's a large set of APIs and you're free to use those. They're all built in as part of Mac OS X and will continue to be going forward.

The cool thing about BSD for those folks in the audience who are Unix-type people is there's a whole set of tools in there as well. Those tools don't just sort of come and go. Those tools are part of the operating system. And so if you want to use grep, then you can use grep. You don't have to rewrite it. Your application can run it in the background, can collect the data, can then quit that, and actually use these different tools to really enhance your application without rewriting things yourself.

Okay, now's where I'm going to tread on the toes of the Unix people. How many are the Unix people in the audience? All right. Hey, no one is-- porting the apps to Mac OS X is the easy part. Making it a great application on Mac OS X is going to be your challenge. So a lot of my Unix friends think that this is the greatest UI ever for chess.

Yeah, the people who raised their hands are now clapping. You know, it's not. So the great thing here is this is a standard GNU chess. I did exactly what everyone does when you want to run a GNU project. You download it, then you untar it, then you configure it, then you compile it yourself, then you run it. And it just ran. It just runs on Mac OS X, right? No changes whatsoever. So this is great.

But that UI leaves a little bit to be desired. Now, of course, the challenge of a good chess program is the smarts of making a nice alpha-beta pruning search and all this AI piece, all these AI pieces. But the UI there needs to be better if you want to get things into the Mac community. Here's GNU Go. Go is pretty simple. It's X's and O's and wonderful TTY, great UI. No, this isn't a good UI.

If you want to build a great UI, though, what you should do with your GNU source or with your Unix-based source is take-- port it to Mac OS X using our BSD layer and then build a Carbon or Cocoa UI on top of it. Right? This is really simple to do. Let me go ahead and show you this.

So I looked around to find a Go app out there, and it turns out--

So here's a, you know, they took that little step further than just having text in here. Now, I looked into it a little further and they took this next step of

I mean, you can actually speak to it.

You can tell it to move the pieces. You can sit across, have it on one machine in your office and continually play chess talking to it. So this is great. But again, you take the engines that are out there, you take all that code that's been written to the Unix base and bring it over to Mac OS X and then put a great user interface on it.

All right, so that's BSD. Now the one thing you'll notice is I have BSD in the frameworks layer, and normally you won't see it there because BSD is really implemented in the Darwin layer, right? It's implemented as part of Darwin. But I put it in the frameworks layer for today because it's a huge set of APIs.

There's a lot of code you can bring over, so it really is a framework. It's just not, you know, it doesn't have a nice UI part to it. And so in general you should think about it as being in the Darwin layer and using Carbon or Cocoa as the UI part of it. In fact, it just sort of fades into Darwin normally and isn't even pulled out. But it is an important stack that you should consider when thinking of all the things you can bring over to Mac OS X. Let's talk about Carbon.

So Carbon is all about bringing your Mac OS 9 applications to Mac OS X. When we looked out there and saw the huge investment that all of you have made in Mac OS 9, we realized it was silly for us not to have an easy way of you moving your code bases forward onto Mac OS X. And so we went through several iterations of this. We met with tons and tons of companies. We talked with lots of people. And we came up with a solution which works great, and that is Carbon.

Now I said that you should carbonize your applications. Should you only carbonize your applications? Well, you should certainly carbonize your applications. That's an important piece that you need to carbonize. Both your foreground applications, Carbon applications, old toolbox applications that have a UI and ones that don't. You should also carbonize all of your plugins. A lot of the apps out there are really just a thin veneer or a casing on a whole lot of plugins, and the plugins define the application. So of course you need to take and carbonize those plugins and move those forward.

However, you should not carbonize device drivers. So device drivers, by their very nature, are an OS-specific thing, right? They live between the hardware and the OS at the lowest level. Since they're OS-specific, you need to use an OS-specific way of writing your device driver. So continue to use Device Manager on Mac OS 9 and write I/O Kit drivers on Mac OS X. And I/O Kit is this great object-oriented way of quickly writing device drivers.

System extensions. So everyone loves the nits, right? What we love about them is the way it just locks up our system all the time. So please, please, please don't pollute Mac OS X.

So this is for a few people in the audience here who don't know what Carbon is yet. Now quickly define it. So what is Carbon? So we looked at all the APIs that define the Mac OS, right? So all the APIs that were Mac OS 9, earlier Mac OSs, and it's a large set, depending on your account, 8 to 10,000.

And we said, We want to move applications that use these APIs forward to Mac OS X. But we couldn't move all of those APIs forward. So it's really simple. We just saw there's, you know, good and bad ones. We had to then define what that meant. Now, the bad APIs are APIs that prevent that application, that library from running on Mac OS X.

So those are APIs that say, assume that you're not in protected memory spaces, right? That assume that everyone is sharing memory throughout the system. All applications can poke into each other's memory. So there's a bunch of obvious ones like that, or things that assume that you're not preemptively scheduled so you don't have to lock around certain things.

We took it a step beyond that. We really wanted to have the ability to move Carbon forward as we advance. We really want to grow it. So Carbon is something we're heavily investing in. We're going to continue heavily investing in long term. And the problem is with the way the Mac OS toolbox was before Carbon, A lot of the APIs were sort of implicit rather than explicit.

So if you wanted to go and set a window title, what a lot of people do is you just sort of munch through some data structures until you find a string, and you add that in there, and boom, you're done. That makes it pretty hard for us to go ahead and add a Unicode string in there, because you're just throwing in some data. We don't know if it's encoded as UTF or how it's encoded.

So what we really needed to do was take all those places where there were implicit APIs, where the developer would just walk through data structures, munch through data structures, and beat on them until it came out with the right value, and add accessors. So we had to get rid of some of these old ones. So of course the good APIs are Carbon.

Now Carbon isn't just that, right? So Carbon is growing, so there's the new growth. Carbon is growing and continues to grow, so some of this is accessors, and going forward we've added a bunch of other functionality, some of which I'll talk about in a minute. But again, this is all Carbon.

When you look at an application, and we surveyed lots and lots and lots of applications, they're typically 95% Carbon ready. Now, what does it mean to be Carbon ready? It means that about 5% of the calls the application made We're calling into those old bad APIs. And it's not because you're bad people. I'm sure you're all very nice people.

It's because we had no other way for you to do that functionality in the past. And so now that we have a way in Carbon to do it the right way, the application really needs to, you know, move over totally into the Carbon space. So some of this work is hard. Some of this work is easy. The great thing is we have a number of tools to help you carbonize your application.

So the first one to start with, and probably the most important one, is we actually create these custom reports that tell you, the developer, exactly what to do to carbonize your application. So it'll tell you exactly, here's APIs you're using that are no longer supported. It'll have a little documentation section just for your application saying, here's what you should do instead in these cases.

So it really is these nice custom reports made just for your applications. So what's it going to tell you to do? Well, the first thing it's going to tell you to do is adopt the accessors, right? As I said before. So places you weren't using accessors, where you were talking to low mems, you now have to use these accessors.

Another thing it's going to do is tell you to adopt these new toolbox UPPs. Now you might say, you know, why do we have UPPs since we don't have 68k anymore? The answer is because we have two runtimes, Mac OS and CFM, which are both completely supported, you have to have UPPs to be able to call between them. The next thing it's going to tell you to do is adopt Nav Services. Standard file isn't part of Carbon.

and adopt the HTML-based Apple Help. So once you've done those things, you have an application which is sort of being carbonized. And the great thing is when you carbonize an application, it can run on both Mac OS 9 and Mac OS X. So you haven't lost all of your current customers who are using Mac OS 9. You've gained your Mac OS X customers. Now the way this works is since Carbon is built in as a fundamental part of Mac OS X, the app just runs on Mac OS X.

On Mac OS 9, we have this thing called the Carbon Lib, the Carbon Library. So this is, for most APIs, a very thin veneer, a thin shim, on top of the Mac OS 9 API, so it calls right through. But for some things that we've added into Carbon that weren't part of the OS before, they're added directly into the Carbon Library. Your Carbon app sits on top of it like that.

So what do you get once you've done this? Well, by carbonizing your application, you get the killer benefits of Mac OS X. These aren't the killer benefits of Carbon. They're the killer benefits of Mac OS X that if you don't carbonize, your app doesn't get. So it's things like stability. You've heard a lot about this. So you get protected memory. You get preemptive scheduling. So both of these add to stability. Another app can't smash into your memory and crash you. Another app can't sit there and hang the system, so people can't get back to your application to save data.

There's responsiveness, so you get preemptive scheduling, so the app is more responsive. And threading is really interesting. You can make a lot of use of threading on Mac OS X to have, say, your UI thread try to be as responsive as possible and then put other actions into background threads so that your UI is always responding as the user clicks.

So here's a killer benefit that a lot of people don't realize that we have in Carbon. And that is the Carbon file manager actually supports a whole lot of file systems. So instead of just supporting dual forked file systems, so the Mac OS Standard HFS and the Mac OS Extended HFS+, when you Carbonize your application, your Carbon application will automatically be able to run on a UFS system or an NFS system or a web dev system.

So these systems where the file system itself is single forked, your app doesn't have to know that. The Carbon file manager will behind your back automatically create an Apple double file, put it into a separate file in the data fork of that file with a special name so it can associate that along with the data fork that you tried to save out with a resource fork, both stored in flat files. Scott Forstall So the Carbon file manager really allows you to use a bunch of file systems that before you couldn't use well.

And there's automatic memory management. What do I mean by this? Here's the panel that you hate as a developer. There's a panel that your tech support hates because they get calls about it. And why do they get calls about it? Because none of your users have any idea what it means. Having to set the memory for an application, having to manage the memory for an application is not something a user should have to do. So on Mac OS X, the user doesn't.

Here's one that whenever I have people make slides for me, they always look at this and start cheering when they realize this is going to happen, which is you won't run out of memory like you do right now. So in PowerPoint, I often would run out of memory and say, go quit your other apps and go give PowerPoint some more memory. No more.

Of course you get Aqua, right? So if you carbonize your application, you get a nice Aqua user interface. If you don't carbonize it, it remains looking classic, right? So it's only through going to Carbon that you'll get the Aqua UI if you're a Mac OS 9 application. And it's really important that your app will stand out as a classic application so the user will know, well, this isn't a native application. They'll look for another native application.

So we tried to make Aqua as easy as possible for the developer. And one way we did that is we retained the platinum metrics. So buttons are the same size, sliders are the same size. We tried to retain the same metrics on all the widgets. There are some places where we've added something where we couldn't just give it to you for free, but we've tried to make it as easy as possible. So Sheets is a good example here. We've added Sheets, and we've added some nice simple APIs to run your panel as a sheet, but there is some adoption necessary here.

Whenever someone changes the UI of something, suddenly everyone looks at UI a lot more. It goes under the microscope. And so as you're moving your application from Mac OS 9 to Mac OS X, and you're carbonizing it, and you're making use of Aqua, it's really a great time to pay particular attention to the UI. And there's a number of people, our UI team is actually holding some one-on-ones this week to try to help you, the developer, out. But definitely spend a lot of time looking at the user interface of your application.

So you've heard this a couple times, but this is possibly the most important slide in my entire Carbon section. And that is performance. When we took the APIs from Mac OS 9 to Mac OS X, we retained the same APIs, we retained the same semantics of the APIs, but we did not retain the same performance characteristics of all the APIs. This is out of necessity. On Mac OS 9, when you ask for date time, it just checks a struct somewhere and it returns it, and boom, you're in your own address space.

It was really fast. When you go ahead and say, give me the process ID, it's immediate. But on Mac OS X, those turn out to be kernel traps. So you actually trap into the kernel. This is a much more expensive operation than just checking a variable in your own address space.

So even though you've spent a lot of time tuning your application and it runs blazingly fast on Mac OS 9, when you carbonize it, and if it doesn't run blazingly fast, maybe it will, It's not because necessarily there's a bug in Carbon which is making your app run very slow. It's because you were assuming the performance characteristics of the nine implementation of the APIs.

Laziness is a virtue. Here's the one time you get to be extremely lazy when you develop. Try to make sure that you don't load things until you need them, because a given user may go through your application and never use some subset of the functionality. So the best thing to do is never have loaded that functionality during that run. So until a user has gone and caused it, your application, to load that functionality because they want to use a certain paint tool or whatever, you just don't load that at all. So try to be as lazy as possible about loading stuff.

So polling is very bad. You know, Roberts in Bertrand's talk showed where an app was doing a whole lot of polling, and it was pegging the CPU even though nothing was happening at all. On Mac OS X, it's much better to just block and wait until you get an event.

So if nothing's going on, don't sit there and keep on pinging it and saying, hey, is something going on? I feel like I'm out of the loop. You're not out of the loop. You'll get an event when something happens. So you should-- don't poll. Try to make your app be as quiescent as possible when there isn't anything happening.

And it's very clear on Mac OS X right now that, you know, we're memory bound. So the great thing about Mac OS X is everyone shares, you know, the memory because it all gets swapped out to disk if you use too much. So even though you have your own address space, the more memory you use, the more you're going to start slowing down the system. And so it's really important to try to use the minimal memory possible. You know, just because we have virtual memory and you can allocate a cache that's, you know, the size of an int, don't.

So there's three recommendations I would have for you to figure out how to improve your performance, how to make your performance as good as possible. First thing is measure. The second thing is measure. And the third thing is measure. Because you probably don't know the performance characteristics of all the APIs on Mac OS X yet, you really need to dig in and measure and see where it's slow before you assume you know what you need to change to make it faster. And then of course, you know, fixing is not bad either.

So there's a set of functionality that we've added to Carbon as part of Carbon that wasn't on Mac OS 9 before. And some of these are great. One of these is Carbon Events. Carbon Events is a way to dramatically simplify your application. And the way it does that is instead of having to look all over for, you know, what event's getting sent and then sort of dispatch those yourselves and, you know, you get a click and you're trying to figure out what's the click in a menu, what happened, pass that on to the right person. There's actually a really nice framework that figures out what events are coming in and then dispatches it to the correct handlers. And since it does that, we can actually have a lot of default handlers that handle most of the functionality for you.

Now since we've removed general patching, Carbon Events actually solve most of the needs you had when you were patching before. So you can add your own handlers, you can actually stack your own handlers, so if one handler doesn't deal with a given event, another one can. So it's a really nice way where it could modify an event and pass it on. So Carbon Events is a great thing to modify certain behaviors.

turns out the Carbon events also help with performance because Carbon events are meant not to pull. They're meant to send data out when the data needs to be sent to someone as opposed to pulling and constantly asking where something is. So in fact, in Robert's example from the last talk, or no, sorry, from Avi's example this morning, the solution to the pulling was to use Carbon events.

So I get a lot of questions about threading. And it's because a lot of people use Thread Manager on Mac OS 9. And they ask, you know, is this now going to be preemptively scheduled on Mac OS X? And the answer is, absolutely not, it can't be. The reason is, the Thread Manager was a cooperatively scheduled API on Mac OS 9. If we were to take and suddenly turn that cooperatively scheduled API into a preemptive API on Mac OS X, then your app will surely crash immediately. You won't have locked around the right data structures, you won't have locked around the right calls.

And so we can't make that preemptively scheduled on Mac OS X. What we have is the MP APIs, the multi-processing APIs, and those are preemptively scheduled. So if you'd like to have preemptively scheduled threads on Mac OS X, the right way to do it is to move to the MP APIs, or you can move directly to P threads, and we actually base all of our threading on top of P threads. Even the Thread Manager is based on P threads, we just lock around them to make sure they're cooperatively scheduled. Thank you.

So there's a bunch of other functionality that we wanted to add to Carbon and Cocoa. Like XML and Unicode, we wanted great event management to be able to tie together Carbon and Cocoa. We want to have great preferences, standard preferences for every application. We wanted it to be multilingual and have simple application packaging.

So we looked at those and we said, you know, how should we implement all of that? And, you know, here's one solution. We could implement it twice in both of our stacks. If someone were to come up with this solution, I would fire them and then you can have them as an engineer.

A better solution, which is what we actually came up with, is you create a single stack for this. And you share it between both Carbon and Cocoa. So all this functionality you put into a single place. And that for us is core foundation. Now I'm not going to talk about it, but I'm going to talk about core foundation. There's a lot of other things that we share as well that I'm not going to get into details on.

Carbon and Cocoa really share a whole lot of code below them. So we don't have totally separate stacks of implementation from top to bottom on Carbon and Cocoa. We try to share as much as possible. Like we share the print panel, for instance. The print panel was implemented one time. It was implemented in Carbon. And it turns out in a Cocoa application, when you print, that sheet that comes down is a Carbon panel.

You don't have to know it as a developer. The user doesn't have to know it. But we're trying to minimize our work. And so there's a lot of places that we share code. But a really interesting one, and a new one for a lot of people, is Core Foundation.

So Core Foundation First supports XML, right? So we have a really-- an optimized general parser for XML. And it's really powerful. And if you want to see the code, you can. We open sourced it as well. So you can take it. You can, again, provide me free engineering hours by fixing bugs and sending them back.

When we looked at XML, we actually looked at a lot of different data types and tried to figure out what is the best persistent format for data. And there was no question, XML has won the game. And so when we implemented this great XML parser, we then went and used it throughout the system. So everything from driver configurations to the Carbon UI can be saved as an XML file, to preferences, to everything in between. So whenever you see a configuration file on the system on Mac OS X, it's going to be an XML file.

We also are very, very multilingual conscious. We want to support multiple languages. We want to be able to ship in multiple languages on the same day. And so we added great Unicode support through CFString. So CFString is an opaque data type to store strings. And the great thing is it can store it however it wants.

As far as you, the developer, are concerned, it's stored as a Unicode. But it can be a lot smarter than that. So if you pass it a Unicode string, which happens only to have ASCII characters in it, it can store them as single bytes. You know, saving half the memory.

When you ask for the string, it can actually pass out the double byte characters and turn it into that if you'd like. If all you do is pass a CFString around throughout the system, it can always stay as a single byte holder because it's an opaque data structure to you. So we use this throughout. All of the APIs in the high-level toolbox, so in Carbon, will now take CFString. So you can set a window to be a CFString. So you can set a window to have a Unicode title.

Now, event management is one that's really, really interesting for us, and it'll be somewhat interesting to a few of you, but this is the way that we actually provide sharing between Carbon and Cocoa. So we have this thing called the CF run loop, and the run loop gets the events in and actually hands them off to either Cocoa or Carbon, depending on, you know, what button you're clicking on, what window you're clicking on. And so the great thing here is we can really leverage a single implementation for certain parts of the UI in both of our frameworks. So, for instance, the menu bar is implemented once. It's implemented in Carbon. Cocoa just uses it.

We think it's really important to have a nice, standard, single place for you to store preferences. We have that, and of course it uses XML. And Bertrand touched on application packages a little bit. This is a really important thing for us because it ties together a number of our different stories.

So we looked out and we said, how can we simplify the experience even for Mac OS 9? In Mac OS 9, when I go and try to launch an application, I go into a folder, and I see supporting libraries, and I see help files, and I see all this stuff. I have no idea what it is. And I search for the one icon which looks different, which is the application.

What we wanted to do and what we did is we took and we packed that all up into a single piece, a single item in the finder. You double click and launch that. But that single item turns out to be a folder hierarchy below the surface. But as far as the user is concerned, it's a single item.

So this allows us to have multilingual applications. Some of the things that we store inside this package now in standard locations are localizations. And of course these localizations are done with XML files, supporting full Unicode within them, so your strings files are XML files. And it allows you to have a single binary, that single item, that single package, that supports multiple languages.

It also allows us to have a single package, a single application that runs on both Mac OS 9 and Mac OS X. Now as you know, you can write a single application which is just a CFM application, single binary, runs on both as well, and that can fit in this package.

But if you choose, you can also have a CFM application on Mac OS 9, a Mac OS application on Mac OS X, package them within the same application package so the user is none the wiser, and then when they double click, it'll run in using the run time, using the binary of the platform. So again, totally up to you, but it's hidden from the user.

And these are extremely simple. I mean, how much more simple can you get than having a single item for the user? So another question I get a lot is, well, for Carbon, you removed a set of APIs, right? When we moved to Carbon for Mac OS 9, we removed a set of APIs. Are you going to continue removing APIs sort of at whim? And the answer is, again, no. Otherwise, I wouldn't have presented it that way.

Once an API is in Carbon, it stays in Carbon. So we believe in being binary compatible, going forward with Carbon, period, the same way the Mac OS has been. So if you look at the first Carbon lib, So, if you look at on different OSs, there will be subsets of the API, right? So, the first OS that we supported, Mac OS 8.1, will have the least number of Carbon API supported. Why is that? Because a lot of APIs that were added to, say, Mac OS 8.6, to move those back in CarbonLib to Mac OS 8.1 would be basically reinstalling the Mac OS 8.6 operating system on top of 8.1, right? So, this doesn't make any sense.

So, in Mac OS 8.1, through CarbonLib 1.0.4, you have all the Carbon APIs that were in 8.1, plus a set of things that we did feel necessary, it was necessary to bring back, like the accessors, like window properties and control properties and menu properties, like Nav Services. Pieces of core foundation. and Carbon printing.

Now, Mac OS 8.6, the operating system brought a lot of APIs to the developer, and those are exposed through Carbon as well. So you can read at will here, but there's a lot of APIs that we added in 8.6, which are then available through Carbon. So you need to look, depending on the version of the operating system you're running on, the same way you have with your applications that run in Mac OS 8.6 versus 8.1, what APIs are available.

A Mac OS 8, you know, 9, the HFS+ APIs were added, and then there was a lot of performance and stability enhancements. So Carbon runs much better on Mac OS 9. And then on Mac OS X, we added a few things, you know, Aqua being the main one, and that's when you get Aqua when you go Carbon on Mac OS X. We're also adding Carbon APIs all the time, right? We are growing Carbon, and you'll get a lot of those on Mac OS X. And on Mac OS X, you can, of course, access other parts of the system, like the POSIX APIs, if you'd like.

So going forward, we are absolutely growing, extending, investing in Carbon. Period. This is not a bridge strategy. That's a question I've heard. This is not a bridge strategy. Carbon is a fundamental framework, a fundamental API on Mac OS X, and we are investing in it and we are adding to it. Each new release that comes out brings all the previous APIs and potentially some more. And then some APIs will bring back to older operating systems. So let me go ahead and show you a nice little Carbon demo.

So in January of this year, Apple for the first time released this application called iTunes. Who's heard of it? OK, everyone who's lazy, not raising your hands, are liars. In February, we came out with the second version of iTunes, right? We came out with an update. And then on March 24th, we came out with iTunes on Mac OS X.

Now, how could we come out with it so fast, bam, bam, back-to-back on Mac OS 9 and 10? The answer, of course, is it's built as a Carbon application. It shares the exact same source on Mac OS 9 as it does on Mac OS X. So you've probably seen it, but here is iTunes running on Mac OS X.

has a list of all the features you'd expect from here. Now, iTunes is also packaged as a multilingual application. Let me go ahead and, you know, Let me take and change my system language. So let's say right now I have it set to The English is my preferred language. Now, let's say that English is actually my third language, Japanese is my first, and French is my second. Let me say this again.

You actually rank your preference order of languages in Mac OS X. It's not a, here's the one language I speak. It is, you know, I know Japanese, and Japanese is my primary language. But French is, I know a little bit of French, very little English, and maybe no Dutch or anything on. So you actually rank the languages. Now, this version of iTunes I have, I actually have removed the Japanese localization from.

So when I go ahead and run it again, after having dynamically changed it, first it says, "Hey, where's the Japanese?" There's no Japanese. So then it goes and it comes up in French. So here is all the menus are in French. It continues to run the same way it was before. So how do you localize an application? It's very, very simple. Let me go ahead and show iTunes in the finder. Now as you see, iTunes is a single item in the finder, right? A single icon. But for you, I will show the dirty insides.

So inside here you have a contents folder. In here there's an Info.plist. So this is an XML file telling it what file types it can open, things about icons. Here is the Mac OS, so it has a single executable. Here's its plugins folder. So, unlike a Mac OS 9, where you always have iTunes and plugins right next to it, the plugins are hidden from the user.

They don't have to worry about looking at it. It's in here. And then here's all my resources. So you see it's localized to Dutch and English and French. There's a bunch of other icons here. Then, you know, this is alphabetized, so Spanish is down here. There's no Japanese in here.

Here's the Japanese package. All this is are the resources, the localized resources,

So to localize your applications, you don't have to recompile them. You don't have to link them. All you need is that set of resources that are the localized resources, add those in, and now you have it localized to another language. So it's an easy way. You can come out with an application with a set of localizations and later ship just the other localizations, and now your app is localized into more languages. That's Carbon. Let's talk about Cocoa.

So Cocoa is there to help you create the next killer app. So if you have this great gem of an idea and you want to turn it into a new application, Cocoa is a great way to do this and do it very quickly. The way I look at it, a lot of people when they talk about creative genius, they talk about artists, right? So here's our friend Picasso looking a little happier over with his bird.

And here he has, you know, some creative genius headache bursting to come out. But most people, they think about an artist as being having creative genius. But I think of developers as having creative genius. Because every killer app that's come out has been the gem in the mind of some developer.

And there's been a lot of those apps that never came out because the developer didn't have the right tools, the right frameworks, the right operating system to enable them to get that application and turn it into a reality. So what we really want to do is enable all those killer ideas to turn into killer apps. So first and very simply, Cocoa supports all the things that Mac OS X supports and Carbon supports, right? So all the heavy hitters in here, including really good integration with other system components.

But the great part about Cocoa is it really accelerates your development. It makes it so you can develop applications much faster. How does it do this? Well, one way is it's object-oriented. So all the different concepts are modeled into these nicely bundled objects. You can combine those objects together. You can actually, and, you know, one of the really interesting things you can do with them is you can extend them.

So Cocoa is really designed to allow you to not only use the pre-built objects, the pre-built classes, but to extend those in ways that make sense for the unique idea that you're trying to implement. So you can subclass objects, you can add delegation. There's a number of standard ways for you to use the objects in new and unique ways that solve your purposes.

Another great thing that Cocoa has, which doesn't come standard with all object-oriented frameworks, is a dynamic runtime. This means that at runtime, a lot of information is found out that isn't known when you compile the application. This allows you to have things like introspection. You can look at an object at runtime and say, "Do you implement this method?" If no, maybe you'll look at another object to find out if it implements that method.

You can find out a lot of information at runtime. A great example of this is cut. Cut, copy, and paste. You can actually wire up your cut menu item to this magical object, which will get determined at runtime to see what is the currently focused widget, and tell that widget to do a cut, as opposed to having to know at compile time what object is going to be pointed to at any given time. And it really allows powerful tools. So Bertrand gave an example of how few lines we need for something like mail. You know, in the Cocoa space, it's not the number of lines you have, you know, it's how you use them.

Cocoa is really easy to use also. And the main reason for this is it's a very consistent set of APIs. So a lot of people have come to me, after they've used Cocoa for a while, and they say, it looks like the entire API set was designed by a single person.

Because each class doesn't have the nuances of a different person's API design skills. And that's really important. The APIs are all meant to be very, very consistent. So when you learn a concept in one class, that's true across all the classes. When we introduce something like a string object or a collection class, everywhere you'd need that sort of collection class, that one will be used. The APIs are supported in Objective-C and Java, so you can call into Cocoa from Objective-C and Java. So if you love the Java language but hate the Java platform, you can use Cocoa as your API set, as your frameworks, but use the Java language.

But a lot of people look and they say, well, you know, Objective-C, what is that? And Objective-C, I mean, it's a very thin superset of C. I mean, it'll take you about a day to learn. But... This does not mean that you have to write your applications in Objective-C and Java. It's really important. You can write your applications in C, in C++, in Objective-C and Java. So you can have, you know, 99% of your code written in C++. A few places where you call into the UI, you have an Objective-C call.

And one thing that we're actually adding in our tools is the ability to have a file which has a bunch of C++ calls and then interspersed will be a single Objective-C call and then a bunch of C++. So within a single source file, you can actually intersperse Objective-C and C++. So you're really... This is a great thing. So you're really writing a C++ application, and it uses Objective-C where necessary.

So what does Cocoa have? Well, it has widgets galore. And I'm not going to list all the widgets, but it has-- let's see, Windows Views. It has all the widgets you'd expect. But it has a lot of other things which are much broader concepts which really accelerate your development. It has a great document architecture. So if you're creating a multiple document application, or just a single document application, Cocoa will help you do that. It'll automatically run your open and save panels for you.

It'll... It'll also pay attention to whether or not your file's been edited. So there's a very strong concept of a document architecture built in. You can get it for free.

It also allows you to plug in the special undo for your application directly into this queue as well. It's very simple.

There's a great scripting architecture. So we really, really believe in the power of Apple Script and Apple Events. And this is built into Cocoa, so it's really simple for you to add Apple Events and Apple Script support to your application. There's a great tech system. So the tech system is fully Unicode-based. Excuse me while I pull out a cough drop. As Steve said, I woke up with a 101 fever this morning.

So the text system is extremely powerful. It's fully Unicode-based. It uses Quartz to have this beautiful anti-alias text. It has things like inline spell checking. It has advanced typographic features like kerning and ligatures. It's really well architected so you can actually replace, subclass, modify pieces of it to get the job you want done.

And potentially most important, It's used everywhere text appears in a Cocoa application. So if you want ligatures, you can get ligatures anywhere throughout an application because it's the same text system. If you want spell checking, it can happen in any place you have text. So even our IDE tools can use this sort of thing because it uses the same text system everywhere.

Let's talk about RAD for a minute. People have very different ideas about what RAD means, but the general one people think of is It's a tool which spits out a bunch of code, which helps you get your work done quickly, but it's sort of a, you know, write once, never modify, and then it's a one-off, you're done with it, and you have to create a new app the next time you want to change it.

So it's really important that, you know, I think what the people are doing who are creating those sorts of tools, they're looking for very simple applications. You know, you're going to build a very simple application with the tool. And they're looking just at the tool as the solution.

What we do on Mac OS X is we look at both the tool and the framework and we develop them together. So they're really married. And that allows you to have the power of the framework and really integrate that into the power of the tool and get a way of developing that can solve your needs at any part of the development cycle.

So Interface Builder is our tool for this. Of course, it allows you to do simple things like visually build and edit your UI. As I said this morning, it allows you to create Aqua compliant user interfaces. So we've built all the rules for Aqua directly into the tool. But it's really cool in that it can wire objects together. So it actually can connect dynamically your different objects together.

You can run your interface without compiling. And it supports both Carbon and Cocoa. So we've actually done a lot of work in the last year to make it so Interface Builder supports Carbon as well. Now if you look at the Mac Toolbox three years ago, it would have been really hard to do that.

But with Carbon Events, Carbon Events are just made for something like Interface Builder. So Interface Builder can really accelerate your adoption of Carbon Events, so it supports them really well. It even saves out the interface, the UI, as an XML file for Carbon, and that's loaded and run when you use the Carbon IB runtime.

Cocoa is also very mature. For a lot of people, Cocoa is very new. You haven't heard about it or you've heard about it once. It turns out that Cocoa has gone through several different stages. Somewhere around the monkey or club stage, There's this guy who had this idea for a killer app.

He had this great idea. He was a creative genius. And he said, here is this idea I have for this killer app. And he went out there and he chose to use a previous... version of Cocoa, a previous incarnation of Cocoa, to build his killer app. And he did it when Cocoa had way less features than it does today.

Well, that person was Tim Berners-Lee, and the application was the very first web browser. The web browser was the first web browser, and the web itself was created using a previous version of Cocoa. And that was back in the club or the monkey stage. Imagine what you can do with Cocoa in its current incarnation walking upright.

So Apple is really one of the biggest customers of Cocoa right now. We know it helps us build applications faster, so a lot of the system apps are actually built on Cocoa. So I had this really great demo for Cocoa where I build this iMovie thing in Interface Builder.

Has anyone seen it? Yeah, okay.

A lot of the time I get asked the question, what is the native framework for Mac OS X? I want to develop an application for the native framework. I'm looking out there and I don't want to develop for the wrong one that you're going to drop.

So what is the native framework? There's a lot of implications for what would define a native framework. It has to obviously provide protected memory and preemptive multitasking and support Aqua and advanced application packaging. It has to allow you to access all the system frameworks as well. But the most important, of course, is it needs to be the basis for future Apple innovations.

and has to be the basis on which we build applications, on which we build other frameworks that define the system. So what is the native framework for Mac OS X? What's the trick question? There's two. Cocoa and Carbon are both native frameworks for Mac OS X. In many ways, Carbon is the procedural API of a lot of the functionality that we have that's an implementation detail, and Cocoa is the object-oriented API to those. We share a lot of code below the surface. We're investing heavily in both of them. They're both native APIs, and we will bring both of them forward and evolve both of them. We're not going to stop on any.

So if you build a Carbon application, that is a native application on Mac OS X. If you build a Cocoa application, that is a native application on X. So I look at our frameworks, I get really excited because I think we're going to get some killer apps from you guys because we've provided you the APIs to do so. Here's the roadmap for those of you who think of using Classic.

If you're interested in Cocoa, stay seated. It's immediately following this hall. There's lots and lots of Carbon talks. The first one is tomorrow at 11:30, which is Carbon Events. If you're interested in BSD and Darwin, you missed it. It was three hours ago. But when the streaming video comes out, you can go ahead and get that and watch it.

and tomorrow morning bright and early is the Java Overview. There's a lot of people to contact here. Mark Turner is the Carbon Technology Manager. For your Carbon questions, go to Mark. For your Cocoa questions, go to Heather Hickman. For your Java questions, Alan Samuel. And for your BSD and Unix questions, go to Jason Yeo. Thank you very much.