is Godfrey DiGiorgi. Thank you very much. It's a pleasure to see so many people here today. You are the survivors. There's only a couple more sessions after this. There are feedback forums, which we would like you to attend. And without any further ado, as tenacious as you are, I'd like to introduce Mike Rossetti, Mr. Tenacious himself. Okay. Thanks, Jonathan. That's a joke. All right. Well, welcome. There was this Microsoft engineer and this Cocoa engineer and Godfrey on this train.

Sorry I'm not going there. We'll do this instead. So welcome. No, you're not getting that joke. I'll tell you later if you really want it. They should put a "up", this side "up" on here. Okay. Why are you here today? Well, we're going to be slightly irreverent in this session. Maybe crack a couple of inside jokes. You'll pick them up.

But I certainly hope that this session is going to be full of good information that will help you make a decision in how you're going to approach your development in getting your application onto Mac OS X. And so that's the intent of the presentation today. Now, these objectives that are on this slide haven't changed in years.

They haven't changed since 1985, really. And so I don't think there's any need to go through each one of them. I mean, the languages have changed. The operating systems have changed. But the goal of any framework is to make it possible for you to get your application out and going and take advantage of the wonderful Mac OS technology.

And we think that the Apple C++ frameworks are the key to success in this realm. Here's what we're going to discuss today. Many of you are familiar with Mac App. One more poll question. How many of you are familiar with Mac App? Very good. And there's a number of you who'd like to be a little more familiar because of the C++ term. Is that correct? Okay. We're going to talk about the Apple Class Suites, which is a new offering, or should I say an offspring of Mac App.

And you may remember that, you know, previously Mac App was this huge monolithic framework where if you, it's like a camel, you know, the nose got in the tent and all of a sudden you had this big beast. Well, it's not that way anymore, and anyone familiar with Mac App over the last few years knows that that's the case. We want to talk about a few new Mac OS features and how you can take advantage of those in ACS and Mac App.

And we want to talk about our progress in the C++ standard library adoption that we have. And, of course, to iterate over the Project Builder CodeWarrio development environments. What we won't discuss, this is not a tutorial on Mac App. So, if you're hoping to learn everything there is to know about Mac App, come next year when we'll have about six sessions.

This isn't going to be a tutorial on ACS. We're not going to teach you all about C++. What we're going to do is hit the highlights of our C++ offerings that will leverage your investment in your current C++ code or what you'd like, decide you'd like to do. You know, we want to help you get that killer application out there.

Now, you might have seen this slide earlier. And this is one of the advantages of having a late afternoon Friday slide. You can go rip off the other sessions. And, well, there have been many frameworks introduced since 1985 when Mac App came out. And before Mac App, there were a few other things like ClassGal and some small talk stuff. But Mac App was really the first commercially available framework. And some other frameworks like to roll out their pedigree like there's some royal heritage associated with it. But with Mac App and ACS, we think... we've taken the next step.

So, 7 of 9 in this slide represents Mac App Release 15, and then R2D2 represents ACS. Well, how does this all fit together? Essentially, we want you to take your investment in your product, your key

So I gave a little bit of history on Mac App for those of you who aren't familiar with it. It started in Object Pascal, and over the years it's migrated to C++.

And it's gotten away from the monolithic class hierarchy approach that it had. And now we're introducing, well, we introduced ACS a couple of years ago, but we're able to productize it now so that you can actually download it and use it in your applications without pulling in all of Mac App. So I'm going to talk about that a little bit more in a second. Let's make sure I don't miss a note here. It's about Mac App and a lot more. It's maturing offspring. Let's see.

So, I want to emphasize this ACS side of things because now I don't want you to have the wrong impression about Mac App being this huge monolithic framework. For example, Tom's going to talk a little bit about C Carbon Event, which is a thin wrapper on the Carbon events that you've been hearing about all week.

Well, this C++ wrapper class on Carbon events provides you nice, convenient accessors and mutators for that Carbon event. And pre-flighting, a little robustness, you know. And so instead of checking for no, we'll throw an exception or something like that. Things that a C++ person really wants to see.

All right, this is the way up until last year or so an application written to Mac App might have looked like. Before that, it would have just been Mac App. But we introduced the Apple Class Suites. That's what ACS is. I think I forgot to mention that. And so your application mixes in a little Mac App and a little bit of the Apple Class Suites. Now, you can still build your applications this way, much to the relief of those who have a lot of legacy code in here. But this is no longer the only way to do it.

You could just use ACS. You could just pull in C string AC, which is a thin wrapper on the standard library string class. And the reason we did that one was because we wanted to provide a little compatibility with resource files and conversion to CFString, things like that. And I mentioned Carbon events.

And you can build ACS as a static library or as a dynamic library if you want and take advantage of everything that's in it or just pick and choose. But what's in it? So here's a list of the suites, the class suites that are available in the Apple Class Suites.

These suites comprise ACS. And they're basically the conceptual children of Mac App over the years. We've started to distill them out. Mac App pioneered things like dependencies and adorners and commands and things that are now written about in design patterns books. So we allow you to take advantage of that without pulling in all of Mac App if you choose, or you can pull in the heavier Mac App classes.

Of course, everything we do in the C++ Frameworks group is buzzword enabled. If we didn't use standard C++, the cost to you would be much higher. You'd have two different types of iterators. You'd have the Mac App ACS type of iterators, and you'd have the standard library iterators.

Well, why do that? So we've been moving to using standard library iterators, standard containers. In fact, one of the suites we provide in ACS is a thing called FTL, and it provides some compatibility with the standard library iterator classes. I believe Tom might mention that. So I won't steal his thunder thumper.

You'll cut that, won't you? So, the other thing is that we try to make it easy to take advantage of those great Mac OS technologies. One of those is AppleScript. Use AppleScript. It's wonderful. It makes products very valuable to people. Look at Photoshop. They used scriptability a long time ago. Well, Mac App makes it possible with very little effort. Scriptable, recordable, attachable.

Now, most of you know what scriptable is. I think all of you know what scriptable is. Most of you know what recordable is, but attachable? I mean, this is really cool stuff. You can attach scripts to documents that you save that do things like if you try to open a document, they ask for a password or do something like that. It's way cool stuff, and we make it easy for you to use this.

I believe in Apple script, by the way. The other key point I'd like to make is that Apple Class Suites works with other frameworks, such as Power Plant. In fact, we do have an example of that, I believe, in the release that we have called the counter example.

Well, with this brief introduction, I'd like to introduce Tom Becker, who will give an architectural overview of some of the work that we've been doing, and with some emphasis on how it will affect your code and some topics about some of the lightweight classes. Tom is an invaluable member of the team, and I certainly heartily welcome him up on stage with me. Okay, thank you. Tom.

Here's a clicker, by the way. Now what button do I press? That went backwards. OK. All right, so-- What I would like to do is go into a little bit of technical detail about some of the design issues and architectural features in what we've got pretty much focused on the current release, the stuff that is new that's available right now if you go to the developer tools website. And so we're going to talk about the Apple Class Suites and how they work by themselves, talk about Core Foundation and what we're doing with that, what we're doing with standard library and Carbon events.

Okay, so the basic idea of Apple Class Suites, as Mike has explained, is that it's a lightweight utility class library. I wouldn't necessarily use the word framework to describe it because it doesn't really affect the way that you do your programming. It doesn't affect your overall flow program or overall design. Instead, it's lots of very useful C++ classes that you can take advantage of anywhere in your application that you feel the need to. And it doesn't require Mac App. So the emphasis on this has always been lightweight, efficient, easy to use. And let's see.

Now, one of the new examples that we've got is the counter example, and that's an example that DTS did that is written in Power Plant, and it shows how you can use ACS in conjunction with Power Plant, and it shows really how easy it is. And we just had to do a couple of little tweaks in ACS in order to make sure that it would go along with Power Plant's way of doing things. So that means, for example, if any code in ACS throws an exception, it actually throws an L exception so that the standard Power Plant exception catching code will catch it.

And so the idea there is that ACS is very good at fitting in, and that's the general philosophy that we want to continue with it. Okay. And, you know, it's placing the emphasis again on being easy to use, and in order for it to be easy to use, it has to work the way that the calling code expects it to work.

And there are a lot of classes in ACS. I mean, you saw the diagram that Mike showed with all of the suites there. And so I can't really go into it all in detail. But if you're doing some work in Power Plant and you're going, gee, I wish there was a class that did this, take a look in ACS. Like we've got a really nice class for working with QuickTime Atom containers.

We've got a really nice class for working with Carbon Events. And there are also some classes like Templatized Handle Locker that works better than the one that is built into Power Plant. And you can just use it. The footprint contribution on something like this is in single-digit number of K bytes kind of thing. It's a very, very small effect. You pay only for what you use.

There are a couple of different ways you can use ACS. If you are using Mac App, you're already using ACS. That's pretty easy right there. Like I said, you can create Power Plant graphical applications and use ACS in those. You can also, if you have your own framework or you've got a different framework that you're using, ACS is something that could really help you out. It helps us out with Mac App. It could help you out with your framework. You can also do things that don't have a graphical interface at all. Several of the ACS examples that we've got are for command line tools.

Let's see, so now moving forward, I want to... Let's see, switch to demo. We've got it. And show a little bit of what we've got with the Carbon Event Support that we have in Mac App. And so this is the standard Mac app skeleton sample application. And this is, can you see right here where the CPU monitor is? And now, actually it took a little bit of work to put this demo together because we actually had to find something where a Mac app wasn't already incredibly well behaved.

But we were able to find that there actually is an issue with mouse tracking, so if I click, you know, just hold the mouse down, you can see that we're doing an awful lot of, you know, while not, you know, while still down, mouse tracking in here. So we're taxing the CPU pretty heavily. And of course, if you do this in your application, what's gonna happen is your customers are gonna ask if all of your programmers are rejects from the Word 6 project.

And And so you go, gosh, what can I do about that? And the answer is you can actually switch to using Carbon events. So here's the Carbon event version of Skeleton. I'm going to click the mouse down. As you can see, I'm doing mouse tracking and auto-scrolling and stuff like that, and the CPU usage is quite reasonable.

And the cool thing about this, you go, well, what do I have to do in order to do this? And the answer is going to come up in a future slide, But it's pretty easy. So, there we go. In fact, it's one line of code. Let me actually go ahead and-- There's the line of code. F use Carbon events equals true.

This is the very first release where we've got Carbon Event Support in the framework. By default, we're shipping with it turned off. We're being a little bit conservative about it. It's the sort of thing where there may be some stuff in your application where you might need to write some code in order to fully utilize the Carbon Events.

What we're heading for is a future release where it's going to be turned on by default and you get all this stuff for free. Actually, I'm being a little bit fast and loose here. I actually changed two lines of code. The other line is I changed skeleton application to Carbon Events so you could see which is which.

So let's get back to where I was. OK. Now, talking about some other really cool stuff that we've got in release 15 is we have a set of C++ interfaces for Core Foundation. If you're using Carbon or if you want to use Mac OS X, Core Foundation is essential for doing that. And what we're trying to do is we're trying to make programming with Core Foundation natural for C++ developers so that it's object-oriented, the syntax is as simple and straightforward as it can be, the error handling is done through exceptions the way that you would expect it.

The way to think about it, and actually I should give credit to Andrew Demkin on the Finder team who helped us out with some really great ideas for how to structure these interfaces. And so he's one of the key people who's responsible for making them as easy to use as they are. The idea is that we're defining the interfaces that you would expect ought to have been there always. And what you have to do in order to actually start using Core Foundation in an object-oriented way is include the header.

And then all of your Core Foundation type references that you already have now are object references. If you just go and you can start making method calls on them and it just works. The one caveat, one thing you have to kind of watch out for is if you use C++ syntax for calling Core Foundation, if there's an error it will throw an exception. If you use the procedural syntax, which then if there is an error it will return a code or it will not return anything. But it won't throw, you know, because you're just calling this procedural interface. But I think that's also what you would expect too.

Okay, now another cool thing that we have, and this is really something that we're just getting started on. It's going to be something that I think will be very useful. But what we've got is we've got the basic idea, we've got an implementation which is out there, and we want to get it out there and get people looking at it and get people thinking about the issues of how well does it work for them, and giving us feedback on the design and on the implementation and what other stuff they would like to see. And this is bridge classes between C++ standard containers and style programming and the Core Foundation containers. And so the first class that we have is the Foundation Template Library String class, and it stores a string using a CFString.

So that it's fully compatible with the Mac OS X APIs for Unicode strings and for all of the new features that you really want to be able to connect to. But you can construct that string using standard template library iterators, you can construct them from standard library strings, you can use standard library algorithms, you can use standard library code, you can use standard code from the library. So that's a really cool thing that we're going to be able to do. And you can build your own version of the String. And it's going to be really cool.

And I think it's going to be really cool to see how that works. So that's a really cool thing that we're going to be able to do. And you can build your own version of the String. And it's going to be really cool to see how that works.

I want to give a little bit of a caveat. This is not intended to be the absolute best string for doing absolutely everything. You're going to find that in some cases you really want to use a C-CF string, which is our object-oriented C-F string. In some cases, you're going to just want to use standard strings, or you may have a library that has come in from somewhere else that is implemented using standard strings. That's just fine. Just keep on doing that. And what FTL string can do is it makes it incredibly easy to build this bridge or connection between the standard library way of doing things and the Mac OS X interface that you want to connect to.

Okay, now what are we actually doing with the standard library itself? Our basic philosophy is the standard library is the wheel that is like the best wheel. We think it's great. We are moving to adopt it. We have done an awful lot already in adopting it. There is still more that we need to do. We're taking a stepwise, incremental approach towards doing it, in part because we want to bring you along with us. And make it so that it's easy for you to transition to the benefits of using the standard library and your stuff.

And we also want to make sure that we're getting it right as we go along. But the basic idea is that we're Apple C++ frameworks. We're making it easy to use C++ on the Mac. That means we're also making it easy to use standard C++ types on the Mac.

And so for where we're at right now in this process, If you use Release 15, you will be using standard strings. And we have put a lot of work into compatibility so that instead of using standard string directly, we've created the CstringAC, which is a very thin wrapper on standard string, and it will automatically convert Pascal strings to standard strings for you. And we're making it very easy to convert back and forth in order to work with the toolbox because that's something that we know that you need to do. So that's an area where we're already well along on the conversion process.

And let's see, the next one, as far as standard containers, we're using them in several places now. And it's something that you really ought to consider using. The legacy containers that we've got, CListAC, CDynamicArrayAC, the standard containers are going to replace those in pretty much everywhere in the framework.

I think we'll continue to make the legacy containers available so that if you don't want to change your code, you don't have to. But as time goes on, we really are going to be moving towards using the standard containers. We think they're more efficient and they're easier to work with.

And now as far as streams are concerned, there are some really nifty features in ACS streams. And we're looking at ways that we can make it so that those features will be available with standard streams as well. But for right now, we're continuing to use ACS streams because things like counting streams and handle streams are so incredibly useful. And we're not going to get away from that right now.

Okay, for Carbon Events, check out the C Carbon Event AC class in ACS. It makes it really easy, convenient, and safer to access Carbon Events. Whether you're using Mac App or not, actually, especially if you're not using Mac App, if you're going to look at one class, this is the class I would recommend that you take a look at because it will make it an awful lot easier for you to get up and running on Carbon Events if you're using your own framework or if you're using a different framework other than Mac App. If you are using Mac App, then you might want to consider writing one more line of code. Okay, so let's bring back Mike.

Thank you, Tom. Good stuff there. Let's talk for a minute about the challenge of getting your microphone in your back pocket. I should have shaved this morning. Okay, I think you got the impression from Tom. These aren't slides, these aren't just slides. This stuff actually works. It's ready for you today. Go to the Mac App website, download ACS, take a look at it, give us some feedback, tell us if you like it, tell us what you don't like about it, we'll fix it.

But you can move your applications to Mac OS X today and take advantage of these features. And there are people who are actually doing it. There are some in the audience who have already moved R15. In fact, there are some in the audience who moved R15 after it was posted on Tuesday. There are wonderful PowerBooks that they are carrying around with them using AirPort today. Incredible technology, isn't it? I'll mention a couple. Artma Medical Technologies, they've got a couple of applications.

Virtual Implant Navigator, Virtual Implant Simulator. They use Mac App and QuickTime. Scheduled for a summer release. This is an application that helps dentists in the planning and drilling of dental implants. I was hoping to have a demo. Tom Myers and his crew, Pete Hawk, this is BD Biosciences, is that right? That's Pete. That's Pete. Well, I mentioned Tom anyway.

BD BD. They're porting a suite of applications and drivers to OS X that use the C++ framework. Flow Cytometry. This is like blood analysis. Another wonderful demo. They're in various stages of development, looking to launch six applications and three drivers by the end of the year, followed on by three more. TextCo has -- that's Anders, isn't it? Anders Pitta.

Texco is his client. Gene Construction Kit 2.5. Okay, coming, he says on here, possibly a beta test version within a week. And, okay, so what else? I mentioned Calc and Apple System Profiler, and Calc is about my level of capability, and I'll let Mark take the real complex Apple System Profiler. We would have had a really great experience converting Calc. It just was too short of an effort. It literally took minutes of work. It essentially took about five minutes to set up the project, builder project, then I compiled.

And unfortunately, I shot myself in the foot by changing do-need-disk-space, which will be familiar to old Mac appers, to a const C++ function. And as you know, when you change a function to const, it has this ripple effect. But I'm happy to say I've shot you all in the foot, too. The lesson for this is do not postpone your day of constness. The other thing I did was I used pre-built resources in the example, so when you take a look at Calc, you'll notice that all the resources have been pre-built in there.

The reason for that was because when I did this project late last year, the resource compiler wasn't quite ready. It is ready now, and so we'll put an update in that will actually build the resources for you using project builder. It wasn't a big deal. So, quick build, and Calc was ready to run as an honorable Maco citizen.

Let's see, now let me bring Mark Dawson up. There we go. Let me bring Mark Dawson up. He's the author, I guess I could say, of Apple System Profiler. And Apple System Profiler is a wonderful application for demonstrating Mac app and ACS capabilities. I'll let Mark talk to that. But it is fully scriptable and recordable, isn't it? Is it recordable? No, it's recordable. Okay, well it's wonderfully scriptable. Yes. And I'll let him address this. Mark? Okay.

Well, for those of you who don't know, Apple System Profiler creates a profile of your software and hardware on your drive. On OS 9, it can find a lot of stuff. On OS 10, it can actually, using some routines, find even more stuff on your drive. Using Mac App, it was extremely fast to make the port.

Some of you were last year, just before, actually a few hours before the demo, I was able to demo Apple System Profiler coming up on OS X using Carbon and Mac App. In the worldwide beta, I was able to ship a product, and then around December, I was able to port in about one week with the code I had to Mac O. And Apple System Profiler ships on OS X as a Mac O application in the 10.0 release and on.

*starts to cough* It was a very quick transition, I'd say two weeks for the UI. Going from the R14 to the R15 was only about a couple days. And most of the transition time I took was to use a lot of the new ACS classes that help a lot.

Right now, I have two versions of Apple System Profiler, one for OS X and one for OS 9. The OS 9 one still uses CodeWarrior 4, just for compatibility reasons. I can ship the same exact source code with only a few power defines from R15 and Mac OS and also OS 9.

So it's just a matter of one's compiled on CodeWarrior and one's compiled on Project Builder. So it's actually that easy. And what really made that transition smooth was using the ACS suites. As Mike said, my application is very scriptable. I think, I believe in the Carbon book, it is actually an example of scripting for Apple programs.

It's probably the next most scriptable program after the Finder. And what has really helped me was the ACS classes for scripting. You just take, basically you shove a value in a variable and you pass it and Mac App takes care of everything else. I don't really know how to script an application, to be honest. If something breaks, I have to go to Tom. Because it's so easy, I actually haven't had to learn it, which may be good, maybe it's bad, but I haven't had to do it. And Apple System Profiler is fully scriptable.

Again, the transition was very, very small. Most of the problems I had is I was the test case, the big app test case for most of Mac App as it was being brought up. And as part of the Mac App team, if I found something, I had to fix it.

So, actually Mac App has been tested on Apple System Profiler and I use quite a bit of Mac App and all my tabs and controls and everything. Unfortunately for some of you, I don't use pop-ups. So I know that's one of the things that's come up. But it has been a very... It's been a quick transition. It's gone very smooth. Again, I say the ACS classes have really, really helped.

I'm as much of a developer as any of you. I run into all the same problems. I read the Carbon list all the time. And ACS again and again has helped me. And then Mac App, I really haven't had to do much work. It's outside of the initial Carbon transition. So for me as a developer and not just reporting to Mike Rossetti over here, Mac App has been a great win for me. I just haven't had to do a lot of work.

I guess the lessons learned, things you all will run into. Carbonizing will unearth bugs. It did for me. You'll be really lucky if it doesn't for you. Most of it, a lot of times it's memory bugs. OS X is a great platform for catching memory bugs because if you write to zero, instead of the system letting you do that and corrupting someone else, it just crashes. And if you've been to any of the GDB sessions and stuff, they have wonderful tools for finding leaks.

Something equivalent to Spotlight you can do using GDB and it's really been very wonderful. The other thing I ran into a lot, and it's my own programming fault, is on OS X, on Project Builder, Bool is four bytes, not one byte. And if you have structures that require that you know where things are in the structure, you'll lose.

And I had. And those were my bugs. Those weren't Mac app bugs. I have to say they were just mine. Those are the kind of things I ran into that had nothing to do with Mac. But again, the stuff I had to do with Mac app went very, very smoothly.

The things I've done that changed a little with ASP, I have a single source code. I've included the Mac app sources into ASP. A lot of that was done just because so the build systems in Apple could compile them. They can't compile right now sources that are outside and libraries and applications together, so I've had to do that.

The other thing I did is just to save time, I ripped out files that I didn't particularly use. That saves time compiling. The other thing I did, actually this shows up in a post. If you have developers, you can look on the developer seed sites for ASP. But I've created a static text control using the current static text in Mac app uses an edit text view instead of the Carbon static text control. And I've converted that to use that. And it's helped a lot since the edit text doesn't give you anti-alias text. And that should be showing up in a future Mac app soon.

But again, the Mac app has made my transition a lot. And ASP is a big app. Well, probably medium, I'd say. It's probably about 100,000 lines of code. So it's not tiny. I know some people have a million lines of code, but it takes a while to compile. So I'll leave it over here to Mike Rossetti. And just leave you with it. Mac App has really made my life-- Thanks, Mark. Thanks, Mark. Thanks, Mark.

Some of you saw this slide a little bit earlier in the week. And I'm not actually with a slide. I'm not actually taking a license with what Ed said. Ed Bose, who's done incredible work on the Carbon event model. He was explaining, of course, during the session how back in the early days, this is how you wrote your application. And all the applications had to write their own event loop and their own dispatcher and their handlers for whatever events came through.

And then he explained that, of course, 16 years later, after he graduated-- he graduated 16 years ago. Don't want to give the wrong impression-- how the new Carbon event manager actually handles a lot of this for you. But now, those of you with some experience in Mac App know that we were doing this 16 years ago in Mac App because this is the responsibility of a good framework, is to take those things that you do all the time, that everybody has to do, and provide the implementation of them.

So we're delighted that the new Carbon event mechanism provides this for us because now we can take-- it's a wonderful fit for the event dispatching that's implemented in Mac App. And this just fits right in. So you'll see that the dispatcher in Mac App will become extremely simple or maybe just disappear. So we're very happy about this. But we did it 16 years ago.

So one perspective is when you build your applications, this is the model that you could build against. And there's nothing wrong with this. I mean, build a Carbon if that's what you like to do. But how does Mac App and ACS fit into this model? Well, it provides a nice higher-level framework on top of the Carbon APIs and the Carbon low-level framework that they're providing in Carbon Events.

And if I say so myself, it's a perfect fit. I mean, do you want exceptions thrown when there's a problem in Carbon? Yes, I think you do. Do you want robustness in the interfaces so that if you pass a bad value, that's caught? Yes, I think you do. So if you're using C++, this is the way to get it. ACS or Mac App provide that for you.

So what does Mac App and ACS Release 15 bring to the party besides adding 15% to 10? Just to kind of go over this quickly, Project Builder support, the Core Foundation classes, the Carbon Event support, Standards Strings. I think Tom said all of this. Have this slide get in here. And ACS is available all by itself if you choose.

And in Project Builder, I wanted to hit just a couple of highlights here. You can build the Apple Class Suites as a static library or as a dynamic framework, ACS.framework. We provide some ACS stationery, so if you want to write Hello World with ACS, you can put that together very easily. Mac App projects are provided as well, debug and a non-debug version. Right now, we're only building them as static libraries. ACS is incorporated into it. Now, you might ask why we don't provide a framework target for Project Builder.

And the reason is because all you Mac Appers like to touch the code. So we're going to leave it that way for a while just to see how it works out. But ACS Framework is fine because I think very few developers have any need to actually touch the ACS code at this point in time. And, of course, the example projects.

CodeWarrio Pro 6 support for all of the usual targets, including 68K still. And we're going to provide, fairly quickly here, some CodeWarrio Pro 7 projects so that you don't have to do that for yourself. Now keep these things in mind. Budget your time to manage the changes that you're going to have to adopt as you move to Carbon because there's changes in the APIs and the tools. Project Builder and GDB and GCC, etc. GCC, for example, has helped us identify a number of problems that were in the old framework that we never saw with the old compilers.

So running your code through this new compiler will expose probably some errors you'd be surprised at. There will be a cost, of course. You know, there's a little learning curve in that. But I think we believe that the benefits far outweigh the costs. So be prepared for the learning curve. And so I call this like the three curves of the development biorhythm. And I think they're coming to a curve right now. But once you get over that, things are going to look a lot better. Important future directions. So keep up the work on Carbon Events.

Provide a nice wrapper around the data browser, something that's long been requested, which is an MLTE view, TMLTE view, whatever. More work in the standard libraries. Tom talked about Unicode strings. Plus the same work that has resulted in the Apple Class Suites, where we've kind of pushed down on Mac App and stuff have come out on the bottom in ACS. This is going to continue.

I mean, this is an evolving process. So I can't promise what you're going to see there. But I could say that perhaps you're going to see things like dependencies moving down there, or maybe event handling. It'll become behavior-based. I'm just spouting off the top of my head here.

And the thing I want to stress about all of this, the future directions and that is, whether you're an old Mac apper or a new C++ programmer, you never used a framework or you've used some other framework, I want to stress that you take a look at ACS, Apple Class Suites, so that you get the benefit of our working with the people within Apple to make sure that those capabilities are in the framework that you want.

Let us know what they are. We'll bring up email addresses. There's a Mac App Dev mailing list. You can send mail directly to me. But if we know what you want, we'll respond. We try to do that. That is our ultimate goal. We want to have fun. We want to have a great framework. But we also, I think, need to make sure that you get what you want. That reminds me, we hope you have a good experience. You know, the definition of experience is, experience is what you get when you don't get what you want.

We don't want it to be that way. We want you to get what you want. And before Godfrey comes back up, I'd just like to thank the developer community. It's given us a wonderful response and feedback so far. And it's helped guide our efforts to provide ACS and to do things like make sure that Carbon events work and that your applications are going to be speedy under Mac OS X.

And thank you for that feedback. Thank you for the support that you provide each other on the mailing list and the news group because this is critical for developing a consensus in the community and making sure that we do what you want. So please keep that good work up.

And also, I have this little kitty cat up here and some of you know what that means. I'd like to thank one of our developers for his gift, Norio Ota, who's sitting back here. And just wanted to tell you that if you want to get faster email response to your applications, you can do that. to your bug reports and questions. Gifts are great, but wonderful Mac OS X applications are even greater, so we encourage you to do that. Godfrey? Thank you, Mike.

So the whole point of the Apple C++ Frameworks is to continue to support all the developer needs, new Apple technologies, and the industry standards going forward. This is a fantastic set of technologies for people who are Carbon developers, who want to move forward, who have a large body of C++ code that they want to move from another platform and want to stay within the C++ environment.

Information Resources. Those of you who have been through the other tool sessions have seen most of these addresses before. Our overall page for Mac OS X tools, developer.apple.com.tools, and the C++ Frameworks webpages at the developer.apple.com.tools.macapp. We get a lot of hits on these pages. We've gotten, I think over the course of the week, we've had over 10,000 hits when I called in last.

So that's quite a bit of activity. And we have a master mailing list for all of our mailing lists, I mean a master webpage for all of our mailing lists. Mac App Dev is one of them. There's also the Carbon Dev, Cocoa Dev, Project Builder users. All of these would be useful to you as resources.

We decided to give you a back road map through the show since this is Friday, very nearly the last sessions of the day. These are some of the sessions that hallmark our tools, various other things that you could use, and when you get your DVDs, because everybody at the show is receiving DVDs of these sessions, you can review these if you've had to be at other sessions over the course of the week. Questions about C++ frameworks? You can always contact me as the Technology Manager for Development Tools. I'm very interested in your feedback, ideas, directions. And Mike Rossetti for questions on the frameworks themselves, who is always extremely active about answering those questions.