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. 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.

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 think you know but two months from now uh... since the developers conference everything so yeah two months from now plenty of time i could keep feeling we've 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 no talk about like fancy new technologies that is being developed and that maybe one day we'll come out we decided to talk with what you have uh... and that's my question the other thing quite frankly is that uh... we were a little tired after march twenty fourth so we took some vacation uh... 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 ten steve said the the context you know 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 ten so i thought okay 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 ten the final version or the public beta or its pre-releases for quite a while now what i decided to do is to talk about ten great things about Mac OS ten ten things that i feel very strongly personally that are great and unique to Mac OS ten 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 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 in fact in some sessions you may see that as the Core-S.

Okay, 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, okay? And you have some APIs, okay, inside the Core-S. So you can have the Core-S that brings some functionality all the way through the stacks, okay, to the Carbon stack, the Cocoa stack, or whatever stack, okay? 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. Okay, Mac OS X is a Unix-like system. It has Unix functionality, okay? It's actually very close to the Mac OS X. It's very close to FreeBSD. A lot of the code that we're 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, you know, all those kind of usual functions to dealing with files. So you can directly access the Core-S through the POSIX APIs. We are very close to the POSIX API set. And the other way you can, as a developer, leverage the Core-S is to use shell commands.

So, of course, you know, no end user will ever use shell commands. At least we hope, okay? If there's still a few places where Unix shows through, okay, for the end user, we have failed and we will plug those things, okay? 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, you know, things together, piping, in Unix terminology.

The last level down in the core R.S. is Mac. Mac 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. Okay. The kernel extension mechanism is useful. All those things enable 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, you typically, sometimes when you have an application, you need to have some init 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. Okay. 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. Okay. 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're 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 an order 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 words at the Darwin level. I'm not going to talk too much about graphics because Avi did, I think, an excellent job of talking about graphics. Fundamentally, we have 2D, and that's Quartz, 3D, and that's OpenGL, and what I would call, and marketing will probably shoot me, 4D, and that's QuickTime because fundamentally, this is kind of like the time as I mentioned, but that's probably not the official way of talking about 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 compatibility, that's the way to run an unmodified binary.

It's still okay 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. It's also 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, okay? It all kind of fits together.

Now, as a developer, you can reuse some of the system applications because some of those applications 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 have a Cocoa application, you can reuse other applications by means of the services menu, and those kind of things will be talked in sessions during the week.

And of course, the lingua franca for all applications is Apple Events. All the applications can communicate with Apple Events. And on top of that, you can put Apple Script, okay, to make it easy kind of 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, okay, having like a separation between UI and non-UI. Okay, so this is how you design a great system, by thinking straight in terms of layering.

Now, the other thing, 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.

in Europe, 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. It runs like another process, like any other process. It's a Unix process. It's a regular process. 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 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 Simula.

That was in the early 60s. And its goal was to simulate the real world. Okay, and this is exactly what I/O Kit does. It modelizes 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 characteristics of object-oriented languages. So this is why we chose an object-oriented framework for I/O Kit. Now, all the basic families encapsulated. You have a family that abstracts 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 two devices active, you may actually run one of each on each processor and gain twice the 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. Many of you I've 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 Avi. But why? How did we make that wake up so fast? I mean, you know from experience on Mac OS 9 that, okay, when you open your power book, well, you have all these things that happen, and after a few seconds, a display comes up, and the finder gets inside. It's hacked 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 modellised 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, okay? However, you have several power planes and so you have this multi-threading and so in parallel you wake up each plane, okay? 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, okay, you've been already doing your email for 30 seconds, okay, 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, okay? And so the recipient of the document will be able to see the same document. Okay, 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 all forms, and PDF is doing a great job at that. And an upcoming kind of style of things is vector line art, okay? 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 saved as PDF for free because if your application draws on the screen, given that we have all these Quartz that displays a PDF, we're able to collect all these pieces of PDF and put that on a 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, 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.

Thank you. 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 Quartz 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 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 X, 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 Quartz user and develop on the same machine. And that, I think, is a significant win.

Also, you have a lot of tools built in. Mac OS X, the box, comes with the tools CD and we ship a broad spectrum of tools. 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.

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 airport, now present in a lot of places, in hotels, in airports. 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. I really enjoy that. Thank you.

let's talk about some of the global features There are two fundamental technologies that help us have great global features. The first one is application packaging. What application packaging is about is, from the user perspective, have a single icon that represents the app. Okay, so for our users, it's very simple.

You know, no longer you need to kind of dig into a folder. You need to have the icon view just set up right so that, you know, the application icon is right there but all the rest is hidden. No. For the user, you have just a single icon.

For the developer on the other hand, you have like files and folders. Okay, 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. Okay, 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 this, putting together this technology is something that I think we did right, okay, 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, you know, drag and drop install. You know, 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. Okay, 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 talk in terms of CFString. Now what we did is CFString, along with our facilities, live in the libraries that we call 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 of the few 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 to ship Mac OS X in seven languages. We actually GMed this exact same day for all seven languages, which is kind of a first internally. 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.

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 the other 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. TextEdit is a Cocoa app, i.e. is Carbon. Because all of the text in my system is Unicode, this kind of stuff just works. For the rest of the demo, I want to switch.

and the rest of the team. So, let's get my language back to English. Drag and drop. Close this. Let's quit TextEdit. I think this one is done safe. Yep. So, we can do this kind of stuff in Mac OS X because TextEdit is an app packaged application. So, to the user, they just see one icon, but inside that package are all of the localized resources.

So, this is going to be great for you guys. You can ship one app all 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 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. 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 app called Graphic Converter. So I'll open my Apple Script 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 converters, 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 ROS, 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, Apple script 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 data is exchanged via the paste 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 de-parser, un-parser, whatever. You can just reuse the parsers that we wrote for you.

We put that poster in several places. We put it in core foundation, that's beneath Carbon and Cocoa. It's also having an object-oriented kind of sugar coating, and that's in foundation. And we also decided to put that in Darwin so that driver developers can reuse the little XML poster there as well.

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. You know, 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, okay? 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, okay? 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 VM, the virtual machine, directly from Sun, the originator. We take the hotspot Java VM, that's the best Java VM, right, from the people who build it. 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 onboard Mac OS X and then to iterate on the performance tuning and such.

So what do you want to use Java for? For cross-platform applications. I'm sure a number of you already have some Java applications. It's going to be great on Mac OS X because it's standard. It's cross-platform, right? There's a twist, though. The twist is that on Mac OS X you can also benefit of certain technologies like QuickTime. We have a great Java binding for QuickTime.

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.

Now, Web Objects 5 was announced this morning. Web Objects 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 remember that. WebEx 5 is best developed and deployed on Mac OS X. A little plug for WebEx 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, okay, 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. Okay, 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, right? It takes 100% of the CPU. That's no good.

Also, fundamentally, the Carbon API is the same between 9 and 10 via CarbonLib. 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 a number of cases because we have a different foundation. So let me take two examples.

Dragging window is really faster on 10 than on 9, and that's 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. 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. Okay, on 9, an access to a low mem may just be a function call and just read, you know, a memory location. Done. Okay? That's, you know, 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 10, 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 with command 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 that stuff to extract the kind of information you look for.

All our tools work without requiring recompilation or relinking of your application. This morning, you saw a sampler demonstrated. There was no, well, there was some recompiling, but 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 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 other servers, generate 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 Bowdidge 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. Thank you. 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 dock, 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 dock and we see action.

Now, to get to that point, Thread Viewer 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 allocate unneeded buffer. 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, thread viewer 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 Image for Process that's in Thread Viewer. And luckily I know my code and I know what this does. That's the function that populates ThreadViewer's attached dialog box. It says here are the applications that you can examine. So what's happening here, because we saw all these icons, these things that must be icons in memory, is that Thread Viewer 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 Thread Viewer. 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 QuartzDebug 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, QuartzDebug 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 COOPER: 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 kind of 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 had been designed a long, long, long time ago, nearly 20 years ago. It was designed when the file system was still flat. It was designed with everything running its own in one giant address space. And those assumptions were embodied in the code, in the Mac OS 9 code, all over the place.

And of course, there was totally different low-level services. Okay, 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, okay, 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 X 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 9 and evolved it to get the Carbon Toolbox for Mac OS X, it meant that we had a high degree of compatibility. It meant that we didn't have to rewrite every single error code. And error codes, as you know, are something which just takes time to rediscover one by one all the exceptional situations that 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. You need to do, 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, you can totally invert this development cycle. You start with the UI. You are an interface builder and you start wiring up things. This is the way to do it. 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 codes 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. There's a very clear distinction between what's non-UI and what's UI-based. 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, you know, if you have kids, you know all those categories of Legos. And they're all very bizarre shapes, okay? No reuse here. It's no longer object-oriented.

But in my days... in my days the basic brick was 2x4x3 right and you had you know different variations on that and you had like five colors all great colors okay just very different it was orthogonal it was an orthogonal toolkit set of bricks and this is a feeling that you have when you use foundation few concepts constantly reused there's a few 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 a thread you know all those kind of high level functionality so that's foundation The App Kit 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 like some App Kit widgets with an extra thousand 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 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. I mean, 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 for that amount of functionality. And actually, about 20,000 lines of that is reusable code that's packaged in your library. The TextEdit application is a pretty good word processor. It has a ruler, fonts, it can embed graphics. It's pretty rich. It's only 3,000 lines of code. In fact, you have that code on 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 C.K. Haun, 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? 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 10 shipped on the Acrobat 5 CD. We're very pleased to have Acrobat Reader 5 available for 10 users because unlike the preview application that comes with 10, 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.

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. Simply the fact that it has protected memory helps us find memory corruption problems we never 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 Lorin 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. Lorin. Thanks very much C.K. 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... I mean, no comment on... We were ready to ship our thing. Our product actually runs on Mac OS 7.6.1, 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 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've added-- 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 support. We're 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. So for example, I'm going to-- well, I'll leave that edit field for now.

I'll drag another. This is another Control-A-Push button. And Apple's taken a lot of really great ideas that we have, and implemented them in their products, like there's iterative development and 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 Michael Rahn. Okay. 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 going to do earlier, which is give it an interesting name. Like I'm going to call this URL field.

What I'll do is double click my button again and I'll say URL field. Nice thing about Real 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.

Okay, 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 Witman 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, we were really excited then. We're even more excited now. It's pretty, you can tell from Macromedia's support of, you know, 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, are exceptional. I'm actually agreeing with my Adobe counterpart. You won't hear that often. And, you know, 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 CarbonLib, which Apple provided ahead of schedule as well, which was 1.3.1 for us. So that 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. They'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 issues very quickly, and it actually made our code structure much more straightforward than it was historically. So 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, you know, Macromedia ColdFusion or ASP, et cetera, to, you know, be able to display the code. And so we're able to do that. And we're able 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 the 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 replan 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 Flash-based, 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 cool. Yeah. And we're going to make it 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, or print operations in FlashPlayer 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 FlashPlayer.

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 FlashPlayer. 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 one. 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.

Ah, 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 10 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 you can, 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 save that, Then that automatically launches another application, actually one that's free, gift fund. The source is available at stone.com if you want to see how a Cocoa app is written. And so it will, it comes up and then it displays it in your favorite browser, whatever that is. Actually the Omni guys are next, so.

And then you can do stuff like drag the, a URL onto an object so that you can load web, web addresses and stuff. And then from gift fund, I can just actually take the output from that application and put it in. Slice and dice is, 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 onstage, 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 your opacity and all that stuff.

And Photo2Web is an application that lets you manage your digital photographs, create websites, thumbnails, slide views, that kind of thing. But what I like to use it for is to quickly grab hunks of image for use in other applications, just drop it in. So I'm going to make another page and create, go back to time equals money, and hit now. OK? Well, there's one thing 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 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, MediaMaker.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 MediaMaker. 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,

Thank you very much, Marc. 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. and David I had some jokes but Apple requested I took them out because they weren't funny. So what am I going to talk about? 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 ten 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. And 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 two and a half people working full time on Omni Web. And I think you have an idea of how big the other browsers teams are. And yet, you know, 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.

and 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 post-it. 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 10. 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. The 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, but... 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.

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 the useful information of the stack and what the radiuses contain. 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's actually kind of cool. Oh, well, I want this Cocoa stuff. I can actually do things like that, like use the Omni Group's 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 the 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 cut, you know, you bring out your app, you compile it with MetroWorks in Nine, and it goes through and does the right thing, and you know, 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, you know, the MetroWorks 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, you know, 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. We've been working on a remaster of Team Arena for quite a little bit of time. It's the first 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 customer's attention, especially when your application has all the multimedia goodness that games have and so forth that you want to show through OS X and your operating system, then 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 Cocoa and actually puts an app out there will disagree with me at all. Anyway, Quake 3, it's why you actually bought a Mac, so... 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, Graeme. 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, C.K.

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 ten? Any idea? I could absolutely not have these ten great things about Mac OS X without having at least my number ten 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... you know, 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 if, 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, you can do that. You can get 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 like a book with the UI guidelines and we have interface builder with the little, you know, dotted blue lines to help you kind of make your application, your UI, Aqua compliant. So, these were my 10 tips. Thank you. And 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 my time. That's the story of my life. The greatest thing though is that we shipped. Okay, 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. Okay, 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.