My name is Dave Payne. It's been my privilege over the past couple of years to have the opportunity to build and lead the developer applications engineering team for Mac OS X. I stood on this stage a year ago and described how Apple was committed to the creation of great development tools for Mac OS X.

I'm very proud to be back this year to show how we're delivering on that commitment. So what we're going to cover in this introductory session this morning is an overview of Apple's development tool strategy, a look at all of Apple's development tools for Mac OS X, a quick run through with that, and then start focusing in on the new Project Builder.

You've probably heard references to that in a few sessions by now. I'll be showing you what we have in Developer Preview 4, what's coming soon, and what's on the drawing board, some things that we're working on that are a little further out. And we'll also be touching on some of the new features of Interface Builder, and the new Project Builder in DP4.

Then I'll get to some of the specifics of delivery and deployments of the new Project Builder. And because this is an introductory session, we have a lot to cover. I have pointers to numerous other sessions where you can find more details about what I'll be talking about here.

So to give the senior management perspective on Apple's overall development tool strategy, I'd like to bring on stage my manager, Steve Naroff, the Senior Director of Java and Core Tools. Steve? Hi there. This is an outline of the strategy. Basically, we feel strongly that Apple has to own its own destiny and develop great tools for our platform.

Aside from developing great IDE, we need to support the platform initiatives. For instance, when we go to new hardware, the compilers need to support that hardware in a first-class way. When we develop new frameworks, like Cocoa, the IDE has to support them in a first-class way. So we have a strong background that, just as Microsoft uses their tools to push their platform initiatives, at Next we have the same background, and at Apple we want to carry through that legacy to make sure when we do do new things, the IDE is presenting them in a first-class way.

Another part of our strategy is to make sure everyone at Apple is living on these tools. I've seen a lot of Apple development efforts over the past decade, mainly from the outside. And at least the last one, which was centered around Dylan, one of its major flaws was no one at Apple was actually using Dylan. Dylan was some really great work that unfortunately died on the vine because no one at Apple actually cared enough to use this stuff.

And in fact, if years ago more folks at Apple were using this stuff, Dylan could have been what Java is today. But unfortunately, that didn't happen. So what we're hoping is the next time there's an opportunity like that, we will make sure we're on top of it because Apple engineers will in fact use the stuff we're developing. And we have support from the very highest, part of the company, Steve, who feels strongly that we need to do this.

Ten years ago, actually, I'll show my age here, more than ten years ago, back in '88, I was one of the early adopters at Next of the GNU compiler project. And it was in its infancy at the time, but as you know today, it's the underpinnings of the Linux movement.

And in fact, open software is now socially acceptable, whereas it wasn't 12 years ago. And we feel strongly that we need to drive this. We need to be a major player in the open source community. Next was a fairly small company. Apple's a much larger company with more resources.

We're putting our resources behind the open source initiative with Darwin, and I'm putting my resources in the tools area behind the open source movement as well. We've benefited in many ways already. Much of the AlteVec support we have in our GNU compiler was actually originally done at Motorola. Because Motorola invests in the GNU tools. IBM invests in the GNU tools. There are countless number of companies that invest in the GNU tools, and we want to benefit from that research and development.

Another thing to mention about the GNU tools is I think they compile, the compiler in particular, compiles more lines of code, I think, than any other compiler on the planet. It compiles all of Mac OS X, it compiles all of Linux, it's compiled all of Maya, it's compiled a lot of stuff.

And as a result, it's extremely robust. It's not a toy. So, here are other open source projects you could read that we leverage. In the Java space, we're also shipping the Jyx compiler, which is an open source Java compiler by IBM. And even though we want to have a great fit and finish to our tools, as you'll see, Project Builder's totally built with Cocoa and Aqua, we want to work with third parties. By no means do we want to close anyone out of the tools market. We want to work actively, and we are working actively with MetroWorks/Motorola, Enprize, Pacific Sierra, Absoft, and lots of others. We, again, want to collaborate with these vendors.

Sometimes that may mean the tools are available or integrate with Project Builder. Sometimes that may mean we may take our tools and integrate with them. So, it's sometimes unclear what collaboration means, but nevertheless, it is a design point. We do not have any motivation in owning or being the exclusive tool on the project. We are the exclusive tool on the planet, at least on the Mac platform. So, here's the thing.

I guess the take-home point there is competition is good, and we want to compete, and we think what we've done that we're going to show you today is competitive. A couple notes before I turn it back to Dave. One is, even though Mac OS X is in DP4, this is the first release of Project Builder. So it's our, I won't say DP1, because we've released it internally for months and have been using it, but it's our DP2-ish release.

So bear that in mind when you use the tools. There's still, we still have a ways to go before we finish this thing. There are going to be some bugs, there are going to be some missing features, so I wanted to set that expectation appropriately. And... Well, I guess the last thing is, what's thrilled me is we've built a great team over the past year to deliver this product.

And even though it's not everything we want it to be at this moment in time, I'm absolutely confident 100% that this product will be everything we want it to be and you want it to be, because we have a great team in place. And you'll meet many members of the team over the course of the talk. So with that in mind, I'll hand it back to Dave. Thank you.

Thanks, Dave. All right, so diving right in, let's start looking at the new Project Builder in TP4. So first off, what is it? Project Builder is the new integrated development environment for Mac OS X. It's been a long time since Apple's had an integrated development environment, perhaps never. Now, so Project Builder is the centerpiece of what we're trying to do with development tools at Apple.

We want to tie many things that we're doing into this IDE. There's a number of other components. We work with the Interface Builder, User Interface Layout Tool. We work with the WebObjects tools, so WebObjects Builder and EOModeler. We work with a number of different compilers, so GCC, as Steve talked about.

We work with the REST for your Mac Resource Manager resources, Java compilers like Jyx and Java C. We work with a variety of debuggers, like the GDB debugger for all our C-based languages, Java debuggers tying into the virtual machine there. And we're working with the AppleScript team on some of these things, too.

So what all do we need Project Builder to do for us? Again, as Steve mentioned, we want to be able to live on this tool internally at Apple. That gives us lots of great feedback from people. We have a lot of new customers who are, it's wonderful, they're in my face every day. So, and we also want it to be a great tool for you.

So, among the requirements, we need to be able to build the Core OS itself with it. And how that translates to you, if you're developing device drivers or kernel extensions, I/O Kit modules, you'll be using the new Project Builder to do so once we've got the KDK all put together there. We build our full-time project.

We build our framework with them. So, the Carbon framework, the Cocoa frameworks, Java, a variety of frameworks there. And of a special importance to you, there's a variety of different types of applications, as well as plug-in modules, frameworks, shared libraries that you can build with the new Project Builder for Carbon, for Cocoa, for Java, and for WebObjects.

So we did actually have a previous product that we called Project Builder. Some of you may have used it. This was derived from Next. But when we looked at all the different requirements that we needed it to solve, that we need Project Builder in general to deal with, we realized that the existing Project Builder was not really going to be able to handle it. So we have completely rewritten it from scratch for DP4, but we do need to be able to import projects from it. We also would like to be able to import projects from Code Warrior. And in fact, in the next session immediately after this, we'll be showing that.

And then finally, in order to be a full Carbon development environment, the definition of a Carbon application is it should be packaged in an application package that's double clickable on both Mac OS 9 and Mac OS X. Currently, Project Builder is building Maco binaries that are double clickable on Mac OS X. We are starting to work on generation of PEF binaries so that we can get double clickable Carbon applications for 9 as well. So, being a full Carbon development environment. So, in order to meet all these requirements, again, we decided we need to start over.

So, we did that January of 1999, so not a tremendously long time ago, about a year and a half. I started building the team at that point, had approval from senior management to add more folks. Some of you may have remembered last year at WWDC when we showed a demo of a prototype called PBX.

So, if you hear of anybody else on stage referring to PBX, that's because I referred to it internally as PBX. The product was called that up until about a month ago. But the official name of the product is now Project Builder and every time they say PBX, charge them a dollar and I'll split it with you.

So, but that was a little scary because by that point I'd only had two guys writing code for three months. So, I beefed up the team considerably more after that and we got to an Apple internal rollout in February of this year. Now, my team had been developing Project Builder with Project Builder for a long time before that. This was about the time of DP3.

We did not go out on DP3 because we hadn't had enough internal feedback yet to tell us all the ways in which we were brain dead. So, we've let the internal developers tell us that. It's been used widely across Mac OS X. And now it's your turn to tell us how we're brain dead. So, we have our first external release on the developer preview for CD. And from here it's onward and upward for us and the OS onto GM.

The concepts of frameworks is very important with Mac OS X. Framework is our shared library packaging mechanism. It includes all the, for example, headers, public headers, documentation, resources. Project Builder directly supports making use of frameworks. We also let you create bundles. It's very important to understand the concept of bundles on Mac OS X. An application package is a bundle.

Plugins are bundles. Frameworks themselves are bundles. Bundles have information property lists that we know how to edit, and this is how you would do your localization through editing of bundles as well. So with project layout and editing, there's a variety of types of ways to create project templates. We have a whole bunch of standard project templates. You can define your own.

Again, we can import existing projects from the old Project Builder and from Code Warrior. We now have user-definable groupings of files. So this is independent of physical layout on disk, which was not the case with the old Project Builder. It's also independent of how the build system works.

So we now also support a target model. You can have multiple build targets per project and select which one you want when. And projects can reference other projects, so you can have dependencies on that. That feature, I guess, is a little bit yet to come, but we're working on that one.

On the build system, last year, when I talked about the build system, I described the build tool Jam, that we leverage Jam as just another make, a freely available piece of software that we get off the net. But what we've done in the meantime is abstracted things away so you don't need to have nearly as good an understanding of the Jam tool itself. So that's what we use to call down to all our compilers, so GCC, Res, Java C, et cetera.

But in the IDE, we take advantage of what we call build phases. So there's a variety of standard build phases for copying your framework headers, copying your resource files, compiling your source code, linking, et cetera. And the Jam build tool we are leveraging at this point to get automated dependency analysis.

Of course, that's obvious, right? But well, actually, our old product didn't do that right. But there is no need to go in and edit make files. So we're handling all this within the context of the IDE, and you can customize your build by adding additional scripts, custom build phases as necessary.

So as Steve mentioned, we are taking advantage of the GCC compiler. For those of you who knew the term EGCS or EGGS, this is that version of the compiler, GCC 295. It's the latest. This is a significant change in the compiler from what we had before. This provides full C++ support now, including an up-to-date standard template library support.

One thing to note about this is that it is stricter with ANSI C++ compliance. So some of the users have told us that, "Wow, I found bugs in my code that I didn't know existed with the previous compiler." With this compiler, we have support for the Velocity Engine, and Steve mentioned the company Pacific Sierra Research.

That company is working to do an automatic vectorization support for Mac OS 9 and for Mac OS X, because they're working on a new version of the compiler. So unless you're familiar with it, vectorization is a little bit difficult. So we're working with that company to try to take full advantage of that.

And again, it's very important to note that GCC does build all of Mac OS X, all the Core OS code, C-based code for Carbon frameworks and core foundation. C++ applications like Finder or Sherlock. Yes, we do use Power Plant for some things internally, so we build that, our own version of that. Mac App is now building in Project Builder and with GCC.

And we also support Objective-C still as a primary development language for Mac OS X. So the Cocoa framework is written with Objective-C. The mail application, Project Builder itself is a Cocoa and Objective-C application. And just to note, you can still write your Cocoa applications with Java as well. So Cocoa Java apps.

One final thing is that we actually do feel that it's very important to be able to build from the command line. There's a lot of things you can leverage in that way. At Apple, our build and integration mechanism builds all of Mac OS X from the command line, as opposed to firing up the IDE in any way. But what we're doing here, rather than calling Jam directly, we've put a new command in place called pbxbuild, which, of course, since pbx is a denigrated term, this stands for Project Builder External Build Command.

So, with this command, what we actually do is a very small application that actually links with the same framework as the Project Builder application itself and actually opens up your project model and invokes Jam once per target of the project you're trying to build. So, you can automate builds with a shell script, a nightly build process, for example, or log in over Telnet and run a build.

I automate my performance testing and quality testing of the build system through this mechanism. So, now, what I'd like to do is bring one of the engineers up on stage, Manuel Da Silva, to help me go through a demo of Project Builder. The first page is here. Thank you.

So what we're going to do here is take a look at an example project from the system. So the GLUT Examples is a project that you would find out in System Developer Examples, GLUT Examples. This is the OpenGL Utility Toolkit Examples project. It's got some graphically cool stuff in it.

We've stripped down this project a bit so that it's only got a few targets in it. Let's take a look at what happens when you first launch the project. We've tried to, as we're doing with the finder and with mail, we're optimizing for use with a single window here.

As we're showing, we have a variety of new projects that you can create. You can create Carbon applications or Cocoa applications, CFPlugin bundles, frameworks. But we're not going to do that. We're going to work with this OpenGL example. What Manuel has opened here is the groups and files outline on the left. On the left, we have tabs that show structure of your project. Across the top, we have tabs that are for tool operations, so find, build, debug.

So, with the structure here, we have three of the examples here: GeoFace, RollerCoaster, and Use a Sphere Map. We can open one of those groups, take a look at the files in that. We see little circles in the left-hand column that shows that these files are built for the particular target that's our active target. We can see that up above, GeoFace is the currently selected active target.

And down below, we also see that we're linking with the GLUT framework, and you can navigate down into the headers of that. So, that's a great way to get started. We do very directly tie into the framework mechanisms of Mac OS X. This is what you do with the Carbon frameworks, or Cocoa, or whatever.

So, let's take a look at how we can do grouping, for example. So, we can select... Let's say that we wanted to have the source files in a group and just call them the sources group. So, we can select them, create a new group, call that... Looks like we can move code in there. We'll show you moving.

Okay, so that's all under sources now. So again, no physical tie to the layout on disk. Now let's take a look at how you would look at some of these files in the editor. We'll click around on a couple of files, main.m, display.c. So these all show in the same window. There's a pop-up here if you want to go back and forth between files that you've recently been to.

And you can also use a browser-like back and forth navigation buttons. But let's say that you did want to have a file of source code off in a separate window. Just go over to the files line and double-click to bring it up in a separate window. That's got all the features. You can split the window, split the panes in the window, actually bring up even other files in it, etc. So a lot of flexibility there. You can have as many separate windows as you want. Now let's take a look at the file inspector.

So up under the project menu, show the inspector. This is where you would set things like what's the reference style to how to get to the source code here. So group relative, project relative, absolute. This is also where you would do, for example, localization. So if you had an interface builder nib file and you wanted to localize that, you would do that from here.

Okay, so let's take a look at building. So we'll go ahead and just build the entire GeoFace project here. GeoFace target, since this is our active target. So now this is one of those areas where we know we need to make some adjustments. We know we need to make some additional user interface improvements here. What's popped down is the expert mode build panel.

What I was trying to do at Apple was get this product out usable as quickly as I could so that I could stop maintaining the old project builder that many people were using. So there are areas of the product where you'll find sort of expert modes built in because we haven't quite had the opportunity to build in all the nice user interface that would show which files need to be rebuilt and which files are building now. But this has built. So now let's say that we had a syntax error in a file. How would we deal with that? So let's go ahead and introduce a syntax file in the head.h file and save that and then rebuild again.

In this case, we see up in the build summary that the number of error messages pop up. We can select on one of those. That takes us to the line of code. Fix the syntax error there by doing an undo. And we can undo past the last save. It's a multi-level undo, multi-level redo.

And now from here we can rebuild. And it just goes out and builds exactly those files that were dependent on the head.h header file. And we're successfully built. And we can go ahead and launch at this point. Okay. So we've launched the target executable. We can make it do a little dance here. Also, one thing to note, Manuel is pressing the A key.

Make him smirk there. You noticed his lip went up a little bit. And you're seeing build log -- or log messages from the application in the standard input/output window behind there. So if you had log messages you wanted to print out, for example. Okay. So let's quit out of that.

Now let's take a look at target editing. So if we select the targets tab over here on the left, you can see that we've got a number of different targets. We'll select the geophase target. And that brings up a different type of editor into the main window. So this editor now shows us the files and build phases.

This is basically how your build is going to work for this project -- what headers we'll deal with, what bundle resources we'll copy, what source files we'll build, and how we'll link. Build settings -- this is where you would set the -- if you can go over to the build settings tab -- this is where you would set the product name that's going to be built. If you were doing an install, where it would install to.

And down below, you see the editor. And down below, you see the expert mode build settings. So this, again, is another case of where we need to provide better user interface. But with this expert mode, at least we can get a way of supplying all the options we need to today into the build system. So application settings -- this is where you would set the information property list for your bundles. This is a very important thing to know about.

Actually, if we can go back to the simple screen there. This interface is -- actually has been cleaned up. But my team moves very quickly. This is post-DP4 feature here. You don't have it quite yet. So what you do have is the expert mode build settings, which is a property list editor.

With Cocoa, we can just leverage an object that we already had to do property list editing. And then the final tab for executables -- for example, if you were building a bundle that needed to be debugged within the context of a given application, you could say this is the application that you would launch. To run that bundle and the arguments that you would pass to it.

So we can select a different target up here. Let's say that we go to the install target. And with the install target, we see some different tabs. This actually is a legacy target here. It's an example of how to have a target that builds something different than what we have in our build system. So this is just running a shell script here. And then we can copy the example source code where we needed it on the system.

And then one final target -- let's take a look at the all examples. This is an example of an aggregate target that itself has no build mechanism, but it does ask other targets to be rebuilt. So we have full dependencies between targets. And if we build all examples then at this point, then it shouldn't need to rebuild geophase because that's already been built. And then it builds the other two targets as well.

So roller coaster and uses sphere. Now we see down in the lower left, build succeeded. But you see up the top in the toolbar that the run and debug buttons are not enabled. Well, that's because with an aggregate target, there is no single executable to run here at this point. But by selecting one of the sub-targets -- so for example, making roller coaster the active target -- now we can launch it and watch the roller coaster come up and spin. and spin.

So these OpenGL examples are kind of fun to play with. All right. Very good. So now let's talk about debugging. With our debugging system, we have an extensible architecture that can accept various plugins. We do communicate with GDB for debugging of all C-based languages. GDB is a very well-known Unix, usually command line, debugger. We also are working heavily on Java debugging. It's not fully functional yet, but if you've been in some of the Java sessions, you've seen some of that. We're working with the AppleScript team for debugging of AppleScript.

We've gone to a much more graphical debugging model than we had before. So we show threads, stack traces, variables within a particular stack frame with breakpoints. Now, one thing to know about Project Builder is that we are designing it to deal with multiple person projects. So each person gets their own preferences per project settings saved off with the project itself. It's actually inside the project document wrapper.

So you could actually check those into a source code control system, for example. And breakpoints is an example of some of the settings that we store in there. So you can have them persistent, not just between runs of the debugger, but between runs of the IDE as well.

And I can have my breakpoints, Manuel can have his, and you can have yours, all within the same project. One person told me that whenever they write code, they put a breakpoint on it. And I thought that was a great idea. Later on, two weeks later, you go to execute the code and hit the breakpoint and step through it the first time you've run it.

Now we can support that. We can invoke functions to get the values of opaque data types, which is very important for Carbon development today, and also for core foundation with functions like CFShow. From the debugger, we control the dynamic loader, what's called DYLD on our system. So we can control where frameworks are being loaded in from if you're doing framework debugging.

So also cross-project debugging. Part of the reason we've got the one window there is we expect that you'll be working with frameworks and perhaps having frameworks in different projects. So multiple windows open on each in its own project window. And from an application, you can step right down into the code of a framework and do cross-project. So we are taking advantage of GDB.

And I've gone through many of the features here. We do have additional things that GDB provides, like the ability to set conditions and commands on breakpoints. We don't yet have user interface for that, but we will have the opportunity to do so in the future to put that in. But we do have access to the GDB command line for any super power features that those of you real GDB addicts don't know about. So we're going to be using that.

Thanks. So we're going to be using the GDB command line for any super power features that GDB addicts want to get to. There's a number of powerful macro capabilities that the Carbon team and the Core OS team are taking advantage of in a variety of ways. And we have done some things so there's faster startup and more robustness in our DP4 version of GDB. So now let's take a look at an example of debugging. If I could go back to demo one on both screens, please. So this is a given example of debugging the geophase target again.

So what we want to do is set a breakpoint on a particular function that we happen to remember the name of, so make menus. So let's bring down the find panel and show make menus and do a find for that. So we'll find -- do a text we'll find right now. There we go. And we select on that. And that takes us to the line of source code there. We can put a breakpoint on that.

Now if we want to see what breakpoints we have, in our project, again this is project data, project structure, we have another tab to show that. So we had just put a breakpoint in main.m, which is .m is the suffix for Objective-C. But it's showing that we already have a breakpoint on makeface.c. So this is actually an example of a persistent breakpoint that was already out there.

So by double clicking on that, we can show the specific lines that the breakpoints are on. Again, this is an example of an area where the user interface has been cleaned up slightly since DP4 actually. So let's go ahead and launch the application under the debugger. We hit the debug button and the debug tab pops down and it starts loading the application into GDB.

and we're off and running. So now we've hit our first break point. Let's take a look at some of the user interface here. So we have a pop-up menu that shows the different threads within our application. We'll leave it on the Make Face thread for now. We can walk up and down the stack trees so we see the variables changing for each of the stack frames. Within the variables of the Make Face function, we can expand on, for example, the face argument and see that that's actually a fairly complex structure in there. We're getting all this information back from GDB.

Now we can close that back up and do a little bit of single stepping through here. We see actually that there's two loop variables here, the I and II variables. And I didn't write this code. Yeah. But every time we change a value, it's showing the changed variable in red, so kind of what you would expect.

And so if we continue from there, then we actually march along, hit the other break point that we just put in. Let's single step a little bit there and then continue again. and we see the application fire up under the debugger here. So debugging fairly nicely tied in, and again, we're going to do the same thing with Java debugging. And I think that's it on that. All right, we can go back to slides. Thank you.

So continuing our discussion of what's in Developer Preview 4, let's switch to Interface Builder for a moment. So what is Interface Builder? For those of you who aren't familiar with it, this is Apple's user interface layout tool. The big deal at this point is that you can create Aqua-compliant user interfaces for both Carbon and Cocoa applications with this. You get all the metrics correct, etc., the standard menus you want.

For those who've done Cocoa development in the past, you're familiar with Interface Builder in that it's a big part of the Cocoa development cycle. It lets you put in actions and outlets that tie back into the source code. But you can also, at this point, use it for your Carbon development. So when you run Interface Builder, it generates what's called a nib file, which is the description of your user interface. Again, we can do that for Cocoa applications, Carbon, and also for Java clients.

And we can do that for Web objects. The Interface Builder team has done a great job of adding in support for additional platforms, so if they're down the road become more, become important, we'll be able to add that into Interface Builder. So how would you take advantage of this in a Carbon context? Well, within the Carbon runtime on Mac OS X and in CarbonLib 1.1 soon, you have what's called the Interface Builder Carbon Runtime that takes the nib file under direction from your code and loads it in, and then it builds your user interface from that. So this is sort of an alternative to using the diddles and D-logs and window definitions and other things you may be familiar with in the past.

Um, so... Why might you want to do that? One advantage is that, again, it does let you create an Aqua-compliant user interface. This does support all the Carbon user interface elements. And for those of you who have been learning about the new Carbon event model, where it makes it easier to tie commands back into your code, this is a great way, actually the best way, of taking advantage of the new Carbon event model.

This lets you create Unicode-compliant user interfaces, and it is tied in with the new Project Builder, and we'll continue to tie it in more tightly as we go. So I'm not going to demo Interface Builder in this session this morning, but 9 a.m. tomorrow, I believe in this room, you can come learn much more about Interface Builder, both Cocoa and for Carbon development.

Okay, again, further elaborating on how we're delivering on our commitment. Let's show you some of the things that aren't in this release but will be coming soon. I've talked quite a bit about both Java and AppleScript. We're trying to broaden the scope of Project Builder to handle development of everything that you'd need to do with Mac OS X. So, I've got an engineer on my team at this point who's working heavily with the Java teams to make sure that we can build all Java projects and that we can debug them.

Some of that's been shown in the Java sessions. We're working with the Mac Runtime for Java team to bring some of the features of their SDK from Mac OS 9 into the IDE for Mac OS X. With the AppleScript team, we're working with Chris Espinoza's team there to provide an environment for developing AppleScript. And then within the IDE, we're working with the Mac OS X.

So, we're working with the Mac OS X to develop a new version of the Mac OS X. So, I've got an engineer on my team at this point who's working heavily with the Java teams to make sure that we can build all Java projects and that we can debug them. Some of that's been shown in the Java sessions.

And then within the IDE itself, we're working heavily on better source code navigation, a number of graphical user interface improvements, so some of these you've already seen, like this information property list editing, sorry, couldn't help it, I already gave a sneak preview of that. Build tool option settings, it's very important to us that we be able to have a much better graphical user interface for setting of do I want optimized code or what level of optimization, etc. We'd like to continue refining our user interface for debugging.

And source code management is a feature that ever since I first took the management job here, the WebObjects team, for example, has been demanding source code management features. So let's talk about...

And another thing that we have built in, you can see also we have full syntax coloring here and you can set the options on how you'd like that to be set. So one other thing is if we go to the Find panel, we can also do a Find Definition and we'll be working to optimize user interface on this to make it more accessible from the code.

But let's say type in "cosang" which we happen to notice there and that shows Find Definition. We can click to go to that. You see a bookmarker there so that if it's a framework, we could go off to the documentation for that. Okay, so now let's take a look at some of the SCM features. If we take a look at the Groups and Files view again, we see that there's a new column over here, the SCM column.

And what this shows us is the SCM section. So this is the status of the files in your project. We see a number of Ms here which indicate that some of the files have already been modified. So let's take a look at one of those like head.h for example.

Actually Manuel, I don't remember what we changed in head.h, do you? Well, let's find out. So let's go over and take a look at the SCM menu. We could update to the latest revision. We could compare. We could commit. Let's do a compare and see what's changed. So we send a message off to the File Merge graphical diffing tool. And in that, up we come and we can see graphically what things have been changed in this file. So very cool.

Okay, and so if we quit out of that, then we can now go ahead and commit these changes if we like them. So we can type in a commit log message here.

So again, you see the same kind of build output, the same output lines, CC. There is a way in the preferences of Project Builder to get the full build command of exactly what it's running. What we've done here, if we go into the build settings, we've kind of modified this project a little bit in ways that you won't have to.

You can see some of the flexibility. So with the -b argument, we can tell GCC that we actually want to use a somewhat different version of GCC that generates different output. And we want to use a different linker here as well. So we've also changed the - in the executables tab, We've changed now, we're going to use the launch CFM binary as what we launch for this application.

But we are passing an argument which is the full path to this particular application. So let's go ahead, it's been successfully built, let's hide Project Builder and we should see the binary here in our Mac OS X system. Let's go ahead and copy that across to the Mac OS 9 system.

Okay, so I sit here on my Mac OS 9 system. Let's go back into Project Builder and we can hit the launch button from here and actually see the half binary launched under Project Builder. And by double clicking here on Mac OS 9, I see the same binary launched on 9. So again, this is showing demo of Carbon scrolling here.

So when we do this for real, what you'll get by default for Mac OS X binaries is a Mac O binary that will let you take advantage of the full Mac OS X system. But for demo purposes today, we're showing PEPF on both sides. All right, so that's it for our demos. Thanks very much, Manuel.

And if we can go back to... Now let's talk about delivery and deployment. Now I've mentioned that we have had a previous version of Project Builder. Those of you who have been doing WebObjects development or Cocoa development are familiar with that. We're playing a little shell game here in DP4.

When you look in System Developer Applications, Project Builder is the new one. And we have Project Builder WOA, which stands for Project Builder WebObjects. That is the old one that today would still be used for WebObjects development, but that will be changing soon. So if you are coming new into this, I would not recommend that you run the old Project Builder WOA at all.

So for those of you who are using the old Project Builder, we will not be shipping that again unless somebody gives me a very good reason why I need to. I have no intent to put any effort into maintaining that product, although we will make sure that the WebObjects customers and developers are fully taken care of. But again, we're working with that team to make sure that the right things happen, integrate with the new Project Builder, and you all want to shift over if you are using the old one. In the next session, they'll show how easy that is to do.

So for delivery, the decision at this point is that this is one of Apple's core development tools. It will be shipped on the quarterly tool CDs to Apple Developer Connection program members. So you get this for free as part of your monthly mailings. We haven't done this yet, so I'm sure there will be some logistics to work through on this, but that is the plan. And we'll also have web updates available.

Again, we haven't put one of those out yet, so I'm sure we'll have a few logistics to work through there. For support resources, we've put a public email list in place, projectbuilder-users at public.lists.apple.com. This is one of the fairly standard places where these go. We do have an email list in place at this point that we've been getting feedback on.

We have delivered this to a few, a very small number of third parties at this point, who came down for one of our kitchens. We sent them back with it. In the kitchen, they shifted their development over to the new project builder, and they're elated with it so far. Thanks, guys. There they go.

And then the DTS support mailing list. So in summary, you can see that we are delivering on our commitment to great development tools. I'm very proud of the team. We've accomplished. We've accomplished what I consider to be a heck of a lot in the last year and a half. And in fact, if I could ask team members to just stand up and take some acknowledgments here.