Thank you all very much. It's a pleasure to have you all here. This is session 104, the affectionately titled Mac OS X Overview for Unix Geeks. So first question is, how many Unix geeks do we have in the audience? OK, if you're looking for the how to make nice pretty pictures, you're in the wrong place.

My name is Rony Prabhakar. I'm the product line manager for development platforms. I'm part of the Mac OS X product marketing team. I consider our group the people who do geek stuff. We make the tools that people like you, that our developers need, to create great apps for our mutual customers. That's responsible for the Java runtime, the WebObjects application server, our development tools, but in particular, our open source and Unix technologies. I've been working on Unix since the days of BSC 4.2, back at MIT. and very excited to see a platform that really, I think, exemplifies the dreams for what I and many others in the Unix community have been seeking. One of the main purposes for this orientation is for people who have not been very familiar with Mac OS X or the Mac platform. How many of you were not using a Mac a year ago? Just getting a feel for, okay, pretty good representation. How many of you have been using Mac OS X for less than three months? Any, a few new people here? Okay, very good. So a lot of you probably have been using Mac OS X in various capacities over time. The real focus was primarily focusing on Unix developers who are new to the Mac, people who may have used a Mac only casually or may not have been using Mac OS X, or importantly, may not have developed on Mac OS X even if they've used it casually. And there's a lot of culture and history behind Mac OS X that affects some of the decisions we're made, and in case you're a little disoriented by some of those terms or concepts, This is the place to try to help you get those answers. And in particular, we want to help you get the most out of this conference. How many of you, is this your first developers conference?

Well, that's great. Really excited to see all these people coming in to experience Mac OS X. We want to help you get the most out of the conference, give you some suggestions of the different events going on that may be of interest to you, and also give you a chance to ask questions. It's just a fairly brief presentation all told. We want to have lots of time for questions. I'll have some of the engineers up here with me to make sure that, you know, any dumb questions questions you don't want to ask because you thought everyone else would know the answer, this is your chance to ask them.

So what we're gonna cover is a number of things here. First of all, the architecture of Mac OS X, just a quick overview for those of you who haven't seen the history of it, the names and history of the key technology components, what's the difference between a Carbon and a Cocoa and a classic application. Some correspondence between what we do in Mac OS X, what you may be used to from your previous Unix platforms, some high level differences from those systems, as well as the roadmap. So I'll start with some history about how we got to Mac OS X. So this, of course, is the picture that you've always seen a lot of, of the face of Mac OS X. And we talk about the power of Unix and the simplicity of Macintosh.

But for people coming from a Unix background, you often see it as the simplicity of Unix and the power of Macintosh. Right? It's the idea that people who think of Unix as simple... How many people think of Unix as simple? Right? That's a very different perspective than the typical Macintosh user or Macintosh developer.

For this, the world looks like this, right? You've got a terminal window. You've got all sorts of developer applications and stuff like that. And in this world, the key idea of simplicity of Unix, it's building on real BSD Unix. How many BSD users in the audience? Just a good feel. Okay, how many Linux users? Various guys. Okay, good sprinkling.

A lot of people showing up both hands, I'm sure. But really taking, you know, not writing our own version of Unix, taking BSD Unix and making it a part of Mac OS X. Embracing standards, not just the technology, but also the philosophy of Unix, focusing on multiple interoperable implementations of well-agreed standards, the technology and culture that gave birth to the internet.

And not just that, but also the whole new wave of open source, which is arguably the most important thing to happen to Unix in the last decade. We really wanted to participate fully in that spirit of the Unix community. So that's all the Unix stuff that we try to do, keeping with being a good Unix citizen. At the same time, what in this context we're calling the power of the Macintosh, all the great things the Macintosh can enable you to do that weren't really possible or at least not very feasible on traditional Unix systems. Having a great streamlined user interface, having a very rich, comprehensive, and complete set of killer graphics technologies, and then perhaps just as importantly, supporting the digital hub, all the new lifestyle applications available from Apple for Mac OS X.

So we see this is coming together not just of technologies, but also of people. Obviously the Macintosh faithful, people who've been on the Mac platform for years, stuck with us through thick and thin, in really core markets where the Mac has always had a really compelling advantage. Among certain segments of the consumer space, creative professionals, design and publishing, small businesses, and particularly educators and students. At the same time, we see this opening the door to a whole new range of people, probably many of you, people who really love Unix. These are people doing animation in movie studios, scientists and engineers doing research, in-house developers doing Unix or even Java applications, and of course, the whole open source community. We want to make Mac OS X not just the best operating system for our existing customers, as we were focusing on last year, but the best platform for Unix users and Unix developers.

A little bit of history for those of you who are new to the Mac community. We actually launched Mac OS X back in 1998 based on some earlier technology we had acquired from Next in 1997. And we made a very conscious decision at that point that we were going to be building the next generation of the Mac OS on top of a Unix foundation. Apple had tried other attempts to rebuild the Mac OS on other foundations. We decided, okay, we're going to throw our lot in with Unix. We're not going to emulate Unix. We're not going to rewrite Unix. We're going to make something that's really Unix. It's going to be based on TCP/IP. It's going to have a shell. It's going to use the GNU C compiler. It will ship with things like Emacs. We have very key strategic decisions to build that. A lot of people didn't think we would succeed in creating something that was usable for mere mortals based on Unix technology. We placed our bet back then. We had several key investments over the years, adopting standards-based technologies for graphics, OpenGL, and PDF. The very momentous decision back then to release key portions of the Mac OS X technology family as open source and committing ourselves to an open development model, increasing the number of open source developments with things like the streaming server. We made a big bet on Java 2, making a formal commitment that we were going to ship Java 2 with every copy of Mac OS X at a time when other major operating system vendors were backing away from Java. We wanted to really move forward with Java and standards. We shipped Mac OS X in March 2001, a big day for a lot of us. And then we made a key decision there, driven in large part by the Unix community to include the developer tools with every copy of Mac OS X software that we shipped.

And this was a conscious realization that our customer base had changed. We would never have conceived of something like that in the Mac OS 8 or 9 days. But because we realized that Mac OS X would appeal to people like yourselves, and blurring the line between an end user and a developer, we wanted to take advantage of that opportunity to make those tools available to people like yourselves. And then, of course, the big day in January when we made Mac OS X the default on all of our hardware. So it's been almost a four-year journey to get to this point. actually four years ago at the developer conference when we first launched Mac OS X. We've gone through two major updates starting in our third here. We're very excited about really starting to take this to the Unix community.

Now, why are we interested in doing this? One is because we're able to bring stuff to the Unix community that they've rarely seen or had a hard time running on traditional Unix platforms. That's productivity software, games, digital lifestyle applications, media players, all sorts of things that, you know, quote-unquote normal platforms use all the time but are hard to get on Unix. You either have to emulate something or dual boot, et cetera. We want to have all that stuff available for people in a true Unix environment.

We're also excited, of course, because this gives us all sorts of wonderful things that we've never had on the Mac or were very hard for us to get on the Mac. Viridian's developer tools for optimized profiling, scientific software written in Fortran, visualization technology like Maya, scalable network services like Samba. All sorts of great things that are sort of taken for granted in the Unix community and very hard to get on the Macintosh. One of my favorite examples of things that we've been able to get because of our Unix foundation is MATLAB. They had a press release just yesterday that we've been looking for for a long time, a very powerful engineering solution now available on Mac OS, well, not quite yet available, but coming available in large part because of the ease of doing Unix-based development on Mac OS X. So it's a whole new world for us in terms of customers and solutions that we're able to provide.

So at this point, I'd like to go over the Mac OS X architecture diagram. How many of you have never seen sort of an architectural walkthrough of Mac OS X? Has everyone seen an architectural walkthrough of Mac OS X? Okay, I'll go over this fairly quickly, but I also want to share, I've been involved with this process for the last four years, talking about some of the choices we made, why we did things, how this may impact what you do in your work.

The key thing about this architecture, which I think distinguishes it from other attempts to make a usable Unix, is we really want to make a modular architecture. This allows us to do things at the bottom level without having to rewrite everything at the higher layers. It enabled Mac OS X to succeed where previous events, attempts at next generation operating systems had failed.

But it also allows us to innovate more rapidly. And by understanding which layer you're working on in Mac OS X, you're able to work more rapidly, more efficiently, and yet still be able to access the power and functionality that you need. In particular, this also allows us to open source the lower layers of the system while still retaining higher value add pieces that we can sell commercially and pay engineers to do more cool stuff. It also enables us to support legacy technology in a modular way without having to pollute our APIs or break compatibility in many cases. It also allows us as Apple to coordinate multiple small teams. So we can have teams working on different technology which may not be known to the rest of the company. things like iChat, which we released or announced yesterday, without having to worry about the entire system having to deal with it, although obviously there are cases where that happens. And more importantly, it allows us to hide complexity from users and developers.

One of the big challenges in Unix is you pretty much had to see everything, and it was great that you could see everything, but there was times where you would not want to see everything or in particular end users do not want to see everything. This layered architecture allows certain developers, our traditional Mac developers, our Macintosh end users, to experience the benefits of all that complexity and power without having to manage that complexity themselves.

A lot of that complexity that people worry about from the non-traditional Unix community is the foundation, which we call Darwin. Darwin is the Core OS of Mac-- core foundation of Mac OS X. We actually use it to refer to a family of technologies, the kernel, the libraries, the network services, and the command environment, what we call user space sometimes. And all of that is part of Darwin. It's all open source. It's all available as part of Mac OS X, but invisible to the casual user.

And of course, it's all the standard stuff you expect from Unix, right? All the utilities, editors, and programming languages you expect, a full terminal environment. But importantly, it also provides the capability for third parties to add other things that we don't ship as part of the system. Whether that's toolkits like X486, QT, Aqua, TK for Aqua, applications like Tech and GIMP and Pine, and languages like Python, Ruby, which, as you've heard, are becoming part of our system in the future. in G77. Some of these things may become part of the system. All of these things won't. Tech has an enormous quantity of fonts and infrastructure, which probably won't ever be appropriate for the base system. But you know that you can get it and run it on your system in a nice, seamless way. Here's an example of GIMP running in X11 on Mac OS X. You can do it. It's not what we consider the most ideal user interface, but if you need GIMP, it's there. It works. And there's people working to port the GTK toolkit to Mac OS X so it can run natively, which would be great. Thank you.

And across all the standards, all sorts of stuff for networking and file systems, directory services, our goal as you heard at the keynote on Monday is to get Mac OS X to talk to everything. Okay? We don't pretend to live in a Mac only world. We're not trying to push Mac only standards. We innovate in areas like rendezvous. We want to make them available to the entire community in order to make these things as industry standard as possible so you get all these benefits of interoperability and connectivity.

One of the important things that we had to deal with when we built Mac OS X, when people said, "My gosh, you're building a Unix system. It has all these ports, all these openings. Doesn't this create a huge security risk?" And certainly there are things we have to be concerned about. But we really wanted to try and break that dichotomy that people thought that in order to be secure, like in the Mac OS 9 sense, you had to turn everything off and not have anything capable with your system. We really think that there's a better way of doing it by investing in two key areas. First of all, robust security policies. At Apple, we make a religion of trying to understand our users.

We may not always get it right, but we're always asking ourselves the question, what are users actually doing? What are they thinking? What's easy for them? What's hard for them? And taking that mindset to security eliminates the most common cause of security problems, which is user configuration issues.

By having intelligent defaults, clearly visible network service control panels to turn things on and off, we think we can eliminate a lot of security concerns, people traditionally had on other platforms, particularly on Unix. A couple of examples. We use role-based authentication for most system authentication. It's not a root user. You don't, SU is root and login is root and have an open system there. You have an administrator role that you authenticate against a secure process as necessary, enabling you to have a much more secure way of managing your system. We turn the network services off by default. We don't ship with all the ports open, as you typically find in a Unix system, because we as Apple can make it very easy to turn them on when we need to. We don't support legacy technologies like Telnet or RSH for incoming requests.

We only support SSH for our secure shell remote access. We have software update technology that's built into the system, that's fully automated, that's well supported by Apple for very rapid turnaround and automatic updating. You don't have to rely on the local administrator to be sure to find and download things. in most cases, an end user will automatically get the update and automatically have that hole fixed before it becomes a major issue.

So a lot of work we're doing to try and change the policies and the way that users manage their system. Thank you. We're also investing heavily in industrial strength encryption technology. If you were at the previous session, you heard about the common data security architecture, an open group standard implemented from the ground up in Mac OS X, also available as open source for anyone else to leverage.

We support the newest security architectures, the AES 128 encryption, the federal government security standard. And we can use that for volumes and folders, as well as for storing things like the keychain. And in addition, we also work with some interesting things because we control the hardware, the software, and the operating system. So, for example, we put locks on our cases because we know that it's easy to open them up. We want to make it easy for people to get into them. We also want to make it hard for the wrong people to get into them, so it's designed to be lockable. Our firmware supports firmware passwords, which make it difficult for people to be able to change the booting into an insecure mode. Things like that that we try and do to make sure the system is as foolproof as possible, at least under common usage scenarios. Obviously, no system is totally secure, given enough time and resources, but we try to solve the problems that we know about. More importantly, we try to solve the common problems that usually cause problems for people, so they're not problems for you.

And finally below that we have the kernel, which provides the flexibility of a Mach 3 infrastructure, which has great portability, with the compatibility of BSD 4.4. One of the questions we get a lot is why did you choose a BSD foundation? And it wasn't just to hire Jordan Hubbard, although that was a nice benefit.

It was because we found BSD more compatible with our view of how we wanted to do things. Apple's a corporate company. We sell commercial software. We need to have a well-maintained, trustworthy code base that we can draw upon. And we found that the BSD development model and the licensing terms and really the culture of their community fit very well with that view of having a single repository that we can maintain and manage well. And it gives us great compatibility with what people expected from a Unix environment.

However, the BST technology didn't really do the sort of flexibility we needed for fine-grained process control, for symmetric multiprocessing, for P-thread supported at the kernel layer, things like that. And so we chose to go with an OSF-MK version of Mach 3. The Mach 3 technology had been used previously at Apple for other research projects, has a long history of research in academia as well as in industry. And by adopting a hybrid Mach kernel with the BSD4/4 kernel, it gives us a much richer set of services than we would get with straight BSD, but still all the compatibility we'd want from a BSD environment.

It has its own trade-offs, but on the whole it's been very useful for us in getting to where we are by today with very great threading support, as well as a great Unix environment. For those of you who are operating system researchers out there, Mach is technically a microkernel architecture. However, we are not using it as a microkernel. We're welding the Mach and BSD pieces together as a single process to avoid most of the performance implications of traditional Mach 3 implementations. We didn't just stop there, though. We took this technology and enhanced it with Apple innovation. In particular, really great support for modern devices, modern hardware, and modern applications.

So that means things like plug-and-play drivers for FireWire and USB, very responsive multimedia systems, where you can get very guaranteed latency when you're supporting things like putting back DVD video, the instant sleep wake that most of you have seen on our PowerBooks, and the seamless mobility, which is being enhanced with things like Rendezvous. A lot of this is based on our I-O Kit technology, a very powerful object-oriented infrastructure, which almost guarantees the drivers you create will work well in an SMP and real-time preemptible environment. So a lot of things you have to worry about in terms of finding the right kinds of drivers that support the right kind of applications are not issues in Mac OS X, because we ensure that through our frameworks and technology.

And of course, as you probably all know by now, all the stuff that's in the Darwin layer is pretty much open source. We have a live open source development model hosted both at Apple and more recently at opendarwin.org. We have over 100,000 people who've downloaded pieces of the source code from Apple, taking advantage of our open source projects. And one of the big benefits we get are security and trust due to peer review. Our security architecture, our kernel APIs, people can go through these things and determine for themselves if they have security concerns with it. They're not reliant on a small group of experts closed room. It also gives us access to a much broader community of people to find and fix bugs. So we're very excited for how people are working with us to enhance the performance and security of Darwin, as well as people who enjoy hacking on it for their own sake.

At this point, I want to give you a few of the common gotchas of the people moving to Mac OS X through the Darwin Layer experience coming from the Unix environment. The biggest issues I hear about are HFS+ and case sensitivity, the fact that it's almost but not quite POSIX, what happened to their etc. configuration files, dealing with things like frameworks, and how we handle preferences.

So, first point here is HFS versus POSIX. Now, the biggest issue that people notice when they deal with the HFS+ file system is HFS+ is case sensitive. Now, this doesn't mean that Mac OS X as a whole is case sensitive. Mac OS X supports multiple file systems. Some of them are case sensitive and some of them are not. - Insensitive. - Case insensitive. Sorry.

Thank you for the peanut gallery up here. Yeah, this is the case insensitivity in H+ versus the case sensitivity you expect-- I'm getting all confused myself now. Okay. You can't have case duplicates in the same folder, right? So if you have a file that says makefile and another that says makefile, capital M and lowercase m, they will collide.

And that can cause problems if you're used to experiencing that. People have been running this on all sorts of other operating systems. We made a choice that this is a better user experience. You can run on UFS volumes if you need to, but something to be aware of when you're working on Mac OS X. We do get some benefits from HFS+. Very fast searches for filenames based on B-tree searches. A couple things to be aware of. Softlinks and hardlinks are emulated slightly differently on Mac OS X and HFS+. Than they would be on a traditional Unix file systems. A softlink, an alias in the HFS plus world, it can be thought of for a Unix person as a softlink backed up by an inode reference. And so that if the name changes, it'll sort of figure out where the file is. A soft link on HFS+ is limited as a special form of an alias, which behaves pretty much identical to a soft link on a UFS volume. Hard links, however, have a slightly different implementation, where they basically have to create a dual alias pointing to a third file. It does work. It provides more or less the same semantics you expect of hard links, but the performance and some of the other side effects aren't quite the same as you might expect. So if you have something that relies on soft link and hard links, It should mostly work, but you may need to be careful about it because it's not exactly the same implementation behind the scenes. Another thing that's true about HFS+, is it supports resource forks. Resource forks were very useful in the old days when HFS, the original file system, didn't support small files very well. Because of that, people put information in resource forks. We consider that a legacy technology.

We don't want people to be using that going forward, but it's still there in HFS+, for people who need to use it. Many older Macintosh applications, even some of the newer ones, rely on resource forks for storing metadata about their application or even data about their application. There's an API at the Carbon layer which supports it, but we don't support it directly at the lower level, although there are ways to access resource forks from the POSIX APIs if you really need to. Again, something to be aware of, for example, when you're working with Unix utilities, CP, when you copy a file, will copy over just the data fork, not the resource fork. There's some work going on in the U.S. community on resource forks management. Maybe that'll change the way these programs are done in the future, but that's where we're at today.

Another thing about HFS+, it has file system metadata, particular type and creator code. We respect type code. We recommend people not use creator code unless they're trying to hard code. We recommend that application developers not write the creator code. We think that should be a user choice if they want to use creator metadata in their documents for them to open with a specific application. But in general, we support file name extensions as the best cross-platform way to associate type information with a document. But you will often see applications on the Macintosh which do not have or at least do not show an extension. That's something to be aware of.

The fact that we're mostly POSIX. We really try our best to implement the POSIX API set, working off the single unit specification version 3 and the antecedent documents. As we've been working to sync with FreeBSD, we've been improving our POSIX support. There's some thread signaling issues that we're addressing in Jaguar to improve per-thread signaling.

Our perspective on POSIX compliance is that if you need it, because you have an application that actually uses it, and it's missing, it is a bug. It's a fair bug. File it, and we'll talk about it. We're not going to try and fix every possible POSIX compliance bug. It's a lot of work for relatively little benefit in this day and age. But we want to work with you. If there's some functionality that you really wish was there, it's all in open source there. We're happy to work with you and see. People have done open source libraries, and we've looked at that, and it's often inspired future work of our own. Sometimes we adopt it. We want to work with you on it, and we think we're pretty good, but we know there's a few corner cases, and we want to keep talking with you about those to see if we can do better.

Manage configuration data. As most of you know, in Mac OS 10.1 today, we don't use any of the slash etc. files, the typical way you manage configuration data for a Unix system. We use a database called NetInfo. That's currently what we use as the primary data store. Moving forward for Jaguar, we're moving to something called Open Directory. Open Directory allows us to have a much more flexible and open architecture for managing all this configuration information. What we're going to try and do is move away from the NetInfo-centric view we have today something that's more built around the LDAP protocol, which includes the ability to do flat file support, currently read-only in Jaguar, but that's usually the most common way that people want to do it. They want to be able to hand-edit their configuration files and have it just work in adding users and so forth to Mac OS X, and with Jaguar, we expect that to be a fully supported option. So you don't need to, you know, use NetInfo if you don't want to. You can just edit configuration files and have them work as you would expect on a traditional Unix system.

Feel free to applaud. I know a few people have been yelling me about that for quite some time. We are working to improve our NIS support. We don't have any plans for formal NIS support, Sun's network information system. We are working with some open source developers to see about ways to plug that in directory services going forward. We still want to support the idea of a local database rather than flat files, although we do use it and allow it. We think there's benefits of having a database structure. It will continue to support that as a way, but not the only way for supporting user configuration information.

Until then, if you need to access NetInfo data from the command line, there are tools like NILoad, NIDump, NICL, the NetInfo command line, which can be very useful for you if you're in a command line environment and you need to access NetInfo functionality. the Another thing that often throws people is the idea of frameworks. A framework can be considered a shared library plus a header.

And this is very important for us because it hides implement details from developers. So, for example, the system framework, which where most of the Unix-related stuff exists, contains all the standard Unix libraries that you tend to have a lot of dash Ls on your command line for if you're doing standard Unix development. So the CRUN time, math libraries, curses, things like this are all part of the system framework. We even include a few aliases so that if you have dash LM, it doesn't complain that it's not there. It just knows that it's really just linking in the system framework. So usually you never need to think about it because the system framework is linked by default for most command line applications. But occasionally you'll find something that isn't where you expect it to be and you need to dig around and it's in the system framework.

Preferences. The typical Unix way of handling preferences is to have dot files in your home directory, which is fine, and if that's what you're writing a Unix application, it should continue to do that. However, Macintosh users expect application defaults to be in a special directory called library_preferences. This is important for a couple of things. One, it's a user-visible place where people can go there and manage it in various ways. But more importantly, it's part of a search path. There's the home directory's library_preferences.

There's a local library and slash library. There's a network library, which can be under slash network, and a system library under slash system library. And what this allows us to do is have defaults that scale across multiple domains. So, for example, I, as an administrator, can set the default browser for my site for all my users, either by setting it when the user is created, or setting it at a network or a local library layer.

So it allows people to override those defaults if they want to in their local, but still have the concept of a global default value set at the local network or Apple system level. Very important for creating a very flexible way for specifying user preferences. The file format is also formalized around an XML DTD, known as a property list, which makes it easy for you to edit alternate tools, right? So you can go in by hand and edit a configuration file. I can't count the number of times where I had a Mac OS 9 application where the preferences file was screwed up and I had no idea what was going on. Now with Mac OS X, I can go in at the command line, fire up Emacs, you know, go through the XML and say, okay, this is what's screwing me up, and just delete it and get rid of it and move on with my life.

So that's what's happening at the Darwin layer, and that's probably what a lot of people think of as the Unix nature of Mac OS X. What I wanted to do fairly quickly, since most of you have probably seen this before, go over some of the higher-level technologies in Mac OS X and our philosophy behind them and what are the benefits they bring to a Unix user. Thank you.

So in the graphics layer, there's three key technologies. The first of them is Quartz, our 2D graphics engine. Bottom line, it works with PDF. It handles pretty much all your fonts, takes care of printing and color correction, all sorts of wonderful things. The big thing from my perspective is that it makes PDF a first-class data type. Pretty much every application can both render and generate PDF. If you're like me, you really hate it when people send you Word documents because you don't always have a copy of Microsoft Office, certainly not a legal copy of Microsoft Office, on every machine that you work on. And so by having PDF documents set around, you can have legit readers and send read-only copies to people which they can view even if they're running on Linux or FreeBSD or something where they're not really able to run Office.

OpenGL is the industry center for 3D rendering. A lot of great applications written using OpenGL, both the game space and the scientific visualization space. Apple's really taking a leadership role in OpenGL. We're on the architecture review board. Because we control the hardware and the software, there's a small number of card vendors we work very closely with, we're really ensuring that we're having a great customer experience and great performance with our OpenGL applications.

And of course, QuickTime. I'm sure you've been hearing a lot about how QuickTime is driving the evolution of MPEG-4, the new standard for streaming multimedia. QuickTime provides a very rich set of APIs. There's really nothing like it on any other platform. It provides things for managing sound and images and music and all sorts of wonderful, rich multimedia data types. And again, all being moved towards using open standard, open source protocols in many cases. and it's also very widely used on both Macintosh and Windows.

And then the quartz compositor, of course, leading now to quartz extreme, but a very powerful technology for integrating 2D, 3D, and video in a seamless way, allowing very rich effects, allowing a very nice user experience that preserves what I like to call the illusion of reality. You're working with these windows. They feel like tangible objects. They don't tear. They don't disappear. They don't go all outlining on you when you try to resize them.

They feel real. And that's part of the illusion we're trying to create to help you work at a higher level of abstraction and not be distracted. Some of you like looking at bits being redrawn on the screen, so maybe it's not as big for you. But we want to try and preserve that for our graphics customers who want to be able to live in a much richer world.

One of the questions that comes up in this context is X11 as a windowing system in a graphics technology. X11 is not part of the system. You know, we made a decision very early on that X11 did not provide the sort of font and rendering support we wanted for our system. But we wanted to make sure it was available to our community. So we worked with a number of third parties, people like 10 and InterSystems, Powerline USA, and of course the X46 project which does a free open source version to make sure that they have good versions for Mac OS X. We work with them as much as we can and to help them provide X11-based solutions for our customers, and let us focus our engineering resources on those things that only we can do, trying to drive Quartz to the next level, trying to create a very rich user environment. We do highly recommend where you have the choice to use Aqua compliant native GUIs instead. If you have a third-party application which is running on multiple platforms and you have to use X11, that's fine. A lot of applications are coming into the platform because of it. We embrace those applications. We're not gonna be showing them as often in keynotes because they don't look as nice, but we're still glad to have them on the platform. If you have a choice, you can use Quartz directly for some graphical implementations. You can use GlotDiffusing OpenGL. There's TKAqua, which can work with Tcl, Perl, and Python, and Trolltex ported the QT toolkit. So wherever you can, we try to encourage you to work at the highest level possible to get the best user experience, the most leverage of native Apple technologies. But if you need to go down to the metal and use legacy technologies, we want you to have that option.

Frameworks. Taking this technology and bundling it up in ways that people have a consistent, coherent environment creates a much more productive and consistent platform for developers. That's why we have a developer conference like this, because there are people who are Cocoa developers who have a very rich set of frameworks. They expect to be there. They know where it comes from. They know who the developers are. So you go to one place and get your problem solved and be assured that all your customers will have it on their system.

Our goal is to really make sure that you can come onto the Mac platform from wherever you are, whether you're a Mac developer, a Unix, Linux, or BSD developer, or a Java developer, or creating a whole new application from scratch or learning to program, we want you to be able to succeed on Mac OS X. We're on some history here for those of you who may not be familiar with it. The legacy environment on Mac OS X is known as Classic. Classic is actually based on older technology came over from Unix.

called the Mac Application Environment. This was used back in the 90s for people to run Mac applications on their Sun workstations, for example. It was really a virtual machine for Unix. We took that, sliced off the bottom half of that, and created something called the Blue Box, which was used in the Rhapsody and the Mac OS X 1.0 products. This allowed you to have Mac applications on one screen and then your native applications on another screen, and you'd swap between the two, kind of like a virtual workspace in the Linux world. and it worked fine for its role there, but we want to have a better experience for legacy applications. So classic applications are those that are written to the Mac OS 9 APIs. They make certain assumptions about being able to own the entire machine, and we want them to be able to do that so they can run. We don't want them to try and take over the machine because we've got a Unix kernel underneath.

So we created this idea of a classic environment which can run Mac OS 9 applications more or less seamlessly with Mac OS X, but you don't usually need to think about it. It's also important that you can have this either as a separate disk image or as another volume on the same partition. In many cases, it should be more or less invisible that you're running a classic application.

We hope that you don't need to do this very often, but often you will have an application which is not being updated at all. The developer or the company is no longer in that business, and we want you to be able to access and run those applications if you need to. However, we don't really want you to be running these things and certainly not writing any of these things. We'd rather have you work on something called Carbon. Carbon is a way to optimize existing Mac OS 9 applications to take advantage of Mac OS X. Example here of Mathematica, a great example of a Carbon application for Mac OS X. And Carbon is the easiest way to bring your existing Mac applications. Basically, it's the way that things like Office came. They took their Mac OS 9 application, they modernized it, removed a few legacy APIs, adopted a big data types, adopted API that was sure to be reentrant so you could have multiple processes running on the same system. And then they now have the option of being able to run applications on both Mac OS 9 and Mac OS X. Obviously, we want developers to be focusing on Mac OS X because that's where the money is, as well as where our efforts are. But people who need to deliver applications onto legacy systems, there is a CarbonLib that allows them to do that.

And this is what's been used by major ISVs to get to Mac OS X. Office, for example, Mathematica did a great job of taking their Unix backend, which was their strongest backend, and their Mac front end, which was their best-looking front end, and combining them into a single application that ran on Mac OS X. And taking advantage then of Mac OS X technologies like anti-aliasing to deliver an even superior customer experience than they ever had before. support.

Of course, one of the things we're focusing a lot on these days is Cocoa, which is really the easiest way to create fully native, Aqua-compliant Mac OS X applications. You can also do all that in Carbon, but it's more work. And for those of us who are lazy like me, we like the idea of Cocoa. And Cocoa provides a very rich suite of pre-built widgets, makes it very easy to create Aqua-compliant front ends, has a very robust object-oriented architecture. One of the great things about Cocoa is it's often very easy to integrate C or C++ back-ends, or even command line utilities, into rich applications. And in the next session, you'll be seeing some examples of doing that. It also takes full advantage of all the Mac OS X tools and provides a great alternative to traditional Unix interfaces. This is an example we showed at Macworld in January. We're running around saying, you know, we need to have a great demo showing how easy it is to bring Unix code over to Mac OS X. who really wanted to stress the Unix nature of Mac OS X this year. So we called up one of our friends at TweakWaves, an animation studio known for The Perfect Storm, and there's a guy there who was like Mr. Waves. This guy's life is creating waves. He has this piece of very sophisticated custom software that generates these wonderful wave algorithms that are used in movies. And this is what it looked like before there was Cocoa. This is what his environment was, sitting in front of a nice gray pudding-like simulation of waves on a high-powered SGI workstation. And we said, you know, we only got two weeks. Can you get us something ready for Mac OS January? He goes, "Well, I don't know, but I'll give it a try." So he got a copy of Mac OS X, brought it over. It took a few days. He goes, "Wow, this is great. "I have a whole week left before the demo. "What else can I do?" He said, "Well, why don't I try and make-- "take advantage of it to do new things "I could never do before?" So he added texture mapping using QuickTime. He added dynamic user interface controls. He drew a background using Maya. And now it went from looking like that to looking like this. And this is a sort of productivity enhancement. Yes, technically, you could have done this on a Unix system with X11 and Qt, but you never would have because it was too much work.

With Mac OS X, I honestly believe this as a long-time Unix hacker, it's as easy to create a good-looking GUI as it is to create a traditional command line interface for your application. So do so. It gives you much wider visibility. It makes it easier for you to remember how to use it when you come back to it three months later. And it gives something that's a much better user experience. And we think using Cocoa technology is a great way to really spice up your existing Unix applications.

One thing that people often ask about with regard to Cocoa is Objective-C. Objective-C is the native language used for Cocoa. It was invented by Brad Cox, one of the great innovators in our field. Used in Next Step, which is where we inherited from. The basic idea of Cocoa was that every object invocation, everything inside those funny brackets, is a function called Objective-C message send, which basically goes through a class information to do lookups to methods. It's actually not that much rocket science. The runtime is all there in Open Source. Nothing to be afraid of.

It's actually more dynamic than what you typically find in C++, but in some ways it's also simpler. Objective-C tends to take advantage of weak typing, although you can also use strong typing. In particular, Objective-C, very much like Java, has single inheritance of implementations. You get multiple types of interfaces. We call them protocols. Java calls them interfaces. C++ you can consider it a pure abstract class.

But a lot of the concepts you find in Java are actually borrowed from. James Gobsling was here yesterday, and he actually admitted that some of the ideas, like protocols, were ripped off directly from Objective-C when they invented Java. So if you understand Java, you can probably understand a lot of the concepts of Objective-C, but unlike Java, it is all native code, has seamless integration with C and C++, and we think it's very useful for the types of desktop applications that Cocoa is designed for. So we encourage you to check it out, and there's lots of sessions on that, and it's actually not that big of a deal. Once you get used to seeing brackets in places, it's actually a very rapid way to just spice up your existing C code with some nice graphical front ends. Of course, Cocoa is also accessible from Java if you prefer a Java programming environment.

And of course, if you just want to write straight Java cross-platform applications, we do a really great job of supporting Java on the desktop. At Java 1, Asan and lots of other people really acknowledge how we're really taking the initiative in driving Java forward on the desktop. We made sure that every copy of Mac OS X we ship includes a fully compliant version of Java 2, not just compliant, but also using the latest client VM based on hotpot technology for best performance. We've worked on adding a very native look and feel. In many cases, it's very difficult to tell whether an application is a native Cocoa application or a Java swing application.

We've done some interesting innovations, basically the idea of shared libraries for Java, which reduce the memory footprint and decrease startup time. Some other enhancements like 2D acceleration, taking advantage of hardware, and working very closely with our third-party partners to make sure we have a wide range of tools and utilities that you'd expect for Java running on Mac OS X. So if you're doing Java development, we really see the Mac OS X, because of its Unix affinity and its great support for Java, it's really the best place to be running Java on the desktop.

And of course, last but not least, on top of all this, we have this idea of Aqua. Of course, the Aqua user interface that you've seen many times. A few comments about Aqua from a Unix perspective. A lot of people... Aqua, in some sense, is sort of a state of mind, right? It's not just a single technology or a single idea. It covers a wide range of different layers.

In Unix, you'd have a toolkit, you'd have a window manager, you'd have themes, you may have several desktop applications. We consider all of that Aqua. It's sort of the gestalt user experience of Mac OS X. And there's also a philosophy about it. One of the big things about Mac OS X is we really insist that all normal usage should be accessible via the GUI. Everything we consider a feature that we want a customer to be able to do-- is Jordan running because I'm saying that? No. Some of the engineers coming from a Unix background are scared at the idea of having to create a GUI for all their services. I'm sure that's not why Jordan is leaving. Coffee. But one of the things that we really try and discipline ourselves at Apple is to say it's not a feature until it has a GUI. One of the problems when you're running on a typical Unix environment is you say, "Well, I can do the same thing on the command line. It's too much effort. I'm not going to bother to do that last little bit and make it fully accessible." Because we are a company where we pay our engineers and we have standards, we're able to enforce that, which guarantees that the full experience in using the system can be accessible from the GUI. And we think that gives us a much more complete and comprehensive system that you're likely to see out of non-commercial efforts. There are some services that are provided as part of Aqua, like the Finder, the Desktop, the Dock, the top-level Menu Bar. There's also widgets, the idea of sheets, the Taskbar that you see on a lot of applications like Mail, Drawers. A lot of these things are things that you may not be familiar with coming from a Unix background. We encourage you to play with these things. Interface Builder, particularly Cocoa, make it very easy to add these to your application. Start thinking creatively about ways to design your application. We'll be having the Open Source Design Awards tomorrow night and we have a category just for open source ports. People have taken existing software and made it look and feel like a native Mac OS X application, trying to recognize the work they're doing to try and go beyond what's traditionally been possible in that community. There is a philosophical issue that's probably worth mentioning that sometimes strikes people a little ajar when they deal with Mac OS X. Mac OS X, we try to think about things being customizable for the user environment, but not replaceable. In the Unix world, everything is usually expected to be replaceable. You can replace the Windows system, the Window Manager, themes, all sorts of different things and drop and plug in and often write your own versions of different things. While that's really a lot of fun for developers, it tends to be a nightmare for end users who don't know what system the thing was developed to run in. And it's often quite a challenge for system administrators, documentation writers, and things like that. So because of the Macintosh philosophy, it's trying to have at least one clear, coherent way with some variations around it, but still a very well-defined, consistent user experience. So I would encourage you, if you're trying to create a mass market Mac OS X application, that you really sort of buy into that mindset and try to make things as consistent and coherent as possible. There is certainly room for experimentation. You can actually, because it is all based on Unix technology, plug in and replace various pieces of it and write your own finder. And that's really good for a research project, but we don't think that's going to be a normal customer scenario. So when you create applications, try to leverage the higher level toolkits and conform to the standards as best as you can.

In order to help you do that, we provide a rich suite of developer tools, which themselves are great examples of powerful software built on top of open source technology. There's all the command line tools you expect from a Unix environment, based on standard technology, pretty much all available is open source.

We have a rich suite of visual tools, really trying to do professional quality development. We faced a choice when we did Mac OS X. All the Unix developers were asking for developer tools. We could have just given them the command line open source tools and charged for the developer tools at the GUI level.

We made a conscious decision not to because we really want our open source developers, people who are used to using GCC and things like that, to create great, rich, you know, GUI, Aqua quality applications. And we actually believe that they can. I mean, a lot of people think that Unix people can't create good-looking applications because of what they've seen. But I think a lot of it is that they haven't been given the right set of tools, they haven't been given the right set of inspiration to which to work from. And we really want to see some really gorgeous, you know, best-of-breed applications created using open-source GUI technologies, open-source technologies using GUIs on Mac OS X. There's a whole bunch of these. There's all sorts of courses on them. The real reason for this list is to show you there's a bunch of different apps for all sorts of things. And, you know, get in there, play around with them, read the documentation, realize that this is really a very useful way of doing a lot of things. And most of them provide support even for command line applications if you need to do things like that.

A couple of things that come up in this space is the object file format issues. A lot of people in the open source Unix world are used to a binary format called ELF. We, from Mac OS X, use a functionality called Maco. They were developed at roughly the same time in slightly parallel locations.

They're more or less functionally equivalent. There's not anything that I'm aware of that you really can't do in one that you can do in the other. But Mac OS X is really tuned for development of Maco. The Maco file format is what we use for all of our tools, all of our performance work, all of our optimization work. And we encourage you to use Maco and get used to it in Mac OS X. The names of some tools are slightly different than their analogs in the ELF world, but it's usually not too hard to figure out what those are. You will often hear people talk about something called CFM, which the CFM or PEF was the way that dynamic libraries and loadable modules and binary files were handled in the Mac OS 9 world. It is supported on Mac OS X as a legacy technology, but some of you may have heard that that's not really our goal moving forward. We want people to be delivering all their applications, Mac OS X native, which means MacO. Occasionally people will ask, you know, "Is a Carbon application native, or is it only Cocoa applications that are native?" And the real answer is anything that is MacO is native on Mac OS X. And Cocoa is always MacO. Carbon may be MacO or may be CFM based on how it was built. And so there's different issues that people have to worry about when they deal with that. But hopefully you coming from more or less a clean slate and a Unix background will be writing directly to Mako and able to take advantage of the Cocoa libraries for your GUI.

As part of that is our dynamic library support based on a technology called DYLD versus the more traditional DLOpen you find on most Unix systems. They're sort of similar, but not quite. In many cases, you'll have to either create a wrapper. There is a DL-compat library that's available as open source. The open office people use it, which gives you more or less equivalent functionality. Or you can just use an ifdef. It's usually not a big deal. But in particular, I think the one specific area where there's a semantic mismatch is in the next symbol field. So if you have a DL, dynamic load library, which expects to iterate through symbols in a linear fashion, that may cause some challenges and some other issues that you face when going to Mac OS X. So there's a few things to be wary of when you go to Mac OS X. If you use some exotic thread signaling issues or you do a lot of dynamic library stuff, you may not have a perfectly trivial port. On the other hand, it is still a straightforward port, and it's something that we definitely encourage you to do. Thank you.

Of course, you've probably seen by now all the different developer tools, Project Builder, which can be used as a great front end on top of GDB and GCC, as well as Java and other languages. We think it's a good way to... The big thing about Project Builder that's important, a couple of things. One is it abstracts you away from having to worry about where things are on the command line and which libraries to link against. But the real important thing is that it creates the packaging format for Mac OS X. Mac OS X creates all these application bundles, which have a very well-defined way of leading out resources, and images and things like that. So if you want to create a Mac OS X application, you want to use Project Builder. You can still use it from the command line when you want to actually do your builds, which can be very useful for a number of scenarios. But the GUI makes it a lot easier to create a fully Mac OS X-compliant application. Interface Builder, learn to love Interface Builder. It's a fantastic way to create great AQA-compliant interfaces. If you're using Cocoa, you can do a lot of the hard work of your application structure by wiring up objects inside Interface Builder. And of course, the more recent addition to the family is AppleScript Studio, which from my perspective is a way of combining Cocoa Interface Builder and Project Builder with the AppleScript language.

The AppleScript language was developed out of HyperScript and HyperTalk and HyperCard and all that family of developments for rapid development and prototyping. It's a very different philosophical beast than a Unix scripting language. A Unix scripting language is usually coming out of a programming mentality, trying to find an easier, faster way to do programming-type tasks in rapid iteration. The AppleScript language was designed explicitly for end users to try to find a natural English language way certain tasks. And you can tell this by sort of the average word length of a Unix command versus an AppleScript command, right? Something that'll be about 25 words for an AppleScript thing will be about 25 characters in a Unix scripting language. The other way I think about the difference between the two is that AppleScript is designed for working with applications. It's and large data objects, images, and things like that. Whereas the Unix command line is really optimized for dealing with text. And because of that, they have different semantic constructs different applicable usage scenarios. One of the more interesting things, I went to the Web Services Framework session before lunch, and the person wrote a nice AppleScript application, and he called down to a Unix command line to format the date for him, 'cause the Unix has all these really rich formatting and text handling capabilities built into the command line, and so he just calls down to that, gets a string, and then passes it off to do, you know, more sophisticated AppleScript kinds of things. AppleScript was really great. One, it allows you to tap into the Aqua widgets in the Cocoa frameworks, as well as calling down to Unix scripts. And more importantly, it has a very powerful remote technology called Apple Events. It allows you to send messages to other applications. Most Mac OS X applications, certainly all the good ones, have a dictionary which allows them to be Apple scriptable. This creates a language that you can execute commands against that are understood by all the different Mac OS X applications. It's really great for application control and network workflows. Chances are the newspaper you purchased, if you bought a newspaper in the last week, had some portion of it that was automated by AppleScript running on the production side, whether it's laying out TV guides or formatting weather maps or things like that, because it's very great for automating repetitive tasks involving GUI applications. One of the exciting things about Apple Events is it all supports web services, and as you've been hearing a lot, there's a lot of rich technologies in Mac OS X for supporting web services, and they're particularly easy to do at a high level from AppleScript, because it's built around this whole idea of doing high-level messaging between applications. It is even possible to call AppleScript from the command line.

There's a command called osascript, which can evoke any OpenScript architecture, OSA-compliant scripting language, in this case, AppleScript. It is possible to create OSA versions of Perl and other languages. If you're interested in working on an OSA plug-in for other languages, please talk to me. We'd love to get you hooked up with the engineering teams. and enable other languages to tap into the functionality. We're not bigots in the scripting language space. We like having lots of scripting languages on the platform. AppleScript is our language. We put the most resources on it. We'd love to help you take your favorite languages, whatever they are, and plug into the power of Mac OS X.

We also support a wide range of third-party tools, whether you're doing Java programming or BASIC or C++ programming. There's often a tool available from a third party which is more suited to your particular application space. We try to have as many tools as we can running in Mac OS X. This is JBuilder from Borland. A lot of people feel that it looks much better than JBuilder ever did on any other platform, but it's still the same pure Java binary, tools like Real Basic, Metrowerks Code Warrior, and all sorts of great open-source tools appearing all the time on Mac OS X. So we really want to make sure that you can have the best environment possible with whatever tools you're comfortable with. One of the tools that I personally think is one of the best things available on Mac OS X is WebObjects 5.1, which is a very powerful development environment as well as deployment environment for creating three-tier web applications, whether they're talking to HTML or Java interfaces. It does a lot of the hard work of database mapping, page layout, and lets you have a nice, rich experience for designing user interfaces. It can work with either standard Java runtimes or on top of other J2E app servers. If you're doing Java development, if you're doing web-based development, we really encourage you to check out WebObjects. We support the traditional open-source stuff, Tomcat and PHP and stuff like that, which is often great for certain projects. But if you're creating very complex, scalable, three-tier web solutions, we really encourage you to check out WebObjects as well, which is also a cross-platform Java application.

Documentation has been a hot issue for a lot of people for a lot of time. We've been making a major push on Darwin documentation. There's a number of different kinds of documentation available. We have all these demand pages, which are viewable from Project Builder or from the shell. There's a lot of parts of inside Mac OS X kernel programming which will be of interest to Darwin developers. There's the new Bringing Unix Applications to Mac OS X Guide, a preliminary draft of which was posted this week. We encourage you to look at it and send your feedback. And of course, the URL will be on the URL farm. But it's really fairly easy to find from the Mac OS X documentation page or from the Darwin page itself. There's some specific tools documentation that Unix developers might find particularly interesting. Particularly all the stuff about our compiler, our assembler, the preprocessor, which is different than the traditional preprocessing in many Unix systems. And also some of the quirks and intricacies of the Maco runtime architecture.

So in summary, I really want to hopefully give you a feel for what we're doing with Mac OS X from a Unix perspective. We really think this is the dream machine that everyone who's been running Unix will want to have. Something that looks like a PowerBook G4 that can run mainstream Unix, has a Mac interface, Microsoft Office, standard Java 2, free tools to go. And we really hope that you'll go with it. Thank you very much.

A few thoughts I wanted to share with you about possible sessions that you as Unix users might find particularly interesting. Of course, anything in the 100 series, part of the Darwin track, obviously of interest to a lot of people. A few things that you might want to look at. One is that after this, obviously there's a porting Unix to Mac OS X session right after this that I think a lot of you would really like to stay for. If you're more of a Java developer, it's not really a porting issue because your code just runs on Mac OS X, hopefully, but you may want to customize it, and there's a great session on that. Tim O'Reilly, who I'm sure many of you have heard of, will be here, a big friend of ours. Feel free to clap for Tim. He's a great guy. We're very excited to have him here. He did a lot of stuff helping bring us here to the conference. Check him out for lunch on Wednesday. AppleScript Studio, if you're doing script-based development of any kind, I think you'll really enjoy seeing what you can do with AppleScript Studio. Project Builder, the IDE, has a lot of great functionality, great plug-in functionality for working with CVS, If you're talking to the Unix command line for legacy Makefile projects, definitely worth going to. Cocoa API techniques, trying to get some of the zen of what it means to develop in Cocoa. People who've been playing around with it want to try and understand it better. A great chance. Using Interface Builder, again, a great companion piece if you want to try and start tackling GUIs. I have a friend who works at Apple who's a, you know, graphics confuse me. Don't talk to me about GUIs. You know, you don't have to be afraid of the GUI anymore. It's okay now. Directory services, the fantastic work we're doing with Open Directory. I encourage you to check that out if you worry about network integration issues. And then, of course, what should be a really fun session is compiler developments at Apple. The great Stan Schebs has been doing some wonderful stuff with the compiler team here, working with the GNU community, and we look forward to seeing some of the updates on that. So at that point, I'd like to bring up the Q&A panel. We have Jordan Hubbard, I think Terry, and Bodhi may be here from the documentation team. And we'd like to start taking your questions. There are mics in the room. Thank you very much for your time. And I'd like to hear some questions. Thank you. Jason from Developer Relations will be coordinating that for us.

Oops, oh, last thing I forgot, there is one more slide about more information from the developer page. Also, the Mac OS X downloads page has a great source of open source applications like X11 and hopefully soon OpenOffice. And some great mailing lists. There's a Unix porting mailing list we've set up for discussions of issues you face, either bringing stuff over to the Darwin layer or adding GUI stuff on top of Unix applications. Stepwise has a great source of information, a lot of downloads and other techniques. And then the Slash.site has a new Apple section in the last month which has some great news.