Hi there. I'm Deric Horn. I'm the Application Technologies Evangelist. Hopefully you'll see my name at the end of this session so you can always send me email. This is the second part to our two part series on coming to the Mac. And it's actually going to be broken up into two parts.

The Mac is an awesome environment for graphics, multimedia, content, podcasts and so forth. So for the first part will have Babak Mahbod talking about our graphics frameworks. And then on the second part of this session we'll have Matt Henderson go down deeper and talk about our different development tools, performance tools, changes we've made in Leopard to our tools, debugging, everything that you're going to need to know. Being developers, that's one thing that we all have in common is our development tools and our love hate relationship with them.

So at this point, I'd like to welcome Babak Mahbod. Thank you.

Thank you Deric for that introduction. So my name is Babak Mahbod and I'm a Senior Software Engineer at Apple Computer. And today I'm here to talk to you a little bit about our graphics, our multimedia frameworks on Mac OS X.

So what are we going to talk about and why talk about graphics and multimedia? If you attended the previous session Larry Cooper talked about basically what frameworks are. And he probably told you that frameworks are basically a folder that inside that folder you have your library and headers. And all of our graphics and multimedia is delivered to you in a form of a frameworks. And in fact, on our platform we take a layered approach to design.

And one layer builds on top of another layer. So why talk about graphics and multimedia specifically when there are so many other you know frameworks to talk about? Well, you know lets look at the spreadsheet application. It's really not really interesting by just looking at numbers in a spreadsheet application.

Typically when you deliver content, with with spreadsheet application, you want to at least have some visual feedback. Right? So what do you deliver with? You deliver your spreadsheet with some graphs. And even it would be interesting that, to the people that you deliver your presentation to if those graphs evolve over time.

When you send an email, you can you know most of you send audio clips with your email. Some of you send your clips of your home movies. So there's a digital, digital content contained therein. And so I'm going to spend a little bit of time today to talk about graphics and multimedia framework to our platform. We're going to talk about a little bit about Mac OS X system architecture and we're going to talk about multimedia image handling and 2D and 3D graphics layers on our OS.

So in our OS we take as I said a layered approach to design. You probably have seen this before in Larry's presentation. But at the core of our OS is a Darwin kernel and that's based on free BSD and Mach microkernel. And then we have our graphics and media layer, which are our Core Services. In this case we're talking about Core Audio, Core Image, Core Video and OpenGL. And on top of that are Carbon and Cocoa frameworks.

So if your procedural programmer, you do C, C++ programming, you probably be using Carbon, but we of course recommend using Objective-C and our Cocoa frameworks. And the top most layers of course are user experience layer and if you've seen our windows aqua look and feel, Dashboard and widgets, Spotlight search engine and accessibility family of APIs and tools.

So for me to talk about graphics and multimedia, I'm going to kinda take a top down approach. So I'm going to start speaking with you about high level APIs, basically our Cocoa frameworks and work our, work my way down to the core services. So let's talk a little bit about QTKit. QTKit is an Objective-C Cocoa framework.

It's a very high level framework. It's designed specifically for developers. So if you want to deliver a multimedia application to our platform, you can deliver it in rather short amount of time. It allows you to work with the QuickTime content, but even goes beyond QuickTime content and what it can deliver.

If you for example want to do simple, if your application you want to do simple to rather complex editing, cut copy and waste kind of workflows, if you want to splice movies, if you want to combine and transcode movies, this QTKit high level APIs will allow you to do that. And of course in Leopard, it's been highly optimized.

There has additional benefits such as if you wanted to do 64 bit development, this is a framework that you wish to use. And of course it really builds as I said on top of our core services, namely Core Image, Core Audio, Core Video and OpenGL, which I'll briefly touch upon later in the presentation.

But also bundled with QTKit framework and its family of APIs is QT Capture. So let's say you want to capture media in real time. QT capture gives you the APIs necessary for you to do that. In fact, many of our own computers are delivered with an iSight camera.

It's you know if you want to leverage off of using iSight camera to capture or camcorders or your you know regular microphones, if you want to capture true QuickTime movie, you want to, if you want to just have it video preview or audio preview or if you want to just capture video that you want to process at a later date, running it for example through our OpenGL engine or if you want to, for example, run it through a filter, you know for post processing. But its lot more than that because this high level APIs will allow you to also take advantage of your HD devices. And it, it does frame accurate capture, with time codes and per sample meta data.

So let me show you how just briefly how easy it is actually to use these high level APIs to actually capture a movie. So the first thing is you substantiate of course a QT movie. The next step is of course you want to set some properties for this movie.

In this case I'm just saying that I want this movie to be editable. And last but not least you will tell your view this is an editable movie so play it in my view. And it's just equally easy to save movies, you captured it, you edited it, what you want to do? You just want to save it. It's really, I mean, two steps.

So we have a QTKit session and lab coming up for you. If you're interested in this technology, I highly recommend that you should attend these, this session and lab. So but not everybody is interested in you know writing a multimedia app. Some of you want to just do image processing.

So for that we have a framework called ImageKit. So what are some of these basic applications have in common? Here I have iPhoto that many of you have seen for just doing basic editing, and you know managing your photo album and I always have here Aperture which is for film proc, raw image processing. So these two apps, what do we have? Some of the basic workflow as if you want to find and browse images both iPhoto and Aperture will allow you to do that.

Well the same two application, iPhoto and Aperture will also allow you to display and edit images. So in general, if you think about it, most of the applications, image processing applications have some very simple and common things. So they allow you to find and browse images and display and edit images.

So why go through the trouble of having to write your own architecture, implement your own architecture when we deliver such a great framework called ImageKit for you to leverage off of? So what are some of the basic components of ImageKit? The first thing is the Image Viewer which gives you basically high level APIs that will allow you to actually view your images. You just basically give a file name and Image Viewer, once you substantiate the object it gives you this simple user interface to allow you to step through your images.

And of course there's ImageEdit panel again simple object, substantiated, it comes with this heads up display that will allow you to, has three tabs, adjust, effects and details tabs. And of course with adjust it allows you to do some basic picture properties like brightness, saturation, and gamma control. Your image edit tab, effects tab will allow you to actually utilize some of the filters that you have all over your system. And of course the meta data view or the details view allow you to look at some information associated with each of your images.

Then it also has an API called Image Browser. So if you want to have, you know if you have a folder full of images and you want one API, want to point that to that folder, and get this simple user interface so that you know your clients are going to be using your application can simply just view pictures that are in a folder. This portion of ImageKit will allow you to do that. Then there's Picture Taker. It gives you a simple, again, user interface component and a API that brings up this interface and will allow you to actually work for example with devices like your iSight camera.

And the Slideshow, same thing, I mean. So here we have, we have a simple folder that have full of pictures and you want to, this API. You point that to that folder and it will bring up again this user interface that will you to just go through all your images in that folder and give your clients a slide show.

There is a save panel. Let's say that you have finally edited and you know add some of the effects to your images as you browse and viewed them, but you want to save them. It gives you a simple user interface again for you to save your images. And last, part of the ImageKit is the ImageKit's filter browser, again allowing you to actually see all the filters in your system and actually see, set some attributes on them and use them as you wish. So basically ImageKit gives you a complete workflow if you're processing images.

So here I'm going to show you a simple three steps that you know you can use a Picture Taker family of APIs to actually take some picture from your iSight camera. So first thing is you get a shared instance. You launch Picture Taker and here as soon as you send the message, begin Image Picker with delegate, along with the selector and a context to this object that you substantiated, you get that user interface and it'll allow you to actually work with your iSight camera. And last part, once you get the result, you just can save the image or pass it to a filter for further processing.

So you have one session and one lab for you to actually, if you're interested in ImageKit, these are places we would like you to go. So next thing I want to talk about is - you have images, you have edited images but how do you read images? So we have this high level framework called Image I/O.

Again it allows you to read and write a plethora of file formats, write them, work with their meta data, do color management and process, if you have a raw camera for instance, framework will allow you to actually work with those. And in fact it does incremental loading of course for those large sized images.

So where does it lie in our OS? Well, again Image I/O, I mean many of you that come from UNIX or other platforms, you're, you know well familiar with libTiff, libJpeg and LibPng. So here we have taken the trouble to actually taking those libraries and optimize it and deliver it on our platform for you in a form of Image I/O. And as you can see, higher level APIs like Quartz ImageKit and Core Image all leverage off of Image I/O.

So you can see that Image I/O supports a web standards, all the, or many of the floating point HDR formats, camera raw formats, meta data formats and as more and more file formats are becoming available, Image I/O team will be hard at work and bringing those to you in a form of Image I/O family of APIs.

So I'm going to go through very, very quickly - go through a bit of sample code to show you how simple it really is to use Image I/O. So here all I'm doing is writing a JPEG image. So the first thing that I want to do actually I want to write it to a location. So what I do is I substantiate an opaque reference, my destination.

The next thing that I want to do is just set some properties. Here I want to set a JPEG, I want to set, set a dots per inch. And compression quality of course. And then I add the image to my destination. And of course I want to close the file or finalize it.

So the next thing I want to talk about that I've talked about just how you read and write images, I talked briefly when I talked about ImageKit about the if at stack, and I talked about filters. So what does Core Image do? Well, Core Image is really a framework of per pixel operations.

That means it's basically really a higher level API that wraps a lot of the OpenGL framework and it harnesses the power of the GPU and graphics card on your machine. It, it is for you to add just basically beautiful effects like transition effects or anything that you can think, think of to your images. It comes with about 100 plus filters.

But let's talk little bit about the filters and how they work. So basically at the heart of core image is this concept of filters. And let's say that you have an original image and you want to apply certain number of filters to get a final image. Normally you know what you would do, you would take one image, you apply a filter, you save the intermediate step, you apply the image, and you apply another filter to get the final image. Core Image is really smart about this process. In fact, instead of storing those intermediate images, it changes those filters for you together and optimizes the pipeline.

Core Image as I say comes with 100 plus filters. So there, there's a good chance that most of the filters that you need for your image processing apps comes already with Core Image. But if just in case that there are some filters that you feel that are not bundled with Core Image, you have these flexibility of writing what's called image units. And once you write image units, you can, they are just your filters and just available to all the applications throughout the system.

So before going any further, I just want to impress upon you the fact that this family of APIs and frameworks that I talked about probably take into account a bulk of your algorithmic workflow. And they were designed to reduce the amount of work that you need to do to deliver the application in a short amount of time.

But there are those occasions that once you go through these high level APIs and you exhaust all possibilities, you feel that these high level APIs and frameworks, you need to do more. And in order to do that, at this stage, as I said, its probably 80 percent, 75 to 80 percent of the time, these frameworks take into account many of the workflows. But that remaining percentage what do you do? At this stage you, then you want to go delve a little bit deeper and then go into the Core Services.

So the first thing I want to talk about is the Core Video. Now so what is Core Video? Core Video is basically let's say that you want to capture individual frame. You work with QTKit and then you come to a point and say, well okay look I want to capture individual frames and in real time I want to apply some sort of effects to them. So this is a technology in this case that you may want to use called Core Video. And in fact Core Video, the pipeline was designed to break that entire work into discrete steps.

One of the advantages of course Core Video once you go to this level is the fact that you don't have you know typically if you work with individual frames you have to work, worry about the synchronization issues, especially with your audio track. Core Video really takes care of it and it allows you to actually work on more creative aspects. If you want to apply individ - if you want to apply filters to your individual frames in real time.

Such as Core Image filters or your own image units. You can, you can use Core Video. If you want to transform images dynamically, you can use Core Video. If you want to add for example any games, some video, you can use Core Video. And of course it's really a good technology for compositing multiple streams.

So it allows you to actually accomplish this through a simple mechanism called the Display Link. Here I've shown you one workflow, but through the combination use of QTKit and Core Video you can accomplish amazing things. So we have three sessions and three labs for you if you're interested Core Video. Now of course at the heart of every good multimedia experience is a good audio engine and we have Core Audio. So many of you are probably familiar with the hardware recording studio and the hardware of every hardware recording studio is your mixing deck.

Well Core Audio has brought that hardware recording studio experience into software. And again the heart of Core Audio is a mixer unit that allows you to actually have an exact same experience through the tie - coupling of this so called hardware application layer and audio units. But it does again much more than that. If you're interested in the signal processing, if you are interested in surround sound and if you want to put that in your games using OpenAL, we deliver a native implementation of OpenAL for you.

If you want to do hardware or software midi processing, then Core Audio may be thing for you. If you want to work with read and write compress audio files, in real time, Core Audio is for you. QTKit again provides you the high level services, but this is there to actually enhance the API workflows for you. And of course we have three sessions and three labs and we have a brown bag lunch for, if you're interested in Core Audio.

Well the heart of every good graphics system has to be a great 2D and 3D graph-ics API. And here we have OpenGL. Again with OpenGL, we've taken layered approach to a, to its implementation. We have the driver layer. We have the OpenGL engine that comes in two varieties the multithreaded variety and non multithreaded. And of course the frameworks we have, these are the utility frameworks called AGL, NS OpenGL, and CGL.

But if you want to do OpenGL programming, again you need to do, to utilize OpenGL APIs and those frameworks, high level frameworks are just utility frameworks. So OpenGL is used at every level throughout our OS from basically our genie effect that you see when you actually collapse a window to compositing to all the Core Image filters, all the video effects, to all the iChat effects are all done in OpenGL.

And again, our own iApps, like iLife, iWork, and our Pro apps such as Final Cut Pro Shape and Logical Pro, they all leverage off of power of OpenGL. And Core Image, Core Video, core animation and core composer all leverage off of OpenGL. And we have four sessions and a lab for you, for those of you who are interested in OpenGL. So at this stage I want to hand off to my, to Matt Henderson, and he's going to take you through the tools.

Hi. My name is Matt Henderson. I am a coworker of Babak, Senior Software Engineer in Worldwide Developer Relations. My background is in tools. I worked for many years on CodeWarrior for Mac OS and Mac OS X before I worked for Apple. And so that's what I'm going to talk to you about, our most basic and fundamental tools aspects.

I think Deric asked you how many were new to Mac OS X as developers? Can I get that show of hands again? So this is stuff you need to know. This is, you know, is getting started right with the developer tools and, and learning you know how to get, how to get involved in Mac OS X programming with the tools is a great for you to learn. And so let's talk about that.

And we have an entire tool chain. Covers every aspect of software development on Mac OS X and it starts with Xcode, which is our IDE. And we have Interface Builder, our UI design and implementation tool. Both these great tools take advantage of Objective-C which is the, as you've gathered through these sessions is the language of choice on Mac OS X.

Objective-C is built with you know good old UNIX GCC and LD, the compiler link combination that's been around for decades and decades. We debug it with GDB, the open source standard for, for debugging that's also, comes for the UNIX background. And we also have our own great suite of performance analysis tools.

So starting with Xcode. Lots and lots of great features and it's a very powerful, very robust industrial strength tool. It's used inside of Apple to build both, practically the whole OS. It's used outside of Apple by virtually every major third party who develops software on Mac OS X. Adobe, Microsoft, anyone who's shipped a universal binary on Mac OS X has probably built it with Xcode.

And Xcode is great if you're from a UNIX background because it wraps all the great open source tools I just mentioned, GCC, LD, GDB, those are all the foundations for Xcode when you get to your building and debugging parts. And it's just a great, powerful, easy to use front end for those sorts of low level, low level open source tools. Core features, every IDE does three things. It edits, it builds, it debugs. And Xcode is no different in these respects.

The great editor, it's a language sensitive, context sensitive, you get nice coloring indentation, a huge number of navigation features for both discovering newer code and navigating two different symbols very easily. And cool features called code sense for figuring out the system APIs and getting those in your code easily without worrying about the parameters so much. Building, it also does everything you accept, automatic dependency tracking, you do not have to manage the relationship between your source and your header files.

I know that for some of you coming from a Make File background that might, that might be luxurious, but it's there. It works. And beyond the simple source and header file dependencies, you can set up your own multi target, multi binary dependencies, you know to make sure that your shared libraries build in the right version before your application builds. And everything is linked properly and everything exists and your build, you know the entire hierarchical build of your application fires correctly.

And one of the best features, especially if you're a fairly large, deploy these fairly large scale applications, is Xcode's hierarchal cross project settings. So you can make a simple few configuration files that contain all of your build settings and deploy them so they, they configure multiple projects across, and multiple targets and it provides complete uniformity of build settings and you can easily, easily make large scale changes by just you know a few, editing a few text files such that you don't end up iterating through all of your projects and targets and manually tweaking build settings when you need to make a change.

And lastly, I don't know, as I said I worked on you know CodeWarrior from MetroWorks and a lot of you all probably haven't heard of that. But code warrior was a really fast IDE and I like really fast builds. And Xcode provides that. It's a multiprocessor and a distributed builds.

If you're a small, five man software shop and you've got five engineers on five MacPros, that's not really all you have. You really have a 20 core buil d farm. Xcode automatically discovers other running X Codes for you and will distribute builds for that. And you can really, really reduce the amount of time you spend waiting on builds when you use Xcode.

Debugging as I mentioned is based on GDB. Provides everything you expected in a debugger, process flow control, variable display, break points, watch points. It also fully debugs, shared code and plug ins. So there's no worry about that if you have a modular applications or are working on a plug in for another app. Xcode will handle all that for you.

And there's a million other features in Xcode, but I'm going to cover a couple that I think that you as an audience are going to be particularly interested in. And the first is the research assistant. It's basically a context sensitive documentation viewer that will show you API references and tools references from whatever you're working on at that moment without losing focus. And it's just such a great way to discover the, the APIs on Mac OS X whatever they are. And to have great fun and an easy to use front end for our documentation.

And also build phases and build rules. These allow you to produce, implement, make file- like features into the Xcode build process such that you can perform common batch operations, integrate your own custom tools. If you have your own compilers or even something standard from the UNIX world like a Lexor Yak Compiler.

Very easy to plug it into the Xcode build process. And Xcode will even track dependencies for those sorts of tools the same way it does for your basic C and C++ sources and headers. And you can also integrate practically any shell script you want into the Xcode build process. And that shell script will have full access to all of the environment variables for the build environment.

So, and after Xcode, which covers you know the, the basics of building or editing, building and debugging, we have Interface Builder which is the user interface design and implementation tool. And if you've heard Larry's presentation in the session before, you'll know that you're, he talked a lot about the view model controller paradigm for implementing applications with user interface.

Interface Builder makes that easy. It's a completely visual editor for the view and control of thing and it, it also has a lot of great features for using Mac OS X and the Mac OS X user interface conditions properly in your application. It knows all about widget metrics and is a great system of guides for snapping things into place exactly where they need to go as you lay out your user interface.

So even cooler than that, Interface Builder can actually learn about your classes that you write in Objective-C. Once you've written one of your controller classes to hook your UI up to your engine code, Interface Builder will import it and parse it and provide all its functionality accessible through its, its design and layout layer when you're visually editing your, your applications interface in Interface Builder.

With that I'm going to switch to the demo station and show you a couple of quick demos of these features. So its, seems to be in screen saver mode right now. But oh. That's our, our boss asking what's going on. So, we'll get rid of that. First thing I'm going to do is a really trivial but interesting demo of Interface Builder.

And I'm going to essentially build a web browser. So we start with an empty window. And every good web browser has a text field. So we'll lay that out there. And as you watch the little guide snap it into place, in the proper place and we'll size it. And we'll bring up the inspector so I can make sure.

Find the right palette here. This is a beta OS and uh

It occasionally misbehaves and this is what I'm looking for. So we'll snap that into place and make sure it behaves when the window resizes. Then we need our forward and our back button, so we'll place a back button. And we'll place a forward button.

And finally we'll scroll down and we'll place the Web Kit web view. So you see a few little drawing glitches, but we're allowed a few glitches because it's a beta OS. So we have all those things and we've build a, a view resources that's some binary data that's going to be used in your, in your application.

But we can go beyond that in Interface Builder and we can sort of wire up the behaviors and the functionality. So we take the URL field and connect it to the web view and tell the web view that it should get the URL string from that URL field.

We'll take the back button, wire it to the web view. Tell it it should make the web view go back. Take the forward button, same thing but go forward. And we've got a very simple web, web browser. So I can, we'll save the whole thing off. Take it, simulate an interface.

And we've got basic web browser. And I know you all want an iPhone, so we'll click on the iPhone link. Wait on it a bit, we see the iPhone, back button works, forward button works. And I haven't written a line of code. And Interface Builder hasn't generated a line of code.

In fact, it's not even actually running your application. This is just taking the simple layout and relationships between the widgets that I've defined and it is using that data driven description to simulate your interface. So we can quit the Cocoa simulator now. Go back to Interface Builder, and tell it to build and go in Xcode.

It will compile it, link it, build succeeds and now it's actually launched my no code demo. And same thing. It works. And no code at all. And no generated code, no build dependencies, so it's, it's really great for way to cleanly implement URI. So we'll quit out of Interface Builder and I'm going to show you a completely unrelated but I think equally interesting demo for you as an audience.

We'll open up one of these standard Apple example projects for your app kit in Cocoa. And this is of course Xcode the IDE and here you can see I'm looking at the sources in here. So I'll open this one big Objective-C file. And here's Xcode's editor, but I'm not so much interested in showing off the editor as the documentation.

Since you are all mostly new to the platform, you're going to have a, a really big initial learning curve, getting used to the APIs and I want you to see how easy that can be with Xcode. So I'm going to use this to quickly jump to a function and you know pretty common Objective-C, Objective-C method.

We see something here on NS Array. And NS Array of course is one of the core collection classes of Cocoa. And so its, its probably interesting to you as a new developer. So if you're a new developer and you want to learn about NS Array, you might jump to our documentation.

Do an API search in our core reference library for NS Array. And we find some hits. We find a lot of good stuff about it. A basic overview of the class that explains it and a method by method description of all the instances vari, instances variables and methods in the class. And so that's great. That's exactly what you were looking for as a new developer. You've, can peruse this documentation, learn a lot about NS Array. But I was a little tedious, so can we do it any faster in Xcode? And we can. We have the Research Assistant.

So just the Research Assistant takes the selection and tells you about it immediately if there's something to say about it. So I've highlight NS Array, you see the exact sample NS Array class reference I just looked up, manually in the doc viewer. And we never had to click off anything or unselect or to the menus or anything else.

In fact, I can even jump to the header file from the Research Assistant. And it works for stuff other than classes. We can look up the array with objects method here. And it provides you know the full description of that as well. So that's my demo. I'm ready to go back to the slides now.

And that's Xcode Interface Builder and that was not a, not a huge and involved demo, but that gives you some of the sort of the idea of how developing on Mac OS X is going to be quicker than it is on other platforms. So we have a lot of content about Xcode and Interface Builder at this show.

I hope you'll go to as much of it as you can, especially the first two sessions on this list, getting started with the development tools and getting started with Xcode. They're great and from those two we have four more sessions that build on that to more advanced expertise and Xcode Interface Builder and you know I think by the time you've seen the first two, the next four will make a lot of sense to you. So please, I encourage you to go see, go see all these as the week progresses.

And the most fundamental aspect, now that we've covered sort of the, the high level pretty parts of the Apple tool chain is the language. And its Objective-C is the language for high level development on Mac OS X. It is a C based language, just like Java is C, or C and C++. In fact it's just a very simple extension to basic C that takes some of the small talk heritage, object oriented features and graphs them onto the plain C language.

So it's not very complicated. Back in the day when it was originally invented, it was a very simple pre processor that took an Objective-C code and spit out simple plain C code and its, so its quite light weight. Like all object oriented languages, it supports all of the stuff you learned in CS101.

Encapsulation, inheritance, polymorphism, unlike Java and C Plus Plus, polymorphic methods in Objective-C are dispatched at run time and are not bound at compile time. And this is a great and powerful feature and is one of the enabling technologies that allows Interface Builder to do all the cool stuff it does.

So, and Objective-C has even more cool dynamic language features, introspection of course, you can query at run time all about methods and instance variables. Object properties gets rid of a lot of the basic tedium of writing getters and setters for your classes. That's a new feature for Objective-C 2.0 in Leopard.

Garbage collection supercedes the old reference counting method that of memory management that Cocoa has traditionally used, but is an opt in scheme as Larry mentioned in the last setting, last session. You don't have to use it if you don't want to. Or if you want very explicit control over your memory management, you can choose to not use garbage collection and continue with a reference counted memory model. And all these things add up to make Objective-C a truly dynamic language.

It has a lot of advantages over other C derived languages. It doesn't suffer from the, you know perplexity of fragile base class problems that C++ does. You can have fragile base classes in Objective C, but it's a lot harder and a lot easier for you to purposely avoid it rather than have it practically always happen.

Because of the dynamic dispatch at run time, it makes writing plug ins and shared code very, very easy. So you can just load them and dispatch by symbols and not have as hard a linking phase as you would with a C++ base DOL or plug in. And of course it enables the very powerful development tools like Interface Builder that lets you, saves you from having to write a lot of code.

And there's a lot of sessions to learn more of Objective-C. Getting starting with Cocoa bindings, we'll talk about some of the ways that Cocoa, Interface Builder and Objective-C work together to save you from writing code. And there's a further session coverage of the new garbage collection feature in Objective-C 2 point 0 and some general coding tips for writing better code in Objective-C and at last an advanced session on the Objective-C language as well.

So Objective-C though is not the only way to code on Mac OS X. We do of course fully support NCC and C++. And the great story about this is we not only support them, they are fully integratable with Objective-C. So if you have a legacy code base coming from Windows or UNIX then you, and you factored it like Larry talked about in the last session such that your UI code is separated from your engine code, then there's a good chance you'll probably be able to use a lot of your intellectual property as is when coming to Mac OS X. That's what we want to do.

We don't want you to have to reinvent your own wheel just to exist on our platform. So we're hoping that all of you as developers from other platforms will come in and build, build a really Mac OS X user interface using Cocoa and then keep using your same CDC++ based code that you've already invested heavily in on other platforms and build them together. And produce a great Mac OS X application. Java exists. Virtually every UNIX scripting and development language that you've ever heard of exists in and is installed by default.

And there's also, if you're coming from Fortran background, G Fortran and Fortran compilers from both Intel and IBM are available for use. And there's two sessions related to this, discovering Java on Leopard and Fortran Development. If those are applicable to you, then by all means, please go see them.

And as I mentioned before, the compiler linker in Mac OS X is GCC and LD and they're actually the same as they are on every other UNIX in the world. We track the current state of the art in the open source community for these two tools very closely. We not only track and we contribute heavily back to them.

So a lot of the, the more current GCCs have Apple contributed changes and features in them. You've seen, you've seen me talk or heard me talk about using GCC and LD from Xcode. Well, they're also fully accessible by the command line. We of course supply straight up UNIX Make, so if you're coming from a Make File background, you can use that on Mac OS X without worrying about your Make Files and with the same GCC compiler you've been used to forever and ever.

And our compiler, linker and debugger use the emerging dwarf standard for debugger symbolics. And that's, that's a much faster and more optimal and smaller format for storing debugging information than the old traditional UNIX stabs is. It goes without saying our compiler, linker target all, all current Mac OS hardware platforms and it supports you know the obvious Mac OS X technologies as well.

Debugger is the same story. The GDB, we started with GDB from the open source world. We've pushed back a lot of our changes to make debugging better on Mac OS X and presumably other UNIX as well. Like our command line, like compiler and linker it's fully accessible via the command line if you choose to use it that way. And it also uses dwarf. And of course it supports all our hardware.

So those are the core tools and after you've built, built, debugged and mostly have your application done, its time to look at your performance. And figure out what things are slow or what things are going wrong. And we have a great set of tools for doing run time analysis of your application and virtually any of its aspects. And the first one of those is Xray. And it's a debugging and analysis tool based on Detrace, which is an open source tracing and analysis tool.

And it can analyze all sorts of things about your application from memory usage to file usage to execution speed to virtual memory usage. It's all very configurable. It all has a great UI based on our iApps UI that shows a, you know sort of a timelines. And so if you, when you get to the part where you're a bit beyond debugging and are looking to optimize the performance of your application or figure out some problem, problematic statistics about it, then Xray is where you go.

We also have Shark which is a lower level, you know specialized profiler that basis, samples at kernel time to tell exactly what you're application is doing. The most common use of Shark is to measure time spent. And it will measure execution time down to the instruction in your application.

But it also tracks all sorts of other low level system events like CPU cache misses, virtual memory usage, page outs, page ins, anything that could slow your application down, Shark will detect it and show it to you and match it to an exact line of code in your application so you can hunt that down and fix it.

And we have a lot more performance, a lot more performance tools as well, beyond those two. Those are the, the big ones and, and who, that cover the most territory. But we have Big Top which is nice UI around the classic mix. Top Tool, stuff for debugging Quartz drawing.

Thread specific debugging tools, even a tool to tell you why you're spinning too much, or tell you why your application is spinning the rainbow cursor of idleness too much. So we have all these great tools for analyzing performances of your application, and they're included by default with the developer tools installer.

So we do of course have sessions about these. And if you're at all interested in measuring your application's performance, I would encourage you strongly to go to getting started with Xray and getting started with performance tending with Shark. And we also have a great session on tuning your OpenGL application, which we use a variety of tools to tell you how to make your OpenGL performance really scream on Mac OS X and because OpenGL is cross platform, on any other platforms you might support as well.

So that covers the basics of our tools chain. So now I'm going to just mention some things that are interesting to you if you're coming to Mac OS X from UNIX. And the great news is if you're a UNIX developer is that Mac OS X is UNIX. Every API, every tool that you've probably ever used on UNIX all, already exists on Mac OS X. Its free BSD at the lowest level as you saw on some of the box slides.

All that good stuff. If you know god help you, you edit your source in VI or Emax, then, then that's there for you to use and, and it's not my fault.

If you use MEG files, that's there. Pearl, Python, Ruby all of the you know great UNIX scripting languages, there by default. All that good stuff, it's available and the wider open source community and set of tools is also available via Darwin ports and FINK, two really powerful and comprehensive package management tools for Mac OS X.

If you are an X11 developer on UNIX, X11 is available. We would prefer that you develop a nice UI for your Mac OS X application in Cocoa, but if you must, you can use X11 and it will come across generally speaking very cleanly to Mac OS X. GTK plus, KD based software, it's pretty much just a recompile on Mac OS X. And that will save you a lot of work if you are trying to get over to Mac OS X really quick from an X based environment.

If you're coming to Mac OS X from Windows, well the story is not quite as good. Mac OS X is definitely not Windows. I've gone over the whole tool chain. Xcode is, I think, the moral equivalent of DevStudio, but a lot better. We do a lot of cool things they don't and Interface Builder has a tool that lets you avoid coding in ways that you can't when you're working on Windows. There's not any APIs in common between Mac OS X and Windows.

But we have equivalent APIs to all of the functionality that you would expect to be able to use you know if you're coming from a Windows background. And of course you know Larry in the last session harped on it again and again, you know if you've done the right thing and at least factored UI from your engine code, if not gone the whole full view model controller app, then rebuilding your Windows application should be easy.

And finally its even though we don't have equivalent APIs for, we do have equivalent APIs for everything on windows, but we also have a lot of great APIs like core animation and some of the stuff that Deric showed off, that just don't exist on Windows that will let you put new features in your application that your customers will love and that won't exist on any other platform. So I think we have a great story if you're a Windows developer coming to Mac OS X for the first time. You have the chance to really add some cool stuff and make the Mac OS X you know the design center for your application.