You know, you might want your Safari for web browsing, you're iTunes, or maybe you want

your web services application. You know, on the server side. And the problem is, until

today, outside of the web, all of your applications are tied physically to an OS. You know, by

APIs, ABI's, other things. You know, it's not true for the web of course. And you're

OS, until today has been tied to your hardware. So, Windows runs on Intel machine from Dell,

Compaq, whatever. Mac runs on the shiny silver laptops that we see peeking out here and there.

How--one, to three, okay. I think we've met quorum of laptops--of Mac laptops. This is,

you know, quickly becoming--yes, thank you. The mating--the mating call of the Macbook

pro. It's quickly becoming a way of the past in virtualization, and Google are, as well,

are trying to break these chains. And that's kind of the point of my talk here, is virtualizations

frees your apps from silicon chains. Before, you know, you wanted to run your favorite

Windows app, you know, heaven forbid Outlook or IE when you happen to do some web testing.

You had to have a physical install of Windows that was tied to that box. The aim of VMware

and Google is to just break that chain. Wherever you are, you apps go with you. From Google's

point of view, it's basically your apps are hosted for you. You go use your Picasa, you

go use your word editing, your presentation editor, it's all hosting for you. VMware takes

kind of an inverse look where you just take your entire computer in a little bundle, stick

it on your iPod or your single hard drive and just plug it in wherever you go. It runs

on your Mac, your pc, Windows, Linux, it doesn't matter. You've got the same platform underneath.

So, I wanted to just like, to tell you a little bit about how we got to this stage. Application

development has gone through a lot of different eras. You know, back in the 80's, application

development was really centered around source level APIs. We got the birth of [INDISTINCT]

for the first time and people were able to say "Hey, I can distribute my application

just by giving you the source code and it doesn't matter where I [INDISTINCT] running,

you can recompile it and it'll basically work more or less." You know, the good example

is Fork. You know, entire operation systems were designed around this one API. To really

know Fork, you really have to know UNIX and vice versa. To have Fork, you have to have

UNIX. And, you know, in the 90s when business computing got a lot more popular, people kind

of seized on the notion that "Okay, I've got these applications. I want the same application

to work as I upgrade my hardware. I want binary compatibility for my applications." And Microsoft

really seized on this. They made them a lot of money. But as we're finding out, you know,

in the current era, this is changing really, really fast. People don't want their application

to be tied to a physical computer or a location at all. So, in the current decade, what we're

moving more towards is a virtualized infrastructure where applications can actually go with you

anywhere. Specifically, what virtualization does is it brings the Intel--oh, I'm sorry,

VMware virtualization, brings the Intel binary layer, the ISA, to any platform anywhere.

It gives you a whole set of virtual hardware. It perfectly emulates the Intel instruction

set without people having to recompile or change a single byte of their existing programs.

So, they can take their ancients, you know, Windows 3.1 development environment and just

copy, import into a VM and bring it around and there's a shiny new Macbooks. Or, a good

example is, you know, there's all sorts of people in Japan, they run power plants off

Windows 98, and that's all that they have. There's offer runs on Windows 98 and they--you

can't even buy hardware for it. But the Intel ISA actually stays the same. So you can actually

install this, you know, you could--you could run a power plant [INDISTINCT] of your Mac

if you want to know. An important thing to know is that there's a lot of other people

who have tried and failed at this. Java really promised to provide another virtual, you know,

ISA that people could code to that would give their promise of being able to be portable

everywhere, run the same apps no matter where you go. We're pretty sure that Java's promise

to do that has failed to this point. Two main reasons, one is, they didn't really have a

stable ISA to work from. You know, the Intel ISA has been around for a long time. It's

cruddy. The current processors don't even really implement it, they just--they just

emulate it on a virtual processor inside. But with Java, you know, I've already had

to rewrite their programs, you know, nth times, once for every version of the Java virtual

machine when they broke the backwards compatibility. The VM gives you perfect backwards compatibility

at the machine instruction layer and--because it virtualizes out the restrictions of the

hardware, you don't actually need to depend on, you know, the version requirements that

Java introduced. But VMware didn't introduce this. Like VMware did not invent this notion

of virtualization and people--people have been doing this for four years now. IBM introduced

that way back when with system 360, 67, you know, we're time sharing again. You know,

we've got server loads that are completely spread out all over the place and, you know,

we're just revisiting the past. Like, everything goes in cycles. Virtualization really isn't

just about, you know, installing monster machines and partitioning though, because it gives

you an individual container that has identical hardware wherever you go, identical machine

compatibility. You can just lift it up and move it form your PC to your Mac, to your

Linux box. Or you can have a cluster of server farms, and maybe the hardware isn't exactly

identical but I'm sure anybody who's worked in IT knows you spend all your time installing

operation systems, and, you know, your applications are tied to that particular install unless

you have a really clever folks like the Google people who know how to write massively parallel

applications. I mean, most system administrators and IT organizations aren't quite up to snuff

[INDISTINCT] huge, you know, massively parallel architectures just yet. So, VM what gives

those people a way to make fault tolerance, distributed systems from another aspect, you

know. You basically take the computer out of the picture and move the [INDISTINCT] into

their own little compartment that you can take around. So, what I wanted to--what I

wanted to get at is what VMware brings the table is, specifically, x86 virtualization.

So, this wasn't really hard--this isn't really hard. A lot of people said this couldn't be

done. There's a really seminal paper by Popet and Goldberg that a lot of people latch on

to instead. You know, you can't actually virtualize the Intel ISA, it's not possible. There's

all sorts of instructions that actually mess with internals of the processor that you can't

trap. You know, several things like call and return, push up and pop off. I mean, you can't

actually trap them and emulate those at any time. So, you know, what VMware innovated

in is actually being able to rewrite this on the fly so that they are safe to virtualize

and that let's us do it on Linux, Windows, Mac, whatever. The reason I bring up the Intel

point is, for the Mac market, there was a really momentous occasion in summer of 05

when Steve Jobs got up with Intel on stage and basically said, "Okay, we were wrong all

along, [INDISTINCT] wasn't the light and it's time to actually jump ship." I know it's hard

to believe for the Mac had to--who heard all the [INDISTINCT] promises and--what was 3

gigahertz but 20065 wasn't it? Or 2004? Yeah, it never happened. They jumped on to the Intel

ISA bandwagon again, which basically says it's another platform that the Intel ISA is

supported on that can become another way to have virtual machines on. So, the engineers

at VMware really knew, you know, "this is going to be something momentous, this is really

huge." So, you know, a couple of us just started hacking around for fun and eventually came

up with what became VMware fusion. I heard that happens a lot at Google, people just

messing around to start their spare time and coming up with something that gets procuctized.

Funny, how that works. The difference on the Apple platform is Apple builds products specifically

for one purpose. Their products are meant to run Apple applications. They give you all

the APIs you need to run iTunes, iPhoto, Safari, but they're not actually going to give you

the kind of robust tools to develop a huge client server network or a massively scalable,

you know, database infrastructure. I mean, that's just not what they do. If you're coding

to make a really cool image browser or a multimedia editor, it's totally the way to go. It's really

easy. It's fast, you know, it's well understood. But if you're going out of the box, it's tough.

Of course, there's one product that people want to run on Apple apps on is that, that

is the iPhone. I wrote this slide before this morning. So, I missed this morning's announcement

of the new Apple API, but it is--it was true when I wrote the slide that the iPhone did

not run the Apple apps, but if you didn't hear this morning, Steve announced from on

high that we will get an API to run--to write our own iPhone application. That's actually

pretty exciting, even more VMware. Virtual machine on an iPhone [INDISTINCT] Intel. So

what we did in Fusion is we focused on one and use case which was totally new for VMware

which was consumers want their Macs to run PC apps. They really want to run their Outlook.

They want to run their IE for web testing. There's a million little PC apps. I use it

to update the firmer on my phone. You know, there's all these crazy little apps that require

Windows support in hardware and software and these--I don't expect Sony to go out and write

drivers from Mac for my phone. It's not very likely. But they will support and write drivers

for Windows and not use a virtual machine to flash my phone. The whole point of virtualization

is that, unlike things like boot camp, you don't have to stop all the applications you've

been using, shut everything down and reboot. Your PC apps and your Mac apps are both first

class citizens for the virtualization. So you can actually drag and drop between your

PC and your Mac. You can copy and paste text, share your files and, you know, more and more,

the lines get blurred. There's even something called unity that we worked on that completely

gets rid of the Mac desktop and you just got your Windows application just floating there

on your Mac. I'll show you guys a little bit later. It's pretty exciting. It makes you

want to jump out and go, you know, grab a Mac, like this lady. So, she's really excited

about Leopard. And--this is the new OS 10.5 that's coming out. It sent all of the Mac

developers into a usual Steve Jobs Beetle style hysteria. Lot of things are really nice

on the Mac platform, but it's not perfect. And what I wanted to tell you guys about was--some

of the lessons we've learned from developing VMware fusion and some of the internals of

how we brought the VMware fusion to the Mac. So, the Mac platform, it's a--kind of a bipolar

situation, and I kind of like to given an analogy from my favorite 60s TV show called

The Prisoner. So, The Prisoner was a 60s TV show about a super spy who came to this--he

was shipped off to this idyllic island and everything was perfect and planned for you.

There was this beautiful scenery everywhere and you could never leave the village. You

were never allowed to escape. Everyday he tried to escape and there was a new face of

the number two who ran the village. And--it's pretty similar to the Mac development world.

You know, you're kind of enticed into it by saying, "Oh, what a cool platform. We're going

to make exciting new apps for it," and then you kind of dive into the inside [INDISTINCT].

Inside, it's actually four or five different operating systems, kind of jumbled together

in different pieces. And as Apple needed different pieces to build iTunes, safari, iPhoto, iWeb,

they use each of this piece and develop them, but there's really no cohesive whole. To learn

these different pieces, you kind of got to learn through trial by fire, and I kind of

call it the Mac Club. And as the first rule of Mac club and everybody knows the first

rule of Mac club is "You don't talk about the Mac Club." So, what I mean by that is,

you know, the APIs, there's documentation, but they're not telling you what's going on

under the hood and they're not telling you about all the side effects, the scary, you

know, callbacks that are being registered for you under the hood. You know, you really

have to dig deep. With good books like "Mac OS X: Internal Assistance Approach" by Mr.

Amit Singh, you can actually start to learn some of the internals under the hood. But

seriously, before that existed, there was nothing and it was all just handed down over

the years. Very interestingly, you know, how many people here have done like Windows development,

professionally? So--I mean you've interacted with Microsoft, with MSDN. It's kind of frightening

but it's thorough, right? And if you have a problem, you can write to somebody. Apple's

equivalent is a once a year conference called WWDC. And you can sign up with WWDC, pay a

couple of thousand, and get direct access to the engineers. But other than that, you

know, there's no way to get information about the actual innards of the operating system.

You can submit support request, but they're more intended to shield the developers from

the hoards of hungry third party application vendors than anything else. So, here's some

of the real rules of the Mac club. So I wanted to share these, for anybody who's doing Mac

application development, because if I could travel back in time and give myself a couple

of tips before I started down this road and helping VMware fusion with my team, I wish

somebody would have told me. The first big rule, know and fear Carbon. Carbon is scary.

So, before OS came out, there was this huge legacy of APIs, all jumbled together based

on C and a little bit of C++ called Carbon. Carbon is intended, basically, to support

older applications, to get imported with a minimum of fuss. If you start using an OS10

though, you have to be really careful. Some of the stories that we actually learned when

we started using a little bit of Carbon, VMware fusion is basically based on our Linux application,