In this session, I'm going to do a quick review of what Carbon is and why it's important. We're going to go more into detail about the transition process and what it takes to get your application carbonized. And then we'll talk about some of the development options that you face with tools and platforms and debugging. So, what is Carbon? We'll simply put it's APIs that you can write to in the Mac OS toolbox so that your application will run on the 8.1 through 10.

As Scott Forstall pointed out on Monday, Carbon is a living organism. As Apple is reviewing the APIs, developer feedback is very important and it has made a severe impact, severe that sounds bad, a great impact on some of the decisions that Apple has made about whether to keep or remove APIs.

Some APIs have to be removed because they just simply wouldn't work in a modern operating system environment and some because our evaluation of how much they're being used would indicate that we should no longer support it, but developer feedback has often made an impact on those decisions. So this mailing list is self-subscribe and if you go ahead and add yourself to that and begin discussing with other developers and Apple employees that are on this mailing list, your feedback will be very important. feedback will definitely be incorporated.

So, why Carbon? Well, I think before we talk about why Carbon, we have to review why Mac OS X. And as Scott also pointed out on Monday, Mac OS X is bringing a lot to the Mac OS platform that simply isn't there enough with Mac OS 8 and 9 right now. And those things are stability because of protected memory, performance and responsiveness because of preempted multitasking, Aqua, which is just an amazing user experience, you've all seen that, a virtually unlimited memory, no more finder panels, no more having to close your app, open the panel, guess the right number, and relaunch your app, and application packaging, which is delivering multiple languages without having to install a different version of the app or a different version of the OS, and simple. All incorporated into a folder, but to the user it looks like one finder item.

So now back to why Carbon. Well, all those great things are coming to us because of Mac OS X, but all the applications that the user has to use are not. The applications that the users are using for productivity are on 8 and 9, and that's where Carbon comes into play. Carbon is Apple's answer to how we're going to incorporate these two great environments, Mac OS 8 and 9 applications, which are so many, and Mac OS X bringing the modern operating system environment. It gives us a great user experience on a robust platform.

So the transition process. It's pretty straightforward. I actually prefer to call it a tune-up process. I was reviewing some of the documentation we have, and I like this term better because I think it's more accurate. Tune-up is kind of getting in shape just parts of your app that need to be changed a little bit to work better in a modern operating system environment like Mac OS X.

So the first thing you're going to want to do is use CarbonDator. I'm going to go into all of this in more detail, but I just wanted to give an overview of the process. CarbonDator is a tool that Apple has made so that you can preview required changes that are going to be coming to your application before you really start a lot of the work.

Then you're going to want to download the CarbonLive SDK, which has pretty much everything you'll need to get going. And then you start the tune-up. Whoa, here we go. Fixing compiler errors, using alternative or modified APIs for those that are no longer supported. and you're going to link against Carbon stub.

Then you're going to run on Mac OS 9, which is cool, but as Mike Garcia from Quark said on Monday, when you run on Mac OS X, it's really fun. It really is. So, CarbonDator, like I said, allows you to preview required changes. It's very simple. You download a tool, you drag your app onto it, CarbonDator spits out a file, you mail that to Apple at an email address that's specified in the documentation, and in about an hour you get back an HTML report that gives you a detail of the APIs you're using that are unsupported or modified.

So, this was mine. I came into developer relations last summer and before that I was working on a project in engineering. I don't know if any of you have had the chance to see a new Macintosh boot within the past nine months, but it starts playing a flashy movie and it allows the user to register and get an internet account. Have any of you seen that? I don't know. Yeah? Okay, cool. That was my engineering project. I was working on the user experience side.

Another great guy was working on the back end, the internet and registration side. So, anyway, when I was coming to developer relations, I wanted to get a really good feel for the experience the developers were having, so I emailed the application to CarbonDator and this was a sample of the report that came back.

So, as you can see, 90% of the APIs that I was using were just supported. That's actually a low number. I think it's because I was a system software engineer. So, we use APIs that, I don't know, aren't always supported or at least publicized. So, your application will probably report a much higher number for supported APIs. 8% were unsupported and a small percentage were either modified or not recommended, which means in a while they would be unsupported.

So after you kind of get a feel for the changes that are going to be made, go ahead and download the Carbon Live SDK. The contents of it are the Carbon Porting Guide. Really, the Carbon Porting Guide is going to be your major guide through this whole process. It's a much deeper, in-depth discussion of the kind of stuff I'm talking about today.

You'll get the latest universal interfaces, which you'll need to keep up with the APIs that are constantly being reviewed and set for Carbon. A lot of the APIs are still being reviewed as to whether we will permanently support them. And then you're going to link against one of two stubs, and I'll explain the difference between those in a few minutes. There's the Carbon Live extension, so that you can run your software on Mac OS 8 or 9. Documentation and sample code. So with this stuff, you're all set. You're ready to go.

There are currently two SDKs for Carbon Live shipping. Carbon Live 104 has gone GM and is available via download from Apple's software update mechanism, and it's available on our developer site on the public area development kits. And Carbon Live 11 is currently under development and being seeded about every two weeks, and you can get that from your Apple developer connection account.

Once you log in, just click download software and go to the Carbon Live section, and the Carbon Live 11 SDK will be there. For Carbon Live, I'm actually going to be going into depth about that much more tomorrow, Thursday, in the Civic Center at 5:00. So if you want to learn more about Carbon Live and Carbon on Mac OS 8 and 9, please be sure to attend that session.

So, the very, very first step about Carbonizing your application has to do with 68K code. There's just none. So there's no 68K code involved with Mac OS X or Carbon applications. And that's all I got to say about that. So the next step, once you're there, you're ready, you're set, go. You wave this big flag, target API Mac Carbon.

So I got to say that at first you're going to hate this flag, because if I could say that Universal Interfaces had a mood, when you turn this flag on, they get really fussy. And when you go to rebuild your application, it's just going to start raining compiler errors. So perhaps many of you have already experienced this. But the good news is that they're so easy to fix. I got to be honest, they're so tedious.

But ending on the good note, they're so easy. So it's just a lot of grunt work. And in some kitchens that we had during the past nine months, I've seen developers show up with just agony as they see the number of compiler errors coming in. They projected like two weeks, which the kitchen was only running a week. And we just thought, all right, well, go for it, and call me when it's up on 10:00. Or whatever. I don't know. But two days later, they were all done. So it goes a lot faster than most people think.

So what are these compiler errors? Well, Scott Forstall referred to them on Monday. Most of them are coming from the fact that we've made the toolbox data structures opaque. We've kind of kicked you guys out of touching them directly, but that's such a good thing because now Apple can keep moving the OS forward and not break your applications every time we have to change something in there. It also allows us to add re-entrancy to the toolbox for thread safety. The other type of error is generic universal proc pointers are no longer supported. Each toolbox manager now has specifically typed UPPs.

So, to take a deeper look at some of those, graph ports and friends are the most common errors that you'll see. On Mac OS 9, a dialog is a window, is a graph pointer. And we all know that we're so used to casting those and using them as such, but on Mac OS X they are not, and therefore, Carbon, they're not.

So in order to do that, you need to use casting functions, and these are a sample of a lot of the casting functions, or even just accessor functions that are available in Universal Interfaces. If you want to get the field from a record, the convention is get_record_field. So get_window_port or get_dialog_window.

For specific real objects, not just a field of an object, but ports and windows, if you have that, you can get the containing record by using the convention get_window_from_port or get_dialog_from_window. So these conventions are followed throughout the Universal Interfaces, so when you're looking for that accessor function key, accessor function, keep this in mind.

So here's an example. In the top line we see what we've all been using today. We want to get the left field of a bounding box of a region. And so we just dereference the region and access the field directly. But in Carbon you can see what it becomes. You have to use the accessor getRegionBounds and pass it a variable in which it's going to fill out the rect with the value of the bounds. It also returns a pointer to your variable just so you can then immediately start accessing it, as you can see there.

So there is some good news. I don't know why. I think I was tired when I wrote this slide, but there's good news. Rects are not opaque. So I just can't even imagine the number of compiler errors that we would be getting if we had made rects opaque.

I know. All right. Universal proc pointers. Why do we still have them? Well, as you know, they came into being when we started having two kind of runtime architectures, PowerPC and 68K. And we still do with Mac OS X. We have CFM, which is familiar to all of us with Mac OS 8 and 9.

But when we brought in the OS that Mac OS X is built on, Maco was its native runtime. And we still support those two runtimes. So universal proc pointers are there to help us. But the generic routines, new routine descriptor and dispose routine descriptor are gone. And you have to use specific ones from the toolbox manager. So here's an example.

As you can see in the top one, we're using a new routine descriptor and dispose routine descriptor. But now, if you were to look in the universal interfaces, you'd see these APIs, new control action UPP and dispose control action UPP. That's an example of a a toolbox manager.

So one important thing that I wanted to be honest about is that CarbonDator does not necessarily report these types of compiler errors. So I had one developer come up to me and say, "CarbonDator said I only had to change eight APIs." And I was like, "Oh." Because when he turned on the flag, he of course started getting these other types of compiler errors that are involved with carbonizing your application.

So now we're going to kind of go down the road that we've all been traveling to get a Mac OS 8 or 9 application on board. We're going to see that some of the roads are closed and we have detours. And I'm just going to review some of the highlights, ones that I have seen specifically impact developers in the past year.

Again, use your Carbon porting guide for an in-depth coverage of pretty much all of the gotchas that we know about at this time. The biggest one that I've seen hit people is that the window manager port is no longer supported. So you cannot draw globally to the screen.

We do have some detours. For window dragging and resizing, Carbon Events is supported. As Carbon Events sends your window handler messages, you can go ahead and grab the event, modify some parameters, and the system will begin respecting those. So if you wanted to snap-drag the window or do constrained resizing.

Go ahead and use Carbon Events. For other types of specific drags, the drag manager should meet your needs. We really do want you to send us feedback, though, if your app's using the window manager port in a way that we're not providing a workaround for. At this time, in our analysis of the way that developers have been using the window manager port, we don't see a compelling need to re-enable that type of user interface capability or mechanism for you.

So far, the cases that we have seen do not fall within the Macintosh Human Interface Guidelines, and there are an alternative to those cases that we've seen. So we're not going to be providing a generic workaround for this mechanism. Again, if you want to give us feedback, join that mailing list and just send it there.

The Trap Manager: So patching is completely unsupported within Carbon and Mac OS X. It works against stability and it was 68k specific. So the new message is that Carbon Events within an application is providing a great way to modify the behavior of the system in a very sanctioned easy way.

And for other things we're providing hooks within the APIs that were not there before. So the message is that if you were using patching for something, actually on the mailing list or to me, please just send the highest level goal that you've been trying to achieve with patching and we'll see if we can go ahead and incorporate sanctioned official APIs within the OS that you can use to get that going. Because generic patching is no longer supported.

Help. Apple Guide Manager is unsupported and Balloon Help is unsupported. So you may find these things just automatically being respected on Mac OS 8 and 9 because those technologies are still there, but on Mac OS X they're not. So the alternative is to use Apple Help Viewer instead and to use Apple Help Tags. One thing to note is that Apple Help Viewer was not brought back to Mac OS 8.1 in Carbon Live, and so you have to launch your HTML help in a browser.

Printing. There's a new printing architecture in Carbon, but the APIs are so similar that it's almost a one-for-one copy of a name change for your transition, so it's really easy. Game Sprockets. I'm just going to touch on this. There are sessions about gaming in this conference, but Draw Sprockets are going to be supported post-DP4, so they're not there yet. Input Sprockets. On Mac OS X, the HID Manager is replacing this and will be available to Carbon applications for APIs. You don't have to go down into the Mac OS layer and access those APIs on X.

Net Sprockets. We've open sourced, so if you still want to continue using the functionality of Net Sprocket, you can go get the source code and incorporate that directly into your application. And on Mac OS X, Sound Sprocket is being replaced by Core Audio. I think the Input Sprocket and Sound Sprocket sessions are still coming within the week, so be sure to attend those if this affects you.

Networking Open transport has changed slightly. So, MAC TCP is not supported within Carbon. And open transport, the basic change is that when you initialize open transport at the beginning of your application, you now get back a context ref. And now you just start passing that context ref as the first parameter to open transport APIs, and that's pretty much the gist of the change.

So, it's very easy. And Apple Talk APIs are not available in the Carbon API set. So, if you are using those, you should move over to open transport. The stacks are still there. The technology providing that type of networking is still on 8, 9, and 10. And if you wanted to go ahead and access those AppleTalk APIs on 10, they are actually available in the AppleTalk framework on 10. They're just not made available through the Carbon API layer to Carbon applications.

This has been said many times, but threads in Carbon are going to remain cooperative if you've been using thread manager threads. If you want preemptive threads, go ahead and use the multi-processing APIs. And many people ask, "What about pthreads?" So it's important to know that Carbon MP threads are pretty much... Sorry, MP threads are pretty much pthreads on Mac OS X. MP threads, pthreads.

So, plugins and Carbon. Plugins must be Carbonized to work with your Carbon application on 10. On Mac OS 8 and 9, a Carbon application can load and run a non-Carbonized plugin because the code fragments are prepared separately. But on 10, of course, all software must be Carbonized. There are a lot of common memory management architectures use zones for handling the memory of their plugins. On 8 and 9, that's still available, so that'll work. But zones are not a concept on Mac OS X, and so that type of memory architecture would not work for plugins on Mac OS X.

CFPlugin and CFBundle are two classes that we're providing within the core foundation, a new set of APIs available to Carbon developers. And those sessions are coming right after this and starting in the fall. These are actually talked about in the advanced session of core foundation. So if this affects you, I encourage you to go to those sessions.

So, not all APIs that control stuff on Mac OS 8 or 9 or Mac OS X can be brought up to the Carbon layer through one API. And that's mostly because of the nature of the APIs. They just simply behave differently on Mac OS 8 or 9 and Mac OS X. And accomplishing these purposes is not the most pleasant thing for Carbon developers, so before we go into it, we've provided you this pretty picture of a fork in the road, because that's what we're about to do. We're about to fork in the road.

So, let this picture in and get in a good mood so we'll talk about this. As I said, not all APIs can be brought up to Carbon applications. At that time, you have to begin and branch and use OS-specific APIs. So, the basic way that you do that is you factor all of your code that is Carbonized up into your application and factor all of your code that will either run on 8 or 9 or on 10 down into shared libraries, and then you load those as a plug-in when you're running on the relevant platform.

The two biggest ones, well, the first one is hardware interfaces. Hardware access is simply OS-specific, and therefore it's not part of Carbon. The SCSI manager will be partially supported, but that's mostly to support scanners. So for other hardware devices on Mac OS 8 and 9, you'll continue using the Device Manager, the Comms Toolbox, and on Mac OS X, you'll use I/O Kit.

For shared memory on Mac OS 8 or 9, you'll continue to use your current mechanism for however you're doing shared memory. New pointers, this is a common one. Also, attaching to a shared library that has a global data section is another one, and that will work on 8 and 9, but not on 10. For Mac OS X, you have to use the POSIX APIs.

Again, these APIs could not be brought up to the Carbon applications with one single "it works all the time" API, because the nature of shared memory on the two systems is somewhat different. On Mac OS X, you'll need to use the POSIX shared memory APIs and the semaphores for controlling access to those.

So enough with downsizing. I've been talking about all these APIs that we've taken away or that modified. And the good news is that Carbon is also bringing a lot of new technology to you. I'm just going to touch on some highlights. There are sessions devoted to each of these new things. Carbon Events was yesterday.

It's an amazing technology that dispatches events directly to your controls and windows within an application. Completely takes care of a lot of the default functionality that you've had to just cut and paste a lot of code in just to get your app to keep doing what it already is doing today.

That's all been put into the system and default functionality is available. It's really easy to override. The system handlers, you can just stack your own on top of it and override functionality. Or if you don't want to override specific functionality, you just keep calling down into the stack and the system handler will take care of that. And there are many more features that make development easier. Timers are one that stand out as one of the greatest things about it that make your development easier. for idle processing.

An important thing to note about Carbon Events is that it's not required to port your app to Carbon. So a lot of people are concerned about that. You wouldn't have to do anything with Carbon Events to get your application as it is over to Mac OS X or Carbon. However, a lot of the new technologies that are being introduced, like Sheets and some printing stuff, those are beginning to only be available through Carbon Events. But the good news is that it's all gradual adoption. You can install one handler and keep doing everything else via the Wait Next event. Ed Vos had gone into that in detail yesterday in the Carbon Event sessions.

Core Foundation is a set of APIs that were factored down out of the frameworks that we had adopted with Mac OS X's original OS from Next and now made available to Carbon applications in its own framework. And it has a lot of services that are good to use. Unicode strings for easier localization is available. Collections, arrays, and dictionaries, things we all re-implement or get from a framework today.

Preferences management, there's a class that helps you manage your preferences via Carbon so that they just work on 8, 9, or 10. XML parsing, URLs, and plugin support. And another class that I'm not mentioning here is application packaging, the new folder hierarchy and layout. There's a class called CFBundle that acts on your behalf as an abstraction layer to all of the resources and locations of stuff that you've put in your application.

And I pretty much see a bundle and the preferences management class, I would go as far as to say that those are kind of required concepts for a Carbon application. To work well in both environments, you just simply need to use those or else when Apple goes to make some change in the future and you're hard coding knowledge when we provided these abstraction layers, you would break. So be sure to learn about those.

And the data browser, the long awaited data browser. This is a system control for list views. It supports the browser column view and hierarchical list view. And it's used by many system applications including the finder, I think file sharing, Sherlock, and now services. So there's also a session about that. So I'm pointing to these. The core foundation, basics, and advanced sessions are listed here. And also the data browser session. So if you're interested in any of those technologies, please be sure to attend that. companies.

So with Carbon, you used to link against a bunch of stub libraries, but with Carbon, there's just one, and it's Carbon Stub. It's no longer Interface Live, Appearance Live, QuickTime Live, one stub library. On the CD that you received this week, there's a CarbonStub9 and a CarbonStub10. If any of you have been already using the CarbonLib SDK, this is the replacement for the CarbonLib stub library.

And the reason that we did this is because at this time, CarbonLib seeds are a little behind on some APIs. The main one was CarbonEvents. So the APIs for CarbonEvents in Mac OS X are a little further along. And a lot of developers were wanting to get through it right away.

So if you're going to use CarbonEvents, you go ahead and use CarbonStub10, link against it, and run your application on 10. If you run it on 9, you would get link errors. But if you want to just keep right now developing on 9, go ahead and use CarbonStub9. And you can go ahead and use the CarbonEvents APIs.

They're pretty much going to just be name changes only. So let's talk about development options. You have a couple decisions facing you as you proceed into all of this Carbon work. There are two run times that you'll need to consider and think about tools and debugging techniques. So the first decision is CFM versus MacO. So there are pros and cons to each. For CFM, you will get to have a single executable that will run on Mac OS X 8, 9, and 10. On 8 and 9, also plug-in architectures that exist today will probably just work.

The drawback to CFM is that you have limited access to Mac OS X native services, such as the ones I already talked about, and that's when you have to begin doing the factoring your shared libraries and loading them as plug-ins. For MacO, if you were a Carbon MacO application running on Mac OS X, the APIs available on 10 would just be available to your application.

You don't have to do the factor and load the plug-in. But you would be leaving Mac OS 8 and 9 behind because that runtime is not available on those platforms. So those are things to think about as you go ahead and decide what you're going to do for your Carbon application delivery.

Development Tools. Apple has just this week announced our new project builder, and Interface Builder has been there. These are advanced tools for kind of a next generation experience of developing your application. They do support Carbon terms. A lot of news is coming out this week about what these tools can do and everything, so I'm just going to touch on these and recommend that you go to those sessions because they're just reporting on a lot of changes and updates that they're making, speaking to future functionality that they intend to support. And of course, MetroWorks development tools, CodeWarrior and PowerPlant, support Carbon. PowerPlant 2.1 and CodeWarrior Pro 6 is the release going on right now. CodeWarrior Pro 5 also supports Carbon development pretty well.

Let's see. So step one is usually you make all your compiler changes, you modify APIs that you've changed, and then you want to bring up the app. So usually developers go ahead and try to start bringing it up on Mac OS 8 or 9 with CarbonLog. They get to stay on the one platform and just keep fixing bugs there until it's going. And then they usually switch and start bringing it over to Mac OS X.

I'm starting to guess a number of things. In the kitchens, when developers finish carbonizing their applications on 8 and 9, they kind of get the deer with the headlights look when we say, "Well, why don't you try to ring it up on 10?" Because they just, I don't know.

I would say that we regularly experience about three to seven hiccups, that's what I call them, when you try to bring them up on 10. Bugs that just didn't show up on eight or nine. The good news is that, as Bertrand and Scott alluded to earlier this week, Carbon on Mac OS X is developer complete. And by that, we mean it's a very stable environment, providing almost all functionality that you need to carbonize your application.

More and more now, when developers are bringing their application up on 10, the hiccups that I was talking about are actually in your code instead of ours, which was not the case at the beginning. The most common one, of course, is memory access. So you will not believe how many writing tunnels have been existing in your applications on eight and nine all this time until you run it on 10.

So the other alternative is to do all development on Mac OS X. On Project Builder and Interface Builder, our native tools to 10, the performance tools for Mac OS are excellent. And GDB, the native debugger on Mac OS X, provides a UI through Project Builder for this debugging experience. So like I said, the tools experience is changing a lot even this week as the developers are making their announcements. In the past right now, the common experience has been that when you bring your application over to 10, you've had to do two machine debugging. So you have your eight and nine machine. You'd move your app over to 10.

CodeWarrior's debugger would talk over the network to GDB, and GDB would feedback information. And you'd pretty much have your CodeWarrior experience. However, because of this, a lot of times when the app crashed on 10, CodeWarrior would not really be able to come through and report the errors that you were seeing.

And then you'd have to move over to the 10 box, launch your application with GDB, see where it crashed, and get a backtrace. And that's actually a very reliable way to find out at least where your application is crashing. And then after that, developers would usually then go back to the eight and nine machine and step towards that place where they know their app was crashing so that they could view the variables and parameters in CodeWarrior.

Because GDB, again, a lot of announcements are being made this week, but at that time, GDB could not show you the values of variables and parameters for a CFM application built with CodeWarrior. So that was kind of why that process was existing. But again, a lot of this is changing.

So, a bonus of getting your application over to Mac OS X is that our experience from developers has been that they're finding bugs faster. Like I said, memory exceptions are the main one. I have a true story. A friend of mine works at a company, and they had a contractor on board doing their Carbon work. And he kept saying to them, "You should get your application on X as soon as possible." Well, of course we should. But he knew what he was talking about. He knew the benefit that would come.

So, after a while, they got it up on X, and they kind of started realizing, "Wow, Mac OS X reveals a lot of stuff a lot faster than Mac OS 8 or 9 did." And they specifically were looking for this one bug. It was a memory bug. And I think that they were anticipating, you know how, like, after a while, you just start getting a feel for how much time you know you're going to be spending on this bug? And their estimate was two hours.

And, you know, the contractor reminded them. "Try it on X." And I think they found it in 15 minutes. So, again, you know, getting your application on to X as soon as possible will start a lot of time saving for this. And make your 8 and 9 code a lot more robust, too.

So, the tool sessions this week, the first one already occurred, so I'm just pointing it out to let you know, and I hope you were able to make it to that to hear the announcements. Right after this is a session called Transitioning to the New Project Builder. Because you're in this room, you're missing the first one, which is Introduction to Project Builder.

My understanding is that this session is actually targeted towards developers who are used to the Code Warrior experience and want to understand Project Builder better. And then lastly, I want to stress enough, session 196, Debugging Your Applications on Mac OS X, do not miss this session. So, the Carbon Porting Guide is there, Carbon Live is there, getting your application up on 8 and 9 has been there. The part where we've most had to help developers with kind of just hand-holding attention is getting their app up on 10. It's where they hit the hiccups and it's where you need to learn new techniques. So, please don't miss that session.

So like I said, once you've got all that going, you're going to be running your application on 8 and 9, and the fun part is running it on Mac OS X. There are some runtime issues to think about. The first one is that just because the Carbon APIs are included all in one set, that doesn't mean that all of those APIs and their implementation are available on every version of the OS. But that's how it is already today. So for example, if you were using Nav Services on Mac OS 8.1, new APIs were introduced to it in 1.1 on 8.5.

But that doesn't mean all of a sudden those APIs are then available on 8.1. So we're all used to doing a Gestalt check to make sure that the latest version of a technology is running indeed on the specific machine that you're running, and that's true with Carbon. So all the APIs are kind of one big set. You still have to do runtime checks on them. So you still have to do runtime checks to make sure those APIs are available on the machine that you're running.

This is kind of a picture, Scott Forstall showed this on Monday. Carbon is a living, growing thing. And as you can see, more and more APIs have become available with each release of the OS. And that is true. Carbon exposes those APIs to your Carbon application when you're running on the OS that supports those APIs.

And also, the good news about Carbon is that we are indeed bringing back some technologies, like Carbon Events, Core Foundation, Carbon Printing, Data Browser. Another issue to think about when you're running a Carbon application is memory. So, one binary, but running in two very different environments concerning memory. On Mac OS X, an application has virtually unlimited memory. You should use this gestalt to make sure of the memory environment you're running in.

Be careful when using freemem. So, one common technique that developers I know have used is they call freemem and allocate a number of different

So, I was sleepy when I wrote this slide and I was thinking, "I can't put that up today, but be sleepy." So what does that mean? What that means is that a Carbon application, its sleep time that's passed to wait next event is fully supported now. It's not like you sleep but get null events in the interim.

That's just not the way to idle time anymore. You should really use a custom mechanism of your own if you're going to be using Carbon Lab 1.0.2, 3, or 4. Or Carbon Events Timers if you're using Carbon Lab 1.1 or Mac OS X. That's the appropriate way to get idle time for your application.

So, some of you, because of this, are going to be tempted to lower your sleep values down so that you can keep getting time back on the processor. That is not recommended, and we really do want you to switch to these other mechanisms. We're hoping that all of you will be able to switch to passing the constant for the longest sleep time to wait next event. Because otherwise, your application just keeps requesting time that it doesn't necessarily always need. And in the new preemptive environment on Mac OS X, and even on Mac OS X8 or 9, we don't want to be seeing that happen.

So I wanted to point out one sample scenario that we had experienced that revealed the nature of this change in Carbon. One developer, when they launched their application, or when they pulled down their about box, they started scrolling the credits and stuff, and then they stopped. When they brought that app, we were just also like, "Well, what's that?" But it turns out that indeed this application was using or counting on null events to do idle time processing to scroll the text in the about box.

The interesting thing is that if you started moving the mouse, the text just started scrolling normally, but that's because the app started receiving mouse moved events. So that's kind of a symptom that you should keep in mind when you're trying to look out for the nature of this change with Carbon apps.

We haven't confirmed this yet, but another developer was complaining about slower processing of a lot of data in the application, and we're suspecting that this might also be the problem. If they're using or counting on null events to get processing time for this huge calculation they're doing, this would not work. That wouldn't work for them that way anymore.

So a couple sessions that I wanted to point out, Carbon on Mac OS 8 or 9, we'll talk about a few more runtime issues that your app will experience when running on 8 and 9. And session 130, Carbon Level, is a really important session to learn about some runtime issues that will affect your Carbon application when running on Mac OS X. So I would really stress that you make it to that session. And it's a Friday at 5:00 in this room.

And I got a lot of flack for scheduling at that time, so you all have to come, or else I'm going to get it. So, no, I'm just kidding. But it's really critical information, stuff that I'm not going into here because it's going to be in that session.

So Carbon magic, what do I mean by that? And is it really true? Well, like I said, in the kitchens and just talking to a lot of developers, they kind of get this look and they're like, let me get this straight. You're telling me that if I modify my source code in some appropriate way, Apple's going to be able to swap out an entire OS from underneath my application, swap in a completely new one, and I'm just going to work? It sounds, well, magic is a strong word, but it was the one that stuck out in my mind that this person had used.

And the good news is that with confidence, I get to say, yes, really. And I'm not just saying this based on speculation. I'm saying it from experience in some kitchens that we've had. And a lot of the demos that you saw earlier this week, applications are just coming up on 10 after they do their Carbon work. Like I said, traditionally, they're about three to seven hiccups. And it's really fun to watch the developers' face, you know, because they're just, oh, my gosh, you know, like here it comes up. on Mac OS X.

When I first, yeah, I started this job last summer. We had a kitchen in October. And I remember the first time, you know, a major application came up on Mac OS X. And I was standing there, you know, because I believed in this technology. We'd seen it working internally at Apple. But, you know, you bring in developers. And I don't know their source code. I don't know all the stuff they've been doing.

And the developer had finished carbonizing. And we were bringing it over to X. And they had a couple of hiccups. And then it just started coming up on X. And I remember my reaction. I was like, oh, my gosh. You know, and then, of course, I had to switch to Apple and go, oh, of course. Yeah, that, you know, of course that would work.

You know, but anyway, over time with experience, I'd see developers with that look on their face. The second time, I think I was like, I'm pretty sure, you know, because I just had that experience. But now developers come in. And without any hesitation, that happens just over and over and over again. And so it's magic. Well, it's true. It really works.

So if you want to get more information about Carbon, please be sure to see our website, developer.apple.com. If you go to the Mac OS X section, underneath that is a Carbon section. There's a pointer to the SDK and documentation there. You can also get directly to the documentation via TechPub's Carbon. Specifically, the Carbon porting guide, which I've already mentioned, comes in the SDK. Another important resource to keep in mind is the Carbon. That is all on the web.

But that is a comprehensive list of APIs in Carbon. APIs are still being reviewed at this time. So if you go to the website and you see an API and it's marked under evaluation, that means that we're still going through API reviews, making sure that those APIs will work in all the environments that a Carbon application will exist in, like a modern OS, preemptive environment.

Thread safety. And if so, the API will be approved and you'll see that change to supported. But the thing to keep in mind is that those APIs that are marked as still under evaluation, we are not committing to support those. So you just need to know that if you're going to go ahead and use those, that label could at some point change to unsupported. But of course, we've been providing workarounds and alternatives. I just wanted to be clear about what that label means on the spec.

Scott mentioned this on Monday, but I just wanted to mention it again. If you go to this website, developer.apple.com, go to the marketing section, programs, Carbon. I think we have about five right now, five consulting firms that are providing services to just port your application. So if resources are an issue, and I know they are in this industry, and you need to get your application ported, please be sure to visit this website for those services.

A couple other sessions that I wanted to point you to are the High-Level Toolbox Carbon Enhancements 1 and 2. They're also going to go into the types of changes that I was discussing today, but specific to the High-Level Toolbox, so be sure to do those. I'm not going to guess a percentage number, because I didn't think I had time, but a very large percentage of the compiler errors and changes that Carbon developers experience come from the High-Level Toolbox. So be sure to attend these sessions because they contain critical information that you'll want to know as you proceed with carbonizing your application. So this time we're going to move into Q&A and I'd like to ask the panelists to come up on stage.