Good afternoon. Welcome to WWDC. I'm glad to see we have quite a crowd today. The development tools of Mac OS X mark a new era for Apple computer in shipping our operating system with tools included. This appeals to our Unix community, it appeals to all the people who otherwise would be working on other platforms and have seen Mac OS X as a new strategy, a new advantage.

In seeing this... I'm flubbing here, excuse me. In seeing this as a strategic asset of the operating system, we take in Mac OS X the combination of our traditional ease of use, our traditional user access, we add development tools to it, and that gives us the opportunity to call ourselves the ultimate development system.

In the hour to come, we're going to be talking about all of our various development technologies, what we're doing now, what we've done over the past year, and what's to come. And to do that job, I'd like to invite my good old friend and colleague, Ted Goldstein, the Vice President of Apple Development Technologies, to come to the stage. I've known Ted for, what is it now, 22 years, 23 years? Ted has a long history in development tools and compilers, IDEs, and Java. So, Ted, take the stage. Thank you.

So I think I loaned Godfrey the money for his first Mac back in 1984, and it's taken me a little bit longer to catch up to him. The Macintosh and such, we actually did a small development on the Mac porting Smalltalk, which I think also has a little bit of history in common with some of the Macintosh effort. But mostly I've been a compiler writer over these last 20 years. And in trying to fit in with Apple, people tell me I should take my coat off. Should I take my coat off? Is that... Okay.

Believe me, you don't want me to take it off. So what is development technologies? What is the charter of this new group within Apple? And we're going to talk about that. Try to give you a little overview about some of the new thinking around tools and such and how the different pieces fits together.

And I want to actually give you a bit of a progress report from where we are. I invite some of my colleagues up to talk about different areas, give some interesting demos. The way we deliver our systems is with partners. And extremely important in the tools business is to work closely with other third-party tools vendors because Apple cannot do it by itself. We really, really do believe in collaboration, that it's key to the efforts to make things happen.

And I want to talk a little bit about some new initiatives that we're going to take some leadership on to bring in technologies that's happening both within Apple and outside into the tools space because we think that all these things need to combine together synergistically. In fact, synergy is a very important word in my talk, and I'm going to use it probably, oh, 17 times. Um... Development technologies is an amalgam of different tools and technologies.

And I think one of the things that's extremely important for a rich platform like the Macintosh is to really build a big tent. And by big tent, what we mean is everybody can come inside, whether you're a Carbon and a Cocoa developer and you are developing the great desktop applications that have made the Macintosh terrific for many, many years now.

We also have appeal to the multi-platform Java developers, people who want to write one program, develop one binary, and ship it on Windows, on Unix, on Linux, and other non-Macintosh systems, as well as Macintosh and Mac Unix, of course. And we think that this is a very interesting dynamic where we have the ability to take the same binary from one platform to another and the kinds of things you have to do.

Mostly we'll be talking about that in my presentation. My next session, number 400, that follows immediately after this. So I won't spend too much time in this session talking about Java, but it really is part of the same department. And we're looking to increase the different synergies between Carbon, Cocoa, Java, AppleScript, and such all together to make a very coherent platform for you to develop on.

One of the most important areas I think that this new department has is it combines together the tools along with database systems. And this means that we are actually going to be looking at and beginning to incorporate database application programming more closely into the standard way to develop Macintosh applications. Unix developers, of course, extremely rich, extremely terrific area because we have really a very fine Unix experience.

It has the ability to run top and all the command line tools and all the rich Perl and Tcl environments. And we get a tremendous amount of benefit from the open source community to bring these tools into the environment. Many of these tools are scripting languages themselves, such as Perl and Tcl and Python. And those tools are also now available, of course, on Mac OS X along with our traditional Apple script environment, which we've enhanced to allow you to create terrific new user interfaces. Using Apple script. Script Studio.

So, for those of you in the room who are new, and there must be at least somebody besides me, I want to just give a very quick perspective on which technology and which should you use for what purpose. We believe Cocoa still is our primary application platform now.

And it really is to create new applications that are special to the Mac OS X environment. And really, Cocoa gives you the most power that you can get for the Mac OS X. And it's well-designed with both access to the Aqua user interface, every possible feature is available, and it has a terrific object-oriented model. One of the things which the richness of using both Objective-C and the C language allows you to blend the right power and flexibility to really create the best possible applications that we know of.

Carbon is our transition technology. And it allows one to write applications that run both on Mac OS X. And as we saw earlier today, Mac OS 9 is not something we really want you developing much more for. Nevertheless, it was a fabulous technology that allowed us to make the transition from a non-preemptive thread operating system to a preemptive thread.

Or from a cooperative thread operating system to a full multitasking, very rich, protected mode environment. Carbon really was a very unique environment and has allowed Apple to make this extremely difficult transition. And it has been fantastic. And we're really fabulous at doing that. Nevertheless, we feel that using Carbon, you don't get everything possible out of the Mac OS X environment.

Java, as I said, is our cross-platform strategy. We do a tremendous amount of work to map it into Acquia interfaces and into other Mac OS X features. Nevertheless, people who tend to write Java tend to want to write something that is platform-independent as opposed to utilizing every possible feature. It is, however, possible to write platform-dependent code in Java, and we don't frown on that, but nevertheless, that isn't the primary mission behind the Java language.

AppleScript Studio is a new technology we just released late last year. And it is a user interface application environment that works with Interface Builder to rapidly create new applications and to rapidly evolve applications. It integrates this AppleScript scripting language into the Cocoa framework and really is the second language that really fully leverages all of what Cocoa has to offer. What I really like about this is that sometimes the amount of time you spend writing an application isn't that much less than the amount of time using it.

Sometimes they're probably pretty close, such as when you're developing an application for one person or a small department. You don't really want to put in the tremendous investment to write a C or an Objective-C based application. And AppleScript Studio gives you the ability to write something that is going to be used by a bunch of people for a period of time, but is going to evolve rapidly. You see this a lot in corporate environments. You see this a lot in corporate environments, universities, and for your own personal use.

And AppleScript Studio really is tremendous at that rapid prototyping RAD development. And of course, no Unix system would be complete without talking about Perl and Tcl and Python. These work on pretty much all Unix application platforms. And they're terrific in their place. Some of these languages actually do have bindings, such as TkAqua, that don't come from Apple directly, but do support the Aqua look and feel to the best they can.

So, Apple is still a comparatively small company. We can't do it all. In fact, even I think some of the largest companies these days don't try. What we need to all do is to take standards and to innovate on top of them. We take the GNU compilers, we take open source systems, and we build upon them to create extremely reliable systems that then can span both our platform and other platforms, and to have the kind of networking and interoperability standards that people expect.

What's important about this in the tools area, of course, is we use the GNU compilers, and we've been extremely fortunate in leveraging the open source foundations compilers of GCC and the linkers and so on to create a rich environment for you that runs both on Mac OS X and our Darwin build systems, delivery environments.

And so, this is an extremely reliable environment, and something that we get tremendous benefit from is that you can help us feed back and can take our knowledge as well into your own systems to modify it and customize it for your own needs. But we don't think that's enough. We think that it's also extremely critical to provide a rich set of graphical user interface tools for rapid development. This includes things like Interface Builder and Project Builder and Web Objects Builder. And what these things do is they eliminate the need to write most of the code.

Interface Builder, you've seen, I think, probably in the previous session. Project Builder is our hub. It is our programming environment that all the other components plug into. And Web Objects Builder is a tool for working with a Web Objects server to create rich two-tier and three-tier web application services. These environments like WebObjects and Apache Tomcat, these are fundamental tools for any web application, whether it's an HTML app or new web services, and we'll be talking about that a little bit later.

So, I want to give you a picture of just how the different pieces fit together. Along the bottom there are the series of languages that we support directly from Apple. They include, of course, C and C++, Java and Objective-C, and AppleScript. These languages form the basic foundation that you as developers write in.

These languages themselves are controlled and manipulated by two different kinds of tools in this case, Project Builder and Interface Builder. Interface Builder, of course, just does gesturing to layout components. Project Builder integrates all the resources of the environment along with the build system. And it also allows for very quick and easy pathways to get to debuggers and performance tools and such.

These other tools, the Performance Tools, AppleScript Studio, and WebObject Tools, they plug into these environments, they leverage the resources, and they are, in some sense, the pathways off of the main thoroughfare. Project Builder and Interface Builder really represent probably a place where you'll be spending a great deal of your time, from time to time, once a week, maybe once a month, certainly before you ship, we want you to run the Performance Tools. If you're going to be using AppleScript Studio, using WebObject Tools, it represents different places to plug into. We'll be adding more tools as time goes on.

Finally, we think of it as that there are four major categories of resources that you develop. Desktop applications, of course, web-based applications, and web-based applications themselves come in both very light HTML-based ones, browser-based applications, as well as applications that talk to a rich client. Device drivers, of course, because we are, of course, a hardware company. We want you plugging in very terrific devices like scanners and cameras and such.

And, of course, other frameworks to take the knowledge that allows for technology to be developed and reused across many, many applications.

So with that, let me introduce Dave Payne, Manager of Mac OS X Development. And he has the good fortune to making good on all of my promises.

Thanks, Ted, and welcome to Apple. So you've heard a bit about what we're going to do, what some of our priorities are. I'd like to first start my talk with reviewing some of what we have achieved over the past year. So if we look back, when we introduced Mac OS X in March of 2001, along with that, we also had a developer tool CD that had 1.0 version of Project Builder on that.

We built the entire Mac OS X system with that, all the applications, the frameworks, the device drivers, the tools, the kernels built with GCC. So it was a very full-blown environment even at that point. In May at the developers conference last year, we came out with a new version of Project Builder in conjunction with WebObjects 5. So this developer tool CD provided full support for WebObjects 5.

The next major release of the OS, version 10.1 in September, had an accompanying developer tools CD with it, where we added a lot of new functionality. Project Builder version 1.1 had a lot of additional functionality for indexing of your source code. On top of that, we built a class browser for C++, for Objective-C, for Java. We also provided integrated viewing of the documentation for all the frameworks on the system and for the help for the developer tools themselves and all the conceptual documentation.

We had a lot of other features and enhancements as well, but those are some of the major ones. In more of the tools area, we came out with a new language, Objective-C++, which is actually a language that Next had had previously. It's very important in our context today as, for example, let's say that you're writing a Cocoa application with Objective-C, but you've got a library of C++ code that's a compute engine for you.

Maybe it's even cross-platform. It's much more convenient to be able to interface between the Objective-C for the Cocoa application and the C++ in the library if you can do it in the same file. And that's what Objective-C++ lets you do. We also modified the library. We've added a linker and loader to provide a two-level namespace feature that gets more correct semantics for symbol binding.

In December 2001, we had another developer tools CD. The major feature of this was Apple Script Studio 1.0. This was promised at the Seabold conference in September. It was announced there that it would be available by the end of the year. There were enhancements in both project builder and interface builder to provide full support for this exciting new technology.

and here at the developers conference today you're actually receiving two new developer tools CDs. So, one, two. Let's take a look at what's on these. So the first of these is the April 2002 Developer Tools CD. So just going along in our series. This is for use if you're running and doing your development on Mac OS X version 10.1. Don't try to use this with Jaguar.

Major new features in this is the beta version of Project Builder 2.0. Why do we call it a beta? Well, we want your feedback about some of the new changes going into that. We'll talk more about that. There's a beta version of GCC 3.1. The default compiler with this CD is still GCC 2.95. So even though we refer to the CD overall as a beta CD, if Project Builder is working well for you, you're free to go ahead and build applications for deployment with GCC 2.95.

Don't do that with GCC 3.1 yet because we haven't fully finished testing and optimizing it yet. Also, there's an updated version of AppleScript Studio, version 1.1, in its final form, and a lot of new documentation. So, for example, the Cocoa reference documentation is now complete on this CD.

I was waiting for that one. There's been a lot of requests for that. The other CD that you're receiving, the Jaguar Developer Tools CD, this is the one that you would use for development on the Jaguar OS that you received. Get the right side. Of course, you can build applications that are compatible back on 10.1. From the 10.1 system you can build applications that are compatible forward.

With this CD, GCC 3.1 is the default compiler now. So again, it's still beta, just as the OS itself is a beta. The entire operating system was built with GCC 3. So we're very interested in your feedback on the compiler so that we can make sure that we work out any remaining issues in the compiler before we ship the operating system and the tools in the final versions.

I'd like to review how we make these tools available because there's a couple of it that I think is not clear. Most of you know that we ship the developer tool CD in the Mac OS X retail box. We also now make the tools available on new computers. When you buy a new Macintosh, the installation images of the tools are already on the disk. So you can throw it away easily or you can go ahead and install it.

And most of you know that you can download the tools from ADC. We do stage how these come out because it's kind of fun when I come out with a new developer tool CD. The network bandwidth just takes us to our knees. So we stage this software seed key holders get it first.

Then Premier and Select members can download it. Then anybody can become an online member and download it. But if you have a slow network connection and would like faster access to it, there is a mechanism. Go to connect.apple.com. Send in your $20 and we'll send you a CD of the latest content.

So... Project Builder 2.0 is the biggest change in Project Builder since we first shipped it. One of the most, loudest pieces of feedback we got about Project Builder was, you know, I like the environment, or I like the tools, except that I feel constrained in your all-in-one window environment. A lot of us like it, but a lot of people, you know, there's different people have different preferences. We have a new, very configurable multi-window user interface that really lets you work the way you want.

We've got support for GCC 3.1, so from Project Builder, you can set up a pre-compiled header mechanism. We're using this new mechanism called Persistent Front End that now also works for C++. And we've changed Project Builder to understand all the new formats of warning and error messages from GCC 3.1.

There's been a number of improvements in the build system, such as the ability now to clone targets in your project. So if you've got one target and you want to make another one similar to it, you can go ahead and do that. So if you're working on a variety of bundles that are similar, for example.

I'd also like to remind you of the build variant support that lets you, for a single target, build it in different ways, so you don't have to clone your targets in all cases. There's been a number of improvements in the debugger, and we'll touch on some of this. But I encourage you to go to the Exploring Project Builder session on Wednesday to learn more about the demo that we're going to see at this point. Actually, one more slide. I'd like to review some of the design point of Project Builder.

From the very beginning, we've tailored Project Builder for development for Mac OS X. So everything that you use for Mac OS X, concepts like bundles and application packaging and frameworks, are all very tightly integrated, these concepts, into Project Builder. If you have not read it, I would strongly encourage you to read the system overview manual to get full details on what all these concepts mean. So you can have a project that builds a framework and that uses that framework in an application in that same project.

With this IDE, we really try to leverage the power of Unix that's on the platform underneath it. So, typically, if you're doing Unix development, you might write your own makefile. We have a built-in build system in Project Builder that relieves you from having to do that. But you may have pieces of open source that you'd like to bring off the net and add into your project.

You can have some targets in your project that use our built-in build system, or you can use what we call legacy makefile support to use the built-in makefiles from the other project. If you are using our built-in build system, then you can take advantage of what we call shell script build phases that let you customize the build at various portions so that you can do interesting things there.

And then one additional major feature that we use very heavily at Apple, and I know that some third parties very heavily use, is there's a command line tool called PBX Build that actually opens your project within just a tool environment and builds the project in exactly the same way as the IDE itself does. So you can script nightly build processes with this. It's very powerful.

And Project Builder also facilitates team development. So, of course, as you would expect, your application preferences are stored per user. But also for each project that you create, every user gets their own per project preferences there. So I can have my breakpoints stored with it, my bookmarks, my window layout.

You can have yours stored with it as well. And Project Builder fully integrates with the CVS version control system. So you can use this to build your own project. So you can use this to actually check in your profile preferences or project preferences if you'd like. So now let's go ahead and I'd like to introduce Mike Ferris, the manager of the Project Builder team, to give you a quick demo of some of the new features in Project Builder 2.0. Thanks, Dave.

My job here this afternoon is basically to give you just a little taste of what we've been doing in Project Builder recently and try to entice you to come to some of our later sessions during the week. In particular, on Wednesday we have our Exploring Project Builder session, and if you're interested in PB, I encourage all of you to attend that one.

So, As Dave said, one of the big pieces of feedback that we got with Project Builder is that not everybody likes everything in one window. So this is the way that Project Builder has looked since we built it. When I open source files, they appear in the one window.

I can move between the files that I have open in a relatively easy way, but I'm pretty much seeing them one at a time. I do my finds within this window. I can debug within this window. Everything is very self-contained here. Some people like this, some people don't. Well, now we have an answer for the folks who don't.

This new Preferences panel is where you can configure what the user interface for Project Builder is going to look like. We have three main default choices: Single Window, you're all familiar with if you've used Project Builder before, that's the way it's always worked. The new Some Windows configuration.

The Project Window still has a built-in editor in this configuration, but all of the tools like finding and building and debugging, these sorts of things have been moved into separate windows in this configuration. and then there's many windows. The project window does not have a built-in editor. All of the tools, finding, building and debugging, all these are in separate windows.

It turns out that these three choices are just... The first thing we want to talk about is the pre-set configurations that we've provided. Behind that is a lot of configurability. We've defined what we feel are the set of development tasks that all of you do all the time as you're building projects.

and for each one of those you can assign a different window template that's set up exactly the way you want it for that task. Multiple tasks can share the same template, even the same window, or they can all be in separate windows. And you can create your own templates, set them up exactly the way you want. But for now, let's just stick with the built-in many windows mode and I'll show you what that same project looks like. So here we have the project window again, no attached editor. As I open up files, each one appears, each in its own window. Okay.

If I do a find, I get a find window. So, okay, well, since we're already looking at the find window, let me show you something else. This... What I've been showing you so far is in both of the CDs that you've received. What I'm about to show you is only in the Jaguar pre-release CD. It didn't make the April Tools CD.

So play with this, with the Jaguar seed, but don't expect to find it in the 2.0 April tools. We've always had integration with Define to be able to search for references, API definitions, and so forth. But if you don't know what the name of the method or the function is that you're looking for, we've kind of not had a solution for that. What we've added is a natural language, content-based search of all the documentation. So I can type in, if I can spell it, tell me about view hierarchies.

and David I'll get a weighted set of results. The ones that it thinks are the most relevant up top, of course, just as you'd expect. And as you can see, the second one looks like it's pretty appropriate. This is a whole document on view hierarchies. And we can load the documentation up right here, pictures and all.

So this is a way, if you're unclear on exactly how to accomplish what you want to accomplish, you can look for it in a sort of a more concept-based Okay. So, again, this is just a small taste of what we've added to Project Builder and what we're continuing to add to Project Builder. And with that, I guess I'll give it back to Dave. All right. Thanks, Mike.

So as we said, this is a beta version of Project Builder because we are interested in your feedback about the user interface and whether this works for you. It has been available on the April 2002 CD, so we have received a lot of feedback about it so far, and it's all been really great so far. So thanks, Mike. Okay. You know, actually, Dave, there is one more thing that I could show here.

Okay. Okay. This actually isn't on either of the CDs that you have, but it's something that we've been working on. And we're not exactly sure whether it's going to make the Jaguar release or not at this point, but, you know, bear with me. You know, I'll show it to you anyway. So one of the things that people have asked for is some features that MPW used to have.

People really like from MPW the shell environment, the sort of the non-linear shell, being able to use a mouse-based editor to write your shell scripts and, you know, select things and execute them. And we like that too, and so we've been meaning to work on this, and since so many of you have been asking for it, we've finally gotten around to working on this.

Here's a shell script, or hunks of shell script, and just with a keystroke, I can execute any shell script within this window. The output comes. I can do something that's a little bit more verbose. Let's actually--this is a little bit silly, but let's do a command line build from within Project Builder.

So here we go, we're building, we're building. And you know, I can scroll around in this thing and you know, whatever, the output is coming. The window where the output is going while a shell is running is blocked from further editing while that shell is running. Anything else, though, you can continue to work.

Okay? All right. What if I want some UI with my script? Well, we have AppleScript, right? And we have this tool called OSAScript, which allows us to, from a shell script, invoke some AppleScript. So here's one that will actually do a search over all of the Cocoa examples, but first it needs to know what to search for. So when I execute this, the first thing it does is it asks me for a search script. And once I enter that, it goes off and it does the search.

So this is all fine and good, right? But you don't necessarily always want to have this window open with all these scripts in it and go and select them and execute them. What if you have a script that you want to execute all the time, over and over and over again? Well, the logical thing would be to create a menu with that script. So here's a script. This is just a script. But when I run it, notice it adds two menus to my menu bar.

Now let me open up a source file because I have some scripts in my menus that are best shown with source. So one of the simple, these are again just examples, right, but you know, there's some cool ones so I'll show them. We have one that just comments the selected text. We can uncomment it, fine.

Here's one that's a little bit cooler. I can select a couple of instance variables. and I can say, you know, generate me accessor definitions for those instance variables. And it puts them on the pasteboard in this particular case, and if I go and I paste them in, you'll see that it generated the standard Objective-C getter and setter methods for those instance variables.

So we have, you know, a certain amount of power to actually get in here and edit, you know, within buffers and project builder using scripts, you know, take your input and pipe your output and all this kind of stuff. But again, because we have AppleScript available to us as well, we can involve other apps in this thing. So let's say that I, you know, want to know what this thing is talking about. What is a design pattern? Well, what if I just go and search in Google for that term? And of course, it doesn't work.

Am I not hooked up to the Internet here, perhaps?

Again, this is just some examples, but give you an idea of some of the things that we've been working on and that we hope to deliver to you in the near future. So, okay, now I really am done.

Thanks, Mike. So there's a lot of exciting stuff going on with Project Builder. Again, I'd like to emphasize that some of what you just saw there, we're not sure whether we'll get into the final version of 2.0 or not, but it will be coming along in the near future.

So, moving on to touch on some of the changes in some of the other development tools. You've seen Interface Builder this morning. You'll see and hear more about it in this session. It's our tool for building AQUA-compliant user interfaces using design guides to help you get things set up properly. For Carbon, it's the best way of taking advantage of the Carbon high-level event model. For Cocoa, it really leverages the Cocoa outlet and action paradigm.

And now, when you're designing for Apple Script Studio, this is the tool you use for that. So, in Jaguar, we have Interface Builder version 2.3. It takes advantage of Jaguar's new Cocoa archiving mechanism. So, there's actually three different ways, I believe it is, to store the nib files. This one, in the future, will give better forward and backward compatibility of nib files as Cocoa evolves.

In addition, over the past year, some of the major changes in the code are the code that we've been using to store the code. Some of the major changes that have happened in recent releases with Interface Builder, the ability to have typed outlets. So, now all of your user interface elements don't have to just say ID. They can have specific types that let you do better type checking in your source code then. Views can be popped out of containers and dragged to other containers.

If that's within the same nib file, then it actually retains all the connections from those views to your source code, which can be very helpful. You can group user interface elements and lock the position and size of user interface elements. To learn more about how to use Interface Builder with all these enhancements, go see Henri's session on using Interface Builder on Thursday.

We've touched on GCC 3.1 a number of times so far today. We've got the new persistent front end for faster build time, so read the release notes for GCC 3 and for Project Builder to see how to take advantage of this. We've added a lot of language compliance, much of it coming with GCC 3 itself. C99 compliance, full ANSI C++ compliance.

and now a full implementation of the C++ standard template library, which has been something a lot of people have been requesting. And we've done a lot of work on code generation both at Apple and within the Free Software Foundation community to improve the code generation. And our benchmarks are now showing, for example, that the AlteVec code is now the fastest of any compiler for Mac OS X. So to learn more, see the compiler development session on Friday.

On the debugger front, most of you know we take advantage of GDB under the covers. We've done a lot of work on robustness and performance tuning for the debugger over the past year. In addition, we've got some new features. We're adding the ability now to see the contents of opaque data types. So, for example, NSStrings. We'll be expanding that out to NSDictionary's, NSArrays.

We're not in either of the CDs that you have, but in the debugging session on Friday, we will demonstrate an expression watch window, which we'll be adding. Make it easier to see your global variables or other values of other expressions. And we also have now in the underlying GDB, we've enabled support for hardware watch points using page protection. So this can help find memory stomper bugs, for example.

In the performance tools area, Avi this morning mentioned that you should really take advantage of the performance tools. We've got a lot of them in Mac OS X. I'm not going to begin to go through all of these. Many of them you may have heard about before. I'll highlight a couple of these.

Down in the bottom right, you see the OpenGL Profiler. This is a really cool new application for if you're doing OpenGL coding, seeing exactly what's going on with your graphics calls and where your time is being spent and help you optimize that. Mac OS X is the only platform that has any tool of this nature. There's also some other tools for more processor-level monitoring of the performance. So there's a couple of sessions on, I believe it's Thursday afternoon, on performance tools. So performance tools and optimizing for OpenGL.

So again, to review some of our near-term priorities, we're going to be working hard to improve the build times with Project Builder and GCC3, working hard on even better code generation. We've had a lot of requests for extensibility APIs in Project Builder. We can't do it all. Many of you have requested the ability to enhance our efforts, if you will. We'd like to let you do that.

As Mike demonstrated, the command execution worksheet is something we're working hard on, and more debugging features. We're also working on a script for migration of source code from Projector repositories into CVS databases. So some of you may find that useful. And with that, I'd like to turn it over to Godfrey to talk about third-party tools. Thank you, Dave.

and David S. Goyer will be joined by the first-time Mac OS X developer, David S. Goyer. One size fits all doesn't really work for Apple just the way it doesn't work for anybody else. So we work very closely with our third-party tool vendors, both to give them engineering directions, which includes seeding pre-releases of the operating system before other vendors, because you're dependent upon them. As appropriate, we give them seeds, we tell them about new technologies coming up, and we try to make sure that we coordinate with them also on a business front.

Our partnership management group works with them in the individual market spaces to be certain that both they and the market space that we're working in know about the tools available there. Now we've seen a lot of activity in the past year as Mac OS X has rolled out, as we've moved through the various versions incrementally to 10.1.3 and now 10.1.4, and a selection of them are here during the week at our vendor fair, exhibit fair that opens this evening at 5 p.m.

We've had a lot of activity in the past year as Mac OS X has rolled out, as we've moved through the various versions incrementally to 10.1.3 and now 10.1.4, and a selection of them are here during the week at our vendor fair, exhibit fair that opens this evening at 5 p.m.

Basic is a development platform in heavy use on the Windows platform. We hear all the time this story that there are three times as many applications available for Windows than there are for Macintosh. Apple has chosen not to go into the basic development world because we have an excellent third-party partner who's doing that scene for us. And to talk about that, I'd like to bring up Geoff Perlman from Real Software to talk about Real Basic for Mac OS X. Thanks, Godfrey. So, um... get to the next slide.

Ah. Okay. So what is Real Basic? Real Basic is a cross-platform development tool. I want to clear up one misunderstanding that some people have about our product. It's not interpreted. There's no byte code. It compiles to machine code on all the platforms we support. It's fully compiled. It provides a modern object-oriented language using a dot syntax, supports inheritance, it supports polymorphism, virtual methods, constructors and destructors, all the kinds of things you come to expect from a modern object-oriented language.

It also provides a native UI and native performance on all the platforms we support, which means that when you're compiling your application for classic Mac OS 8 and 9, you get that UI. If you're compiling for Mac OS X, you get Aqua. If you're compiling for Windows, be it 95 or XP, you get the native UIs for those platforms.

and Real Basic provides you with a rich set of intrinsic functions and classes. We provide you with things like 3D APIs, printing APIs, QuickTime APIs, APIs to access sound and pictures, graphics, all kinds of multimedia stuff. And the idea here is that you're abstracted from all the platform specifics. So you can write one set of code and deploy it on all the different platforms that we support.

and we provide a cross-platform plugin API. So if you want to use some of your existing C++ code, you can write plugins that'll run on all the platforms that we support, which is really great. We don't claim the real basic will do everything we necessarily want it to do, so that's why we provide a plugin API just for that. And finally, the whole point of cross-platform is to write a single application and deploy it in many different places. In our case, we support Mac OS 8, Mac OS 9, Mac OS X, and Windows 95 through XP.

So what's new in Real Basic? Well, there's a bunch of new things that we've been doing in the last few versions. We support core graphics text rendering across the board everywhere in Real Basic. We have a new edit field using AtSui at the low levels, so you get multilingual support through our edit field. And, of course, core graphics through our edit field as well. And for those of you that have done that in Carbon Apps, you know how much work that is, and we've taken care of all that for you in our edit field.

And we've got external project items. External project items allows you to share anything that could be in your project among multiple projects. That means classes, class interfaces, windows, modules, pictures, sounds, quick time movies, anything at all that you can put into a Real Basic project can be shared among several projects. And they're stored as external files, actually sort of as aliases, which means that any changes you make in one automatically will be in any other projects that you're building. Another nice thing about this feed is that it's not just a file. It's a file.

We also have an interactive shell. We have a shell class that lets you talk to the Unix shell. And this is really great if you want to do something as simple as put a nice UI on top of a series of shell commands. It's really great for that. For example, one of our engineers put a nice UI on top of top. And it took him about maybe 20 minutes to do it.

and we do things like, you know, we do the hard work for you. For example, for Carbon, serial ports aren't supported. Well, we've done the work to make them supported in RealBasic. So that means you can use our serial port API to write applications and talk to serial ports on 8, 9, 10 and, of course, on Windows as well.

and hundreds of API-- or excuse me, hundreds of IDE, intrinsic library improvements, et cetera, across all of Real Basic. We've added Regex, for example, to Real Basic. We've got a dictionary class in Real Basic. And as I mentioned earlier, we have a fairly extensive 3D API that abstracts you from OpenGL on Mac OS X, QuickDraw 3D on Mac OS 9, and OpenGL or some other render on Windows.

And finally, where are we at WWDC? Well, we're at the exhibit fair in Hall 1. We have a Birds of a Feather session on Tuesday from 7:39 in Room K. And we have the lunch presentation on Friday in Hall 2. I wanted to mention one last thing that I didn't put a bullet point up for.

You know, people ask us, where are you guys going with Real Basic? Well, I want to tell you real quickly about some of our future directions for Real Basic. One is we're working on Mac OS support for Real Basic. So you'll be able to create Mac OS executables. We're working on version control. So Real Basic in the future is going to have tightly integrated version control for team development.

Unicode support across the board. Things of that nature. So, for example, more platforms and perhaps the ability for you to write things other than just applications, like CGI's, plug-ins, those sort of things with Real Basic. So come visit us here at WWDC and thank you, Godfrey, for the opportunity. Thank you very much, Jeff.

Great work from Real Basic folks. Some weeks I've gone to Version Tracker and taken a look and about 40 to 60% of the new applications being announced are all written in Real Basic. So it's a very, very strong environment. With that, an overview session for development tools on the Macintosh simply wouldn't be there incomplete without a word from our friends from MetroWorks. And to fill that, I have Matt Henderson, the technical lead for the CodeWarrior IDE, here to speak.

and David Levy will be joining us. Just a quick introduction for any of you that might not have heard of MetroWorks or CodeWarrior. In 1993, we built a new development environment from scratch to help support the transition of Apple from 68K to PowerPC. That was a very traumatic time for Mac developers and CodeWarrior was probably the first compiler available to the general audience of Mac developers for PowerPC development. It was very successful.

Virtually all of the PowerPC commercial applications that were built for the initial PowerPC hardware were built with CodeWarrior. And that trend has continued. And in 1997, we added support for Mac OS X. Right from the very earliest announcement of Rhapsody, we've been on board with Apple's next-generation operating system plans, even to the point of adding Objective-C when they were talking about Yellow Box and there was no Carbon yet.

And to this day, our support for Mac OS and Mac OS X have paid off and most commercial Mac OS applications are built with CodeWarrior. Some recent releases include Photoshop 7, Alias Wavefront Maya, Office 10. All of these things built with CodeWarrior are great applications. And that's what we love to do is to empower developers to build great software for Mac OS and Mac OS X. And so with that, I'd like to talk about CodeWarrior for Mac OS version 8, which is coming soon.

In fact, it's coming May 31st, so pre-order at the show. But, you know, quickly, I'll go with some cool things in 8.0. Avi Tevanian plugged Mako this morning. He said, get off CFM and on to Mako. We're here to help you. We've got a new, completely rewritten, faster Mako linker that's based on our proven PEF linker technology. Our old Mako linker was based on the Apple Darwin open source linker. It was kind of old, kind of slow.

The new Mako linker is very fast, very...generates very tight executables. You should see the executable size for Mako applications using our new linker go down from anywhere to a half to a third of its original size. Also, because it's our linker, we use Sim for debugging symbolics instead of stabs.

Sim is actually an Apple-designed debugging format that we adopted in the early days of PowerCon. It's a very small PC, and it's very small, it's very compact, and it allows for greatly improved debugger performance. So we're very happy to have Sim for Mako apps, and it tremendously improves the Mako debugging experience.

But combined with a new linker, I think that you'll find that the turnaround time from the time you make a change in your source code to the time that you've built it, linked it, and are debugging in Mako land to be much, much shorter than it was in Code Warrior 7.

Another cool thing, cool feature for 8, custom debugger data viewers. So we have two sorts of things for this. One is a data-driven way of defining the display format for your variables. For example, for the STL string class, we defined some simple XML code that will tell our debugger that when you see a string object in our debugger, you really only want to see the string value. You don't want to see all the member variables and have to dig through it to find what the string is.

But even beyond the simple data-driven way, you can actually write some plugins to our debugger to produce whatever representation of your data types that you want. Some of the examples that we're providing is regions. So if you wanted to see what a region was, you can double-click it in Code Warrior.

It'll pop up a window that will draw the region for you. You can look at it, see what it is, see what its bounding box is. And none of this trying to define what your region is based on just the simple flat... and David Schmuck are also featured. Another great feature: C++ and Java code completion. No more digging for header files.

Type the first few characters of a function name, hit control period. It will bring up a little window that shows you all the possible functions that it could be. From there, you can pick a function, it will insert it in your code and you can go on to the parameters. It will look up the parameters for you.

So as you type, you can see the function definition and the parameter types and know what to fill in and not worry about digging through your source hierarchy to find it. Next great feature: Cocoa support. We worked very closely with Apple's interface builder team to integrate the Code Warrior IDE and interface builder so you can use them together. So now instead of using project builder and interface builder together, you can use interface builder and code warrior.

this is great by using-- and we encourage-- I know there are a lot of Cocoa developers that are still using Apple tools, and we hope that they'll consider Code Warrior because of our faster build times, you know, better code generation, smaller executables, et cetera. And there's much, much more.

We've added a ton of features. This is one of our biggest feature releases in a long time, and I mentioned that it's available on May 31st. And with that, we'll plug what we have at the show today. Tomorrow we have the Metro Records lunch presentation. Apple has very generously given us an hour of lunch time to show off all our cool new stuff. It will be here in Hall 2.

I encourage you all to come. We'll have a lot of demos. We'll have Berdina Barada, our CTO, leading you through most of that. We have a Birds of a Feather session tomorrow night, 7:30 to 9:00 p.m. We'll have a number of the Code Warrior engineers are here at the show, and they'll be answering your questions.

So come to Hall 2. You can ask any of the Code Warrior engineers, find out the product, make feature requests, complain about your favorite bugs, do whatever. Tuesday and Wednesday we're running the Code Warrior Lounge, if you remember that from years past. So come in, hang out. We've got a pool table. We'll have online stations where you can preorder Pro 8.

It's in the Hilton Plaza room. And finally, we have the Metro Works booth in the exhibition hall that's during the exhibits fair. So it's open standard exhibition hours. And with that, I'll give it back to Godfrey. Thank you, Matt. So some great stuff. I'd like to bring Ted back now to talk about future initiatives for Apple tools.

Three topics to touch on very quickly. Database integration, Objective C, futures, and web services. One of the new things in the Jaguar seed is ODBC connectivity. We're bundling, as part of the Darwin level of the system, an open source solution from a company called OpenLink. They make something called IO-DBC Driver Manager.

For those of you who have ODBC databases and applications that use it, this is a way to get these different services to plug together. It works with many third-party ODBC drivers, including FileMaker and such, and it's really great for legacy development. ODBC has been around, I think, since Windows 95 or something.

But much more important to that is our Enterprise Objects Framework. And what this provides is an object-oriented database access, or rather, access in an object-oriented fashion to relational databases, more accurately. And it allows you to use Interface Builder to easily connect the data objects in the database using the schema-driven information to the user interface widgets. We're going to briefly touch on where it's been in the past, where it is today, and where we want to take it.

So in the past, EOF has been very popular and it's been around since next days. It has very clean Objective-C integration with both Cocoa and Interface Builder. People are extremely highly productive. But it had very limited database adapters. If Apple or Next didn't write the adapter for it, it didn't exist.

And so it really meant that it only worked with a limited number of databases and the performance wasn't always everything you might want it to be because, in fact, one of the big issues to writing a good multi-tier application is to really use some of the low-level I/O features in the database adapter system. So, the third problem with EOF in the past was that it was really tied only to older versions of web objects. This meant that in order to get it, you had to license a copy of web objects for every client application you may want to ship.

EOF in the present now uses Java. And it uses Java so that we can leverage the Java community and their use of database systems. And there's a very important initiative in Java called JDBC, Java Database Connectivity. And what that does is it provides us with a very rich set of adapters that are plug-compatible with Java. The downside, of course, is it does require that Objective-C programmers do a little Java programming.

And this is, you know, may not be the most positive thing with an Objective-C programmer. And I'm going to show you a little bit of code and talk about that. One bit of good news about EOF today is that you can now get a redistribution license available today. And so that's one nice bit, nice new thing.

So those of you who have been around for a while know the EOF story better than I do, and I know this at least represents that we are making some progress on the EOF front. I don't want to take up too much time. There are EOF-specific sessions later in the week, but this is just a screen snapshot of what a typical EOF client application looks like.

It uses Cocoa widgets very heavily. And one uses Interface Builder to just simply drag and make the connections between the tables, the table interface on the right-hand side of your screen, using two of the interface widgets, and it's a very easy system to use. It provides a tremendous amount of flexibility because it is very much almost code-free development. Almost code-free, because there is some glue code required, and today you have to write that glue code in Java. But it uses mostly Objective-C Cocoa data types. So you can see in blue, of course, I've highlighted the Cocoa calls. In orange are predominantly the calls in Java.

And typically a given window will require between 10, 20, really lines of code. A very complex controller object may require 100 lines of code. But really on average it's about 10. There are many cases even where it's zero lines of code. So this is the one unfortunate thing about today's EOF. And we are working to fix this.

In the future, what we want to do is to make it so that there is no runtime inefficiencies between Objective-C and Java. And to make it so that we have a much more seamless boundary between the two, we also want to provide you with the choice of programming language. So you get to choose whether you're programming in Java or Objective-C or other languages as well.

And that, of course, means, in many cases, of course, having full access to the native Objective-C data types and not just the Java data types. Finally, we want to hit on palette integration so that the components directly feel very much integrated with IB for better productivity. And we're going to use this to drive our thinking on improvements to Objective-C. Objective-C is a fabulous language. It's a very high productivity and allows for a great deal of capabilities at both the low C level and the high object-oriented level. And we want to keep that.

We are committed to Objective-C. It is Apple's primary language for desktop applications. It's one that we see the best results in for native look and feel for getting the most out of the Mac OS X platform. And we have a number of improvements we're investigating, including things like exception handling, garbage collection, and other syntactic additions, not changes, additions.

We want to improve the interaction with other languages. These are features that we've been hearing from you and hearing feedback on and we want to get more feedback on at this conference and we want to use this to drive Objective-C forward so that it doesn't feel like it's lagging behind and falling in the language marketplace.

I guess there's still some Objective-C programmers. Great. Web services. Web services are something new. And of course, you can't pick up a computer journal these days without having some third of it or two-thirds or the entire thing being devoted to web services. Web services really are an outgrowth, of course, of the database and web-based application integration, spitting out HTML pages that has been the predominant theme of the Internet for the last seven years. In the last two years, there's been a tremendous repurposing using XML and SOAP to pull and separate the web services, the data layer from the presentation layer, so that other applications and other programs can read the data in.

What that means to Apple and to development technologies is we've needed to integrate and to extend each of the different platform services that we provide with additional features so that you can easily take advantage of web services. So in AppleScript, it meant adding a small vocabulary. In C++, Objective-C, we've added a core framework, core services. Java, of course, has the famous JAX frameworks.

Later in the week, we'll be showing you something called WebObjects Direct-to-Web Services, which brings the power of WebObjects to the web service environment. This morning, you saw Sherlock 3. And as well, of course, we have the Apache Tomcat Access Package on top of the Mac OS X server. So altogether, this is a terrific set of environments. Really, every one of Apple's technologies supports web services. So to show you what this means in terms of integration and synergy, I'd like to invite up... Francois Jouel and Tim Bumgarner to demonstrate web services with WebObjects in AppleScript Studio.

Thank you, Ted. What is so great about web services is that you can take completely different technologies and using a couple of industry standard protocols, which are namely XML, RPC, and SOAP, you can use those to take those technologies and have them work together. Now, the problem, though, is that it actually can be quite a bit of work in both providing the web service, constructing it, building it, and then publishing it, and on the client side, actually consuming that service. And what we'd like to do today is demonstrate a solution to that problem. And so what we're going to do, and slides, actually. Back to the demo. Slides.

Thank you. Okay. What we're going to do is we're going to introduce direct-to-web services. And this is going to be built on top of WebObjects. And it's going to be -- enable you to easily construct or publish your EO model and create sophisticated Web services. And then on the other side, we're going to take advantage of AppleScript Studio.

That makes it very easy to build an application. And we're going to leverage AppleScript's built-in support for XML and RPC SOAP and be able to easily create this application and have them talk together. So we're going to have Francois show how easy it is to start from scratch and build a Web service that I'm going to then take and use.

So Francois? Hello everybody. I know what you're thinking. It's 4:30 and yet another Frenchman to listen to. Bear with me and I'll show you how Direct2F services is extremely cool. So the first thing I'm going to do is to open EOModeler and show you the diagram view of the database I here have on this machine. It's a simple real estate database.

And what EOF enables me to do is to take these database tables and turn them into objects that are readily available to my server. The only thing I want to do here is to browse the database to verify that everything is working correctly. And that's all I need to do with EOModeler.

Now I'm going to start Project Builder and create a new project from scratch. We have added a direct web services wizard. And because this is a real demo, I'm going to start with I will name it real demo. I will not deploy it as a J2E servlet. The JDBC adapter is already selected for me. What I need to do now is add the model I opened earlier.

Here it is. And that's it. That's all it took to create a complete web services server that knows all about this database I showed you earlier. Project Builder compiled the project and now started the server. Because this server is built on top of web objects, it is entirely written in Java and is totally portable. It will run on any J2SE, J2SE-based server. Platform out there and can be deployed either standalone or as a servlet on top of a J2SE server.

This is all very nice, but everything has been turned off in this web service for security reasons. To configure it, I'm going to use the web services, the direct web services assistant. It is a swing-based application. that connects remotely to the server running in the background. So I can now close the window for the server and concentrate on the assistant.

On the left hand side you've got a tree view with a default service created for you. I'm going to enable it. Basically what the direct web service assistant does, it makes a public view of your private business information. On this right hand side column you've got all your tables that you do not want to expose.

I'm going to pick one, the listing, and make it available to the world. Because this is an alpha, in alpha state I know I have to save it, close and reconnect. Bear with me for a moment. Okay, now if I go back to the left column I see that four services have been created for me as conveniences. If I click on one of these...

Now, what I can do here with these buttons is, for example, clone this service and customize it.

Now I have a clone. And because I'm going to search on zip code, I'm going to get rid of all the arguments but the zip code entry. Okay, the return values now look all good. I want to get a lot of information on this listing properties. Something else I would like to display. My database contains JPEGs for every houses that are for sale. I would like to display these JPEGs on the client. For this, I have a listing photos table that I'm going to expose.

So here the power of EOF comes to play. I am telling the service to return a photo URL, although there is no photo URL in the database. All I have is JPEG data. Well, I have added a little bit of business logic in my enterprise object representation of the database so that when the data is extracted, a new URL is returned for it so that the client, when it gets this URL, can call back and get the data from the server. You see anything wrong, Tim? - Nope. - I think I'm going to save. And move on to the test interface.

The test interface is going to come up with two tabs. One showing you the service WSDL. So WSDL is a web service description language. It's very complex. It's written in XML and it's something that no human should ever have to look at. Unfortunately, all the other tools out there require you to touch the WSDL at one point or another.

Because the main problem with the WSDL, although it's very easy to specify in this format the argument, it's very hard to specify the return values. When you return a complex object, you don't know the structure of this object underneath. Well, with direct web services and its model representation of the database, we have all the information necessary to build a complete WSDL file.

I now move on to the testing tab and the test interface built me a trivial text field so that I can test my service. and that's it. It's written the listing that is associated to this zip code. At this stage, a direct web service assistance works and it's Tim's turn to build a client on top of it. Thank you Francois. Great.

So what we're going to do... and David Koehn. We're going to take advantage of this listing for zip code web service that is now published. It's out there live and we're actually using the network and we're going to go across and talk to that. I'm going to start in Project Builder and for the sake of time we're going to move it. It's pretty much an assembled application but we'll finish it up. So I'm going to launch into Interface Builder and I've got my application here that has a table that's already laid out with all the columns that I want.

It's got a search field but it's missing our find button. So I'm going to go ahead and just drag in a button and we get the nice Aqua guidelines there and I'm going to rename it to find. Change the size a bit. Okay, resize it over here. And the other thing I want to do is actually change some of the attributes. It would be nice if it was the default button and we can simply bring up our attributes and set it to be a return. So now it's got the nice Aqua blue and we don't actually have to click on the button. We can hit return.

The other thing we need to do now is to actually add our AppleScript functionality. And what I want to do is I want to know when somebody clicks the button, execute some AppleScript. And we do that through the AppleScript application. So I'm going to go ahead and click on the button and I'm going to go ahead and add my script.

And I'm going to go ahead and click on the button and I'm going to go ahead and add my script. And I'm going to go ahead and click on the button and I'm going to go ahead and add my script. And I'm going to go ahead and click on the button and I'm going to go ahead and add my script. And I'm going to go ahead and click on the button and I'm going to go ahead and add my script.

And I'm going to go ahead and click on the button and I'm going to go ahead and add my script. And I'm going to go ahead and click on the button and I'm going to go ahead and click on the button and I'm going to go ahead and add my script.

And the code is very simple. I check to see which button was clicked since I named it find. I can see, make sure I'm in the find. And then I'm going to actually execute this handler that I've created called find with zip code. And I do that by passing in the contents of the text field that was my search field. So let's take a look quickly at the find with zip code. and this provides some UI, it sets up some status, shows a progress bar. And then the interesting part is that I do this listings for zip code.

This is where it gets interesting. This is where we take advantage of XMLRPC and the SOAP support in AppleScript. We basically point to the URL that we've constructed that's his web service and using just like we do for telling a local application, we do tell application the application. We set up some parameters for the SOAP service and then ultimately we call SOAP. This actually takes the method name called listings for zip code. Let's go ahead and build and run this.

And up it comes, and I can actually even type in wildcards. So I'm going to put in 95 star, click my Find button. It's talking to its web service, went and got those values, populated the table, and then I can start double-clicking on this and actually getting that image that he was vending from his service and putting it into my detail. And I just quickly look through it for a couple of these.

Oh, let's check a look at this one here. Oh, I'd say that this one's a little overpriced according to that image. All right, you can see actually how easy it is to take advantage of web services, and you can build some compelling applications. And with that, I'd like to bring up Ted.

God, I was getting so interested and I said, oh yeah, that's right, I work here. So, in summary, we're focused on doing some great development tools. We work with our partners. We provide resources to them. We want to extend to new initiatives. I want to invite Godfrey DiGiorgi up to give you the full week's roadmap. Please, please, please find Apple people that you saw up on stage. Give them your comments and feedback. Find me. We want to hear what you've got to say. Thank you very much. Thank you.

With five different technologies to present, blow by blow, these are color-coded to be the same as what's in your program guide and indicate the tools track, the Java track, the WebObjects track, some of the Core OS and some of the lunch sessions. Please don't forget the exhibit fair starting this evening. Remember the Developer Depot is also here all week to vend the developer tools.

The next sessions that you might be interested in attending, the Java and Apple State of the Union, immediately follows this session in this hall. Tomorrow morning we have our WebObjects State of the Union and the Client Web Services Framework session. And then later in the afternoon tomorrow, the first of our tool sessions following this overview, the Command Line Development Tool session.

For more information, these are the URLs. You'll see them in all of the sessions through the week. And they're also included in the master URL list, which shows up at the end of every session. That's about it. We have no time for QA today. We would invite you to please attend the feedback forums on the technologies that are of interest to you. They're listed in your program and here for your convenience is all the times. And with that, thank you very much for attending. We hope to see you through the week.