Ladies and gentlemen, please welcome Director of Product Marketing, Ken Bereskin. Welcome back, everybody. You know, one of the things that really excites me about the short-term, medium-term, and especially the long-term prospects for Mac OS X is it truly is a system that has something for everybody. Now, you heard a lot from the customer perspective this morning in terms of the great features and technologies, but taking a look at what Mac OS X means to the developer community, What I see is if you've dedicated yourself to Mac programming over the last 15 to 17 years, this is a perfect evolution where you can bring your products to life again, incredible new capabilities.

If you've done a ton of Unix programming and you're looking for a platform that you can ship millions and millions of copies of your product with a great, beautiful, consistent user interface, Mac OS X has your favorite toys and technologies in spades. If Windows drove you to Java programming, have we got a great Java implementation for you with Sun's Java 2 Standard Edition built in. And if you have that spark of the next great idea that you're just trying to find the best possible way to bring that idea to life, Cocoa and its advanced object-oriented capabilities is a perfect ideal platform. Wrap all that together, this is an exciting time to be a Mac developer. If you're new to the conference for the first time, we welcome you. And this is really an important session, as always. It's the transition from the high-level overviews into really why you're here, getting into the heart and the meat of the system.

I'd like to bring on stage a person who's had a huge amount of pressure on his shoulders, being responsible for the software engineering of Mac OS X and shipping it as we promised earlier this year, building a great team that's been working tirelessly, listening to your feedback, trying to factor it into our plans, and now planning for the future. Bertrand certainly cares a great deal about Mac OS X, and he's going to share his personal insights into what Mac OS X is all about from his unique perspective. I'd like to warmly welcome Bertrand Serlet, Vice President of Mac OS X Engineering. - Thank you, sir.

good afternoon let me tell you how life in the software engineering works at apple two months before the developers conference you get the message from an email from so they're operations hey guys uh... i don't know if you know but two months from now and says the developers conference everyone thinks oh yeah two months from now plenty of time i could keep feeling with whatever i'm doing you know great technology all that stuff and you forget all about it and then two weeks and before the conference you get another message saying we need your slides now then certainly all my god i need to scramble i need to make a mess like that i need to prepare some demos and i have an unstable system i have you know this this system that's broken because it's currently the middle of the bill and whatever and so So this is typically how it happens. So this year is different. First, we decided early in the process to talk about the present, not talk about like fancy new technologies that is being developed and that maybe one day will come out. We decided to talk with what you have, and that's my question. The other thing, quite frankly, is that we were a little tired after March 24th, so we took some vacation. At least a lot of folks in software engineering took some vacation. So this year should have been a fairly straightforward presentation. However, I had a personal challenge, which is this morning you've heard Steve and Avi. And they've been talking a lot about what is Mac OS X. Steve sets the context, the big picture kind of thing. Avi set up the high level goals and also went to some level of detail on what is Mac OS X. So I thought, OK, what should I do this year to make it interesting for you and not having too many repeats? And also, I'm assuming that most of you have been running Mac OS X, the final version, or the public beta, or its pre-releases, for quite a while now. So what I decided to do is to talk about 10 great things about Mac OS X, 10 things that I feel very strongly, personally, that are great and unique to Mac OS X.

so the first thing i selected for you is the architecture i am very proud of the architecture of Mac OS X. you've seen that that graphics okay so it's a very nice graphics it kind of looks like a marketing piece of graphics but there's some enduring reality behind it okay so let's focus on just a little bit on each of the layers so let's take darwin darwin is also named the core s and And in fact, in some sessions, you may see that as the core S. That's kind of where Mac OS X derives all of its power. That's the engine room kind of things.

So what does that mean for you as a developer? Well, it means you can harness that power by using the core S. And you have some APIs inside the core S that bring some functionality all the way through the stacks, to the Carbon stack, the Cocoa stack, or whatever stack. and you can leverage all that power through the toolboxes. Also, of course, you can directly go down one level and go to the level of the POSIX API. So I should probably stop here for a second, because the terminology is a little confusing. Mac OS X is a Unix-like system. It has Unix functionality. It's actually very close to FreeBSD. A lot of the code that we are integrating for commands and then libraries comes from the FreeBSD code base. And POSIX is a standard for the API set in the Unix world. So that's where you have functions like open, read, write, all those kind of usual functions to dealing with files. So you can directly access the CoreOS through the POSIX APIs. We are very close to the POSIX API set. Now, there's another way you can, as a developer, leverage the core S is to use shell commands.

So of course, no end user will ever use shell commands. At least we hope. If there's still a few places where Unix shows through, for the end user, we have failed. And we will plug those things. But as a developer, you might be able to leverage the existence on the system of shell commands. Shell commands is a way of scripting. It's a very powerful way where you can plug things together, piping in Unix terminology.

The last level down in the core REST is MARC. MARC is a microkernel architecture. I should clarify this point because there was some controversy. We actually are not the classical microkernel with lots of little services that talk to each other. We wanted to have a highly performing system, and we decided to link all that code into one for performance reasons, because then you can short-circuit a lot of the communication cost. But conceptually, it is a microkernel.

And at the API level, the Mac API, are great APIs to go at the lowest level, to deal with VM, to deal with inter-process communication. And so you may want to be at that level. Although, hopefully, you'll stay at the high level as much as possible, of course.

Now there is another way to leverage the CoreOS. You can extend it. And the primary means of extension is what we call kernel extension. And the vast majority of all kernel extensions are drivers. So we have devised a subsystem called I/O Kit to help you write drivers. And I'll talk a little bit more about that. There are other forms of extensions, of kernel extensions.

You can add a new file system stack. And I'm sure we'll see a few coming in the next few years on Mac OS X, which is quite exciting. You can add a networking protocol layer, a networking protocol stack as well. The kernel extension mechanism is used for all those things and enables you to do that. But on Mac OS X, contrary to Mac OS 9, it should be fairly rare to have an extension. In fact, on 9 and previous version, sometimes when you have an application, you need to have some minute or some extension mechanism.

Hopefully none of that will be required on 10. And only when you want to do these things like drivers, you will have an extension. And why? Because extensions are very tricky to write. If you have a bug, you may crash a machine. You are back to the same kind of very fragile world. Fundamentally, extension, kernel extensions, are for experts. It's a very hard thing to do, to write those extensions and make sure that they are bulletproof.

So because it's hard to write kernel extension, we decided to open source all of the core S layers. There were other reasons to do that. I think open source is clearly a growing movement, and we are totally part of that, and that feels great. But at the same time, it was also to help you in the case where you need to write a kernel extension. We've had great success with the open sourcing. We have, I think, 95,000 registrations, registered developers, which is amazing. I mean, that's a lot of magnitude more than I would have expected. And we have a very healthy exchange with Darwin developers. We have actually taken some of the fixes and integrated into our software that free in 10.0.3, which is the third software update. So we've already seen the benefit of that. And hopefully, you are running 10.0.3, And you've already seen the benefit of this.

so that was kind of just a few worlds and at the dow in level going to talk too much about graphics because i did i i think an excellent job of taking a good graphics fundamentally we have to do and that's courts three d and that's open to yell and what they would call and marketing we probably should be for the and that's quick time because fundamental is this kind of like the time as a dimension that's probably not the official we have to keep those things So what we decided for those technologies is to make the best 2D technology to adopt the standard for 3D, the best possible standard. And we already had QuickTime as for this. So we essentially wanted to have the best in each category. And underneath all those three things, you have the compositors that mixes all those things together on the screen. And that was demonstrated this morning.

The next level up is the level of frameworks. And I know many of you are here to hear about frameworks so that you can develop your app faster or whatever. And so we have fundamentally three frameworks. Classic is a little bit special as a framework. That's, of course, the compatibilities. That's the way to run an unmodified binary. It's still OK to call that a framework, because you can, as a developer, actually use Classic, because classic, like all the other environments, communicates with Apple Events and Apple Scripts, therefore. So you can, as a developer, leverage some classic app using Apple Events. That's a way to use that. Carbon is to help you migrate your application from 9 to 10. And Cocoa is to write the great next killer app. And of course, more on that later.

The next level up is Aqua, of course. And this is Aqua. I'm sure all of you are running Aqua and you enjoy that. But Aqua is something else. The system applications, we ship about 50 applications along with Mac OS X and as many, again, on the developer CD. And all those applications reinforce Aqua. They are part of Aqua. It all kind of fits together.

now as a developer you can reduce some of the system applications because some was a vacation's have APIs that you can leverage for example if you want to send mail you can reuse the mail application and the underlying frameworks there if you're a cook application you can reuse over application by means of the services menu and so scan the things will be 13 sessions during the week and of course the linker from care for all applications is Apple Events. All the applications can communicate with Apple Events. And on top of that, you can put Apple script to make it easy to do some workflow. So this is another powerful means that you have to develop applications. So this is a stack.

And I think it's a great architecture, first of all, because it's layered. Now, layering is a means of managing complexity. It's a means of thinking straight about things, having a separation between UI and non-UI. So this is how you design a great system, by thinking straight in terms of layering. Now, the other reason why I think it's great is you have clear boundaries. you have a clear boundary between the kernel, kernel space, and user space. That means a user application, I mean an application, is not going to crash the kernel and crash the whole machine. You also have a clear boundary between each process. So that means that the app of your neighbor, the person sitting next to you, is not going to crash your app. Of course, you would never have a bug in your app, right? It's a modern architecture. If you remember the diagram, at the center of the diagram, you have graphics. This is not an accident. We conceived it with graphics at the heart. That's why we put so much emphasis in having those great technologies there available for you.

it's a no compromise architecture even for classic we didn't have to compromise this is amazing actually classic the classic environment is a unix app okay it runs like another process like any other process it's a unix process it's a regular process right and we had to do no compromise to get that to work a lot of hard work and very creative engineering went and was done by the the classic team to make that just work.

The architecture is also very scalable. It's a base for Mac OS X server that was announced today, available today, that adds services on top of Mac OS X. So it's a great scalability in terms of breadth. It's also, I think, scalability in terms of time. I'm very convinced that this architecture will enable us to evolve for the next decade or two.

And we'll do that by replacing pieces in the architecture, but not changing fundamentally the overall diagram. And so I think the architecture is going to be a great basis for all of us, for Apple and for you, a great basis for innovation. What I-- oh, here are some pointers to some of the sessions.

What I selected as my number two great thing is I/O Kit. So I/O Kit is an object-oriented framework to ease development of drivers. Now, you may think, object-oriented and drivers? Are those two things kind of a little far apart? so you have to actually go back to the roots of object-oriented languages and the first object-oriented language was similar that was in the early 60s and its goal was to simulate the real world okay and this is exactly what iok does it modellizes the physical world for every piece of hardware you have a corresponding class a corresponding data structure so this is a perfect match there's another reason why it's a perfect match there's a lot of reuse going on in drivers very often a driver is a subclass of another driver with just a few things that changed okay and of course reuse is probably one of the most well-known characteristic of object-oriented languages so this is why we chose an object-oriented framework for I/O Kit now all the All the basic families encapsulated. You have families that abstract entire protocols, USB, fire wires, that kind of thing. And then you have drivers for specific pieces of hardware.

I/O Kit is feature rich, it's true plug and play. That means it's really dynamic. At the heart of I/O Kit is the I/O Kit registry, which is essentially a little database of everything that's available on the machine and all its state and meta description of those things. And that's also where all the matching of devices comes in.

I/O Kit supports snp it's also thread ready it also supports multi-threading which means that if you have two processors and you and two devices active you may actually run one of each on each processor and again twice as a throughput which is great just pure scalability automatic scalability and it has sophisticated power management so let me go a little more on power management you you've many of you have seen in the hallway have this new great titanium power book right so why does it wake up so fast you've seen the demo this morning with heavy okay but but why okay how did we make that wake up so fast I mean you know from experience on on Mac OS 9 that okay when you open your your power book well you you have all these things that happens and after a few seconds a display comes up and the finder gets its act together and then you wait for the 30 second timeout for Apple talk, right?

So the way on Mac OS X the wake up happens so fast is because we map to the physical world. We have modelized the concept of power planes. There's some rules that you need to follow when you wake up kind of the devices, electric rules. And we follow those rules. However, you have several power planes. And so you have this multi-threading. And so in parallel, you wake up each plane. And so that means that you can wake up the display along with the USB kind of subsystems, all in parallel. And because we have lazy propagation of state changes, it means that when Apple Talk finally comes up, you've been already doing your email for 30 seconds, rather than have been blocked for 30 seconds. This also shows value of doing the entire widget all the way from the hardware and the software stack and some of the applications. So I think I/O Kit is really a great thing. Some pointers to see I/O Kit sessions.

The third great thing I selected is PDF, the portable document format. So for those of you who are not totally familiar with PDF, PDF can represent any 2D information. It can represent any font, okay, and fonts are so important. I mean, this is what we live with every day, okay, printed paper.

And the ability to represent every font is significant. Moreover, there's this subsetting facility in PDF, which means that if your document uses a few characters from one of the fonts, it will embed those characters of that font in the document. And that's why it's portable, right? Because as you move the document along, you move the subset of the fonts that you need. And so the recipient of the document will be able to see the same document. This is where the P comes from. I don't know. I hope so. some folks from Adobe should tell me about that. Now, the other thing about PDF is that it can represent sampled images. There's more and more kind of sampled images coming from old forms, and PDF is doing a great job at that. And an upcoming kind of style of things is vector line art. And PDF, again, can represent that with pure fidelity.

So what does PDF do for you? Well, the first thing is that PDF is fundamentally the PostScript imaging model. So the PDF imaging model and the PostScript imaging model, it's the same. It means that rather than having some cheesy model where someone invents a draw rect or whatever, you have something which is a pro model, something that will scale all the way to pro applications.

of course pdf also means that you get save as pdf for free because if your application draws on the screen given that we have all these quotes okay that displays a pdf we're able to collect all these pieces of pdf and put that on the file so you get the save as pdf functionality without much work and you get the printing functionality as well okay with what the user sees okay and on the screen and what the user gets on the printed page being the same so all that is available for you for free all fonts format are supported so you don't need to kind of bend your application for several font formats and you have color sync as well for free Now there's another way you can also integrate PDF in your application. It's to use the graphics importer, if you are Carbon, and NSImage, if you have Cocoa, to integrate reading of PDF documents. So not only do you use PDF, but you also integrate with PDF documents.

Here are some pointers to PDF and some of the QART sessions. The number four thing I selected is, I believe Mac OS X is a great platform for developers, for all of us developers. So what do I mean by that? On Mac OS 9, if you develop your application and your application has a bug, which typically happens during the development cycle, you are taking your chance. Your application may loop and then never give you back the control. Your application may crash and potentially do something very bad to the machine. Writing is wrong, low mem, things like that. On 10, no such thing can happen because of the protected memory. So that means that you can be confident as you develop your application, as you test it, as you use Project Builder or some other IDE to develop your application. You can be confident it's not going to crash your entire user world. So that means you can both use the machine as a regular Quat user and develop on the same machine. Okay, and that's, I think, is a significant win.

Also, you have a lot of tools built in. OK, Mac OS X, the box comes with the tools CD. And we ship a broad spectrum of tools, OK, as Ken was saying, spanning the whole spectrum from Unix application to traditional toolbox-oriented applications to new kinds of things, say Java applications or whatever.

And we have great performance tools. And I'll talk a little more about that later. Thank you. Personally, I spend a lot of my week in meetings, and I don't get too much of a chance to write code. So what I like to do on weekends is kind of go near a beach. What's very nice is that I can take my portable along and still kind of touch code on weekends, because I have my entire world here with me. I have the portable, I have access to my email, and I have access to the tools.

with mobility that gives you kind of an extra layer of comfort also with the airport now present in a lot of places in hotels in airports and when i say airport i mean 802.11 of course present in airports in the physical airport and as well as cafes it's great okay you can connect to the internet while being next to the beach okay drinking your espresso and i really enjoy that let's talk about some of the global features There's two fundamental technologies that help us having great global features. The first one is application packaging.

what application packaging is about from the user perspective have a single i could that represents the app okay so far our users it's very simple you know no longer you need to kind of dig into a folder you need to have the i can't use a set of rights of that you know the application i can use right there but all the rest is hidden for the user you have just a single i could For the developer on the other hand, you have like files and folders. And there's a convention on where you are going to put the languages, each language, in this tree. And so it's very easy to manipulate. We call this technology SBML, single binary multiple languages. All you need for your application is right there in that token.

That's all the resources, localized resources, but also things like help, templates, sub-libraries, if you need that. In fact, the libraries themselves use the same packaging technology. So putting together this technology is something that I think we did right, and that has helped us tremendously for this globalization. Many of you have an app that is sold in different countries. I strongly encourage you to adopt the application packaging. It also enables for drag and drop install. Drag it to the folder where you want it to live, and you're done. And I think our users are going to love that.

The other key technology, of course, for being global is Unicode. So our stacks are Unicode throughout. So that is both the Carbon stack and the Cocoa stack are ready for Unicode. So Cocoa was already kind of there a few years ago. What we did for Carbon is we added a parallel set of APIs. And we have an abstraction that we call CFString. And all the Carbon stacks talks in terms of CFStrings. Now what we did is CFString, along with our facilities, live in the libraries that we called core foundation that lives below Carbon and below Cocoa. We also had to save some engineering efforts, of course, and avoid duplication.

Also, we have a great set of fonts, and our fonts span the entire Unicode spectrum. So you don't have to worry when you use Unicode whether this particular character is going to be available for your fonts. The system will do that for you. And I think that's one fewer worries that you have as developers. Finally, we have some great higher level controls, both in Carbon and in Cocoa, to enable you to provide for your users a little text widget, editable text with rich fonts and so on.

so together those two technologies have enabled us shape my question in seven languages we actually g_m_ the just exact same day for all seven languages which is going to prefer austin Soon, it was announced this morning by Avi, we will ship in a whole new set of languages. We actually GMed that last night. So very pleased in time for the conference. So soon we'll have Chinese, Korean, and a few other European languages. So my two take home points there is that it's easy to have your app, SBML, as a single token if you use that packaging. And it should be relatively straightforward to have your app Unicode ready so that it works in all locales.

These are some of the pointers to some of the sessions that talk about application packaging and localization. So what I would like now is to invite on stage Tony O'Brien from the integration team to demonstrate some of the things I've been talking about. TONY O' Thank you, Bertrand. So-- Bertrand just mentioned the global aspects of Mac OS X. And what I want to do now is show you what that means for our users.

So I have a system here running in English. I'm going to bring up IE. It goes to the Apple website. And I have a URL here in my doc that brings me to the Apple Korea Mac OS X website. So you might ask, what's so special about this? Well, because we have Unicode throughout the system, and our fonts span the entire Unicode character set, even though my system is still running in English, I'm able to render Korean and Japanese and all languages in my apps. It gets even better. The user is also able to dynamically switch the language the OS is running in.

So I'm going to switch this English OS to running Korean. To do that, I drag Korean to the top of the list so that it becomes the primary language. And now I'm going to launch TextEdit. And look at the TextEdit menus. So this app has now been switched to running Korean, just with one operation. I can also take some of this Korean text from IE, drag and drop this into TextEdit, which is text edit, of course, is a Cocoa app, i.e. is Carbon. Because all of the text in my system is Unicode, this kind of stuff just works. So for the rest of the demo, I want to switch.

language back to English, drag and drop, close this, let's quit TextEdit. I think this one is done safe. We can do this kind of stuff in Mac OS X because TextEdit is an app packaged application. To the user, they just see one icon, but inside that package are all of the localized resources. This is going to be great for you guys. You can ship one app all over over the world, and it will run in whatever language the user chooses, whether they're running the OS in that language or want to switch to a different one.

So the next thing I want to talk about is I/O Kit. I/O Kit, as Bertrand mentioned, is an object-oriented driver model. All of our families are encapsulated, and the families abstract the driver developer for the protocols. So we think this will make really rapid driver bring up on Mac OS X. I'm going to show you yet another plug and play demo.

This is a USB digital camera. And this camera happens to comply to the USB mass storage spec, so it doesn't even need a driver on Mac OS X. And two things happened. The camera mounted on the desktop here as a USB hard drive. An image capture was set up to auto launch. So I just want to fetch a few of these images. I'm browsing the images on the camera. I'll select these four, download them to my disk.

and the Finder window will pop up with the four images I just took off this camera. So the next thing I want to do is process these images. I want to change the resolution of the images to make them smaller, make them more web friendly. I also want to make some color adjustments and that kind of stuff. So I have four images here. So what I'm going to do is I'm going to use two things to do this. One of them is Apple Script and the other is a really cool shareware app called Graphic Converter. So I'll open my AppleScript folder. I have two droplets here. Select my images, drag and drop.

So this is Graphic Converter. I've been using Graphic Converter for years on Mac OS. It's one of my favorite shareware apps. And I was delighted to see about a week after we shipped that this came out as a Carbon app on Mac OS X. So what's happening now is Apple Script is talking to Graphic Converter. It's changing the color levels, reducing the color table, brightness and contrast, reducing the resolution of the images, and so on. So this kind of workflow is typical of what our customers expect from the OS. They use Apple Script with their key apps to automate their workflow. I mean, I have it here with four pictures. It could be 400 or 4,000.

And it just works. OK. So now we have the four converted images from Graphic Converter. And the next thing I want to show you is FileMaker Pro, which was announced last week for Mac OS X as a Carbon app. I believe it was the first Mac OS X app to be announced for Windows and Mac OS X simultaneously. And we wrote a little image archiver database for storing digital photographs. So I can add comments and date information and all that kind of stuff. And of course, what I want to do now is take these four images that I processed and put them into this database. But rather than do that manually for each image, I'm going to let Apple Script do the work for me again. So I have another droplet here. I'd select these are the images that came out of Graphic Converter, so they're smaller.

So if you're not using AppleScript on Mac OS X, you're probably working a little bit too hard, especially for this kind of stuff. And we're done. So let's look in this view. And our images came in OK. And there we go. Now, the last thing I want to briefly mention is PDF on Mac OS X. PDF is a Pro Graphics standard. It's a great web standard. It's built into our OS. And it's great for printing, because what you see on the PDF on screen is what will come out in the printer.

So I find it very useful, because I often send documents to friends of mine who, believe it or not, may not be running Mac OS X yet. And I'm not sure if they have the application that I use to create the document. So I tend to save documents as PDF and just email to them. So you can do that from any app, no matter what fonts or what text you use in the document, it will keep all of that. I'm going to do it here for this FileMaker Pro record.

So let's preview this as a PDF to see what it will come out like when they view it or when I print it. And there it is. Save as PDF. It's that easy. It comes for free. It just works on Mac OS X. So in the last few minutes, I've just shown you a simple workflow using a few things. We started off with seamless multilingual support, great plug and play with I/O Kit, AppleScript for automating tasks across the OS, and PDF built in. And we think we've really got something here. Back to you, Bertrand.

So the next great thing that I selected for you is XML. It is a little known fact, but XML is everywhere on Mac OS X. So what do I mean? Well, all your preferences as a user are stored in XML files. The little meta files for applications that describe what are the types of documents that the application claims or where to find the icon for the app are stored as XML. Plugins are all XML-based as well for the meta description. Even drivers are XML-based. the way that is exchanged by the pass board is XML based.

So we have decided to store every single configuration file, and God knows how many formats there's always for all those little files. We decided to use XML for that whenever there was no predefined format for those things. So that's, I think, a great developer benefit of that, because you don't have to rewrite constantly a little parser or dparser, unparser, whatever. You can just reuse the parser that we wrote for you.

we put that poster in several places we put it in call from the shun that's beneath Carbon and Cocoa it's also having an object rented kind of sugar cutting and that's information and we also decided to put that in dahlwein so that driver developers can reuse uh... little x_-men posture What this will enable your apps to do is to be a little more data driven. And that means if you have some parameters, say the animation rate or whatever, you may want to store that little parameter in an XML file because it's easy to play with. No recompilation. You just change a little value and go. So I think that will bring a user value, a developer value, to the picture.

This is part, of course, for greater strategy. That's the strategy to embrace open standards. all kinds of standards you know graphics standards whatever or networking standards rather than reinvent the wheel, we have adopted those standards. And XML is one of those things. Number seven, we have a great Java 2 platform. Now this may come as a surprise, OK? Java 2 and Apple are not necessarily kind of obvious.

Well, we are poised here to have the best Java desktop operating system. And why? Because we take the VMs, the virtual machine, directly from Sun, the originator. We take the hotspot Java VMs. That's the best Java VM, right? from the people who really understand Java, who made it happen.

Because the Java VM originally comes from a Unix environment, it's very easy to move to Mac OS X. And so we have to do very little modifications to get that great VM onto our system. And that's why we were able to get Java 2 so quickly on board Mac OS X, and then to iterate on the performance tuning and such.

so what you want to use java for for cross-platform applications number of you already have some java applications it's going to be great and i question because it's done dot it's cross-platform there's a twist is that the Mac OS ten you can also benefit of certain technologies like quicktime we have a great server binding for quick And your application, rather than look and feel a little different, like the Java look and feel, will integrate very nicely with all the other native applications because we have done the work so that you can have the Aqua look and feel for your Java application.

Also, we keep improving Java, and very soon there will be a Java update that will enable applets and browsers and more applications. Thank you. Now, WebJax 5 was announced this morning. WebJax 5 is cross-platform. It's entirely written in Java. and it's cross-platform but it's best on Mac OS X on Mac OS X server so um remember that webx5 is best developed and deployed on Mac OS X. a little plug for through object folks here And what does WebEx really do? Well, at its heart, you have like a little jewel of technology, which is the ability to write business logic in Java. Now, if you don't know what business logic is, I strongly encourage you to go to the sessions that talk about that.

Number eight, performance is of course a key concern of us. We always work towards that. And I'd like to motivate that a little. We have a great, powerful engine. That's Darwin, that's a Core OS. It has extremely fast fundamentals. It has unrivaled throughputs. We have great primitives. You know, VM, our VM is really great. It can take a lot of abuse.

We have great primitives for tasks and for threads and for inter-process communication. But there's one thing that we've discovered as Carbon apps were brought along, either from you as we were kind of working together on bring-ups, or by ourselves as we were taking some existing app from 9 to 10, is that the first bring-up is really exciting. You get that window on the screen and you say, wow, it's easy. I carbonized my app. It just took me two weeks to get to that stage of the window on the screen. The problem is that in some cases, the Carbon app is not quite geared to deal with Mac OS X. In a number of cases, it does polling. It takes 100% of the CPU. That's no good.

also fundamentally the Carbon api is the same between 9 and 10 via Carbon lib however that's just the same about the semantics it does not mean that the performance characteristics of the api are the same we cannot make it so in the number of cases because we have a different foundation so let me take two example dragging window is really faster on 10 than on 9 and that's because because you have your double buffered windows. So as you move the window outside, uncovering another window, you don't have to repaint the other window. You don't have to go through the painting code of that other app. Okay, so the drag window function is going to be faster on Mac OS X that's built in.

On the other hand, let's take access to low mems. OK, on 9, an accessor to a low mem may just be a function call and just read memory location. Done. OK? That's at 500 megahertz. That's a really minuscule fraction of a second. On Mac OS X, that state that the accessor provides may be stored on a server, a little server that runs in a separate process. So you may have to do to access your LOMEM to go through some inter-process communication. That's four orders of magnitude difference in the performance characteristics, which means that your applications that on 9 was doing in a loop accessing that LOMEM was just fine. Nobody would ever notice that. on ten suddenly that becomes the biggest thing okay performance wise for your application and dwarfs all the real work and so you need to really think and I implore you to think about tuning your application after the initial bring up that is key to our success now to help you we have put a lot of effort on performance tools we've included a number of those on the developer cd both applications developer applications you know the gui kind of things and also command line tools why command line well that's the heisenberg principle when you do kind of performance tuning which is you don't necessarily want to perturb the system you're observing and we've come in lines that's a very lightweight way of doing things also you can leverage some of the unix facilities for piping things and scripting and all the stuff to extract the kind of information you look for all our tools work without requiring com re-compilation or re-linking of your application this morning you saw sampler demonstrated there was no well there was some re-compiling but the and you were attaching avi was attaching to the running process without compiling in a special mode for that application we have put a lot of effort on those tools so that you can analyze and optimize your application all the things that matter for performance like memory usage like your cpu like how many system calls your application does or like drawing you can also optimize the system because your application may actually be fine from a performance standpoint but totally take over some of the of a service It generates a lot of work for some of the other servers of the machine. So we have some tools to look at the system behavior. And we have some resources via a book, a great book on performance. So now what I would like to do is invite Robert Burdage of the Performance Tools group, master of the performance tools, to demonstrate some of the tools. Thank you Bertrand.

I'd like to show you a couple more of the performance tools that are available on the Developer Tools CD. The first one I'd like to show you is called malloc-debug. And the idea of malloc-debug is it helps you understand how your application is using heap memory, that is memory you allocate yourself via request to malloc or to new pointer. Now, memory use on 10 is extremely important because it's so easy to ask for. You simply say, "Give me some memory," and the virtual memory system gives you the extra pages you need. And if the heap needs to grow, it grows without limits. So you have no bounds on how much memory you might ask for. The problem is that if your application starts getting a little bit greedy about how much memory it uses, it can get to the point where your application and the rest of the system may require more memory than is actually available in physical memory. And at that point, the system needs to actually start taking memory out, writing it to disk, bringing new memory in.

That's called paging. And as a result, your application will start running at the speed of the disk rather than the speed of the processor. So whatever you can do to keep your application's footprint as small as possible will help improve the performance of your app and of the system. So with malloc-debug, what we can do is we can launch an app. And in this case, we need something that is badly performing. So I naturally decided to choose one of my own apps.

Nothing like rubbing your nose in it. This is called Thread Viewer. You don't have to know very much about it. All you have to know is it's a prototype of a performance tool. You can select an application, in this case the doc, and it gives you a timeline view of what's going on in that application. And the colors will change depending on whether the various threads are running or not. So we'll move across the doc, and we see action.

Now, to get to that point, ThreadViewer needed about 2.5 megabytes of memory. Actually, 2.7 megabytes of memory on this run. This seems a little excessive, and I'd like to try to find out why. Now, the primary abstraction that mallocdebug uses is a call graph. And so it shows you all the ways that various functions call each other. And then it overlays on top of that the information about exactly how much memory was allocated at each point. So for example, we can see right here that in main and below, we used about 1.4 megabytes of memory. The rest was used on other threads.

1.3 megabytes of that was in the function called NSApplicationMain that was called by main, and that's the entry to the Cocoa routines. Also, there was a function called by main called allocateUnneededBuffer. That called malloc directly, and there's currently one buffer of 10,000 bytes that was allocated by that function. This seems suspicious. I'll come back to that later, I suppose.

So, if you understand how your program's built from main down, you can look at the call tree and you can try to find the expensive routines. Sometimes that's not the right way to go. Sometimes you care more about, for example, who's using malloc directly. And so we can see here, for example, that we used about 856,000 bytes of memory allocated when we called malloc directly.

About 555K of that was in NSZoneMalloc, which is the Objective-C version of malloc. And about 356,000 bytes of that was one we called NSImage, which called NSZoneMalloc, which called malloc. Now this is suspicious because as you can see, ThreadViewer isn't that complex. There aren't a lot of icons, there aren't a lot of images, so something seems wrong here. So what we can do is we can say, "Who called NSReadImage?" we can go up the call tree, going through the various app kit libraries.

and we end up in a function called imageForProcess that's in ThreadViewer. And luckily, I know my code, and I know what this does. That's the function that populates ThreadViewer's attach dialog box that says, here are the applications that you can examine. So what's happening here, because we saw all these icons-- what these things that must be icons in memory-- is that ThreadViewer is trying to be intelligent. It's trying to cache the icons so that the next time we bring up that dialog box, we don't have to go out to disk and read those bytes again.

The problem is, as a result, we're wasting about 300,000 bytes of memory, about 75 virtual memory pages, just to keep those icons in memory. And if we start running out of space, all we're going to do is page them right out to disk again. This isn't very bright.

Instead, what we want to have happen is when that dialog box goes away, we want the icons to go away. So they're not sitting in memory, so there's more memory available for the rest of the system. This is an example of how Malik Debug can help you track down memory problems.

The second tool I want to show you is called Quartz Debug, and it's out of the Core Graphics team. The idea is that it helps you understand how you're doing drawing in your application. We can again bring up Thread Viewer. Let's look at the dock again. And you can turn on this option called Flash Screen Updates in Quartz Debug. And what it does is every time that you try to do a drawing event, it colors the screen yellow. In this way, you can identify where drawing's happening. In this case, Thread Viewer has a one second timer that causes a redraw to happen. We can also see when we resize the window how much drawing goes on. And we might be able to detect cases, such as when we draw the same object twice in the same redraw cycle, where we're being inefficient.

Oh, by the way, there's a really cool feature in ThreadViewer. Let me show you this. There's a pause button. And the reason why you need that is that if you're ever looking at information going by and you say, hey, I want to see what's going on there and see exactly what functions I was executing then, you can hit the pause button. And what that does is it stops the application that you're examining. Then it stops the collecting of information. However-- oh, no.

As you can see, ThreadViewer is still trying to do the redraws. We can see in Quartz Debug that the screen is still flashing yellow. And this implies that I did something really bad. Although I'm correctly pausing the application that I'm examining, I'm pausing the data collection, I forgot to pause the redrawing screen. And as a result, I'm wasting CPU time, I'm taking time away from other processes by causing that redraw to happen.

This is one of those bugs that would be really hard to track down any other way. But luckily, Quartz Debug can make it immediately pop out that you have a problem. You can immediately perceive that you have problems with your drawing. These are only two of the tools that are available. There are several others on the Developer Tools CD. Please read the performance book to learn more. And if you'd like to learn more about these tools, there is a session on Thursday on the performance tools. Thank you, Bertrand. BERTHAND COHEN: Thanks, Bill.

And in fact, this is the roadmap to some of the sessions talking about performance. So the number nine great thing that I selected is, of course, great frameworks. We have great frameworks. And classic is wonderful. And it enables us to transition smoothly and to transition our users. But I want to talk about Carbon and Cocoa. And Scott in this room, Scott Foster in this room, is going to go into more details about those two. So what I wanted to do is bring in my personal perspective on Carbon. We had a challenge with Carbon. The challenge was to take the traditional Mac toolbox and put underneath it a modern operating system. And there were a lot of people who said this could not be done, even within Apple.

and it could not be done because the toolbox and the design a long long long time ago nearly twenty years ago it was the same when the file system was still flat it was designed with everything running its own in in one giant address space so the assumptions where and but it's a code bookings of Mac OS nine code all over the place and of course it was totally different low-level services Networking, totally different. Open transport had to be there, otherwise it cannot be done. File system, you have to assume a different file system, one that has resource box. Otherwise, there's no way you can get the toolbox to run.

So those were some of the challenges. We also had some goals. We wanted the carbonization process to be a tune-up for you, not a rewrite. We wanted to modernize. At the same time, we were doing this very smooth tune-up. We wanted to enable you to do things like Unicode, with again, without rewriting your application. And we wanted to provide tools to help you, like the Carbon data tools. So I think it's fair that we've accomplished a number of those goals, if not all. But we've learned quite a lot of things along the way. We took the Mac OS 9 code base for Carbon, for the toolbox, and little by little stretched it in various dimensions in order to get the proper layering. This took a lot of time. We spent a lot of efforts internally disentangling this spaghetti bowl.

however because we started with Mac OS nine and evolved it to get see Carbon toolbox for my question it's meant that we had high degree of compatibility it meant that we didn't have to rewrite every single error code okay and error codes as you know are something which it just takes time okay to rediscover one by one all the exceptional situations that what you need to do in those situations we didn't have to do that And that meant for you greater compatibility. But of course, what we've learned, the hard way for our own apps, is that carbonization is not enough. We need to do some performance tuning.

So this was kind of my personal perspective on Carbon. There's a lot of sessions that talk about Carbon. That's-- I don't know if it's half, but it's maybe 30% of the conference. So these are some of the pointers. The key session is probably the one just after this one.

Cocoa is a little less well-known for many of you. So what is Cocoa? It gives access to all the facilities of the machine. It's fully featured. It's object-oriented. It's very modern. What enables you is to do rapid application development. And what that means is that instead of working very hard to get your engine in perfect shape, okay and polishing your engine and kind of tuning it and then afterwards putting a UI as the afterthought on top of your engine it you can totally invert this development cycle you start with the UI you are in interface builder and you start wiring up things this is the way I'd like my app to look like it's all fake there's no reality there's no engine underneath okay but it enables you to iterate with the UI. And little by little, you put underneath the UI all the engine code that you'd like to have. And at some point, you have your app. So this is a very different kind of way of thinking.

now in terms of structure Cocoa has two layers that's a very clear distinction between non-new i and what's So the non-UI set of classes is called foundation. The first image that comes to my mind when I think about foundation is a set of LEGO bricks. And from day one, we wanted to have foundation classes really kind of plug into each other. It's kind of algebraic, the notion that everything just fits with everything. And nowadays, LEGOs have totally diverged. You have like Star Wars LEGO, the Rock Raiders, you know, the Adventureland. And if you have kids, you know all those categories of LEGOs. And they're all very bizarre shapes. No reuse here. It's no longer object-oriented. But in my days-- in my days the is a basic break was to buy for by three and you had you know different variations that that you had like five colors all great colors okay just free it was for the north it was a enough for the mall set of breaks this is a feeling is that you have when you use from this few concepts constantly reused says if you collection data types, you know, string, data, arrays, dictionary, that kind of thing. Also, that's where we put the XML parser, because obviously it's non-UI things. And then you have facilities to deal with the rest of the operating system. Things like abstracting the task, abstracting the thread, you know, all those kind of high-level functionality. So that's foundation.

The AppKit is the set of UI classes that matches. It's a rich set of controls. You saw this morning a demonstration that Scott did of hooking up some AppKit widgets with an extra 1,000 lines of code, and you get something that is close to iMovie, in basic functionality at least.

the paradigm that's followed consistently for the ui classes is the model view controller paradigm coming from the early 80s from the small talk kind of school of thought you have some low-level objects buttons you know windows things like that and some high-level objects an entire tech subsystem with you know phones with rulers all that stuff you know with with very little cost for you to use that, a one-liner. Or actually, it would be better to say the drag and drop in Interface Builder. You have an entire outline view, same thing, drag and drop. You have it in your app. Or even the reusable toolbars that you see in Mail or Finder can be done that way. And of course, it fully fits with Foundation.

So why is Cocoa particularly interesting for writing a new application? Well, let's look at some of our application. MEL is a pretty rich feature set MEL program. And maybe we can add a few features, and we are getting a lot of feedback from all of you on all the bells and whistles that we should add into MEL. But it has some basic functionality, and that's 75,000 lines of code. that is not a lot okay for that amount of functionality and actually about twenty thousand lines of that is reusable cuts that's packaging library the extended application is a pretty good what processor you know it has like a ruler of course falls it can be bad graphics and it's it's pretty rich it's only three thousand lines of code in fact you have the code in your cd because it's example code and you can make a simple text editor you know like the simple text of the old times with just 50 lines of code i believe that's another kind of tutorial or something like that so you are getting a lot of functionality with Cocoa for free and that's kind of the moral about Cocoa Here are some sessions that talk about Cocoa. And now what I would like to do is invite CK Hoen, who is the director in developer relationships, to give us a taste of Carbon and Cocoa.

Mac OS X is an extremely powerful engine. But an engine is not what our customers buy. They buy applications that take advantage of that engine. They buy people's applications that have looked at the things in the core, that have looked at the architecture, that have looked at our frameworks and said, "That's really great. If I put this in it, then somebody's going to have something even more powerful and even more exciting." So this afternoon, what I'd like to do is bring up some developers who've had that experience, who've brought their applications to Mac OS X, so they can give you some of their perspective on the task you have ahead of you over the next three to six months. I'd like to start by bringing up our representative from Adobe, from the Adobe Acrobat team. Yeah. Vince? Thanks, CK.

So Acrobat Reader 5 has a distinction of being the first Adobe application to run natively on Mac OS X. We actually shipped Reader 5.0 nine days after OS X shipped on the Acrobat 5 CD. We're very pleased to have Acrobat Reader 5 available for X users because unlike the preview application that comes with X, Reader 5.0 supports several advanced features that people like to use.

For example, you can find text. You have bookmark support. You also can do form fill-ins, support annotations, and other such features. So we started carbonizing Acrobat Reader 5 in late 1999, and by January of 2000 we had it running on an early version of OS X. During that process we discovered something fairly interesting. We actually discovered that OS X is an incredible debugging tool. Basically the fact that it has protected memory helps us find memory corruption problems we would never have found otherwise. Often these types of problems are notoriously hard to find, they're intermittent. With OS X, you do something bad, it stops you, tells you where you did it, and you go on. So Acrobat Reader is very much a full Aqua application. It has the full OS X look and feel, really throbbing icons. We have multilingual text fields. And even, most importantly, a really nice icon.

So as I said, we learned an awful lot doing the OS X version of Acrobat Reader 5. And we're going to take this knowledge, go back, and make the next Adobe applications run on OS X even better. Thank you. Thank you very much. Thank you very much, Vince. That's Vince Parsons from Adobe. Next, I'd like to bring up Lauren Rivers from Real Basic. Real Basic is an extremely important development tool for a lot of our introductory beginning programmers and some of the high end professionals. Lauren. Thanks very much, CK. How's it going?

We've had a version of Real Basic that ran on Mac OS X since last year's WWDC, and we actually shipped our Carbon version of Real Basic before Mac OS X did, because we were ready. So, no comment on, we were ready to ship our thing. Our product actually runs on Mac OS 761 on a 68K machine all the way up through Mac OS X. The beautiful thing is, Quadro 660 AV, like there are some at my daughter's school, running real basic, you can ride a Mac OS X app on a Quadro 660 AV running 7.6.1. This is pretty cool.

And of course, there's other operating systems out there besides Mac ones. Like there's a Windows OS. And you can also write Windows applications with Real Basic, which is also pretty cool. And of course, we've had a lot of experience with Carbon being involved with it for so long. And what people have been saying about it being a great debugging tool and a great excuse to refactor is absolutely true. So this version of Real Basic, it's version 3.2. We've actually had two revisions of Real Basic since we shipped. And this version has got more Mac OS X goodness than any previous of our releases.

In fact, we're actually eating our own caviar. And we're starting to reuse a lot of our own objects in our own application. So for example, now the project window is a Real Basic list box. And the great thing about eating your own caviar is that it's an opportunity to add new features that your users have been demanding for a lot of time. And it now becomes so much more urgent when you need to use them yourself. So what I'm going to build today is the two-minute app.

So the way Real Basic works is you drag a control from your tool palette into your window editor. What you see is what you get. We also are big fans of supporting UI standards. So you can see my little dash lines that are helping me keep within the parameters that are the UI guidelines. As always, you should comment your code, and you should name things intelligently. For example, I'm going to-- well, I'll leave that edit field for now.

I'll drag another. This is another control push button. And Apple's taken a lot of really great ideas that we have and implemented them in their products, like this iterative development stuff. Great minds think alike, right? So using Real Basic, you can be iterative yourself. So I'm going to just start off by doing a sample. For example, I want to put a message box up on the screen. And I'm going to say the classic first programming exercise.

and it'll run. Okay. But that's not a very interesting application, although I could compile it, compile it for Mac, Mac OS X and for Windows, just like this. But I'll do something a little more interesting, and I'll go back and say what I said I was gonna do earlier, which is give it an interesting name. Like, I'm gonna call this URL field.

What I'll do is double click my button again and I'll say URL field. Nice thing about Rule Basic is it's auto-completing for me. I'm sorry. Got ahead of myself. I'm going to say show URL. Here's my list of things that could be show. Show URL. url field dot text and run again and say www dot real basic dot com OK. There's my website. So there I have a functioning application.

And just to polish it up a little bit, I'll go in and make it the proper UI. and say go to URL and I'll be done. and then we'll just build. So there's my build. I can say, make all my settings, and there you have it. And you've got a compiled application, 100% native, single file, double clickable executable file. Thanks very much. Appreciate it.

Thank you, Lauren. One thing that we all work with every day is the internet. And one of the important parts of the internet, of course, is to have a rich multimedia experience. So now I'd like to ask Eric Wittman from Macromedia to come up. You've already seen Freehand this morning. I've asked Eric to talk a little bit about Freehand and about some of the Flash activity they did for Mac OS X.

Thanks, everyone. So yeah, Macromedia clearly is very excited about OS X. When we engaged in a conversation two years ago about OS X, really excited then. We're even more excited now. It's pretty-- you can tell from Macromedia's support of-- we're the first professional vector-based application that shipped with OS X. We got a lot of support from Apple, from the developer community. The debugging tools, clearly they're exceptional. I'm actually agreeing with my Adobe counterpart. You won't hear that often. And the public bug base and online support system that is available was crucial in getting a lot of our mission critical issues solved. We were actually able to ship a week ahead of schedule. And we were able to ship with the latest version of Carbon Lib, which Apple provided ahead of schedule as well, which was 1.3.1 for us. So it was crucial on the freehand side. And you guys saw freehand earlier. But another application that we've actually ported at Macromedia and have released is Flash Player. Flash Player affects 336 million people on the web today. That equals 96% of the people on the web. We're the most distributed piece of software on the internet, and we're even more viewable than, say, for example, like Java, which is at 86% viewability.

So it's really important for us when we're doing any work to make sure that our code is as stable as possible. And because we ship with so many browsers and operating systems, that the features are consistent across as many platforms as possible. And so one of the things that we found when we did our initial OS X port for Flash Player was that we actually exposed some memory issues that we didn't know about. And we were actually able to fix those quickly and actually made our code structure much more straightforward than it was historically. We actually have a pretty clean code base as it is, and we're only about 200k when it comes to our compiled app. So what I did want to show you is just a bit of Flash Player running natively on OS X. And Flash, as a lot of people think about it, is actually used for a lot of animations and user interfaces. And now as more websites are actually becoming dynamic, it's important for people who are using like Macromedia ColdFusion or ASP, etc. to be able to display that application information in a much more effective way. So we're finding that people are using Flash's web application UI and it's becoming a standard across a lot of types of applications. In this case, this is an actual application live today. It's for the city of Everett in Washington. And what they're actually doing is they are replanning, the city is replanning some of older areas of the city. And instead of just having a bunch of public meetings, which take a long time to organize and you have to get everyone there, they're doing a web-based version of their planning application.

So you're actually able to re-plan parts of Everett, Washington. So what we're going to do is we're just going to go to our main map area. So everything that you see here is FlashBase, this entire thing. And we are going to hit up Parkland. And let's add a couple basic things here, You know, the ability to actually drag an amphitheater here. Sounds like the kid theme is really big, so let's add a zoo. And we're going to have to feed the animals, so let's put farmland there. And we need some fertilizer, so let's add a horse arena.

And once you actually do that, you can actually natively print. Our native print operations and Flash Player are native on OS X as well. And you can actually submit this. And that information via our XML support goes directly to the application server and then to the database. And then these people can view the results offline. So it's a really excellent example of a web application in Flash Player. And like I said, we have had a very positive experience when it comes to porting very complex applications and old applications like Freehand, Freehand 10, and even somewhere on the lower end of the spectrum from a complexity standpoint, which is Flash Player. And as Tom mentioned earlier in the keynote, we're actually in the middle of porting the rest of our web publishing apps, Flash, the authoring application, Creamweaver, and Fireworks. And again, we're getting a lot of excellent help from the Apple folks, and we really appreciate it. And I encourage you guys to jump on the bandwagon because thus far it's been a good experience. Nothing without pains, but a good experience, nonetheless. Thank you. Thank you, Andrew. I mean, Eric. We've talked about Carbon applications across a variety of market segments. Now I'd like to bring up Andrew Stone from Stone Design to talk about the Cocoa experience.

Thank you. The Cocoa experience. Let's see. I started in 1989. And three years ago, when Gil was the I-CEO, I got to come up and demonstrate Create. And since OS X took a little bit longer than we might have thought to get to this wonderful day, thank you. I got six more apps written. So I'm going to show you an application. I'm going to show you the Stone Studio. And what I'm going to show you is how Cocoa lets you have all your apps talk to each other without hardly adding any code. There's no special code here other than just writing to pasteboards and stuff. So this is time equals money. It's a way to check how long your demo is. And so we'll start a new time session.

And Create is our web publishing, illustration, and page layout application built from ground up in Cocoa. And so everything's an object. And I'm just going to resize this guy a little bit and bring up our little kind of poor man's flash. What it is is it's an animation thing where you can just set some attributes and make your graphic or set of graphics do stuff. And if I say that-- Then that automatically launches another application, actually one that's free, GIF Fund. The source is available at stone.com if you want to see how a Cocoa app is written. And so it comes up, and then it displays it in your favorite browser, whatever that is. Actually, the Omni guys are next.

And then you can do stuff like drag a URL onto an object so that you can load web addresses and stuff. And then from GIF Fund, I can just actually take the output from that application and put it in. Slice and Dice lets you take images and turn them into JavaScript rollovers, which is gnarly code that we hate to write by hand. And so I can just save that for Create.

And one thing, never type on stage, or if you do. It's amazing how you can randomly type the same exact thing. So I can drop that in. And then Pstill is our low-cost distillery that lets you take freehand and Illustrator files, EPS, or PostScript, and convert it into something you can actually see live in OS X. And so you can instantly play with and all that stuff. Photo to Web is an application that lets you manage your digital photographs, create websites, thumbnails, slide views, that kind of thing. What I like to use it for is to quickly grab hunks of image for use in other applications, just drop it in. I'm going to make another page and create, go back to Time = Money and hit Now. There's left to do really and that's make an invoice and bill you guys for this. And so what I'm going to do is now create a web page from all the junk I brought in from all those other applications.

And so once again, a browser gets called, and to display the stuff, you've got your table of contents, your GIF, automatic nav bars, and there's your JavaScript. See, they're changing color. And there's the bill. So finally-- There really is one more thing to do, and that's show you our Shareware Pack Up and Go, which lets you, you can instantly save things out of Create with the image well, but if you drop it on the Pack Up and Go, it'll launch and make a tarball for you, then you can drag that into some other application. Free CDs of the Stone Studio while they last are at the exhibit hall at our booth. Number 15, I got it in, woo!

Thank you, Andrew. The internet, the collaboration between all of us working together at a lot of remote locations or in large or even small companies is really important to a lot of our customer segments. And I'd like to ask Marc Parmet from MeetingMaker to come up to talk about their experiences with bringing MeetingMaker to 10.

We've been in the Carbon game for a while. Late last winter, through the diligent work of our chief architect, Rob Ciccolini, we started on the path towards Carbon and by early 2000 had a working version. Apple is not only a partner of ours, but one of our customers, so it's been beaten up famously at Apple over the last year. We learn a lot about our successes and our mistakes. Thank you very much. There were two real pieces that we wanted to gain from the OS X experience. One was graphics. So we were overdue for a real good user experience overhaul. And the first thing that we were able to leverage out of OS X was this great graphics experience with Aqua, top to bottom.

While we may not be the sexiest application up here, we are in use by millions of people every day. And it's all about juggling people and places and resources in real time. So the objective here was to give our millions of customers a really cool user experience without having them forced into relearning an application that they use by the hour, by the day, by the week.

So in every window across every part of the app, OS X really helped us to reinvent things. You heard Steve and Avi and Ken and Bertrand talk an awful lot about the globalization of OS X. And that's the other key piece for us. We answer the when question. Gee, I'd like to be able to put six people in a room, in a conference room, and add a data projector.

When can we do that? When is the best time for us to meet? So the way we were able to leverage OS X is to create this wonderful new engine in Media Maker 7 called client-side time zones. Let's say we had to meet with our peers not just across California or across the U.S., but across the world, And I needed to find out exactly the right time without having to compute higher math while I'm trying to put something simply on my schedule.

We are the first app in the world, and by the way, we will be the first collaborative app available on OS X this summer. We're in final beta now. Shameless plug, you can go to our website today, mediumaker.com, and download the latest beta on Carbon. But we have not done just 24 time zones, but all 319 discrete time zones throughout the world are built into Media Maker, which means if you've got your calendar up and Bertrand's on the phone and would like to meet with you tomorrow in Indianapolis, which, by the way, is in a totally different time zone from the rest of Indiana. You simply click on Indianapolis.

Click on the wonderfully throbbing OK button, and there you go. It's just re-registered your calendar in Indianapolis. Or if you're lucky enough to be Bertrand and working from, let's say, the Aleutian Islands-- or any other spot on the globe, you're able to do that. And we've had an extraordinary experience. Steve talked an awful lot this morning about the partnership, about us coming to Apple, about Apple coming to us. I am certainly proof on behalf of Media Maker that that partnership's work, worldwide developer relations, has been the difference between this happening and not happening. And I can't say enough good things about Dev Relations at Apple. So thank you.

Thank you very much, Mark. I would also suggest that Avi's interaction with the meeting maker team may have influenced some of it. At this point, I'd like to bring up Wil Shipley, president of the Omni Group, to talk about some of the Cocoa perspective for someone who does a whole lot of applications very quickly.

Let me just launch the wrong app. So a duck walks into a bar. No. I had some jokes, but Apple requested I took them out because they weren't funny. So what am I going to talk about? I have a browser, and if we could-- Show it. Sometime. Yes. That's it. I'm guessing most of you are familiar with it. And if you're not familiar with it, you're probably familiar with browsers. So I'm not actually going to go through it, because we're a little pressed for time. What I do want to talk about is Cocoa and how great it is. So I'm sort of here as unpaid shill for Apple, as it were.

Fundamentally, I'm a Cocoa programmer because I'm lazy. I want to write only the parts of apps that are new, that are different, that are creative. That's why I got into this business. And Cocoa enables you to write apps 10 times as quickly as any other toolkit. And you've all heard that a million times. And you don't believe me, of course, because you're like, I've heard it a million times. So what I hope to do is give just two examples of the kind of productivity gains you get with Cocoa. and then maybe I'll get you interested enough to actually select the Cocoa book from O'Reilly Associates rather than the Carbon book and maybe win some converts. The first example is OmniWeb, our browser. It doesn't do everything in the world, but it is, according to one unscientific poll I saw, the most popular browser on OS X. This was a web poll, so who knows, maybe it was just my friends voting. I don't know. But still, it was really nice that that many people knew us.

There's only 2 and 1/2 people working full time on OmniWeb. And I think you have an idea of how big the other browsers' teams are. And yet, we're-- We're providing a professional quality browser from two and a half people. So what's the rest of my company doing? I think an even better example of productivity gains is the game ports we've done. Right next door, there's a games pavilion and every app running under OS X, every game running under OS X is a Cocoa game.

all those ports were worked on by us. And bigger than that, all those ports were worked on by us since about January 15th of this year. And bigger than that, they were all done by one guy. And bigger than that, it was only part-time by one guy. So as you're playing those games, Tim Wood. We love him. Yeah, this is my highly technical 3M note-taking device.

It's posted. Also, we have a booth out in the hall, along with, I think, six other companies that have been invited by Apple to help people get their apps to OS X. If you want to stop by any of our booths, we specialize in Cocoa. The other guys do Cocoa and Carbon or other stuff. Please do no charge to talk. Thank you. Productivity applications, calendaring applications, web browsers, and things like that is all what we do so we can make money, so we can buy and play games. So I'd like to ask Graeme Devine to come up, chief designer for id Software.

Thank you. Boy, seems like we've shown Quake 3 and running a bunch of keynotes for a bunch of years. Now you've all been playing it, and you can see how it runs next door. It's running really well. We've ported two things to Mac OS X. We've ported our Doom technology, which was shown by Steve back in January in Tokyo, well, February in Tokyo, and we ported Quake 3. That process has been a real big education for us. As much as we loved Mac OS 9 as a consumer OS, and it was a great consumer OS and still is, it was very hard to make that your primary development tool. Let me go switch off the radio. because of all things, like you can't go and you can't go and do this.

do the wonderful things like debug the application, have it crash on you, and up comes the Macintosh debugger giving you a kernel panic with all useful information of the stack and what the radiuses contain. And that's really not very helpful for decoding your application. So I started to work with Mac OS X back about a year ago when DP4 came out.

And I started to deal with all of the wonderful-- the beta operating system and how cool can that be? I'm the one person in the office running it. How cool is this? And all of a sudden, it started to get useful. It started to become, oh, well, this mail app is actually kind of cool. Oh, well, this Cocoa stuff, I can actually to kind of do things like that, like use the Omni groups, foundation classes, their timer group and so forth, and just bring that stuff in. And it's easy, and it runtime binds, and it does all little cool things.

all of which makes Mac OS X a great primary development tool over other competing operating systems which we've used before, typically Windows. So now, as id, we develop on both Windows and Mac OS X simultaneously, and that helps us greatly, because as you've heard time and time again, people coming up, they say, "Oh, we found bugs in the memory thing "when we ported across X that we didn't find in 9, and somehow we missed it for 10 years.

But it really does happen. You bring out your app, you compile it with Metrowerks in nine and it goes through and does the right thing and it ain't ever gonna crash. You bring it up in MS dev under Windows and it compiles and it has a few more warnings that you fix that perhaps the Metrowerks compiler should have done and it compiles just great and runs for the next 10 years.

You bring it into Mac OS X and you put up that warning level up to the severe warning level and you've got 3,200 warnings when your application builds and you think, Golly. Then you run it and your application runs great and it's leaking merrily like a sieve that it's never done before.

So you start to use some of the apps like Sampler. And I use VTune all the time under Windows, and Sampler was a surprise for me to use. This comes from Apple. It wasn't coming from Motorola or some other surprising company. Apple made this great tool that helps me get Doom up and running to 30 FPS for February 24 for Steve in Tokyo the night before.

That was a story. It also let us tune this app, which is Team Arena. And we've been working on a remaster of Team Arena for quite a little bit of time. And it's the first, I think, game that's going onto CD that's will ship the actual Windows version, Win32, the classic OS 9 version, and the Cocoa version all together on the same CD.

There's a lot of good reasons for taking a classic app and trying to carbonize it. In many cases, that works just absolutely wonderfully. But I think if you really want to look towards the future and grab the potential of OS X and grab your customers' attention, especially when your application has all the multimedia goodness that games have and so forth, that you want to show through in the OS X operating system, the Cocoa is the way to go. It's absolutely the best development environment in the universe. Nothing beats it. And I don't think that anyone who works in CodeCoin actually puts an app out there will disagree with me at all. Anyway, Quake 3, it's why you actually bought a Mac.

Macintosh operating system, Mac hardware, is an absolute great gaming platform. And it's great for customers to be able to play games. And thank you for having me. Thank you very much, Graham. You saw a bunch of applications that are either shipping or very, very close to shipping on Mac OS X. You've seen the slides about people wanting your applications. I'm hoping to see at least 60% of your applications at Macro New York. Thank you. Thank you, CK.

So we're a little late. You probably lost track, but that was my number nine, great frameworks. So what's missing? What's my number 10? Any idea? I could absolutely not have these 10 great things about Mac OS X without having at least my number 10 being Aqua. So we run short of time. I'm not going to talk about Aqua. I've been using it for two years, And it's still as fresh as day one. And I think it's wonderful. And thank you a lot for all the feedback on Aqua, which has helped us make it much better. So Aqua is the most great visible thing about Mac OS X. And I think many users out there are going to equate Mac OS X with Aqua. They won't know about the underpinnings, the great foundation, and all that stuff. They will think about Aqua. Now, I think this is a great opportunity for you, because I believe there will be a lot of demand for your application to be Aqua, in case you don't already have such an application.

So the good news is that you're going to get a lot of the Aqua support for free. The basic Aqua support via Carbon or Cocoa, or even Java, you are getting for free. If you want to do fancier things, you know, integrate better with Aqua, have sheets that drop down, and you know, and the like, You can use some of the advanced APIs that we provide. Again, we've done most of the hard work there, so it should be fairly straightforward to add those features to your application. And we have a book with the UI guidelines, and we have Interface Builder with the little dotted blue lines to help you make your application, your UI, Aqua compliant. So these were my 10 great things about Mac OS X. There's a lot more great things about Mac OS X that I'm sure you like or you appreciate. Always press by time. That's the story of my life.

The greatest thing, though, is that we shipped. We shipped on March 24th, about two months ago. Today, we announced that every single machine coming out of the factory is going to have Mac OS X pre-installed. Ahead of schedule. This is significant. We already have a number of applications, about 600 applications. And I believe that by the end of this week, we may have quite a few extras. So I believe we'll get a lot of applications from you this summer. The ball is in your court now. We've done a lot of hard work. We will continue to move on, and we're here to help you. So enjoy the conference. Thank you.