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 Ernest 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 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 a long time? How many of you have been using Mac OS X for a long time? 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 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 exciting 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 any dumb 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 going to 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 in a classic application? Some correspondence between what we do in Mac OS X and 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 want to 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.

So we see this is coming together not just of technologies but also of people. Obviously the Macintosh faithful, people who have 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 existing customers, as we were focusing on last year, but the best platform for UNIX users and UNIX developers.

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, quote unquote, normal platforms use all the time, but are hard to get on UNIX. You either have to emulate something or dual boot, etc. 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, talk 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 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 TEC and GIMP and PINE, and languages like Python, Ruby, which as you've heard are coming part of our system in the future.

Some of these things may become part of the system, all of these things won't. TEC 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.

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. We don't pretend to live in a Mac-only world. We're not trying to push Mac-only standards.

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

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 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 BSD technology didn't really do the sort of flexibility we needed for fine-grained process control, for symmetric multi-processing, 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 BSD 4.4 kernel, it gives us a much richer set of services and capabilities. It's a much more complex set of processes 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 implementation. 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 kinds 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 in a 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 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, the 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. Case 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. Soft links and hard links are emulated slightly differently on Mac OS X and HFS+, than they would be on a traditional Unix file system. A soft link, an alias in the HFS+ world, it can be thought of for a Unix person as a soft link 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 properly. It's 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. 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 Unix 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. So, again, we're not going to be using resource forks Another thing about HFS+ is that it has file system metadata, in 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. In general, we support file name extensions as the best cross-platform way to associate type information with a document. 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 UNIX 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.

Managing Configuration Data. As most of you know, in Mac OS 10.1 today, we don't use any of the /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 sort of 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. 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. 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 to having a database structure. We 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.

Another thing that often throws people is the idea of frameworks. A framework can be considered a shared library plus a header. This is very important for us because it hides implement details from developers. For example, the system framework, which is where most of the UNIX-related stuff exists, contains all the standard UNIX libraries that you tend to have a lot of -l's 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 -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 to 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 library. So, for example, I can set the 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.

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

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 interested in having a great customer experience and great performance with our OpenGL applications.

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, images, music, and all sorts of wonderful, rich multimedia data types. 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. 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. 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 Tenant Interest Systems, 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 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 going to 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 Glott diffusing 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 coming over from UNIX.

This is a virtual machine 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. An 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 an API that was sure to be reentrant so you could have multiple processes running on the same disk.

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 Carbon lib 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 frontend, which was their best looking frontend, 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.

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 that 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 were 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." We 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, "We've only got two weeks. Can you get us something ready for Macworld 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 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 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, Ahsan 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 that Mac OS X, because of its UNIX affinity and its great support for Java, is really the best place to be running Java on the desktop.

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. Aqua, in some sense, is sort of a state of mind. 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 and use of 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's some services that we're working on. There's some services that are provided as part of Aqua, things 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 who've 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 theme, 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. It's often quite a challenge for system administrators, documentation writers, and things like that. So because of the Macintosh philosophy, we try 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 Mac OS X application, 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 great 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'd 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, GUI, Aqua quality applications. We actually believe that they can. 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. We really want to see something like that happen. We're going to be doing some really gorgeous, 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. 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. 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. 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 analogues in the ELF world, but it's usually not too hard to figure out what those are. You'll often hear people talk about something called CFM.

CFM or PEF was the way that dynamic libraries and loadable modules and binary files were handled in the Mac OS X 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're coming from more or less a clean slate. And a Unix background will be writing directly to Maco 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 library. forward port and it's something that we definitely encourage you to do.

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. 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 are a very well-defined way of laying 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 Aqua-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 to accomplish certain tasks.

And you can tell this by sort of the average word length of a UNIX command versus an AppleScript command. 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 firmware and large data objects. It's not just about 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 and also 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.

Because 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. And then he calls it off to do more sophisticated AppleScript kinds of things. AppleScript is really great.

One, it allows you to tap into the Aqua widgets and 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 AppleScriptable.

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. 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 plugin, 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 for 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, MetroWorks 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.

The URL will be on the URL Farm. It's 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 Mac OS X 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.

Jason from Developer Relations will be coordinating that for us. 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 Slashdot site has a new Apple section in the last month which has some great news.