Speech Transcript - Jim Allchin, Microsoft Professional Developers Conference 2003
Oct. 27, 2003
A transcript of remarks made by Jim Allchin during the Microsoft Professional Developers Conference 2003, held October 27, 2003 in Los Angeles, Calif.

Transcript of Remarks by Jim Allchin, Group Vice President, Platforms
Professional Developers Conference 2003
Los Angeles, California
October 27, 2003

JIM ALLCHIN: So what do you think of "Longhorn?" Huh? (Cheers, applause.) You want to know how to do some of that stuff? That's what my talk is about. And we're going to start with this eye chart. (Laughter.) This is going to be up on http://commnet right after my talk. It's also going to be on MSDN.

Now, during the next four days you're going to have an opportunity -- talking with some of the best architects -- to drill down in all the boxes on this slide, and there's more besides what I showed here.

What I'm going to do is just focus on the four areas that Bill already mentioned. I'm going to talk about the fundamentals of "Avalon," "WinFS" and "Indigo," and we're going to do what I call a lap around "Longhorn" to get you sort of in the roadmap about all how those pieces fit together. And then during the rest of the conference you're going to be able to drill down into those.

Now, if you have all this great functionality you need a way to be able to interface into it, and we call that WinFX TM . And what is WinFX? It is the next step beyond Win32. And if you've programmed to the .NET Framework, it's going to seem like second nature. It's very well-structured. This is something that we expect to last decades, and so we've spent a lot of time thinking about how the classes, the types, the methods, the properties, the events all fit together so it's a holistic environment.

Actually, every time that a new extension is put into the system, it's reviewed by a set of system architects and then it's usability tested by a set of developers. We think we're doing a good job. We're going to be interested in what you provide to us as feedback about this.

Of course, another thing that we wanted to do was increase the capability of what you're able to do in your code. And at least for me, the number of lines of code that I can write is about the same; actually in my case a little bit less than what I used to do. But in the last ten years, I don't think the productivity in terms of number of lines of code has really gone up that much.

So what can you do about it? Well, I have a saying. The best line of code that you do is the one that you don't have to do. And what we're trying to do in WinFX is bring up that capability so things like add ref and release you don't have to think about, so you can make your code more resilient and write your code faster.

Lastly, in this next step in WinFX, we're trying to continue on our commitment to compatibility. So if you have a Win32 bit app or you have a .NET Framework app and you want to start taking advantage of some of the extensions that we have in WinFX, you'll be able to do it in a fairly straight ahead way.

Now, I believe in your bags you will have gotten this chart. This is the namespace chart. And I encourage you to study it because it will help you understand, especially using Visual Studio, but help you understand how the namespaces fit together from all the areas that I'm about to talk about.

So now what I want to do is start the lap. In the fundamentals area, even though we didn't really show any of it in Hillel's demo -- he basically just showed a top-level view -- "Longhorn" is really about fundamentals as much as about any of the other areas that we're trying to move ahead.

Today, it's still too easy for a driver to confuse other drivers or confuse the operating system, it's still too easy for applications to confuse other applications, and we're spending time trying to create more firewalls, more sandboxing between these applications and drivers so that you have a more resilient environment.

So the big challenge today: deployment, huge challenge, huge. It's probably the number one I hear following security. And it's not just when you deploy your app, it's how you service your app after the fact through patching or whatever.

And then there's this incredible growing security burden. It's not only in our code, it's in your code and it's not just looking at the code that's been done today, it's the new changes dealing with Digital Rights Management, because authors are going to want to get compensated as this new evolving world that everything moves to a digital form, they're going to want to be able to ensure that we're doing the right thing. We need people to be able to trust their computers and trust their content.

Last, performance is a continual problem. Today we don't take advantage of the GPU, except in certain games, and just basically because of memory leaks and the like it's very easy to have a system that is running for a long period of time to degrade in performance.

Those are some of the challenges that we're trying to address in "Longhorn."

And how are we doing it? Well, I'm going to talk about each of those areas very quickly. In terms of deployment and servicing, we have a technology that we call "Click Once," and Click Once is the ability to just do an xcopy -- the equivalent of an xcopy -- to a machine, and you've installed it, very easy to get an app there, very easy to deinstall an app.

No reboots: I'm on a campaign to get rid of reboots, not only in our code but in any of the code -- (applause) -- any of your code. So we have new servicing APIs that we're putting into the system to be able to tell applications you have a new set of capabilities that you need to integrate in and at the appropriate time you should shut down and take up -- shut down that part of your app and bring in the new piece.

This is also true of the operating system. We've made a lot of progress in Windows XP and Windows 2003, but we need to do a lot more.

And I could go on and on. Migration, going from one machine to another, today it's a weekend of work if you're at home. We'll have migration from machine to machine or migration that goes on the same machine, upgrades, it's the same code. And we're not talking about hours; we're going to get it down to where it's in the minutes range. We're not going to demonstrate that today but that's the progress, and I think it's actually in some of the bits that you'll be getting today.

Reliability: I talked about it. Built into "Longhorn" will be essentially a flight data recorder. It's going to be able to trace, on all the time, and if your application has a problem, you'll be able to back up and see what happened, true for the operating system as well.

Another area in here that I'm particularly excited about is driver verification. I really want us to take the next step and be able to put an analysis on a driver to ensure that the driver, before you even go through an operational mode of stress testing, you know that the thing is correct. I could go on about other improvements in that space.

Performance: We have improvements going on in the paging system, something called "Super Fetch." Now, what's Super Fetch? Super Fetch is the idea that we can look at what's going on in a system and in a much smarter, semantic, heuristic way, determine what you're going to need again in the future. And Super Fetch is dramatic in terms of its performance improvements. We're adding a lot of code in "Longhorn" and we're going to be able to hold performance, once we work through all the other problems that we've got to work through by the time we ship it, we're going to hopefully hold about the performance we've got today by the fact that we'll have the capabilities such as Super Fetch.

Glitch free: We want to be able to manage a media stream while other things are going on in the system. If you want to do some of the beautiful stuff you just saw, you need a glitch free environment, full GPU exploitation.

The last area in fundamentals I wanted to mention is about security. And frankly, Bill brought up just some of the things that we're doing in SP2 in the near term. In "Longhorn," we're going much farther. We're going to basically soup to nuts [address security] from the entire lifecycle of when you're writing applications: When the system boots, starting, running, communicating securely, building and then staying secure. So we're spending a lot of time thinking about the fundamentals and going back and seeing what we can do to improve them.

There are a couple I'll highlight here. You really need to be able to communicate effectively between nodes and between people, and do it in a secure fashion. We've spent a lot of time in the Web services area and with protocol specifications such as WS Security. We will continue to ensure that those capabilities are built into the system so you, as an application developer, you don't have to think about and worry about whether or not your communication is secure.

Another area I wanted to highlight and Bill highlighted a little bit is the way we're trying to work with hardware in a deeper way. The NGSCB, this wonderful acronym that we have, used to be called "Palladium," we're working with the hardware vendors to be able to create a system so that we can boot and ensure that we're booting securely and that we can create shadowed memory where code can execute but you can't debug it. You can if you actually needed to debug it, but in the running case, the idea is that it's in a curtained memory, which means that it will be very, very hard to penetrate that.

Another case in hardware, we're adding no execute capability to pages in the system. And by that I mean today's 32-bit processors, until recently, have not had any way in order to lock a page and say there's no execute here. And so with heap data it could always be corrupted; we'll have a solution to that with the no execute flag as we work with the hardware vendors.

There's a lot that we're doing in this space. There's a lot of talk at this conference. I encourage you to go to those sessions and learn how you can write the most secure apps that you can.

So next part of the lap, presentation. Now, today there's basically two models. There's the Windows app and then there's the Web app and both have great characteristics. If you want to have great interactivity, great performance, if you want to have offline capabilities, if you want to integrate in with things like the Start menu, a Windows app is the perfect thing to do.

Of course, there are a few downsides to that. If you want to have a great Web app, there are great things that you can get out of that. You get, for example, text free flowing very easily, you get easy deployment and, of course, you can't put a Windows app in your browser favorites; in other words, it's designed in two separate worlds.

What do we think people want? We think they want one world. And it's been a long path for us to get here, but we're incredibly excited that we think that we're on a path to solve these problems.

Now, you saw some of the demonstrations that Hillel did. Those are some of the screen shots from that. What we're doing in "Avalon" is creating a unified presentation model for Windows apps, for Web apps and for media and animation type applications. This is a big step forward. We're going to take the best of both worlds and create one programming model that you can count on.

Another huge innovation in "Avalon" is a vector-based compositioning engine. Now today, there isn't a single system for hardware drivers. There's a 2-D one and a 3-D one. In "Longhorn," there's just one, there's just one driver model that you can get access to, whether it be the text, media, any of the capabilities that you might have had to switch before. You get better performance, because you don't have to switch between the pipelines, between the 2-D and the 3-D.

And this compositing engine works not just as you saw earlier, not just between an app with the alpha blending that you saw in the transparent Windows, not just an app in the operative system, but even between apps, because of this cross-process compositing engine.

And it's vector-based. Any of you who have tried to play with a high density screen size in there, or becoming higher density, you'll know that if you did a bitmap-oriented font or bitmap-oriented icons and the like, it basically just doesn't work. So this is all vector-based, which, of course, is also faster.

Another area where we're making a huge step forward in "Avalon," from our perspective, is native input for a variety of new input needs. You've seen Media Center -- very cool little guide with a remote control -- you can get native input into "Avalon" from the remote control. How about ink? One standard API for getting ink in. And even speech, you'll be able to have one interface into the system.

Now, as you look across here in this diagram, you can see that we're going to let "Avalon" come in through documents UI or media, with a common form. And then, as you can see, it gets down to a direct 3-D graphic box that you can see there on your right.

Now, the last innovation that we're doing, we think, is huge. It's moving to the declarative programming. Now, each time, through the ages, as we've moved from assembly language to C to VB, we've made steps up in the capability of what you can do. So the declarative of this is better in a variety of ways. And we are introducing a code name, "XAML," as part of our work in "Longhorn," and it's a new markup language that lets you have the ability to build a Windows app in a declarative way. And, of course, we all know that the declarative things are typically easier to read, learn and write.

We also have the ability with this declarative language to separate the coding from the content. And to have some of the rich experiences that we all are used to now on the Web, you really have to have incredible designers in addition to incredible programmers. Today, it's sort of all mixed up together. And what XAML does is give us an ability to separate what's called "code behind" from the designers. And so, you can have collaboration between those designers and the developers.

And, as I mentioned, it's very easy for tools to generate as well as consume declarative text. So on the screen, it shows you what a button would be in XAML. Now, the cool thing is that you can use any C OS language as well to generate that same button. So these three snippets of code generate the same type of button, a huge step forward.

So with that, I want to get down a little bit more, the next level down in the system, and have Don Box and Chris Anderson, Windows architects, come out and do a little programming in "Avalon"."

Chris, Don?

CHRIS ANDERSON: Thanks, Jim. Hillel got to show you a great preview of what "Longhorn's" going to be like to use it, what it's going to be like for IT professionals and consumers. Well, Don and I, we get to show you what it's going to be like to develop it, what the code's going to look like.

So, of course, everything starts in a console, right? (Applause.) All right, Don. Let's start a C# file. We're going to start coding our application in C#. (Laughter, applause.) Don -- Don, you use EMACs?

DON BOX: Yes. All right. Remember, Chris, the premise here is we're walking up to a vanilla "Longhorn" box, we're looking at what's on everybody's box. I go to my mom's house, I want to hack.

CHRIS ANDERSON: OK, so we're at your mom's house.

DON BOX: And naturally, my mom, the only app she will have installed is EMAC. (Laughter.)

CHRIS ANDERSON: So this is all I have to rely on.

DON BOX: Wow. I don't want to be on your Christmas list.

CHRIS ANDERSON: OK, so we start with some using statements. All the APIs, all the functionality you've seen in "Longhorn" today are exposed through a simple set of managed APIs. We're going to import the system namespace, the MS "Avalon" Windows, and Windowsdotcontrols namespace. We're going to create a namespace. I'm sure you guys are all pretty familiar; we're going to keep going here.

Create a class -- we're going to derive this class from Windows. Windows is the base type for all the top-level frames in "Avalon"."

There's already people critiquing your coding, Don. It's sad.

DON BOX: There's already what?

CHRIS ANDERSON: People critiquing you. So we're going to create a main -- (audience member, off mike)

DON BOX: Ah, ah, I hear them. Hold on.

CHRIS ANDERSON: Thank you. We have a solution. We have solved this technical problem. Good? (Applause.)

CHRIS ANDERSON: Hold on -- I have one better.

DON BOX: Watch this. Font, lock, mode --

CHRIS ANDERSON: Get rid of that nasty color-coding.

DON BOX: Excellent.

CHRIS ANDERSON: The contrast is really a local thing for me. People in the back, they don't want to see all that fancy color stuff, because they want to see true systems programming.

OK, we have a main. Inside of our main we're going to create a new application. OK, new, My Window. We're going to create this. Now, this is actually instantiated in a class. The key thing to remember here is in "Longhorn," this isn't creating some wrapper that's underneath the covers calling create Window. This is actually instantiating the real code that is going to execute this app.

We're going to set some properties -- text, invisible. Like our forefathers, we are making the default visibility of all Windows to be invisible. We're going to run -- and Don, I think I need to make you flash back to history. You remember COM --

DON BOX: Yes.

CHRIS ANDERSON: OK, if you remember COM, I'd like you to put SPH right on the main, proving developer continuity on the platform. Yes, that's why we did it: developer continuity.

DON BOX: Great.

CHRIS ANDERSON: All right, so let's go to console. We're going to compile this now. We're going to invoke the C# compiler. Now remember, Don said this is only the software on his mom's machine. The C# compiler is now included in the default Windows client installation.

(applause)

CHRIS ANDERSON: Going to include a bunch of new DLLs, make it a Windows executable, and compile.

DON BOX: Just a warning: don't be alarmed; it's fine. My mom's got these crazy environment variables on her box. I never know what she's doing.

CHRIS ANDERSON: You've got to talk to her.

DON BOX: Yeah.

CHRIS ANDERSON: OK, let's run the app.

DON BOX: This is it -- drum roll.

CHRIS ANDERSON: OK, it's the first "Longhorn" application compiled at the PDC. You'll notice it is not gray. It is now white. That is our improvement. Hold on -- hold on.

DON BOX: Oh, my goodness. Look at all the stuff you can do with this app. This is that "Avalon" thing you guys have been spending like three years on, right?

CHRIS ANDERSON: Yeah, it's that "Avalon" -- yeah, thanks Don, thanks.

DON BOX: All right.

CHRIS ANDERSON: Just wait. All right, so that command line's not going to satisfy us for the rest of this conference, and we really need to make an improvement here. In "Longhorn," we're introducing a new build system, a unified build system that unifies Visual Studio, the platform, and the SDK with a single build format. It's included in the box. It will ship in every "Longhorn" machine.

So, Don --

DON BOX: So my mom does not have to suffer the tedium of running this command line.

CHRIS ANDERSON: Correct, yeah. It's another consumer -- a home feature. So let's create a project file. MS Build projects are, of course, XML-based. We're going to start with a project tag that consists of three main types of tags: properties, tasks and items. We're going to set some properties. Specifically, we want to have, you know, C# as our language, because we're not going to go change the code right now.

We're going to say the target name, give it, you know, whatever random names Don feels like today. Vanilla, this is great. We'll do chocolate later, but we weren't quite ready for that. In our items, we're going to include all the C# projects -- all the C# files, rather. Excellent. Flight in -- very tough, very tough.

Import -- so now, we need to get all the tasks. We have properties and items to find, and we're going to get all of our tasks from the Windows application dot target file, which is kind of the default for everyone. I think we're good. It looks great. Let's try for the console.

Oh, we don't need that anymore. Instead, I type "MS Build" --

DON BOX: Yes.

CHRIS ANDERSON: And what we've done is we've produced a lot more console output. We're trying to increase the amount of console output in this build. So, Don, let's run the next app. Well, actually, I could run it -- there's insects here. There's a bug in our demo already. Look at that.

DON BOX: Oh!

CHRIS ANDERSON: You know, as a hardcore EMACs user, there's something I've always wanted, which is that thing that you Visual Studio guys have -- what is it -- where you hit the F5 key.

DON BOX: I love F5.

CHRIS ANDERSON: I think I can get that. I think this is an enabling technology here. If I set this to Build, Run --

DON BOX: That's not going to work.

CHRIS ANDERSON: That won't work?

DON BOX: Try it. Let's see.

CHRIS ANDERSON: I think it will work.

DON BOX: We're trying -- you know, F5 and EMACs wasn't the top priority here, so --

CHRIS ANDERSON: This is the second "Longhorn" app of the conference. (Applause.) And oddly, it still looks like a boring white window.

DON BOX: Yes. But wait until we add some more angle brackets. (Laughter.)

CHRIS ANDERSON: OK, so -- all right. Jim talked about that great new declarative programming language, that higher level of distraction over, you know, the vanilla C# -- or, well, really Vanilla C# now. So what we'd like to do, I want to take that C# file and convert it into XAML. So, Don, maestro, if you would please: a new XAML file.

So in XAML, the syntax is relatively straightforward. The root tag is the class you want to derive from. We're going to include the XML namespace, which, by the end of this conference, you will all have memorized. It is schemas.Microsoft.com2003XAML. We will repeat over and over again.

We're going to include the definition namespace. This let's us do directives to the language compiler. So we're going to use that same class name in the same namespace as the code behind file -- excellent. So what we're really doing is we have two source files now that are going to generate -- we're defining the type, we're splitting the definition across two files.

DON BOX: Yes.

CHRIS ANDERSON: So that means down here, I have to go and say "correct."

DON BOX: This is a new "Whidbey" feature, actually.

CHRIS ANDERSON: Yes.

DON BOX: Where you're able to have, in C# have multiple source files contribute to the same class. In this case, we're using a markup file as one of our sources.

So let's move those property sets out of, you know, that rather old school C# and into the new revolution that is XAML.

CHRIS ANDERSON: Let's move this code into the 21st century.

DON BOX: Wow.

CHRIS ANDERSON: You can't use semicolons in the 21st century?

DON BOX: No, we don't need them anymore. We have angle brackets.

CHRIS ANDERSON: Wow. (Laughter.) Great, all right. So the last thing we need to do, we need to tell the project system that we want to compile that. So let's go and open the project file, and we're going to say that we want to include, as pages, all the XAML files -- that's XAML, Don.

DON BOX: Yeah.

CHRIS ANDERSON: Yeah.

DON BOX: OK, so -- Web build? Did you change the -- is anyone going to know?

CHRIS ANDERSON: No, no, no -- no one will know that it's XAML. Hold on -- don't look away, look away.

DON BOX: That was not the third act. Wait for it. Go to the XAML file. Yes -- oh, this is going to be much better. This will be exciting. And we build and run. Hello, world, from XAML. (Laughter, applause.)

What happens is as we ran the build system it took the XAML and it converted it into code and resources and it took the C# file and put those together as we compiled.

Now, alas, that is still but a mere reflection of what we want. Will I ever come back to the source code or now am I like just XML-boy?

CHRIS ANDERSON: Don, you've always been XML-boy.

DON BOX: Yes. (Scattered cheer.) We have one other XML-boy in the audience. Excellent, excellent. (Laughter.)

CHRIS ANDERSON: A true believer if ever there was one.

DON BOX: Let's add some content. So create a closed window tag and inside of here we want to include a text box and some buttons.

CHRIS ANDERSON: While I drink.

CHRIS ANDERSON: We're going to set the width and height. You remember Jim talked about those high dpi monitors? In Windows, we're going to natively support physical measurements, inches, points, pixels.

Don, your code is so clean.

We run Office, it's beautiful. Don, you are a guru, and everyone can see our patented "jello" button effect as he clicks. Yes, you get that for free. But, Don, your app is sitting there, you're poking the app and it's not giving anything back. You're getting nothing back. It's not an interaction, it's not a dialogue between the software and the human.

So, we want to add an event handler. So if you use ASP.NET, this should come as no surprise. We should also declare the event handlers in the markup. So, we're going to add an ID to the text box, and we can programmatically access it, and we're going to have a quick handler. Your names are poetic. I'm a code poet. Excellent, fabulous.

So, we create our event handler object, and take the click event art, and we decided here we're just going to be a little mundane, we'll get to the exciting stuff in a moment. We're going to show a message box. The message box shows, and we're going to access Bob, Bob, text. The text box was a variable called Bob, and it has a property called text.

Shall we, let's do it. So, we build, we run, we see a window. Type the text, we have interactivity, it's a message box, it will get better, don't worry.

We have our code and markup separated. We're able to out of the box. The developer experience on the platform has a simple to program declarative markup. We have this new build system. But the next thing we want to get into is the app looks pitiful. Hillel is actually in the back crying, I can see him from here.

So, let's go in and add a little more polish to this. We're going to put a text box. Jim talked about this unification of UI, documents, and media, and here you can see that we can put rich text right in the middle of our UI flow. In addition, all of "Avalon" supports a composeable layout model, so we're creating a text panel, and that's going to be laid out inside of the window. I'm able to embed really interesting text. See, we should have rehearsed more of the text Don was going to type.

We're going to put that in, we're going to build, we're going to run. We see text. No we don't actually, I can barely see the text. They don't see the text. Well, I can see it down here. Let's make this a little bigger, let's make it so everyone can see it. "Longhorn" and "Avalon" has this great vector-based drawing system, and maybe when Jim was saying that you kind of said, 'So what, you know, vectors are all new fangled, they're for games, or whatever. I like my bitmaps.' But, alas, bit maps don't scale very well. So, in "Longhorn" we're moving to this composeable vector-based graphics system, and so we're just going to scale this up, right there. And that's going to just zoom the whole UI. Let's bring it up.

We've failed. Gone. We've failed for the first time in front of this audience.

DON BOX: Our code has failed, how about that. Would that be better?

CHRIS ANDERSON: That would be much better. I think the compiler will also like that much better. But what we saw was compile time error checking. That was a feature demonstration.

DON BOX: Did you see that build thing where they did the Behind the Technology?

CHRIS ANDERSON: Yes.

DON BOX: You know the characteristic parts of those videos, I think we can actually capture that in "Avalon," you have behind the technology. So, if I do this, I think that will get us to look more or less like those interview shots, like with Puff Daddy, P. Diddy, Sean Coombs.

CHRIS ANDERSON: Excellent, much better.

DON BOX: Does the text box still work?

CHRIS ANDERSON: Of course it does.

DON BOX: Don't try this at home.

CHRIS ANDERSON: So, we've seen text, we've seen graphics, we've seen the rotation and the scale. But the last thing we talked about was media, the ability to integrate media into your application.

DON BOX: There's no blinking lights yet. Which is a cool Altair inside thing with the blinking lights.

CHRIS ANDERSON: Bingo. OK, but we want to do a little more modern version of the Altair. So what we want to do is, let's add a video into our application. So, in Hillel's demo, you saw how he was able to zoom into that video and it was really easy from a user standpoint. But how hard is that from a developer standpoint? If you tried this before, of course, you know that you need DirectX, and you probably need Windows Media Player, and implement maybe two or three hundred interfaces to try to host it. But here, we've gotten all that down to one single tag with a lot of attributes on it.

So, we set the width, we set the height, tell it to stretch, and we repeat for a really long time, and we set the source.

The last thing we're going to do, we're going to layer the video behind the text. We want to show a really great integration where they're seamless. So, we're going to have this canvas, and now we should be able to build and run. And let's see, what does the future hold?

Clouds.

(Applause.)

DON BOX: Now that I have these new-found graphical skills, I right now feel like I should critique this the way many of us critique other artwork produced by Microsoft, I think it's a little harsh, a little Fisher Price, if you will, too much primary color, not enough subtlety. We need more pastels.

CHRIS ANDERSON: OK, let's go for pastels.

DON BOX: The future is not harsh and Lego-like, it's more pastels and friendly.

CHRIS ANDERSON: So, in here what we're going to do is, we're going to set the opacity on the video, every element supports opacity. The entire "Avalon" composition system is built from the ground up with the ability to apply a transform, an opacity transform, effectively, to everything. In addition, every color reference, you remember the RGB, but it was always short of a quad, you always added that fourth bit. We found a use for that bit. And we've packed in alpha into that. So, every place you use a color, you can specify an opacity.

DON BOX: Which is the left most thing.

CHRIS ANDERSON: The left most. Let's go. Video, notice it's playing behind the text box. And it's stretching, and we can type, and the button actually works, all of this running at the video refresh frame rate doing real-time alpha composition. In the bits, this is running, by the way, in the directly on the video card. We've moved all of that processing directly onto the GPU, so it's consuming very few cycles.

(Applause.)

So, and this is also running on just the vanilla PDC bits. Eventually, at some point, who knows when, in the future, you'll actually be able to reproduce this exercise themselves.

What we've seen is a great vector-based compiling engine with composition, media, UI and documents all running together that even Don can write a great looking application on, even you.

With that, I think we should turn it back to Jim.

DON BOX: We've gone way too long without a senior executive on the stage.

CHRIS ANDERSON: We need a senior executive. IS there a senior executive in the house? Excellent.

(Applause.)

JIM ALLCHIN: As I said earlier, no tradeoffs. You can see even though these aren't some of our best graphic designers here, that you really don't have to have tradeoffs like you've had in the past. I want to move into storage, the next piece of our wraparound "Longhorn."

Today, data is generally trapped inside the application. What's happened is the managed aspects of the data are often put, not only because there has to be a separate storage, but they are wired into the procedure code that's inside the application. What does this mean? Well, in some cases, it's not a big deal because you really don't need to export it. If you really want to export it and let other people take advantage of it, the fact is the schema isn't visible, meaning that other applications can't go and add interesting value to it. We also find that developers have to tool their own store all the time, because the file system today does stream. It does stream really well. But you might want to have very small items that you manipulate. So we find application developers creating their own stores to try to manage their particular data.

We also find that relationships can often be buried, and if I say something like let's do a meeting, you know immediately that there's going to be an agenda, maybe not at Microsoft, but in most companies. But there's going to be and agenda, and you want to know when is the time of the meeting is going to be, and who it is going to be with, so you know all that. And so you want the systems to understand those links and be able to present them. So, if I say 'Bill Gates,' or 'William Gates,' you know that I'm talking about the same person. Systems could have better semantic knowledge to make those links very visible.

And the last area that we think is a huge challenge, and you've already seen demonstrated how we're addressing it, is that if you want to have separate views today in the system, you have to create your own folders. If you have photos sorted by date, 2001, 2002, 2003, and you can work on it that way and it's great. But now let's suppose that you want to look at your photos based on perhaps a vacation that you went on, you have to go in and physically reorganize. There's no logical versus physical separation.

On this screen, it shows little people, little funny people, representing that today contacts are sort of buried in a whole bunch of different places. When you put an author on a document, is that the same name space of contacts as in the Instant Messaging system? Is that the same one that's in e-mail? So we think that's a problem, because we think that if you have APIs that expose that and let you manipulate it, you could do a lot of cool things.

So, what we're trying to do in "WinFS" is do a couple of things. First, schematize the data, and provide a great store that you could use if you decide to. They're really two separate concepts. We think that moving ahead in schema is going to be a great step whether that data is, in our case, in Active Directory or someplace else. And we also think that store will let you do very exciting applications. So we have an extensible XML schema. We have a set built into the system, things like people, user, infrastructure, and you can add extensibility into those XML schemas for those particular ones.

For example, if you have a specific attribute that you want to add on to a user, then you could do that. You can also, you notice on the far right, that you can add your own huge new data type. So, your applications can install the schema, and then your applications take advantage of it.

We have logical views, which gives you this separation between the physical and the logical views, so you can look at the data in lots of interesting ways. Programmatic relationship: again, you've already seen the things that we're doing in Hillel's demo, and the app where it let us look at the different data, the linkages between them, and you can program those so that you can surface them through a variety and number of applications.

Synchronization is today extremely difficult, whether it's PC to PC or PC to a Web Service, or PC to a device, and so we spent a great deal of time. If you store your data in "WinFS," we'll be able to move it around in a consistent way between the devices without you having to do a significant amount of work.

Lastly, when data changes today, you can get things like an "on change notify," you know something changed, but then you have to go grapple to figure out what in the world happened. There's something called Information Agent that will let you run specific pieces of code when things happen. If I get an e-mail from somebody that's really important, I could have an Information Agent rule that looks at that and says, ah, it's from such-and-such a person, I want to go ahead and send me an IM that goes to my phone.

In terms of the general architecture, some of the things I want to highlight on this chart, and hopefully you can see this one, is that there's lots of different programming interfaces that you can come into "WinFS" with. You can come into it through objects, you can come into it through a SQL. You can come into it through an XML interface. There's a whole set of services being provided by the system, such as synchronization, I've already mentioned, an information agent, built in schemas, and then beneath it there's a data model that lets us build up these great schemas above it, things like items, relationships, and extensions. This is built on a transactive NTFS system, so the streams that you have in "WinFS" are actually stored in NTFS. Of course, "WinFS" itself is stored as a stream in NTFS. So there's a very good synergy between these.

So with that I want to ask Chris and Don to continue on, and take us around the lap with "WinFS."

CHRIS ANDERSON: Actually, Jim, I have this is my first PDC since joining the firm. And I sat up there all these years, and this is like my seventh of eighth PDC in my life, and I've always wondered why doesn't the executive write some code. And I think it would be nothing would please me more, I'd be honored if you wouldn't mind being my code monkey for this leg of the lap.

JIM ALLCHIN: It depends, do you have like a good editor in here?

CHRIS ANDERSON: Well, as you know, we have EMACs, if you were watching back stage, we have god's editor, I think.

JIM ALLCHIN: How about VI?

CHRIS ANDERSON: Let's see what we have. Why don't you bring up the editor of your choice. Windows is a big tent, we love everybody here, so you use what you want to use. We're going to edit vanilla.tf, which was the source file we were just working on. Now, you'll notice that, unlike EMACs, VI doesn't retain the font setting. And they want at least that, that's good. So you just told us about "WinFS", I'd like to see some "WinFS" coding. The first thing we're going to need to do is, why don't we talk about how people work. Right, we saw there's this unification of people in the store, why don't we bring up a contact ticket dialogue and see what that looks like. So replace my message box, which it looks like you've already done, and make yourself a contact ticker dialogue. So a contact ticker dialogue, give it a variable name, whatever you feel like, equals new contact ticker dialogue. Great. And we're going to need to set up properties so that the dialogue knows that we're looking for contacts explicitly. So why don't we go ahead and say dialogue that was a request property, request properties property request.

JIM ALLCHIN: I think it's property request.

CHRIS ANDERSON: Excellent, we agree, you lose.

JIM ALLCHIN: I could be wrong. I just work here.

CHRIS ANDERSON: Type what you will, we'll work it out.

JIM ALLCHIN: The compiler will probably help with that.

CHRIS ANDERSON: And we need to set the property type. Just because, the contact ticker has all that great functionality, you can select multiple items, you can say addresses, or e-mail names, or properties, anything.

DON BOX: Chris, you're sugar coating it, it's a very verbose API that we have to code around.

CHRIS ANDERSON: Contact properties dot contact, that I am certain in the fullness of time this line of code will become unnecessary. For now, this is a real bit, so we have to

DON BOX: We know, it's a couple of words.

CHRIS ANDERSON: Unlike "Avalon," where everything is perfect.

JIM ALLCHIN: Guys, move on.

DON BOX: So, Jim would you go ahead and show the dialogue, to do a show dialogue, which will do a modal dialogue on this sucker, pass your object reference there, compare to dialogue result dot OK. If and only if this works, what we want to do is grab the selected contacts, which is a property on the dialogue

JIM ALLCHIN: Is that the thing you call BOB?

DON BOX: Yes, the edit control is BOB, of course. We've been trying to teach Don Hungarian, but he just refuses to learn.

CHRIS ANDERSON: Yes, I thought now that Charles isn't with the company anymore we could pick our own variable names.

DON BOX: So, selected contacts zero, dot contact, dot display name, dot value, dot string, dot text. I'm sorry. I got a little carried away. That's looking pretty good, do we have enough close curlies there?

JIM ALLCHIN: One more.

DON BOX: I think you've got the exact right numbers. Now, hold on Jim, let me channel a much younger Don before I became enlightened, will you hit escape, colon, W. Is that it?

JIM ALLCHIN: Yes.

DON BOX: Sweet.

JIM ALLCHIN: These young people.

DON BOX: Can we go back to the shell? Now, I don't know if you noticed, what I did when I wrote the original make for the project file, I went ahead and put the build run in the target. So we now have F5 for both EMACs and VI. So if you want to just write MS build, and go ahead and click the button.

DON BOX: Fantastic. So why don't we go ahead and find in contacts. These are real bits, remember that. I picked Mr. Anderson. Great, fantastic. OK, VI boy, let's see what else you can do with this thing. Let's see how this VI works with XML, a more modern syntax. So why don't you crank open the vanilla. So what we're going to do is add some more user interface goop at the bottom of this form. So after that go ahead and put in a line break, so that we get a visual

CHRIS ANDERSON: Because we want to make it look better.

DON BOX: We want to make it look better. Let's see, let's get a button and a list box. So, a button, we're going to have an event handler, which is going to be the button event handler is click equals whatever, search.

CHRIS ANDERSON: Good name.

JIM ALLCHIN: Like that?

CHRIS ANDERSON: Yes, I like that.

DON BOX: And close angle bracket.

CHRIS ANDERSON: Yours are actually a little better than Don's, they actually have good variable names, you code a little better. You've been doing this longer.

DON BOX: He's more experienced, he's more seasoned, as we say.

JIM ALLCHIN: We call it old.

DON BOX: And let's go ahead and drop a list box in here, and we're going to give it a programmatic variable, so capital ID equals the variable name of your choice. You're not going to say LB list, in honor of Charles. And you're going to need to make that a string with quotes. Result list, and you're going to get all visual fancy with this VI thing, fine, you go girlfriend, whatever you want. That's amazing. And why don't we put in a dummy item in there, so that it comes up looking fairly reasonable, because as it turns out if we don't, it's the size of the content, and we get a very tiny list box. Close that sucker out. Looking beautiful, close off the list box. What do you think of this XML stuff?

JIM ALLCHIN: I don't think it's going to blow over.

DON BOX: You don't think it's going to blow over?

JIM ALLCHIN: I think it's here to stay.

DON BOX: You think it's here to stay. I'll quote you on that one.

CHRIS ANDERSON: That makes Don happy, we can keep him employed now.

DON BOX: That was actually one of my review goals.

CHRIS ANDERSON: That XAML looks as good as XAML can possibly look. Why don't we go ahead and go back to our source file, and

DON BOX: Just give me a second. Did you overwrite our vanilla?

CHRIS ANDERSON: No, I think it's just ul, again, the French spelling. So as I recall, in the button you declared an event handler called search, so would you mind writing a new event handler next to

DON BOX: I think we should get that "WinFS" namespace in there, right?

JIM ALLCHIN: I think so, too.

DON BOX: So let me put something about storage, because that's not core enough for us.

CHRIS ANDERSON: That is truly the core of the core.

DON BOX: Uber core.

CHRIS ANDERSON: We were going to have core.ex, but we decided we'll wait until next version.

DON BOX: It didn't make the LAPI design timeline.

CHRIS ANDERSON: So go ahead and write us an event handler search object, sender, click event

DON BOX: Jim knows the guidelines, it's sender, E.

JIM ALLCHIN: Yes.

CHRIS ANDERSON: OK. Great. And what we're going to do is issue a query. So there are some documents on this machine I'd like to see what we've got available. So to make a query in "WinFS," the most important thing we need is this thing called an item context, which is really a query scope. Because the query might take a few moments, just a few, let's clear out the list box so the users knows what's going on. And now we're going to declare an item context, C, and we're going to get it by saying item context dot open. So this is kind of the master control object from which we're going to issue all our queries. So now that we've got this, we're going to issue our careers are looking shorter and shorter. So when we issue the query, because we're in CLR land, where things are very productive and developer friendly, the query is going to return a collection. So we'll do a for-each, and we're going to get back documents. This is a strongly typed object, right?

CHRIS ANDERSON: Yes, it is.

DON BOX: So we've schematized all that common data stuff, all the everyday information. So we'll do a C dot find all, type of document, that's exactly the number of

CHRIS ANDERSON: One more, I think one more will do it.

DON BOX: I like that number. So let's get a block of code after. So for each one of these guys what we're going to do is create a new list box item, so we say result list dot item, dot add. There we go. And the title of the document will come from D, and there's a property called title, and we're cooking with gas there, you can close off another curly brace, and that VI is just an amazing tool. So why don't we go back to the shell and do a built. So there's our new button and our list box.

JIM ALLCHIN: Should I push it?

DON BOX: Again, it's thinking.

JIM ALLCHIN: What do you think?

DON BOX: Now, Jim I noticed that we got everything. In fact, we got so much everything we got two of everything, it was so happy to cough up these items. Is there anyway we can pare this down without going through like four loops, trimming these things out? I remember from SQL it was always better if you get the engine to do

JIM ALLCHIN: Yes, in fact, this is about as inefficient as you can do it, because we're dragging everything we can, and then we could do a compare if we wanted to. Maybe we should just let the engine do the search.

DON BOX: I would love to see us do that. I think we should let the engine do the search.

CHRIS ANDERSON: So let's go to our find all, find all is overloaded, the first version that we used simply takes a type predicate, which says, 'Find all things in this store that are affiliated with this type, and the type we used was documents.' What we're going to do now is put in a predicate, which allows us to actually reason about, and express constraints against the schema of what is stored in the store. So the second parameter to find all is going to be a query string, and author's dot display name equals Mr. Anderson, looks good. And if you can put a comma right after type of document.

JIM ALLCHIN: Of course.

DON BOX: The dreaded line wrap.

CHRIS ANDERSON: That insert

JIM ALLCHIN: I did, I did.

CHRIS ANDERSON: So that's looking as good as it can possibly look. Why don't we go back, save it out, go to the shell, dare we? Hit the search button, and I'll bet we get a few less files this time.

JIM ALLCHIN: How about that? Great. (Applause.)

CHRIS ANDERSON: Jim, before we move onto the next part, I don't know if you watched that video with the Halo stuff, with the red and blue and all that, one of the challenges of PDC is to get a vice president, even better a Group Vice President, such as yourself, to say developer 37 times. Would you please say developer 37 times? (Laughter.)

JIM ALLCHIN: Developer 37 times. (Laughter, applause.)

CHRIS ANDERSON: Thank you.

JIM ALLCHIN: Oh, gosh, what can I say.

OK, well on to the next part of the lap around, which is about communication. And I think we've made a bit step ahead in Web services. We've spent a lot of time working with the industry to come up with the protocols, but if you really want to have a Web service today, you're going to have to do a lot of work. It's a lot more just coding up some simple SOAP messages. You need security, you need to handle things like transactioning, guarantee that you can handle the resiliency and the recovery. You need to be able to handle the trust issues of security to cross boundaries between companies.

You have a decision to make: Are you going to do objects? And there's some advantages there or there's some disadvantages. Are you going to do services? And there's some advantages and disadvantages there. How are you going to deal with the fact that you might want to do this little peer thing that you saw here but you also might want to do this cross-company or cross just your enterprise? So there's a lot of code you have to do if you want it to take place today.

So what we're doing in "Indigo" is creating a subsystem that you can access that does everything for you. It starts by addressing the basics, so that you can do transacted messages in a reliable way, that you've got security built in it, you've got heterogeneous interoperability also built in it; the messaging capabilities, so that you can do just very, very simple things like send a message, or you can get down really low level and dirty and be able to play with exactly how the sequencing is to work.

Now, there are programming models that extend the existing models that you are used to, whether it be what's available in COM+ or the like, so it naturally fits into all of those environments. And the bottom line is that this simplifies the building of services in a fairly dramatic way.

And if you can see -- this picture of course is not quite as big from the architecture -- but from the top, we start off and we have facilities for you to create services so you don't have to do much thinking. You can either do a lot in declarative statements to let you build these services. If you go to the next level down in the architecture, there are connectors and channels for you to import for you to be able to fine-tune the way you want the system to operate.

Finally, beneath that you have a variety of hosting environments that you can have these applications run in. You could have them run in a Web context, you could have them run as an NT service, you could have them run in DLL host in the COM+ world, so there's a lot of different ways that you can have your application and still be able to service the messages, and not handle all the issues that you typically would have to about scheduling threads and synchronization characteristics.

So that's what "Indigo" is about. And, with that, I think I want to cover one more thing before I have these guys come back up here.

We talk about "Indigo" for communications. There's also a collaboration piece that we put underneath the "Indigo" name. And today in the collaboration space, there are way too many contacts for you to deal with them if you want to have an RTC communication. It's just tremendously confusing. There's no single API for really doing the peer-to-peer or enterprise level environment that you want when you set up an app to do to real time. And today you can't get any of our UI to really integrate in with your application. Let's suppose you want to do a video call inside your application. There aren't any controls that we're making available for you. So that's a big problem.

And then the problem of apps and firewalls, both enterprise and then with the home, block so much of communication that you are really stuck with some hard problems if you want to have a guaranteed, end-to-end real-time communications environment.

So what we are trying to do in this space is create a single namespace and environment for contacts so that you can find the contact and you can get the presence -- presence meaning is the person there right now? And in "Longhorn," as you'll see in the bit, that there is a single concept of contacts that everyone is using, whether real-time or things like e-mail. We are adding controls so that you can get the capabilities for doing collaboration up into your app without you doing all the code, single platform, peer-to-peer and enterprise. And it's easy to traverse namespaces, even the peer-to-peer ones that are being dynamic. And if you move from a peer-to-peer into the enterprise, then that still works with the same APIs that would have worked on a simple code.

And now -- now back to you, John and Chris. (Applause.)

DON BOX: Thank you, Jim. (Applause.) So I've decided this time maybe I'd have someone a little less seasoned, who I could push around a little bit more. So Chris, would you mind coding?

CHRIS ANDERSON: I'd love to.

DON BOX: And I don't even want to think about what text editor you're going to use. So what we are going to do now is take our program, which is a fairly lonely program -- it's a program that just sits all by itself -- and what we are going to do is allow it to reach out to other programs that are running out in the world.

So what I want to do is let's go ahead and do some blog work, right? So you know the PDC bloggers, .NET, everybody is into Web logs now. I know your simplegeek.com is becoming a cottage industry, generating three or four times your salary.

CHRIS ANDERSON: Click through.

DON BOX: Click through.

CHRIS ANDERSON: Google click through.

DON BOX: So why don't we go ahead and add some blogging capabilities using "Indigo" with this little program.

So what we are going to do is, would you mind opening the XAML file, because we're going to have to set up a little bit of user interface? So what I'd like you to do is after -- or before actually -- I don't care where you put it -- I'm going to need three edit controls, so three text boxes and a button. So that looks like as good a place as any. So I'd like a text box -- ID equals -- we're going to put the title of our blog entry here.

CHRIS ANDERSON: Title you said? Is that close enough to Hungarian?

DON BOX: Yeah, good point. And do you want to make the width 100 percent?

CHRIS ANDERSON: Yes, Don, you've been listening when I've been talking, haven't you.

DON BOX: Did you just say something? What's interesting is that was actually spontaneous when I did that -- shocking. Yet it got no laughs.

CHRIS ANDERSON: Don't try, don't try. So go ahead and mark up these variables. So we've got three variables. And you might want to put a little label there so that other users who come along --

DON BOX: Usability.

CHRIS ANDERSON: Programs that other people use are often more useful than programs that only you use.

DON BOX: Put a line break at the end. Oh, my goodness, where's your black beret in Macintosh? Great work on --

CHRIS ANDERSON: And we need a button. We need a button.

DON BOX: A button?

CHRIS ANDERSON: That will actually invoke the blogging code that we are going to write in "Indigo." So we have a button, invokes the blogging code. Fine, close off that tag. And go ahead and put a click handler in there. Blog it, then copy.

So we've done all the XAML work, and now what we need to do is go over to our program and write some "Indigo" code.

So the first thing we are going to do is get the event handler in place. And the event handler looks astonishingly similar to every other event handler. If anyone in the audience would like to help out, you can --

DON BOX: Great, we're auditioning later.

CHRIS ANDERSON: And what we are going to do is bring in system.message box, which is the namespace for "Indigo," and we are going to take the three edit controls, bundle them into a data structure and send them over through a SOAP message to my blog.

DON BOX: A data structure?

CHRIS ANDERSON: We call those classes. Is that what you're --

DON BOX: Fine. So public class item, and I need three public fields of type string, title --

CHRIS ANDERSON: Wait, wait, title? I'm guessing, description?

DON BOX: You are so good.

CHRIS ANDERSON: Yes, content, fantastic. So we've got a data structure, also known as a class, that we are going to work with. We quickly marshal that off of the form into the --

DON BOX: Now, I really should be using data binding. There are some people backstage who are going to yell at me because I'm not.

CHRIS ANDERSON: That's okay.

DON BOX: There's great data binding -- I'm just letting you guys know.

CHRIS ANDERSON: Yeah, yeah, plug away.

DON BOX: My monitor has gone blank. That's not very fun. I.description equals the title. --

CHRIS ANDERSON: Actually it would be the description.

DON BOX: The description.text. Thank you, Chris.

CHRIS ANDERSON: It's harder to read when I have to look down at that --

DON BOX: Great. So while Chris fills this up, this thing we're going to do next, which is actually the important "Indigo" piece -- this was actually just a bunch of bootstrapping code so we could get our app to work. What we are going to do now is declare a port. A port is the central focal point in the API for "Indigo." A port is also a great kind of wine.

CHRIS ANDERSON: Yes, it is.

DON BOX: And the port is the way messages come into and leave a given app domain. And so I've got my port set up. What I'm going to do now is create a channel. Actually, I'm going to do a port.open -- so P.open.

CHRIS ANDERSON: I think we should also close it at some point.

DON BOX: Yes, let's close it.

CHRIS ANDERSON: Practicing good coding practices.

DON BOX: Good for you.

CHRIS ANDERSON: You taught me well.

DON BOX: Yes, thanks. Yes. So what we are going to do now is create a channel. So "Indigo" is all about ports, which are these places in network place, and channels, which are these little IO devices we use to get messages into and out of a port. So we are going to need a send channel, and we're going to call "p.createsendchannel." And open-paren, new-URI -colon, HTTP colon, whack-whack, www.gotdotnet, whack team, whack ebox, whack Indiepost.asp. Cool. Close, close, close, semi-colon. And now we've got a channel. So we are ready. We are poised to get the message out to the server.

CHRIS ANDERSON: I'm poised.

DON BOX: Yes, you are poised. What we are going to do now is create a new message -- so we are going to create a message object, M equals new message. We are going to give it an action URI -- and get ready for this -- UUID, colon, 0002, 0812-0000-0000-C000-000000000046.

CHRIS ANDERSON: So you made that up off the top of your head?

DON BOX: No, my friends on the Excel team really wanted to see their name in lights. (Laughter.) So, go ahead and pass "I" as the body of the message. So we are basically creating an in-memory SOAP envelope.

CHRIS ANDERSON: Did you pass "I" as the second parameter? Oh, that was just too fast for me.

DON BOX: So we've got a channel, we've got a message. If only we could -- actually show me what you want to type.

CHRIS ANDERSON: You know, I just want to introduce somebody. I really want that to be the code that I have to type.

DON BOX: Yes, and of course this is real bits. This is not the final product. There is a grotesque line of code I need to type. I would like everyone to look down or away from the screen while Chris types this. (Laughter.) Look away. This will not be in the final product. It is a horrible hack, M-doting coding equals new system.text encoding. And by the way, this has got nothing to do with system.text. This has to do with the way our plumbing dispatches messages. And system.text.encoding.UTAF8, close paren, semi-colon. Do not do diddly-squat. Go to my blog, go to the shelf -- go to our -- no, no, not there. Get rid of that. What are you? Got to the shell that we've got. Please do a start, http://www.gotdotnet/team/dbox, and fine.

So let's go take a look at my blog. This is just a blog which any of you folks in the room can --

CHRIS ANDERSON: You have a Sunday PDC post-world?

DON BOX: This is the thing I blogged at 3:00 a.m. this morning, before I went to bed. And what I'd like to do is blog something new. So why don't you go ahead and build and run and our app. And this is builds, F5 for visual slick edit as well. That M is billed as very enabling.

CHRIS ANDERSON: You know, I'm sorry, Don is -- or Jim has been sending me mail all day about this, and so I have got to fix it. So we --

DON BOX: Great. So Chris is going to tweak the UI a little bit. There we go. For "Indigo" we want things to look perfect.

CHRIS ANDERSON: Yes, there we go.

DON BOX: Great. So why don't you go ahead and exercise your creativity. You have wanton access to my blog. Please be gentle with her. "Chris is the best demo god in the world." Yeah. "I only wish I could be that cool." You're right, Chris, I do.

Now, before you hit the button, moment of silence, a hush -- a hush falls across the room. Go ahead and hit it. I don't want to think about the number of moving parts in this demonstration -- across the Internet. While this button remains depressed a moment or two, it's sad -- oh, it came back. Why don't you go hit refresh on your Web browser? (Applause.) That was great, Chris.

So we've seen a classic scenario where there's some service running on the Internet, we've got security built in, we're using "Indigo," we're doing the dance. I think "Indigo" is actually a lot more interesting than just talking to things that are Web sites.

What I'd like to do now is to use that same technology to build some funky UI that will make me feel better about "Avalon."

CHRIS ANDERSON: Excellent. I like to think you'd feel better about "Avalon."

DON BOX: And, you know, I've noticed something about you. We've been spending time together recently, and I've noticed that you have tendencies which you're fighting -- (laughter) -- that you have been somewhat in denial for the past few years. And I think today is the day we come to terms. And it's often -- you know, you --

CHRIS ANDERSON: No, no, don't say it. They can't handle it.

DON BOX: Yes. I think the next piece of code should be written using the language you really know in your heart of hearts you want to use, the language that you knew from the age of five you were attracted to, even though you couldn't explain it. (Laughter.) (Applause.) So what Chris is going to do is create a tile. A tile is one of those fancy gadgets over on the left-hand side of the shelf. And we have got a new tile project -- have you already created the project?

CHRIS ANDERSON: It's done.

DON BOX: Great. So we are going to create a tile project. What we are going to do is comment out the text of the tile, and you might want to bump up the font size.

CHRIS ANDERSON: Hey, this is way better than those tech centers we've been using. There's Intellisense and save incompletions.

DON BOX: There might be something there.

CHRIS ANDERSON: There's something to this Visual Studio thing.

DON BOX: There might be a future in this VS thing. (Applause.) And give it a variable. Great. OK, fine, be creative, whatever. Fantastic. Chop, chop, chop. Take me to the code. OK, fantastic.

What we are going to do is write a service. We are going to write an "Indigo" service that runs inside this task bar. And to do that, we are going to write a new class inside of our class that we have got here already. We are going to bring up a system-up message box of course.

CHRIS ANDERSON: I like system-up message. It's one of my new favorite namespaces.

DON BOX: I know it is. So go ahead and declare a new class, so public class My Service. And it is going to inherit from synch message handler, which is a type-in message box. And, oh, wow, look at that.

CHRIS ANDERSON: In the body.

DON BOX: Oh, that's excellent.

CHRIS ANDERSON: I actually am pretty attracted to this language. It's pretty cute. It's --

DON BOX: Yes.

CHRIS ANDERSON: I like it.

DON BOX: I wonder if I could do both. So, why don't we go ahead and what we are going to do is this message is going to be a little bit simpler than the message we used before. We're just going to put a string in the body. So declare string. And I want you to go ahead and crack that out as a message. So even though the message in that is in XML, is 100 percent SOAP conformant, what are we going to do is just program against it as if it's an object, and then it's easier in this case. So we do a message.content.getobject. This gives me a reference to the content. I then ask it to be coerced to string, and then there's some VB magic syntax to make the cast work.

CHRIS ANDERSON: It's a cast.

DON BOX: Yes, welcome to the new world.

CHRIS ANDERSON: I am getting used to it rapidly.

DON BOX: Fantastic. Now, we've got the string. Again, this is one of these -- the code I would like to write. Actually, first we've got a new class. That class doesn't have any reference to the foreground. So why don't we declare a field of type tile foreground, and we'll set that up later on. We don't have to worry about that yet. What we really want to do is the tile.thetext.

CHRIS ANDERSON: That's statement completion against the mark-up as well, so we haven't built -- thought we had -- well, I did built it actually.

DON BOX: Great. Cool. And what we are going to do -- what we want to do is just assign it F. Now, this is the ideal world we wish we lived in. Today what we are going to have to do to get this to work is a little magic. So what we are going to do is put that code into a function that takes an object as a parameter and returns an object as a result, and we're also going to have to --

CHRIS ANDERSON: Do we have to return null or nothing or --

DON BOX: We do. Or we don't?

CHRIS ANDERSON: VB takes care of that for us.

DON BOX: OK, great. So is that all you need to do in the function?

CHRIS ANDERSON: We need to cast the string.

DON BOX: So we'll pass the string in through that parameter. Fantastic.

CHRIS ANDERSON: I need to remember to put commas in the right place.

DON BOX: Yeah, great. Fantastic. And so now, what we need to do is this is again a line of code -- don't take too seriously, but it's needed to make this demo work against the live bits. So look away from the screen. We're going to call context.begininvoke. What this does is it takes the context in our thread, which is not the user interface thread. This is a service in "Indigo" that the incoming message will be dispatched on an arbitrary thread. What we need to do in this build of "Longhorn" is flip from that arbitrary thread to the thread that has user interface access. And to do that we do context.begininvoke, passing it to delegates of the code we actually want to run.

CHRIS ANDERSON: So this is also VB doing multi-threaded programming with method type, talking to "Indigo" across any protocol?

DON BOX: Yeah, yeah.

CHRIS ANDERSON: That's pretty good too.

DON BOX: Fantastic.

CHRIS ANDERSON: Great service.

DON BOX: That code is looking good.

CHRIS ANDERSON: It is.

DON BOX: Did we give it a good name?

CHRIS ANDERSON: We gave it the name of My Service, which I think is a great name.

DON BOX: Great. Let's go ahead and wire it up. So what we are going to do is create a new port. This is "Indigo." So we create a port -- that's where all life begins in "Indigo." And this time what we are going to do is pass a constructor, which is the URI that we are going to listen on. And I don't really want this thing to be accessible across the Internet. I only want it to be accessible on my local box. So "Indigo" ships with a variety of transports. One of them has the MS.SOAP -- or cope -- dot-Xproc --

CHRIS ANDERSON: And you were complaining about the other APIs?

DON BOX: Yeah, I know -- colon, and then put in an identifier of your choice here. One -- an identifier, great.

So we've got our port. Before we open the port, we need to wire up our service as a receive channel or on a receive channel, so go ahead and say P-dot -- make your service, initialize it, and then go ahead and go port.P.receivechannel.handler equals S and now release the hounds. Do a P.open and at this point all kinds of stuff's going to happen in my app.

CHRIS ANDERSON: Oh, but watch this. Everyone pay close attention here. I'm going to now install the tile. Let's hope I get the right one. So, inside the build environment, I have Visual Studio automatically register that with the side bar so I didn't have to do anything extra.

DON BOX: That's a very nice productivity enhancement.

CHRIS ANDERSON: It's a productivity enhancer.

DON BOX: Yes, great. (Applause.)

CHRIS ANDERSON: So, why don't we go modify our client to take advantage of this? So, we'll just use the existing XAML -- this is the last piece of code we're going to write, so we're just going to ripping --

DON BOX: Oh, I'm just going to start tearing this apart.

CHRIS ANDERSON: Yeah, get rid of that stuff. That looks -- oh, change the URI to point to the real one that we just typed in, which is MS.SOAP.XPROC, an identifier, very good. We'll be living with that identifier for awhile.

DON BOX: Can we actually use the same UUID?

CHRIS ANDERSON: No, actually I'd like you to change the first eight digits very quickly.

DON BOX: OK, first eight digits.

CHRIS ANDERSON: 00000000, eight zeros, great.

DON BOX: This is in honor of the tune do, like an I unknown.

CHRIS ANDERSON: And pass a string, which we'll get from the bob.text. And, nuke that onerous, horrible line.

DON BOX: Gone.

CHRIS ANDERSON: You're cooking with gas, dude.

DON BOX: Fabulous.

CHRIS ANDERSON: Please go build. Have we had any demos tank, that just didn't work at all?

DON BOX: Not so anyone would know. (Laughter)

CHRIS ANDERSON: So I think, since this is our last demonstration it would be okay if it tanked.

DON BOX: OK

CHRIS ANDERSON: If it doesn't work --

DON BOX: So we'll set expectations low and then if it works --

CHRIS ANDERSON: You almost need accepting of that. So in the pink box type something. Yeah, of course, literal boy. And then go ahead and say push me on. Actually I'm going to hit the invoke blogging code.

DON BOX: Oh, is that where we are?

CHRIS ANDERSON: Ah, argument null exception. I know what the failure is. I knew about this one before, and I have failed you, Don. I have caused the only demo to tank. I've always wondered what it would be like to have your demo fail in front of, you know, 7,000 or however many of thousands of people are here and now I truly know.

DON BOX: So, you're going to fix it in real time.

CHRIS ANDERSON: I am going to fix it in real time. So the error, for those of you who would like to know, is that I am still woefully inadequate in my ability to use my language that I love truly and I miss, yes, pass the data to the background thread.

DON BOX: Ah. It's all about data. So you still haven't come to terms. You were conflicted.

CHRIS ANDERSON: Great. OK, chow, chow, let's make this one happen in a successful way. OK. Or I could say that was my attempt to show people that -- all right -- it's not coming up.

DON BOX: Really.

CHRIS ANDERSON: And, I know why. You see we have this -- remember this (in-proc ?), the ports, right, so we have a port that's dangling and you never want to have a dangling port. But because we have that dangling port I'm going to make a minor little change.

DON BOX: Ah.

CHRIS ANDERSON: And we're going to fix this. I can recover because I've paid attention in school and I know how to make this work. So what happened was the -- something wedged, we left a transport port open. So we need to go change the identifier. This is why the tool bar, the task bar was glowing.

DON BOX: OK, so we have our hole of PDC.

CHRIS ANDERSON: It showed.

DON BOX: Now, Chris, just do it.

CHRIS ANDERSON: OK. Please work. Yes. (Applause)

DON BOX: My brother, my brother. So that didn't use IIS, nothing.

CHRIS ANDERSON: No IIS, no nothing, very fast, very light weight, very cheap.

DON BOX: Great. This feels like a reasonable time, Jim. Thanks for having us.

JIM ALLCHIN: Thank you. And not too bad for whippersnappers, huh? (Applause)

Well, I've got a hard decision to make. We've got some incredible demos that we're about to go into, but we've already kept you here a long time. Would you just like to stand for a few minutes or keep going?

AUDIENCE: Demo, demos!

JIM ALLCHIN: OK, we're going on.

The next thing that we are going to cover is how apps can take advantage of the great system you just saw and we have been out working with a set of partners, both from the commercial side, corporate developers and Web developers to see how they might take advantage of some of the great stuff that you're seeing.

So, we're going to have Adobe, Merck and Amazon come up and show. We're going to show what they're working on and the first demo is going to be from Adobe and you know they're a premier graphic design company and most people aren't building in notepad by EMAC slick edit; they have to use something very, very high end and I think Greg Gilley is here with his team and is going to come out and give us a little demonstration on how they are going to take advantage of Longhorn. Hey, Greg. (Applause)

GREG GILLEY: So, I assume everybody's familiar with PhotoShop, right? So Adobe does also had professional video tools. One of them is Adobe AfterEffects. AfterEffects is used for motion graphics, compositing and special effects that gets used in films and commercials and things like that, anyplace that you really want to add sizzle to your presentation. So, let me run a real quick video here to show you an example of some of the things that AfterEffects can do.

(Video segment.)

So, pretty cool stuff. And, as we've been talking with Microsoft and as they were showing us some of the capabilities of "Avalon," the "WinFS" stuff, we were thinking what if you could use a tool like this to design your user interface for your application. So we decided we would sit down and try and see what we could do. So, we got Len who's a UI designer and Chris, who's our coder. They're going to come out and show you a little example of what might be possible.

LEN: All right, thanks, Greg. Say, as a designer sitting down to build a new application for Windows today, if I wanted to find a UI, I have very few options.

The way it is today is I sit down with a static image editing program, maybe like PhotoShop, and I create a bitmap of what I want to produce. It's a really manual process. I take that bitmap and the first thing I do is print it out and hand it to my friend Chris. And as a developer, he's going to sit down and try to recreate what I've done.

In an ideal world, I'd like to be able to use the tools that I know how to use as a designer, like After Effects from Adobe. And what your seeing on the screen here is AfterEffects 6.0 with a program that we've written that exports to XAML.

So, what I've got here on the screen is actually some UI, which we use AfterEffects for, like Greg showed you, to build motion graphics and special effects. So what you can see, this is sort of a motion graphic effect like you'd see for a stock check on an evening news program, right, showing stock data coming in, except you'll notice it's not complete.

What it is actually is not just a video that I'm saving out, but a template for a UI. The way I might do this in today's world is to build a video, put the data in there as a fixed value and then just save it out to something like Windows Media format.

Now, once that's done it sticks, I can't change it. What I've done here is created the charts, the animation. I put in some parameters here for Chris to use later. And now I can save this as instead of a video that's fixed in time, I can save it as a piece of UI and give it to Chris and he can go do something like bind it to a Web service to get real time data.

So what I want to do is save that, go over to export, export it to XAML, put it in a directory where Chris can pick it up. Going to go ahead and write over this. And now that it's done, Chris can take over and add some logic to this and build some code on top of my UI. So let's see what you can do, Chris.

CHRIS: Thank you, Len. So, the first thing as a developer, Len and I spoke, and we decided on a class name. And I went ahead and I build a project. You can see that I had a dummy file, or a XAML file that Len has created in AfterEffects and delivered to me. The first thing I'm going to do is load in his files and rebuild the application that I was working on just to make sure that Len gave me what we discussed.

As you can see here, it's up, the animation loads, it looks beautiful, the fidelity is almost exactly what you have in After Effects, except for some of the metadata that Len had in there, which soon I'll be binding to a Web service.

Additionally, you can see some elements that I added across the bottom, there's a portfolio and a news button and a little text edit field for symbol look up.

So, let's go ahead and add some event handlers, but I'll actually bind this to the Web service and make this animation dynamic and interactive. The first one we're going to add is just a loaded handler. I've already gone ahead and written some of the code to handle this, but that will go ahead and bind this to the Web service and get the data dynamically.

The second one I'm going to add is an on-selection change handler for the list box. And what this will do is this will allow us to handle changes in the list box and repopulate the data from the Web service.

So, I'm go ahead and send this again. Once again this is just XAML that I got for Len. I did not have to go into Notepad and re-edit this. You can see now we have data that we've pulled from the Web Service running live on this machine. This is stock data (Applause.) Pretty cool, huh?

And, in addition to that, you have this lit box down here where you can select different ones, and once again the animation starts over, and you can see more data has been pulled off the server. But this is still XAML. So not only did I not have to code the XAML, which I'm very happy about it, but I get to take advantage of the properties inherent in XAML such as the fact that it's resolution independent, it's vector based. I can lay it back out and it has relayout built into it for me automatically. So regardless of what this runs on, by Len and I working together we created this excellent UI and I didn't have to code any XAML.

LEN: Wow, that's impressive. (Applause)

CHRIS: So you can see that's a great example of the kind of user interfaces that you can create inside "Avalon" and the nice thing is there wasn't any EMAC involved. (Laughter) And, if I could make one final plea, so I know there's a lot of desktop app guys out there and I know you guys probably already have UI designers that help you with this, but for you enterprise app guys, could you please hire UI designers to take advantage of some of these new capabilities. Thank you. (Applause.)

JIM ALLCHIN: "Avalon." It's fabulous. The problem that often happens today that prevents a huge step up in the productivity is the fact that doing things across organizations and with different systems that exist in different organizations, it's virtually impossible. So if you really want to have a huge jump for any of the business apps you really have to do something that's sort of different. And, we have Merck here who's going to give you an idea of how they're approaching a big jump ahead using Indigo. So Jim Karkanias is here I think with his team and is going to give you an idea of what his group is going to be able to do.

JIM KARKANIAS: It's good to be here. (Applause) Well, as you've heard, I'm Jim Karkanias. I head operations for part of Merck, and what operations means is we basically solve problems that we encounter in the business of clinical trials. Now, you may know already that clinical trials is a complex business, complex for a lot of reasons. Some of the inherent reasons are that it's research and discovering the unknown is sort of inherently a difficult task, as you can understand.

But there are others factors that contribute to this. For example, clinical trials, just one clinical trial, one piece of a clinical trial, would involve as many people as would fill this room, so you can imagine how many interactions you need to take into account.

As a developer, if you're going to build a system to handle that or an application to handle that, you can appreciate that that's a challenging task, so how might you approach that.

We're going to suggest that information management is a key here, and focusing on the information itself from a supply chain standpoint and working it into the workflow of the folks involved -- the patients in the trials, the physicians taking care of those patients, the regulatory agencies, the hospitals that are involved -- allowing them to work in a way that's natural for them and allows us to collect the data at the same time is a much easier way to implement such a system.

So obviously "Indigo" is an opportunity to connect all these things together and we'll show you what we mean by that.

I thought we'd take the opportunity to put together a demo that talks about a hypothetical clinical trial. This will be an allergy study and we'll just show you a few of the participants that would normally be encountered in such a thing.

This is Rich Gleeson, who's going to be playing the part of a physician taking care of patients in the trial, Jim King, who will be playing the part of a clinical monitor managing the data in the trial and, Jim, if you wouldn't mind being the patient in the trial.

JIM KING: I'm still breathing.

JIM KARKANIAS: OK, great. We'll get you set up and come back to you.

So let's talk about how you might deploy a system. I just finished telling you that we don't think that you can achieve a solution here by approaching it from a classical direction, so how do you even get the software to the people that need to use it, and we'll show you that. I'll turn it over to Rich, who will walk us through one-click install.

RICH GLEESON: Great. So, the first step as the physician for this trial is I need to get the software installed onto my desktop. And we're going to do the one-click "Longhorn" deployment. I'm going to click on My Studies site initiation, and this is going to pull down the client to my desktop.

So now instead of the old world of just having a Web page I have a full rich client that is going to allow me to participate with this trial.

Now, the next step is I need to add a patient to my study, I need to add Jim here, so I'm going to Select Patient. And you're going see the "Longhorn" contact picker, but customized for my application. So this is showing me my contacts that qualified for the study, of which I've got Jim. So using the "Longhorn" identity system, I have this contact and I can trust that I know who he is, and I'm going to add him to my study. I've got a lock showing I've got a trust. I also have a pathway for data to Jim.

So let's see how he's doing. Let's check his real-time readings. I should start taking data from him. There you go.

RICH GLEESON: Thank goodness. (Laughter.) So that's pretty cool. What you're seeing here is real-time data coming from Jim. He's holding a device here, as you can see. This is a measurement device from QRS Diagnostics, and it connects to an iPAQ. And you remember I said let's try and create an environment that allows the patient or the participants in the trial to work in the way that is natural to them.

This is an allergy trial, so we need to collect data on pulse, oxygenation, respiratory function. And we could ask Jim to go to a hospital or schedule a visit with a physician, but instead allow him to work at home, for example, and collect data on his terms. This is wirelessly communicating with a PC. It could be in his own. The data is traversing Net gateways, a whole host of intermediate servers, making it in real time to the physician's office. And the applications developed along the way don't need to know the details of that and "Indigo" helps to bridge that environment.

So the data is looking pretty good. On these screens here you should be seeing the real-time data. Let's create an anomaly that we need to handle. So, Jim, if you wouldn't mind, just take a shallow breath into that tube. And I'll explain that, of course, Merck needs to make sure that we understand what's going on at all times in our trial to maintain maximum safety and efficacy of our product. So the physician is being notified of an anomalous event and he's going to start a collaboration session with Merck to talk about this data. And you'll see how "Indigo" bridges a disconnected environment in that case.

I'll turn it over to Jim King, who will walk us through that.

JIM KING: Thanks, Jim. As Jim said, I'm playing the part of the Merck clinical monitor, so I'm going to receive notification that you just saw pop up on the screen there. And that's in a position indicating that there's something to investigate. So I'm going to go ahead and look at he's sending me data.

Let's see what we're actually looking for. We're going to go to real time. And remember, when data was sent, I wasn't connected. Now I'm looking for that cue to respond and feed me all that data. You see it all catching up here, and I didn't have to do anything but go ahead and click on it.

Thank you. (Applause.) Also, there's an anomaly noted here, so clearly that's what he wants to look at. So we're going to go ahead and do a little bit more work. And again, we're going to make use of some of the features that are available here; specifically "Avalon" for the visualization and then we're going to use "Indigo" again to make another Web services call and really do some more drilling into this.

You see, there's three patients here who look like they share the same anomaly. You've got a threshold here that they all fall below. So we're going to drill into these three patients. And I'm going to use a Web Service call out to MapPoint to pull all this together. So I've got data coming from many different places, from the patient to the physician, back into my office. And right off the bat, I'm able to draw an initial conclusion by looking at the geographic proximity of these three patients. They're all in a cluster here. And MapPoint allowed me to do that.

But that doesn't tell me enough, so we're going to drill into it a little bit more and overlay the pollen count or for all of us maybe smoke would be a little bit more appropriate with everything we're dealing with. But we're going to overlay the pollen count. We'll see what happens. Almost immediately, you see that everybody's in the pollen zone who had the anomalous event.

So we can draw an initial conclusion. To make it more compelling and understand if there's a temporal aspect here let's roll back the block and again we're going to use the feature of "Avalon." Notice the alpha blending of the overlay and the data binding we're able to do as I roll this back. That's pretty powerful stuff right there.

So we roll it back. We're able to draw an initial conclusion, and say that it looks like the data that was sent to me indicates that the anomalies are definitely pollen-related, and I can collaborate with a physician on that information.

JIM KARKANIAS: Thanks a lot, Jim. That's awesome. (Applause.)

So you can see -- let's review what we've seen here. We have a multitude of systems involved, connected here, all with applications written, without regard to the infrastructure. "Indigo" helps to map all that together. We're getting the right information to the right people in the right time frame. And we are working with the IT barriers that are created as a function of all the different systems that are in existence as a result of this large population that we have to deal with in clinical trials, much like what other large businesses are faced with in today's world.

So we encourage you to talk with us more about this. There's a booth to visit, the "Indigo" booth, and a partner pavilion. But now Don Box will be talking about the code and walking us through some of that. Thanks a lot. (Applause.)

JIM ALLCHIN: Thank you. Well, we're going to have Don come out. He's back there someplace. He's just going to give you a little bit -- a snippet of exactly how the "Indigo" code worked.

DON BOX: Thanks, Jim. Let's take a look at this machine here. Let me minimize all these fancy windows. Here's some code. What I'd like to do is take a quick glance at the code that made that Merck program work. I'm going to open up a simple C# file, which is already written. This uses "Indigo," as we said already.

This one actually uses a different part of "Indigo" than we used in the lab. In the lab, we were programming at the low-level messaging layer. This uses a more higher-order-of-service model. And notice that we simply write a class. We mark it with Dialogue Port Type. What Dialogue Port Type says is I expect arbitrary messages to come in and go out; it's not a strict request reply disciple.

And notice also that I was able to annotate methods with a variety of attributes to control what the contract was between the service and consumer. And in this case, not only was I able to control the shape of the messages and the message exchange pattern, but I was also able to declaratively say, 'Here are the security requirements I need' -- in this case, pointing to a blob of config XML, which controls the concrete details of the security, as well as a logical role name, which I'm going to use for standard authorization of incoming messages.

JIM ALLCHIN: You did it all with just those few lines of code?

DON BOX: Yeah, with just those few lines of code.

JIM ALLCHIN: Fantastic. Thanks.

DON BOX: Thanks. (Applause.)

JIM ALLCHIN: So you've now seen two of the demonstrations. I want to do another one with Amazon that ties it all together. And this will show what can be done in an application using "Avalon," how it can be used and store information in "WinFS" and get new views out of that, and then finally, how to use "Indigo" for the Web services.

Al Vermeulen is here from Amazon. Al, you want to come out and show us cool stuff? Great.

AL VERMEU: All right. Thanks, Jim. (Applause.) Hi. How are you all doing? Are you starting to see kind of the possibilities of what you'll be able to build with "Longhorn" and "Avalon" and "Indigo" and these things? Are you starting to kind of get excited about this stuff? (Applause.) Or are you just at the point now where you've had a couple of cups of coffee and some water and been sitting there for three years?

And the reason I ask if you're getting excited about what it is I'm doing here, is that we got together with some folks from Microsoft and some folks from Amazon -- oh, I don't know, maybe a month or so ago -- just to talk a little bit about what we're doing at our respective companies. The Microsoft folks, they told us about "Longhorn," a lot of the things that we're seeing here.

And at Amazon, we told them about our Web services strategy. And our Web services strategy is really pretty simple. What it really comes down to is take all of the elements of our e-commerce platform that you all know and love through interacting with our Web site. I assume everybody here is boxed up on Amazon.com. If you haven't, we run this Web site. You can go there and buy stuff. I encourage you to go for it.

Our Web services strategy is to take all of that functionality, all of that data, all the algorithms that we've developed over the last several years, and expose them to applications via Web services. That's it -- pretty simple, pretty straightforward.

When we got together with the Microsoft people, we started thinking, "Well, how is it that we can create innovative new things using "Avalon" and "WinFS," these rich client technologies, to create interesting shopping experiences for our customers? What kind of things can we do by combining Amazon Web services and "Longhorn?"

And we came up with all kinds of ideas. Unfortunately, I only have a few minutes so I'm just going to sort of show you a couple of those ideas. And what I'll do first is fire up the Amazon rich shopping application. This is just a demonstration that we put together. And you can see right away, just as we fire this up, that this is not your normal HTML Web page. Right? We've got some video happening here. That's kind of cool. We've got this shopping cart control so you can sort of check out what's in your shopping cart at any time without having to go and, you know, actually change to a different Web page. That's kind of neat.

This is something interesting here. You've got recommendations, and the recommendations are actually cycling through. One of the things that we know at Amazon is that material that we put -- we call this above the fold -- stuff near the top of the Web page is much more likely to convert; that is, people are much more likely to click on it than stuff below the Web page. So some clever person here said, "Well, we can use that space above the fold and rotate some recommendations through it."

Now, why would a developer do this? One of the things about our Web services that's really kind of interesting is that developers who build things on Amazon Web services actually have a bit of an economic model that they can leverage. OK, this is an important thing we do with our Web services.

The model goes like this. If you write an application and you distribute it out to folks and they use that application to buy things on Amazon.com, then, via our Associates program, we give you a piece of the action. So you get a cut. And there's actually a lot of people who build things on Web services that are making a reasonable living at it. So that's kind of cool.

Let's actually use this thing now to buy something. So I'm going to do a search for a digital camera. It turns out that my wife this weekend has gone to visit her sister. Her sister just had a child. And when your sister has a child, you have to go and visit her. The other thing you have to do is you have to take your camera, because you can't have too many pictures of a four-month-old baby.

So that left me without a camera. And I got to thinking, well, I really ought to have two, because I'd love to be able to take pictures of all these fine people. And so we'll go ahead and search for a digital camera. What's happened while I was talking is that the application, this rich shopping application, has hit Amazon's Web services, asked for a digital camera, and then gone and retrieved all of the rich information we have about 300 cameras that match that search criteria. It took all of that rich information and stuck it into "WinFS" so that we can have "Avalon" controls that could, you know, quickly and easily go ahead and search through that information to find things. If I was Don Box, I'd actually in real time build this app and show you just how easy it is to do this. But I am not Don Box.

So we can go ahead and we can do things like filtering operations. Let's say we're only interested in cameras that are really kind of well-liked by our customers, that got, say, four stars or better, and we've cut down from several hundred cameras down to 31. That's kind of fun. We can sort by brand. Let me reset this. We can sort by brand. Let's say we're interested in -- can we sort -- we can sort by brand; just ask for, say, Canon cameras and Vivitar cameras.

So that's kind of neat. We can do some basic sort of filtering things here. We can get detailed information on any camera. And you notice the detail information. This camera doesn't have any reviews. The detail information includes reviews and price and all kinds of stuff like that. That's great. Let's see. Does this one have reviews? Oh, I've picked two cameras without reviews. That's okay.

But at the end of the day, this is still kind of a relatively flat sort of a list, right? I mean, it's cool, but it's not kind of what you'd hoped for in this rich graphical environment that we're expecting with this new operating system.

So let's take a look at another way to display this information. So this is kind of cool. This is the "Avalon" carousel control. So taking all of that data about cameras that we retrieved from Amazon, and put it in this really kind of nifty control, we display all several hundred cameras at once. And I can go through and rotate through. (Applause). Doesn't that look slick? It's just beautiful.

It's not only beautiful; it's actually practical, too. This is a really kind of useful way to be able to check out stuff. Let's see. I can filter on price and you can see the number of panels kind of diminishes there. I want to pay -- you know, I probably want something more than US$200, and I don't really want to spend more than $583.81. So that's great.

I can go through, and let's actually buy one of these now. Let's see, how about this one? And here we go. This one actually has reviews, so you can see that I was telling the truth when I said there was additional information about all of these products that's available.

Now, to buy this, again, we'll just do a nice simple graphical metaphor. We'll grab this thing and we'll just drag it over here into the shopping cart. There we go. And we've got a shopping cart now. That's kind of fun. And now, to check out, all we have to do is push the button.

One of the things that I want to point out here is that all of this stuff is real. OK, this is all real code. So Amazon Web services, this all works today. You can go home and write these kind of applications on top of the Amazon platform and you can use the "Longhorn" bits, once they're available, to actually build this kind of UI. So that's very cool. We can go ahead and change things about our shipping options, and let's actually place that order.

The reason -- this is the one thing, actually, that was dummied up in this demo is the demo doesn't actually place real orders. Otherwise I'd own a lot of cameras by now. And you know the nice thing about that? When I buy that camera, buying things from Amazon makes you happy. (Laughter.) It's a great thing.

OK, so that's one thing we can do. We have a nice, rich client shopping experience. What else can we do? Like I said, we came up with a lot of things. The other one I'm going to show you right now involves the calendar control, and this is the idea that at Amazon we have lots of, you know, products that release all the time. And it's a big deal to people to know when do products release.

So we can go ahead and get that data again from Amazon Web services and display it on this nice calendar control, and you can see that the David Bowie album came out on the 21st. Actually, my family has already bought the two things at the top this week, the Indiana Jones and the David Bowie, and we'll be buying "The Two Towers" as soon as it comes out. My son is just a huge "Lord of the Rings" fan. So this is kind of nice.

What I would really like to do, though, is see how this fits in with my personal life, if I'll have time to actually watch these movies and so on. So I can overlay my calendar on top of this calendar. What's interesting about this -- you heard Jim talk about this already -- it used to be very difficult to get at my calendar information, because it was buried somewhere in Outlook or in Exchange or something. I don't know; it was hidden way down there. And there's probably a lot of people in this crowd who are smart enough to know how to get that stuff out and dig it out of there and put it on this page, but it's difficult for mere mortals. Well, with "WinFS" it's easy, because that data is exposed.

It's really interesting to think about the Amazon information you're seeing here, because really our Web services strategy is the same thing. All of the Amazon data used to be buried behind a Web site. It was hard to get at. What we've done with Web services is make it easy to get at. Right? So now we can take this easy data to get out from Amazon, the nice data from "WinFS," and put it together in this one control. So that's great. I can see I'm at the PDC this week. This is something else that was made up. I'm not really going to Hawaii. It'd be nice.

But this is actually true. This is really true. November the 2nd is my mom's birthday. And I look at this and I go, 'You know, this is terrible, because it's Monday. My mom's birthday is on Sunday and I haven't bought her anything.' This is actually literally true. I've known about her birthday for a while and I still haven't bought her anything.

The reason we know this is mom's birthday is because in "Avalon," we have information about all of my friends and family. We go ahead and we look there. We see that there's birthday information. So we know that this is the actual birthday of a friend of mine. We can build functionality into the app, which we've done, to go through and purchase a gift for my mom. So we'll go and we'll purchase a gift for my mom.

What we've done now is we've hit Amazon.com Web services and gotten hold of my mom's wish list. And this actually is my mom's wish list, just to show that this is real stuff. And you can see my mom likes cool things, unlike Don Box's mom, who installs E-Max and probably owns all the O'Reilly books; it turns out that my mom quilts and listens to Elton John.

So I can go ahead and I think I'll buy here the Elton John CD, and again I wish the ordering thing was actually hooked up here because I've done this several times now and I still haven't bought my mom a present. (Laughter.)

So we'll go ahead and drop that in and again I'll go ahead and buy this. I can add a few more things. I can put a message into my mom for her birthday, so that's a good idea. So I'll write my mom just a little note. OK, that's cool. And it knows it's a birthday gift, so it's automatically set up gift wrapping. I can turn that off, but I actually want gift wrapping for my mom. It knows I'm buying something for my mom's birthday, so you notice that the people picker, the contact address has already set this up automatically to ship to my mom. That's great. If I wanted to, I could fire up the people picker and go ahead and change that or I could change it and have it build somewhere else. That's great. Standard shipping will be fine because her birthday is in five days. So we're all set, we'll go ahead and place that order.

And there we go. Now, if this was actually hooked up at the end to do the order, my mom would have her gift. So that's cool. The last thing I want to show you -- thank you. (Applause.)

The last thing I'm just going to touch on very briefly, and that's to show that this whole environment could be integrated. And what we've done is, over here, in order status, as I'm placing these orders, I go ahead and I drop them into my sidebar. Something really interesting that we've discovered about our customers at Amazon is that they love to see what's happening with the stuff they've ordered.

And I'll bet you've done this too, right? People love to track their orders. They love to know that UPS has picked it up in Fernley, Nevada, and it's now going down whatever interstate, and it's getting dropped off here, and so on. So what we're imagining that we could do here -- and this is not real yet, we haven't built this -- what we're imagining we could do is with a notification service, we can actually be sending notifications, via Web services, and a client, like an "Avalon" client, could receive those notifications and sort of show you, in real time, where your order is going. So that's kind of neat.

So this is what I want to talk about, is the rich client experience. So in closing, let me just again mention that this was, except for the very last part, all real stuff built on Amazon Web services. We've released -- I believer there's been something over 35,000 developers who are currently using Web services, built lots of cool applications, lots of orders coming through that channel.

If you want to learn more, I think we have a booth setup here, and we'll have somebody there to man it, and you can come and talk to them. I encourage you to download the software and play with it. Thank you very much.

JIM ALLCHIN: All of the underlying code that you've seen is real. Think about it. It's not that way in some other events. (Laughter.) And nothing crashed. It's not that way in other events too. "Longhorn" is truly a milestone event for Microsoft, who has been sort of the receiving end of not moving fast enough on the Internet. You know, we pay attention and try to get a lead on as many things as we possibly can. We think that this is an area where, if you invest early and get with the train and learn, then you can receive some disproportionate share of the gains that will take place.

We've got a lot of technology. We're also going to invest to help you make money in deeper ways than what we have before. Typically, we try to push marketing. We push the product out there, give you a lot of what we would call sockets for your applications. We're going to go beyond that this time. We don't have this all worked out, but some of the things that I wanted to mention at this event was that we've done some system design reviews, some early reviews of this with developers, and they keep saying, 'How about helping us out on licensing? How about putting an automated system in there so you could license your product, if you're a commercial vendor?'

That is something that we are going to do. We have continued to work on that technology, so we'll have a facility for you to be able to license your product and do it at scale if you want to, in whatever licensing models that you want to use. But the infrastructure would be in place. That's one thing.

Second thing is that we have a very, very, very simple Windows catalogue today. Think about us taking it to a whole other level, where you will be able to have your product and be able to take it from end to end. And we will push, push, push those out to people so that they can see the best Windows "Longhorn" applications. And, of course, there will be more coming. We will make this a tremendously large event.

In terms of, now, how do you get there, if you have Win32 bit app today, barring security issues and the like, those applications should be able to run on "Longhorn." If you're working with the .NET Framework today, those applications would work on "Longhorn," and you're on your way to the WinFX APIs. If you have a Win 32 bit app, or a .NET Framework app, you can start taking advantage of the WinFX APIs.

And perhaps, you can't rewrite your code to manage. It's OK. Just start using the functionality in the system that you need for your application, whatever it would be. We've designed the system specifically for that purpose.

And then, finally, if you're writing a new application and it's in the "Longhorn" timeframe, then you can take advantage of the full WinFX environment. Now, we don't have WinFX APIs today, certainly, in the bits that we're going to give out here that cover the entire system. But it should be very clear that's the path that we're on, to basically make that the new layer, surface area for the system.

In terms of schedule, this is only the client. Obviously, there are separate schedules for server. They've both got the same general technology in server, but I'm only going to get into the client schedule. Quickly, the media center just shifts. The "Longhorn" developer preview, that's the bit that we're going to provide to you today.

In the first half of 2004, there will be a service pack for Windows XP, and a new updated Tablet, which has dramatically better recognition capabilities, as well as several other very, very nice facilities. In the summer time, and second half of the year, we'll be coming out with a 64-bit edition for AMD, as well as "Longhorn" Beta 1. Beta one will be where we take it to the next level and ask a lot more people besides you.

I mean, honestly, we've shown "Longhorn" to no one before today -- just a few set of people, like the ISVs here, to get their feedback. We will be going bigger there. We're not going to make other commitments about when we're going to get done with this product. We're going to try to focus on getting to Beta. See, you will have a pretty good idea, with the bits, about where we're at. We still have a long way to go.

We are listening. We have a show net here called http://commnet. There's an application that, if you already haven't downloaded, I propose that you do that. Give us feedback. I know there's been, already, a bunch of information coming. I was walking back stage, looking at some of the information. It's great. It's a great way for you to get with your peers. It's a great way to tell us what's going on. We are listening, and we're very invested in your success.

There's a set of things that we think you should do. This would be what we would call our call to action. They're very straight ahead. We think fundamentals are really important. We, together, have to nail the security infrastructure so that people can trust these systems. Web services: it's the way to get great inter ops. Managed codes: it's the way to avoid arrows, pointers, get higher productivity.

Smart clients: you want high, interactive, rich experience. You need to take advantage of those and help us be better in community. We're trying to really work on that, as you'll see with the application we've got here -- all of the people that are into blogs, and other things. We're really trying to connect with you, and that's what this conference is about.

Now, you get the bits today. In fact, as you go to lunch, you're going to be able to get the bits. You should have gotten a card, which is in your conference bags. There's a lot of information on these discs. There are two CDs just of "Longhorn" and different versions -- a 32-bit version, 64-bit, both of IA 64 as well as AMD 64. We also talked about that as X64. There is the "Longhorn" driver kit, along with the SDK. There is Visual Studio, the would-be version, Yukon the sequel, newest update of that.

There is the Virtual PC 2004 version. Now, that's a virtual machine technology that does actually work with these "Longhorn" bits. And there's lots of white papers, and samples, and other things.

Now, I want to set the context for where we are in this release. We still are very early. We've never shared bits this early. So you're going to see a lot of work. There's things in terms of the programming model that we haven't cleaned up yet. Performance is not good. (Laughter.)

I mean, there's no other way to talk about it. Performance is not good yet. You should put on only high end machines, and I propose that you not put it on any production machines, and I propose that you not connect it -- at least not knowingly -- to the Internet, in the sense that, it's fine if you put on the Internet connection firewall, which should be on by default. But you should be thinking, you should know that these are early bits.

We think it's incredibly cool, and we hope it's what you need in order to get really familiar with the system and provide us that feedback that we want. We're incredibly excited about it. We think it is the next generation. And with that, I want to thank you.

Have a good lunch and good conference. Thank you very much.

Read More: