Good morning everyone. Very excited to have you all here today. This is the first session of our Tools of Track for the Worldwide Developers Conference. And we have a lot to talk about this week. We're highlighting tools because Mac OS X creates such an enormous range of opportunities. Both in applications, drivers, and in the tools themselves.

Now, we are all dependent upon tools. You'll see tools through the entire show. They're essential for all of us. So we all know the difficulties of working with the new operating system with pre-release tools, with tools that aren't quite ready yet. and what we want to do is we want to make Mac OS X the premier developer environment.

To do that, Apple is very, very serious about developer tools and about making sure that you have everything you need to bring your applications to market. In this session we're going to cover our goals and strategy, how we're going to get there, we're going to give you an overview of the Apple tools, and we're going to give you a look at the third party tools that are coming available and some of which you have in your bags at the show today. And to start that, I'm bringing to the stage Steve Naroff, our Senior Director in charge of Java and Cocoa development.

So I'm just going to take five minutes and try and tell you what we're up to. One thing that's really important for everyone to hear, sometimes I get emails, voicemails, or just talk to folks in the audience who really sometimes want to understand whether Steve Jobs and Avi Tavenian and other executives at Apple are really committed to tools.

And the answer is yes. And it's not just because it's the right thing to do for you guys, even though that is the prime motivator. It's also because it's just in their blood. It's in my blood, it's in their blood. And ever since I've been working with the two of them for 15 years, like Avi has worked with Steve, tools have been a focus of their work and of our strategy. So I think you could be assured. That A, we're making great progress and I think you'll see that. But B, this is a long term proposition here. This isn't something that's going to change overnight.

So we want to participate, okay? For a while there, Apple wasn't participating in this activity. It was purely leaning on the third party community for great tools. The good news is, even though we're participating, even though we're investing, even though I think we're doing great work, we are also embracing our third parties.

We work closely with Metrowerks, we work closely with Borland, we work closely with a lot of the companies you're going to hear about today. And the simple fact is we can't do it ourselves, okay? The space is too complex. And the types of problems you guys are solving are too broad for Apple to have or to be the sole purveyor of tools. So it's pretty clear that that's our strategy, okay? So I'd like to close by... by saying, and David Koehn.

One of the reasons we do tools is to support our framework and platform initiatives. However, Carbon, clearly Metroworks has been a leader in the community for years, again before we decided to reinvest in tools, so clearly Code Warrior is a superior environment for doing Carbon development. On the other hand, if you're doing pure Java development, when I say pure Java I mean not programming to web objects. Not programming to QuickTime and so on and so forth, but just doing swing development because you need that cross-platform application, then JBuilder is going to be the sweet spot for that type.

For those of you who were in the Java talk, it's the moral equivalent of what I was talking about in the Java talk, which is decide where you fit in terms of what you're trying to do. You're going to make a framework choice based on that. Then you're going to make a tool choice based on your framework choice, or at least the framework choice might be influenced by the tool choice. All those things factor into the path that you guys need to take. Certainly many of you have lots of legacy code. In that case, the answer is fairly simple.

I'm speaking to people who are doing new things. People doing new things have to basically reflect on what it is you are trying to accomplish and make decisions based on that. With that said, I'm going to bring up Dave Payne. He's one of my development tools managers. He's going to take you through the details.

Hey Dave. Thanks Steve. Here you go. The magic button. Okay, many of you may have seen me before here on stage at WWDCs in the past speaking about developer tools. I'm responsible for Project Builder, the Compiler, Debugger and Performance Tools for Mac OS X. So we'll take a look at

So with Project Builder you can do all the development that you need to do for Mac OS X. So again there's a whole variety of languages, the primary languages that we support on the system. C, C++, Objective C, Java. With these you can develop for all of our frameworks, Cocoa, Carbon, Java 2 as Steve showed you in your previous session.

We've got a great Java environment. And now WebObjects 5, a full Java environment for WebObjects that Builder with the new developer tools CD provides support for that. You can also do Unix development. You can write tools or server daemon processes that you might want to interact with from graphical applications. And then I/O Kit kernel extensions and device drivers as well. There was a question yesterday about Objective C++ development. So we are going to be resurrecting Objective C++.

For the purpose of allowing Cocoa applications to use existing C++ libraries. I'm not going to go into that in detail in this session. If you want to hear more about that go to the compiler technology session on Thursday morning. But through all this technology you can build the full array of things that you'll need to do for Mac OS X.

Sometimes people ask us, so is Project Builder real enough that I can use it for big projects? So we use it for all of what we do for Mac OS X. There's over 250 projects that go into Mac OS X at Apple that are using Project Builder today. There's a lot of facilities in there to really help with team development. So of course every user has their own preferences for the application. But in addition, for each project, each user has their own settings for that.

So their own active build styles, their own active target, their own bookmarks, their own breakpoints. And all of this is integrated with the CVS source code management system, so you can really work effectively as a team. Unix has been known for a long time as a great development environment in terms of the sheer power underneath it, but it's been very complex. So again, Project Builder makes things simple for you, but there's a lot of power that you can tap. The GCC compiler, we compile all of our code for Mac OS X with this compiler.

So I've talked about that we leverage a lot of open source tools. We are working to actively give back to the community. We've started giving GCC patches back to the Free Software Foundation. We've signed the copyright assignment agreement with GDB as well so that we can do that with GDB changes.

So for example, giving Objective C support back in both cases. Project Builder uses the Jam build tool, but if you need to know about that, then we're doing something wrong. CVS version control, the file merge utility uses diff, so we take advantage of a lot of this power.

So from the very beginning, Project Builder has been designed especially to develop for Mac OS X. And in order to understand Mac OS X development well and in order to understand Project Builder well, you really need to study and memorize and learn the system overview manual. Now you'll find this in HTML and I believe even PDF on the system. You can order hard copy like this from Fat Brain.

There's a lot of concepts that you'll hear about throughout the week that are documented in very good detail in this manual. I'd highly recommend that you get a hold of that and really study it in depth. So for example, Project Builder builds properly formed bundles. This is all your application packages themselves. Plugins, frameworks.

Inside bundles, you can put multiple localizations of an application. So English, Japanese, German, French. In fact, in the new developer CD, we've got Project Builder localized into Japanese. But you've got to build bundles in order to support this. Project Builder, you can localize files directly from there. If you're using Carbon and Carbon resource files, Apple strongly recommends that you know what you're doing. You can now use flat data files to store the resource manager resources in so that you can store this in a file system agnostic way for file systems like UFS or NFS that don't support resource force.

Again, this is the default way that Project Builder builds on Mac OS X. We generate Maco binaries, which is the primary format for binaries on Mac OS X. This provides you direct access to all the systems that you're building. This provides you direct access to all the system APIs that we've got throughout the system. And that also enables full use of all of Apple's Mac OS X tools.

Frameworks. You'll hear a lot throughout the week about frameworks. It's a very fundamental concept in Mac OS X. These are Mac OS X's shared libraries. So, for example, Project Builder itself, the application is a very small application that links with a couple of large private frameworks and a couple of smaller frameworks. We've really factored the application out in that manner.

Project Builder gives you full access to all your system frameworks. So, for inclusion and searching of header files, you get direct access to pre-compiled headers for our umbrella frameworks like Carbon and Cocoa and application services, core services. As well as, if you do finds across API documentation, you see book icons that let you go directly to the API for that.

You, of course, can build your own frameworks for your own applications. And then Project Builder gives you facilities to allow you to test your application with your development versions of the frameworks without needing to install either of them fully into the system. So, you don't have to trash your working versions that you may be depending upon.

Moving on to other tools, you saw a great demo yesterday in the keynote when Scott Forstall showed you Interface Builder. This is our user interface construction tool for building Aqua compliant user interfaces for Cocoa and Carbon. There's a lot of great new support in Interface Builder for what we call guides that let you see exactly when you're compliant with the ACWA guidelines. A very powerful feature. To learn more about that, come to the Interface Builder session this afternoon. This is integrated with Project Builder in that you can directly launch it from Project Builder and move back and forth.

Interface Builder makes it very easy to use Cocoa's outlets and actions paradigm. So you can directly set up your connections there. And with Carbon, you can create Carbon nib-based applications with Interface Builder. This really is the easiest way to use the Carbon event model. So you might find that useful as well.

We've got a full suite of performance analysis tools. As you've heard, the performance characteristics of Mac OS X are much different than those of Mac OS 9 in some cases, so it's really important that you use these tools and understand those differences and optimize for X. So there's a variety of categories here to watch what your CPU is doing. You can use tools, the sampler graphical application or its equivalent command line tool sample to see where your application is spending its time.

To examine what's going on with your memory use, we've got tools like malloc debug and object alloc, graphical tools for displaying where in your application you're allocating all your memory from and how many objects you've got at various times. There's also a set of command line tools, heaps, leak and malloc history. Check out the man page of malloc to see information about malloc history. For all of these tools, go to the performance tools session on Thursday afternoon. Robert will give a great demo at that point.

Quartz debug shows you really, are you drawing too much on the screen? Sometimes you'll be drawing the same thing multiple times in the same place. You don't even know it. You can't tell, but it's taking time away that could be used for other things in the system. FS usage for file system usage, seeing what all calls you're making. SC usage for system call. VM map for VM usage. Top for overall system performance analysis. We've got really a full suite here, and it's important that you take advantage of this.

So how do we deliver this? On the Mac OS X Developer Tools CD. So as you've seen, we shipped this CD with Mac OS X. We think it's really important that we get the development tools out there and widely available for people to really start ramping up on Mac OS X as quickly as possible. I'm sure that you all are at the leading edge of the curve. We plan to do quarterly releases of new Developer Tools CDs.

We're sort of still working out the precise details here, but as you've seen, the first quarterly update here is at WWDC. You should have all received a new Developer Tools CD. If you didn't, check downstairs. Make sure you get one. The CDs are free to all ADC Premier and Select members, and you'll also be able to download the packages from the web. The current CD packages are not yet up there, but should be soon.

So on the CD as a whole, what all do you get? So you get the developer applications that I've talked about. In addition, you get the open source development tools and the BSD tools from Unix underneath. And you get what we call the Mac OS X SDK. So the headers for all the system frameworks. You get profile and debug libraries so that, for example, in Project Builder you can switch easily to use a debug variant of your frameworks. So you can get more information about what's going on inside the frameworks. The debugger session on Friday will tell more about that.

As I mentioned, you get sample code. There's a lot of documentation on the system and the tech pubs people are hard at work creating new documentation all the time. And you've also got CarbonLib SDK on the CD itself, not in Mac OS X packages, but out there so you can copy it on if you're still doing CarbonLib development for Mac OS X and 9.

So you get a lot of documentation on the system and the tech pubs people are hard at work creating new documentation all the time. And you've also got CarbonLib SDK on the CD itself, not in Mac OS X packages, but out there so you can copy it on if you're still doing CarbonLib development for Mac OS X and 9. 8 and 9.

So what's new in the CD that you got here at the conference? So the primary theme of this CD was support for WebObjects 5 development. You can use this for all development for Mac OS X. There's some general purpose enhancements, but the primary theme is WebObjects 5. Because WebObjects 5 is a pure Java environment, we've done some enhancements in the Java support in this build. And we'll tell a bit more details in the project builder intro session and then the Java sessions throughout the week.

Also on the CD, you do get the WebObjects 5 developer packages. And in addition, a time-limited license for a restricted version of the runtime so all of you can start experimenting with WebObjects 5 today. We don't plan to put that on the CD forever in the future, but this is a great opportunity this time around. There's new documentation, additional examples. So you'll find a new performance manual out there. This is very important again to study. This one also you can order from Fatbrain, get hard copy. It'll make the performance characteristics of the system a lot more understandable.

Also there's an accessing hardware document for those of you writing apps that you want to get directly to characterizes the system. It's a very useful document. It's a very useful document to understand the characteristics of a device and a quartz primer to understand the graphics system better. In addition, updated API documentation for Cocoa and Carbon. And there was a bug in the original developer tool CD that's been fixed here so you can get directly to the Carbon APIs help information from project builder again now.

So with that, that's a quick summary. Again, there's lots of additional sessions, project builder intro this afternoon, but let me turn it back over to Godfrey to learn more about the third party tools. Thanks, Godfrey. Thank you very much, Dave. Big hand for our development tools team. They've done a tremendous amount of work and obviously have a lot more to go, and we're going to continue to be upgrading those.

Let's talk now a little bit about our third party tools and our collaboration with third party tool vendors. We work very closely with these people. We give them engineering direction. We give them engineering assistance on a direct basis. We seed them with early versions of the operating system that none of you in general would want to run because they're too fragile.

We also help them with business coordination so that our tool strategy internally coordinates well with their tools. And that they have the right things on target when we go to market with our pieces. Just thought I'd walk through and review some of the tools that are currently available for Mac OS X development, many of whom you're well familiar with already. Absoft is doing their Pro Fortran product.

They've got a Mac OS 9 version. They've got a Mac OS X version in beta. They tell me they'll probably be GM about the end of June and be ready for all of the science and technical industry that has this huge code base, millions and millions of lines of Fortran code.

Metrowerk's with Code Warrior. They're releasing here at the show, you have in your bag, the early access Pro 7 release. And they have lots and lots of enhancements. I actually have the folks from Metrowerk's here to talk about their release and give us all an update on their products. Real Software with Real Basic to answer the basic challenge. They've had a GM Mac OS X application for some time now and they've done some updates and I have them here to talk about that today.

Another category of tools that developers need are installers and utilities. We have both of our external vendors of installers, Aladdin Systems and MindVision, with GM Mac OS X Ready products now. So once you finish your development, you can wrap it, you can package it, you can deliver it to your customers.

Mathem Aesthetics has done a marvelous job of updating Resorcerer and bringing it to Mac OS X for all of you who have been using traditional resource manager resources for many years and who have need for lots of new features, Apple Script debugging and all kinds of other things. They've gone GM with the new version of Mac OS X Resorcerer and they're here with it at the show in the Exhibit Fair.

and then for the Java specialists in the audience, we're working very closely with Borland. You have a new preview of JBuilder in your bags. Also, Zero-G with their install anywhere. And VMGear with Optimizeit. They're all ready for you. They're coming up on Mac OS X in the very near future.

So I think we have a very complete set. These are only a sampling of what's available. There are many other tools available. How many here have gone to the exhibit fair already? About three quarters of the audience has their hands up. I'd like everybody to go visit them. We're running it all the way through Wednesday this year. So you should be able to visit and talk with each of these people and see how their tools meet your needs.

Now let's talk a little bit. I'm going to have our friend from Real Software come up. Let's talk about the basic challenge for a moment. When you look at the industry, when you look at the industry journals and read what's out there, you always hear that there's three times as much, four times as much software for the Windows platform as there is for the Macintosh.

And when you look in the industry journal and look at the statistics, what you find is that 60 to 80 percent of the additional packages out there are implemented with Visual Basic. Why is it so successful? Rapid application development and ease of access. Nearly anyone can learn Basic. Well, we've had a big hole in this area for a long time and now I think we have a real contender to fill it with a Mac OS X solution. Let me introduce Lorin Rivers, the product manager from Real Software. Thank you, Godfrey. Thanks for having me. Thank you.

And, uh... So Mac OS X is the present. If you were here for Steve's presentation yesterday, talking about the likely adoption of Mac OS X and how people who are running Mac OS X feel about running classic applications, I think you got the message about how important it is that you also support Mac OS X. Our relationship with Apple enabled us to deliver Real Basic for Mac OS X in February. And through our collaboration with them, we've also been able to release two updates. Our most recent one adds a lot of support for the latest and greatest Mac OS X functionality.

Mac OS X is not just for early adopters. You know, I'm a marketing guy and I'm running it. And Mac OS X is not just for people who are Luddites. You know, it's got a lot of, there's a lot of legacy software that people need to continue supporting. And this opportunity, as Steve alluded to yesterday, is very similar to the introduction of the PowerPC. If any of you were in the Mac market at that time, there were, when Quark released QuarkXPress for native for the PowerPC, it really exploded. And it was a great opportunity for Quark to gain huge, amounts of market share.

Real Basic runs on the Macintosh. In fact, you can run it on a Quadra 660 AV running 7.6.1. And it's not as fast as it is on a G4, but it's certainly capable. And the really cool thing about it is that even if you're running on an antique piece of hardware like that, you can create a Mac OS X native application with nothing special. It'll just compile it for you. So we run on Macintosh, Mac OS X, and we compile for those two as well as for that other OS. And it's a great opportunity for you to possibly expand your market if you're able to, without changes, generate a Windows executable as well.

So, you know, create on the Mac, deliver on three other platforms. And Real Basic is compiled. It's not basic like 10 Go To. It's a modern version of basic that uses the familiar, you know, object dot property kind of syntax. It's professional strength. There's plenty of commercial developers using Real Basic.

It's completely object-oriented from the ground up, designed that way and very rigorously. So, at the same time, you know, sure it's basic, but you have direct access to all of the power of the underlying OS, direct access to Mac toolbox calls, PapiSheet shared libraries, as well as the Win32 API through declares.

It supports SQL. You can connect to almost any database you might name. We provide plug-ins. And it uses a single API to access all of them. So you can do your development running against Real Basic's native relational database and then deploy on Oracle, for example, or OpenBase or FrontBase or any of the other ones that we support.

Plus, we have direct support for Apple events. You can drag a compiled Apple script right into your project and access it quick time and plenty of other great Apple technologies. Why would you use Real Basic? Well, you know, Michael and his team at Microsoft use Real Basic extensively for prototyping. Every new feature that they add to the new version of Office and to Explorer 5 was all prototyped in Real Basic.

Thank you, Michael. Another example would be MYOB account edge made in Real Basic, but the engine was written in C. And, you know, it's a very, very complex engine. And this tool allows MYOB adopters to convert their crafty old QuickBooks documents over to MYOB, someone who's supporting the Mac OS.

The Real Basic also provides a rich plugin SDK, so say there's something that Real Basic doesn't provide you that you need, you can write it in C. You can write it in a cross-platform fashion and access it very easily from within Real Basic without having to write a bunch of special code inside of Real Basic.

Real Basic is a rapid application development environment. It's very similar to Interface Builder in many ways, except I can use it. I'm a marketing guy again. I have a degree in geography with a minor in philosophy, and I can use Real Basic. I'm not stupid or anything, but I'm certainly not a computer programmer, or at least I wasn't until I started working in real software. The really cool thing about it is that it's an iterative process. What you see is what you get.

You put some stuff in your window, you test it to see if you like it, you add a little more functionality, and next thing you know it's 4 in the morning, and you've got bags under your eyes the next day because you're having so much fun. So, Real Basic gives the ability to be both productive and have a great time using your tool. Concentrate on the value add that you have, which is making great software.

Going forward, we've got big plans for Real Basic. We're enhancing the performance of the compiler. We're going to make much smaller applications. We plan to begin addressing other operating systems and platforms and also be able to create plug-ins for other applications, which is something I'm really excited about because I think it would be really fun.

So before I go on, let me mention something real quickly. You know, there's a couple of events in a software company or a technology's lifespan that are defining. So one of them would be the appearance of an O'Reilly book. And, you know, you're really, it's a validating event. And that's really cool. And this is a fantastic book. If you're interested in getting deep and dirty with Real Basic, you can't do any better than this book, which is going to have a second edition out this summer. Thank you. last summer.

And that's all great, you know, Riley stuff, top-notch technological things, but... But you know that you've really arrived when there's a Real Basic for Dummies book. And actually the fact is, this is a fantastic introduction to Real Basic. And it's a very well written book and full of pithy information. I encourage you to take a look at it.

So I want to show you around a little bit in Real Basic. What I want to do is show you how easy it is to use Real Basic to go from, like say you are a Real Basic developer, to go from your old Real Basic code to Mac OS X. So here's Real Basic 2 running in Classic.

One thing I love about Mac OS X is being able to do other things while applications are launching. I was an old Next user and it really spoiled me. So here's my Real Basic project. This is actually, this is version 1.2 of Real Bugs. It's the tool we use to ask for our customers to provide us with feedback. So this is version 1.2. I just dug around on my desk.

I had a two-year-old version of the source. You know, open it up, run it in classic. Simply run and, you know, you want to enter a summary. You know, Real Basic, so rocks. You know, and then you submit this bug and it'll send, it uses an Apple script to communicate with the email program that you're using.

And sends us an email and then we can automatically track it and that kind of stuff. And, you know, you can see this looks like a standard. Mac OS Platinum user interface. And. and what I'll do now is open that same project in the latest version of Real Basic, which is Real Basic 3.

I'll just drag that same Real Basic 2 project onto the icon, run it, and... and David It's a two year old project. I hadn't run it in two years. So, you know, it's just that easy and, you know, creating it, you know, people talk about eating their own dog food. We don't do that. We eat our own caviar. And we're using more and more of Real Basic inside of Real Basic.

And this version of 3.2, all of the lists are actually Real Basic list boxes. So it's a powerful motivator to update and fix any, you know, missing features in your products. So I want to thank Godfrey very much for having me out today. Thank you for your attention and we get a lot of value out of our relationship with Godfrey. He's the bomb. Thank you very much, Lauren. Thank you, Godfrey. No doubt.

So for more information about Real Basic, Loren is here all week and he'll be over in the exhibit fair. There's some contact information. You can find him. And Real Basic has a birds of a feather tonight. And that's their URL so you can find them easily on the web.

They deploy a lot of their software via the web so you can download an evaluation copy and just try it out. See if it works for you. Extremely useful product. Tremendous capability bringing apps to Mac OS X. At this point in time I believe there are about 40 or 50 applications in the shareware domain that were written with Real Basic and are immediately native Mac OS X apps. This is a great story.

Now, I'm sure all of you are waiting for this. I think it goes without saying that 95% of the Mac OS X commercial apps on the market are made with Code Warrior. So I felt it important to bring them to talk with us today. They're our leading third party supplier of development tools and we are working very hard to get together on Mac OS X with them. And to talk about that, I'm bringing Matt Henderson, the technical lead for Code Warrior, to talk to you.

Thanks Godfrey. Steve, you're on the phone. Okay, so I'm here to talk to you today about a number of things. First off, I just want to say that we've been on Mac OS X a long time. We've been doing this, I've been in charge of getting everything on Mac OS X running and targeting Mac OS X for almost two years now. So, Mac OS X with the release of public beta and maybe with the release of final, if you haven't moved your apps yet, is new territory for you. But it's, we've absolutely been there from the very beginning and it's been a lot of great fun for us all.

So, in your show bag, speaking of that, is your Code Warrior 7 Pro Early Access CD that has our latest stuff for Mac OS X. So if you haven't gotten that CD out and tried to use it yet, you should. We've experienced, I'm going to cover everything in depth, but it's an across the board improvement for every aspect of the Code Warrior tools running on Mac OS X.

And so, after we cover what's in Mac OS X, we're going to cover the Mac OS X development tools. And then, once we get the products on the Pro 7 Early Access CD, we'll go into the future directions and how we're going to continue to enable you to make cool apps for Mac OS X and take advantage of new Mac OS X technologies.

So first thing and most important to everyone who's developing on Mac OS X is debugging, which was probably the weakest part of the Code Warrior Pro 6 Mac OS X experience. So to talk about debugging, I've got Ken Ryle, our Director of Debugging Technology. He's going to cover in-depth what's new with the Code Warrior Pro 7 Early Access stuff in regards to Mac OS X debugging.

So, for the past couple of years, Metrowerk has come to WWDC and shown you Code Warrior debugging applications on Mac OS X. But, of course, the operating system has evolved since we shipped the Pro 6 tools last fall. So, as Matt said in your bag, everyone's got one of these CDs and we wanted to update the tools we shipped last fall so that they work a lot better with the release, with the final release of Mac OS X now that the OS is out the door and in your hands. Since most of our developers are working with Carbon PEP apps, initially we focused on improving debugging performance for CFM Carbon applications. So, the tools on this CD are faster, they're more reliable, and work better than the ones that we shipped with the Pro 6 tools.

In particular, we worked on improving debugging of shared libraries. We worked a lot of our larger customers that have big applications, lots of shared libraries. Big plugin architectures. And so, we worked with them to improve the whole shared library debugging experience to try and get better performance and try and approach our real goal, which is to give you the same kind of debugging experience on 10 that you've had on 9 with our tools for years.

We also cleaned up some things about the tools. They no longer require some of the helper apps that we've had before, like DebugNub or MetroNutBacks that you may have seen in some of our tools releases before. So, we streamlined that process. We've also been working with Apple to improve performance.

Earlier, Dave Payne talked about leveraging open source for tools on Mac OS X. And the Code Warrior debugger on 10 uses GDB as the low-level debug service. So, we've been working closely with Dave and his team to improve GDB for our customers as well, and consequently just improve the debugging experience on Mac OS X. So, that's it. Thank you.

So, we've been doing all those things for people developing Carbon PEP applications, but we've also been working on Mac O debugging. Mac O has a different symbolics format than Carbon, or rather, PEP applications do. They use SIM, which you've seen on the Mac for years, and Mac O apps use Stabs. So, on the CD, there's a new plug-in to Code Warrior that's a Stab symbolics reader that will let you debug applications built with GCC and with our own NUCs.

And with our own Mac O tools that are also on the CD. The Mac O debugger isn't as polished as the PEP debugger is, but we're going to be working on both in the future a lot, and also improving the experience if you're debugging both binary formats in the same process. So, if you have a Mac O application hosting a CFM bundle and vice versa.

So, that's what's new in the debugger in this CD. And we're also going to be doing more releases over the summer through our beta program. There's an email address on the CD that we'd like for you to contact us at, let you know your experiences with this CD and the tools in general, and let us know how we're doing with that.

And that way we can update you with additional debugger components as we improve them towards our Pro 7 release later this year. So, that's our debugging story, and I'd like to get Matt back up to tell you about the rest of it. And I'll tell you about the rest of the tools on the CD and what we're going to be working on in the future. Thanks again.

So, after the bugger, probably the central tool that you use the most on Mac OS X will be the new IDE. The Pro 7 Early Access CD that you have includes the new 4.2 IDE. And it has a number of new features to make Mac OS X development much better. First and foremost, it handles untyped files. With Mac OS X, Apple has rolled out the support for non-HFS file systems, and so you can no longer rely on the HFS types and creator codes that FSP, Github, Info gives you back.

So the IDE uses a variety of mechanisms, including content sniffing to identify files by what they really are and not just what the file system says they are. And so as a consequence, you can open both the untyped text files that Apple installs with their dev tools and also any files on a UFS file. So that just makes actually looking at the Mac OS X header files actually possible now with the CodeWare IDE.

Also, one of our biggest features for the new 4.2 IDE is support for Mac OS X frameworks. You've heard all the Apple guys talking about frameworks, which is their new mechanism for distributing headers and libraries together in a bundled package. And the IDE can now use those to build and link against.

So you can add a framework to your project and it will show up in a new tab in the project window. So for you to see which frameworks you're using. And once you've added them, you're effectively linking against the Mac OS library that's in the framework. And so you can use that to get at both the headers that are provided by the framework and the library.

And you'll be linking against the library and you'll get full access to the API. So through frameworks, you can get access to all of the Mac OS only APIs, such as Quartz, Launch Services, and some of the other native APIs that aren't available via Python. So you can get access to all of the Mac OS APIs, such as Quartz, Launch Services, and some of the other native APIs that aren't available via Python. And of course to support frameworks fully, Apple has introduced a new include directive syntax where you qualify your file name with the framework name in order to find the actual file. So for example, include carbon/carbon.h really means find Carbon.h wherever it is within the Carbon framework.

We didn't support that before, we do now. So you can say include, use that exact syntax. And that exact syntax on the screen, it will compile fine with Code Warrior if you have your framework set up and you'll be able to use the, you'll be able to compile Apple's headers and use framework notation in your own include directives as well. And of course to prevent us to not break all of your existing source that's assuming our sort of flat access path mechanism, include Carbon.h without the framework qualifier continues to work so you won't have to make massive numbers of source change to your include directives. directives.

Also for the IDE, Apple has been talking for, I guess, over a year now about distributing applications and binaries in bundles, which is sort of a magic directory structure that contains both an application and all its resources. So we've added support for building bundles from the IDE and all our other various tools. And in particular, the IDE has a converter that will easily update your existing projects so that they output bundles. So you can run this simple converter.

It will generate the bundle directory structure for your target output. It will create your plist resource for you based on your old-style finder BNDL resource. And it will create Mac OS targets for your project. So run this once and you're ready to go to build a completely Mac OS X native application.

So MSL has been updated with a few feature tweaks. We've added support for various HFS Plus features, the most notable of which is long file names. So you can use, in MSL now, you can use file names that have more than 31 characters. And when we're building for Mac O, we don't use MSLC, we use the ANSI C implementation that Apple supplies in System.Framework and our NCC++ application will link against Apple's implementation and save you some overhead since Apple's version is really just a shared library that's available to all system apps. So you don't have to build MSLC into your Mac O applications and waste a bunch of code in disk space.

The Power Plant has been revved as well. It now builds for Mac OS. So you can build your Power Plant for Mac OS and get complete access to all of the new native APIs on Mac OS X that aren't available for PEF. We fixed a number of Aqua-related bugs in the Appearance Manager related code in Power Plant, so your Power Plant applications will, in general, if you're using Appearance Manager, come out looking much nicer when running on X now.

And we have a new version of Constructor that outputs Apple's new recommended flat resource fork format where the contents of the resource fork are actually stored in a files data fork, so that file can live easily on flat file systems like UFS and be transported over the internet easily. So all those features are in Power Plant and Constructor now.

The compiler and linker have been revved as well. We continue to crank away on optimizations for the compiler. With the new high-end PowerMax, the 667 and 733 megahertz PowerMax, Apple introduced the PowerPC 7450 chip from Motorola, which has a longer pipeline and enhanced Altebec performance. And the compiler on the Pro 7 tool supports optimization specific for that chip that will make the code run faster when you target that chip. The PEF linker has been revved in a manner similar to our other tools that deal with resource forks, so it supports, or resource files, so it supports flat-file. resource files, and it supports building application bundles easily as well.

and we're completely new, or not a completely new set of tools, but new tools that are actually beginning to get into the realm of being very useful are our Mac O Compiler and Linker. We've put them before as extremely, you know, extremely early access thrill seeker on past releases and now they're getting to the point where you can start using them to build big things. The Mac O Compiler is exactly the same C/C++ front end as our existing PATH compiler.

So really unless you're using new Mac O API, you want to use new Mac O APIs, there's no reason you'll have to change your source to switch from PATH to Mac O using code ware. Our Mac O Linker, right now we're using an interim linker that we've developed in collaboration with Apple. It's based on Apple's Darwin open source linker.

It uses stabs for debugger symbolics like Ken indicated earlier and it's a bit slower and stabs is quite a bit bigger and more inconvenient. It's a bit more convenient than the SIM symbolics are. So we're working really hard on a new MetroWorks Mac O Linker that will be just as fast as our PATH linker. We'll use SIM for symbolics and it will have all the features that you expect in the, in a MetroWorks linker.

So future directions. This is where we're going with Code Warrior and we think that it's all solid, you know, fundamental stuff that needs to be done for, you know, to keep you as customers and to keep you targeting Mac OS X. First and foremost in the compiler linker we're going to finish off our Cocoa and Objective-C support. We initially added Objective-C syntax support quite a while ago in the back in the days of Yellowbox and Rhapsody. We haven't really gone through a rigorous validation of that support though.

And we're going to fully validate it, qualify it, make sure it's, you know, 100% compliant and, you know, it's fully integrated into our compilers. We're also, as I mentioned earlier, working on a new Maco linker based on our own linker technology and not the Apple's Darwin open source linker. It will be, like I said, inherit a lot of code from our existing PowerPC linker. It will be very fast.

It will dead strip unused code that, you know, is not called by our application but is actually included in your project. And it will output SIM for data. And it will also be able to debug your symbolics which are traditionally much smaller and tighter and faster to use than Stabs is.

and David So for the IDE, in the immediate future you'll see hopefully for the fourth Pro 7 final, you'll see long file name support. So you'll no longer have to worry about headers and sources having only 31 characters in the file name. You'll be able to use full 255 character Unicode file names and have the IDE be able to deal with those source and header files easily.

We're in the initial planning stages with Apple about integrating Code Warrior and Interface Builder together to provide support for both Carbon Nib-based development and Cocoa Objective-C and Java development. We would like to have something to show for 7 final. We may not though, but it's very interesting to us and Apple and we intend to fully, fully explore that avenue of supporting Cocoa. And of course we're always working on our user interface to make Code Warrior better, easier and faster to use and we're always working on performance both in our own tools and in CodeGen. so that your software will run faster when it's built with CodeWare.

The debugger. Our ultimate goal with the debugger is, which has been the most frustrating aspect for people using our Mac OS X tools so far, is to make the debugging experience as smooth and work as well on Mac OS X as it does on 9. That being said, we're not there yet with the 7 Early Access stuff, but it's gotten a lot, lot better since 6 and some of the beta releases that some of you have probably seen between 6 and the 7 Early Access stuff. And it's going to get a lot better in the future and it will be better for 7 and we're going to keep hitting on it until it works like you expect it to work.

And even more exciting for the debugger stuff is that Mac OS X allows us, because we're using GDB as the underlying low-level debugger, and by the way, you will never see GDB when using Code Warrior. You'll be completely isolated from it, so really the fact that we're using GDB is a technical detail that doesn't concern you. Um... We will be able to do a few cool new things like adding support for viewing opaque data types.

Apple rolled out completely opaque data types in the Carbon API such that you can't see, you know, the actual values of the members of your window pointer, for example, or you can't see the contents of a control handle. Um, so hopefully we'll be able to integrate in some support that actually lets you--tell you what the values of your control are or what the position of your window is from the debugger, even in spite of the fact that it's an opaque data type.

And another thing, a long requested feature for our debugger is support for calling functions while debugging. Um, because on Mac OS X, because it's, you know, Unix and has preemptive multitasking and protected memory, we think we'll be able to get that feature into our debugger, and you'll be able to just use function calls and expression evaluations without any difficulty.

So power plant. We continue to adopt new Mac OS technologies and power plant as rapidly as possible. With the Appearance Manager, we gained a lot of Aqua support. With this release of power plant that's on the Early Access CD, we've polished up the Aqua support a lot more, so it's a lot cleaner and easier to deal with.

We have initial support for Carbon events in the Early Access power plant, an initial implementation of a view class to support MLTE, which is Apple's new text API for editing both in multibyte lingual scripts and for greater than 32K editing. So if you use MLTE, you'll be safe for localization, and you'll have a full-featured text editor that doesn't have text edits on 32K limit. And we also have started investigating a wrapper class in power plant for the data browser, which is Apple's new ListView API that the Mac OS X Finder uses.

So that's it. On the who to contact thing before I talk about sending us email, I'd like to mention that tomorrow at 12:30 we have our very own lunch presentation at the Civic Auditorium across the street. Lunch will be served there in case you didn't want to go and not miss lunch. So if you show up in time, you should get lunch.

And we'll have a number of cool things there. David Perkins, the president of Metrowerks, will be talking. And Berardino Barada, the CTO, will be talking. We'll be giving away the PlayStation 2 to somebody at the presentation. So please show up about that. You'll learn a lot of great things about Code Warrior and you'll have a chance to win a PlayStation 2.

Of course, contact me if you have questions about Mac OS X tools. Contact Joe Hayden if you have questions about Mac OS X tools. And when you start using the Pro7 Early Access tools, send your bug reports, feedback, feature requests, whatever you want to that email address. That email address is actually in the package, so don't feel obligated to write it down. And with that, I'll hand it back over to Godfrey. Thank you very much, Matt.

The guys at Metrowerks have really been amazing. They come to most of our Carbon kitchens. They support our engineers. Our engineers support them. We work tremendous, tremendous amounts of hours with them. And I can't thank them enough for the fantastic job they've done with the early access. So again, for more info from Metrowerks, there's their URL. And remember the lunch presentation tomorrow, 12:30 to 1:30 p.m.

Putting it all together, for Mac OS X development tools are a very healthy state now. You saw in Steve Naroff's slide that we've covered the bases for all of the work that needs to be done. Obviously all the tools are young. All the tools will take more development and have better features and more performance as time goes on.

The Apple tool suite is ready now. It builds all of Mac OS X and all of the 50 or 60 applications that we deliver. The 3rd party tool developer products are ready now and there are lots more coming. So there really isn't any excuse. The goal is to get your applications to customers to make Macworld New York and Apple Expo Paris a tremendous success.

Information Resources at Apple. We have an information page for all Mac OS X tools. All you have to do is go to that one URL and you can walk through all of our products and all of our third party products. We also support a mailing list server so you can do self-help with other members of the development community. We have mailing lists for Project Builder, for Cocoa Dev, for Carbon Dev, for Java Dev, and several others. I think about 15 or 20 development-centric lists there.

A roadmap. This is just the first session of our tools track. We're really highlighting tools throughout WWDC this year. You can see we have a tremendous number right here in this hall today after lunch. We have Project Builder, a full detailed feature presentation on Project Builder. We have at the same time for the WebObjects community, an introduction to the WebObjects tools over in the civic auditorium.

We have Interface Builder again here this afternoon. And then continuing through the week, tomorrow Project Builder, Java development tools, application packaging and document binding, compiler technologies, very important session, Apple Performance tools. We want not only your applications to be there, we want them to perform at their best. And our tools can really help you in that.

All the way through Friday and we cap the week with a developer feedback forum on Friday afternoon. And with that, we've got about 10 minutes left. You can contact me if you're a vendor or if you're just a developer and you need to know something about tools, this is my contact information. If you want to give feedback to the Apple Tool Developer Group, Developer Tool Group, excuse me, there's a mass mailing address for us to receive your input.