>> Tim Laverty: So I'm Tim Laverty, I'm a program manager on the
Windows Phone developer platform team. And a couple of my teammates
are out in the audience some of which I'll show some of their code
today. So but feel free to ask questions as we go.
We're relatively small group.
interrupt and let me know.
So just raise your hand and let me --
So I have probably I don't know half slides, half demo, Visual Studio
and demo both. So we'll pop back and forth. So, again, this is about
one of the larger pieces that we've added to the developer platform and
Windows Phone 8 is native code getting C++ access.
And I'll focus on where you can write it, what some of the or what
limitations there are, and a recommendations as well. My e-mail
address is here. Twitter account is here. So if you have follow-up
questions, just hit me up over mail or Twitter as well.
Okay. So C++. This is the C++ you know and love. This picture is my
book from, I think, 1990 or so. And this is my sixth edition from this
year.
Both from Steven Prada. It's a great book. I would recommend it. And
the reason I put this in here it's kind of funny to think about. It's
been a long time.
But what we built or what we've added to the developer platform Windows
Phone 8 for you is C++ as you know and love it there's nothing special
or anything super new here from a C++ perspective.
You're just getting access to the, just added access to it from the
platform.
Okay. So you need VS 2012 to build apps for Windows Phone 8. This is
the same as you need for Windows 8, if there's things if you're not up
and running on it already you need a slot enabled machine and so on.
I'll talk a little bit about some of the new C++ features or C++ 11
standard features.
Okay. Sorry, that's -- can you see it in the back? Jeff, can you see
it? All right. So the C++ standard we support in Windows 8 is a
subset of C++ 11 features. There's a great blog post here from the
developer or DEV DIV C++ team that I would recommend looking at. But
largely it gives you pretty decent access to C++ 11 features. You have
lambdas and auto keyword for typing and you have no pointer constant,
et cetera.
>>: Is that the same as visual C++ supports or is it smaller than that?
>> Albrecht Lindner: No, it's the same. What you see in Windows 8 in
terms of C++ 11 standard support is what you see in Windows 8. It's
the same compiler.
>>: [inaudible].
>> Albrecht Lindner:
Windows 8.
We do not manage C++, no.
The same story as
Do you guys want me to repeat the questions as I go?
>>: Yes.
>> Albrecht Lindner:
All right.
I'll start doing it from here on out.
Okay. I want to show -- I wanted to hop into code pretty quick to show
just a couple of demos of how you can get at C++ in Windows Phone. And
so I'll show a couple. So probably the easiest way to show how C++ can
be used in Windows Phone is we have a set of project templates that are
in the box.
You have a pure native D3D app. You have a D3D with XAML app. If you
go into the sharp node you'll also see a XAML and D3D app. Those later
two are just very slightly different.
I'll dig into detail a little bit with them later. They use a
different control to render D3 or D2. But the first thing that I'll
show is the pure native app.
And if you click through this or this is -- I think of this template,
it's a good way to bootstrap yourself with if you want to write a
Windows Phone app that's pure native, you don't want to have any XAML
in your app whatsoever this template gives you a really nice safe
harbor for actually doing it.
If you take a look at, say, this is, so my phone direct through the
app, 59 CPP, you'll see a number of -- mostly what you'll see in this
file that VS auto generates for you out of the template are the OS
handler hooks. So you're seeing the systems initialize, set window.
If you come down here, you basically
just your render loop, I guess, it's
wrapped in one. So what's happening
the Windows Phone OS will initialize
it will call run on this.
see your render loop or, well, not
your simulation and render loop
here is when your app starts up,
you, create your window and then
And this is really where your code will be. So you have a timer. You
have this dispatcher process events is basically handling input for you
or giving you a hook to trigger input.
You have updates. Any of your simulation that would be added would
happen either inside of this render update method or you would add it
previous to it here. And then you have render and present. So
actually drawing your pixels to screen.
A little bit down below are your hooks for input. You get an input off
of this arcs pointer or sorry off of this args argument. And here you
have current pointer and you can grab the position or the point off of
this.
So in terms of getting your feet wet or having just something that
shows you, well, how do I write my first C++ app, the template is a
great starting point. You can walk in. It shows you how it hooks into
the OS, and all it's doing is it's drawing a triangle on screen.
Let me go ahead and run it. That would have been much more smooth if I
had my emulator booted up before.
So all we're doing here is we have our square rotating on screen. If
you want to look at how or cubes I should say. If you want to look at
how the cube is rendered you can walk underneath the cube render CPP
file.
If you want to look at how Direct X is initialized and bootstrap so
that cube can render you can look under Direct 30 base. This direct X
helper I always think of this as a little misnamed. I guess we
probably should have changed it. Is that it's basically your IO for
reading your shader or reading your shaders from disk is all this is
really doing for you.
So I wanted to show that, and then the other thing that I wanted to
show, it's super simple demo of just getting up and running. But I did
want to show and talk about some of why we actually -- so why bother
adding C++ support to Windows Phone. And some of the reasons are like
this. So what it allows you to do is write systems with -- actually ->>: Can we dim the overhead?
>> Albrecht Lindner: Is there a way to dim the overhead? Okay. So
what it lets you do is you have access to pretty much about 95 percent
of the platform as a whole. And I'll talk about the small missing
pieces that you can't get to from native code.
You also have access to direct 3-D and programmable shame shaders. So
this was actually built by our graphics team. And it's really more of
a tech demo. And the idea is basically to show the extent that you can
or show the extent that you can leverage custom shaders and direct 3-D
on the phone. So this is writing apps that would showcase this kind of
graphic fidelity was possible in some cases but very, very challenging
with just our managed platform. So what we've tried to do and opened
up is letting you write apps that have much more graphics fidelity.
>>: How hard was it to develop that app?
>> Albrecht Lindner: So the question was how hard was it to develop
the app? It came from our graphics team. So came from someone really,
really familiar with the gap. We plan opposing the source for you to
take a look at. I think it was a two or three-day effort. It was kind
of one in one of the we finished our milestone let's go and write a
bunch of code and samples and demos to prove what we were doing and it
was during one of those times.
So significant but not outrageous. I mean, you're talking about
writing some fairly complex shaders ND and 2-D code.
>>: The question can you do it in the C#, I noticed you had a project
in C# could you get that level of fidelity.
>> Albrecht Lindner: So the question is can I get that level of
fidelity with just C#?
So what I would say is is probably not. That particular app uses a
significant number of custom shaders, programmable shaders written, in
HLSL. So code executing on the GPU. However, I'll talk about this in
a little bit, you can leverage D3D inside of your managed apps or
inside of your XAML app using RD 30 controls. And I'll talk a little
bit about the two controls we've added that allow to you get at that in
just a couple of minutes.
Okay. So that was my, the basics of C++, getting your first C++ app up
and running and my fancy shader demo.
So I'll talk a little bit about your question right now, which is what
are our application models. So are you limited in if you create an app
are you limited in using C++ on that app depending on what model you
chose?
So if I built a Silverlight app or if I built a XAML app can I leverage
C++ code from it? And like I showed graphics just now, and I kind of
focus on graphics. There are a number of scenarios that aren't
graphics-related.
So say I have an existing C++ library that I'm using for financial
calculations, or just legacy C++ libraries that I'd like to use in my
phone app, I'll talk a little bit about how you could leverage those or
if you can.
And then like I said, I think that some people get really excited about
writing C++ or writing native code and I'll talk a little bit about
when and why we would recommend that you use it.
Okay. So a little bit of a busy slide. So I'll talk through it.
There are really two at models in Windows Phone 8 now. You have a
direct 3-D app, a C++ app I just showed based off that template. Pure
native. Absolutely no managed code running in it. The C LL is not
loaded in the process.
It is to the metal app model.
>>: When you say data, you're talking directly writing to the GPU?
>> Albrecht Lindner:
Sorry I didn't hear your question.
>>: So when you say native, I just want to make sure I understand it.
You're talking like a pilot go right to the GPU assembler language or
immediate language?
>> Albrecht Lindner: So the question is is when I say native, do I
mean am I writing real C++ -- sorry real C++ code that compiles down to
IL or to the metal, it's to the metal is the answer. So there is no, I
L here. This is not managed code. You don't have a C LR running in
process. This is actually native code.
And I'll talk a little bit about how you mix the two over here. So you
have the same XAML application model that you had before. So
previously or I should say very, very similar. You were writing
Silverlight apps before. That same code all of those skills you have
around building XAML apps, laying out Sam Mel forms are still
100 percent supported on the phone.
We largely have 100 percent app compat for apps coming from Windows 7.1
on Windows Phone 8. What we've added is the capability to, one,
interop with native code. The way that you call native code from a
managed app is using the Windows runtime or WINRT. I'll demo in a
couple of minutes of actually doing that. Creating a XAML app and how
do you call something that is native.
You also have two additional controls that you can use in a XAML app.
So controls just like your button or this box, et cetera, these are
controls that you can place on a XAML app and they are a D three
surface that you can render D 3 into.
Underneath both of these application models is a common API surface
that is based off of, in large part WIN RT, but is accessible from both
managed and native code.
If I want to get at the file system or want to get at audio or video,
et cetera, I can get at each of those through this common API surface.
>>: So is it the same naming?
>> Albrecht Lindner:
Can I hear that again?
>>: Is there a different naming or the same name?
>> Albrecht Lindner: So the question is are, is the API surface
different names or the same name? Largely the same.
There's some -- there's some API surface you'll actually see, let me
think of an example. Say like for http, there's a little bit of -there's a difference here in that you're using Web client if you're
writing managed code but if you're writing native code you need to go
through IXML http reg request too. A little bit different.
But the core of your question is, hey, if I'm writing managed code and
I flip over to C++, can I write code that accesses the file system or,
say, networking, say bluetooth or, say, NF C. And are the APIs named
the same? And the answer is yes. They're based off of WIN RT. And
I'll talk a little bit about how WIN RT works. Essentially what you're
doing is you are defining an ABI. So an application binary interface.
And that gets projected into C++ or C# or VB.
So same exact API names and functionality here. Just projected into
the languages that or the language you want to write in.
>>: When I talk the WIN 7 specifications, you want some things, I have
reference towards something dot, dot, dot sensor or something like
that. If I want to write something up in C# or C++, so they're going
to make the same kind of [inaudible] or different.
>> Albrecht Lindner: It's the same. So the question is if I want to
get access to WIN RTP, I want to get access to sensors, access to
bluetooth, are the mechanics like how I add a reference to it or place
the name space in my code the same as they were in managed?
And the answer is yes. It's actually even slightly easier. Like for
WIN RTP APIs, the reference is there by default. You'll be using to
get -- I'll show you in a couple of minutes. I don't have it in my
demo sequence but I'll add it. I'll show you what it looks like to get
it.
What I'll show we'll build an WIN RT component and I'll show you how to
get access to those that are built in as well.
>>: So both interoperability and all those kinds of things?
>> Albrecht Lindner: So let's wait on inter -- the question was about
interoperability. Let me keep going because we'll hit this in the
demo. And I'll talk about interop once we get there. Is that okay?
>>: Another question. If you look -- if you reference at least .NET
APIs, WIN RT APIs and are other APIs accessible?
>> Albrecht Lindner: The question was are .NET APIs accessible from
the Windows C++ apps? The answer is no. If I'm in a pure native app,
then I do not even have the C RL loaded. So I can't get at those
managed APIs.
Now if I wanted access to them I could build a XAML app, use WIN RT for
my own custom native code or to wrap my own custom native libraries
where I wanted and use those managed APIs from my XAML code or my
managed code.
>>: Want some legacy from some street binary streams and one of them
contains XML.
>> Albrecht Lindner:
Uh-huh.
>>: XML parser is in .NET API, not managed.
XML parser from specific --
That means I can't access
>> Albrecht Lindner: That's correct. Yeah. Okay. Okay. So the
really, I think, that the message for this slide, what it really says,
is if you want to use C++, it doesn't matter which app model you
choose, you can. So you have access to it.
Usually we recommend that if you're building your triple A games title,
you're probably going to stick with either a pure native application
model or potentially a XAML application model with one of the, probably
the drawing surface background grid control. And I'll talk about why
in a few minutes. There are some small differences between the 2-D 3-D
controls that you should be aware of.
And like one thing that -- like I said, like sometimes like we say,
hey, we've added native to the platform, people get really, really
excited. Not every app needs it. If you're very comfortable writing
your managed app or writing your XAML app, you don't see a perf need or
portability need to write in C++ code then don't.
It's if there's a fair bit of complexity and we'll talk about interop
costs in just a few minutes that it's probably makes sense to stay away
from.
So the top three reasons that we added C++ to the platform this round
were portability, reusability and perf. Notice perf is third.
Obviously important, and there are some scenarios that you just can't
accomplish using managed code, but our primary objective here was being
able to write code and share across our platforms and competitive
platforms both.
Okay. Let me talk about WIN RT just a little bit. Okay. There's
something -- there's something a little bit off with the slides. So
I'm going to flip back over to my PC.
There it goes. Okay. So when somebody says WIN R T2 they're talking
about two things. They're talking about a runtime or infrastructure,
and then APIs that are built on top of that infrastructure. So on the
left-hand side you see here you're talking about plumbing, a tie
system, this common programming model.
On the right-hand side you're talking about features we've pulled in
from Windows 8, things like sensors, things like bluetooth and you're
talking about our specific WIN RT functionality. So platform features
like, say, speech is probably a good example.
Also on the right-hand side, if you're writing your own native library
that's used in a Windows Phone app you're very, very likely at least
shimmying it with WIN RT. I'll show in a second how that's done.
So it's runtime or infrastructure and then separate from that APIs. So
actually features that you're leveraging. And as I said earlier, it's
important to know that if when you write your WIN RT API you define
that interface, part of the great, like the thing that's one of the
really cool things about WIN RT is it's projecting into C++ into C# and
into VB. So when you write these WIN RT components you use them from
any language is the idea.
Okay. I think I hit most of this already. Okay. Let's go over to
code a little bit. So I'll write -- what I'm going to do I'm going to
take a simple XAML app and show you how you call native code from it.
And what I'm going to show is something a heck of a lot more complex
than that that actually Jeff Begeulin in back row wrote. Controls the
Sphero. Makes the Sphero roll around. Talks to it over bluetooth. So
there's when I show it -- I'll talk through it once I show it.
So first simple managed app calling C++ code.
spin up a new C# app.
And so in this case I'll
And all I want to do is when I click this button I'm going to want to
call some kind of -- something in native.
So the way you do this is you have a XAML app. The only way to call
into native code from a XAML app that we support is by using WIN RT.
So it is your interop mechanism. Now, once you're inside of a WIN RT
component, if you wanted to link in libs or dynamically load libraries
you absolutely could.
So it's not a question of, hey, I have these old, I have these legacy
existing DLLs or libs I'd like to leverage. You absolutely could. But
to get access to them from a managed application, you would need to
wrap them or shim them using WIN RT.
So in this case I'm going to add a new project.
>>: To clarify.
This XAML [inaudible] flat API and CTLs.
>> Albrecht Lindner: That's correct. We do not support P invoke for
WIN 32 APIs or DLL calls. The only interop mechanism that we support
from XAML apps is WIN RT.
>>: That's a flat API a place to, for instance, activate audio claim.
And that means I would be forced to use C++ if I want to interrupt with
them from C#, I guess.
>> Albrecht Lindner: That's correct. If you want to interop with WIN
32 APIs, D-3-D is mostly com-based. We have a set of file IOs that are
you would need to wrap them inside a WIN RT component. I'll show you
right now how to do that.
>>: It's also a com interoperate won't work.
>> Albrecht Lindner: That's correct. WIN RT in large part is -- I had
a colleague say, well, WIN RT is really calm with fancy metadata. So
it is really calm under the covers, but if you're using legacy com
components, you can, when you're inside of your WIN RT component. But
you cannot directly from your XAML app from managed code.
So I created my managed app. I put a form I have a form. I put a
button on it. If I want to access native code from here, I can add a
Windows Phone runtime component. Notice you have an anti-DLL static
lib project type in here as well. To use those you would need to go
through this shim.
So here I've added this Windows Phone or WIN RT component. And I'll
write my extraordinarily complex calculation. Maybe. So all I've done
is added this Windows runtime project. I took the header. I added our
prototype for add something. It takes an A and a B. It returns
your -- returns whatever adds and I've implemented it here. And I'm
obviously not showing this to show the complexity of the code that you
can write. What I want to show is the basics of how you actually do
it.
So so far I've got my managed app. I created my native app with my
tiny add something method in it. Now I want to call it. So here I add
a reference to it. Not a surface reference. And then -- so here I'll
show you one of the things -- so that's really it for how do you get at
native code so the absolute basics of I write my managed app. I want
to call something in native. What I just showed is really as much to
take -- it's very simple. So I'll run it. And then I guess one thing
to consider is one thing that we do not have, which we would have loved
to have in Windows Phone 8 is mixed mode debugging. I can't F 11 or I
can't step into this.
So if I hit step into, it just steps over it. If I want to actually
step into my native code, then I need to come to the project settings,
the debugger, and just actually switch it to native. So this is
something that could be somewhat painful as you're debugging, is you're
either debugging manager, you're either debugging native.
Actually to make that explicit switch. Once you're in, I mean once
you're actually debugging your native code, it's what you know and
would expect out of your C++ debugger.
So same locals, watch window. Break points, et cetera.
breaking into native code as well.
So here it's
Okay. Questions before I keep going? Because that's the basics of how
you interop or how you get to native code from managed.
>>: What about .NET file storage and native files stream, where are
they stored? The same place? How would you access the files you saved
in both areas?
>> Albrecht Lindner: The question is -- I'll make it concrete. I
write a file to Iso Store using managed code, can I read it from native
or can I read it and rewrite it from native? Yes. There are some nice
helpers for writing to Iso Store, if you're writing WIN RT code, and I
think that they work from managed code. I don't remember. Do you
know?
There's some nice helpers for like you basically type like Iso Store
colon// and it figures out what the iso store path is and will help you
write them. I know they work for WIN RT because that's what I manage.
But the answer to your question is there's no difference in terms of
what your chamber has rights to write files to.
You're writing to the Iso Store location. And obviously you can read
from your app install location for any art asset, models, meshes, et
cetera. Make sense?
Other questions?
Go ahead.
>>: I'm not sure if you're familiar with it, but today I stumbled upon
under WIN R key there's the graphics questionnaire.interop and
input.interop APIs. I'm sure you're familiar with those. Does that
mean I have to use native code to use those?
>> Albrecht Lindner: The question under WIN RT can you get to
graphics.interop and input.interop. I don't know. If you send me an
e-mail I can find out. I have one more and then I want to keep driving
through.
>>: My question is to make sure that everything, native or the managed,
whatever you write, the piles, goes to iso storage, right?
>> Albrecht Lindner: So the question is similar to over here was if I
use the file system APIs so the IO APIs, do I get any more, any
additional access to where I can write to or where I can read from from
native or from managed or is it the exact same? So if I write a file
with managed IO APIs, is it the exact same as it is with native IO
APIs, and the answer is yes. You write to Iso Store or you can read
from your application install folder. That's it. So no difference
between the two.
And really no capability difference between the two either. If you're
using the WIN RT APIs, then you're executing the same code. You're
just executing it writing the C# projection or the C++ projection.
It's no different. So same capability across the two.
So someone asked earlier how do you get at -- well, actually Jeff does
this in his Sphero app. I'll show the Sphero app real quick.
So the Sphero app is super cool. It has a managed app that is a pretty
simple GUI. This managed app handles the I think I've written a couple
of these, but I think how we split it was the managed app actually does
the bluetooth communication with the Sphero device itself and opens up
a socket to that Sphero device itself. And it hands that socket to a
native app which is this Sphero communicator. It gives it a socket,
WIN RT socket, and it Sphero communicator handles all communication
with the Sphero ball, tells it where to move and what color and
actually hands back to the managed app any communication from Sphero
that comes back.
So mostly I think about color of the ball is what it does right now.
And the way that the Sphero app moves is using sensors. So I'll talk a
little bit about this in just a second. This is how you actually make
the connection in bluetooth. But all this is managed code.
So I wanted to show where you get at sensors. So all you're doing -so this accelerometer is -- I'll hover over it -- it's a WIN RT
accelerometer object. All you're doing to get at it is when you
declare it here, all you're doing is saying declare accelerometer. Now
it's in the Windows device sensors name space. And there's a using
statement at the top. There's no reference to any sensors binary that
we've added. By default you have access or your app has access to all
of the WIN RT built-in runtime.
So when you write this code, all you're doing is something along this
line. You're saying -- all you're doing is here and adding the using
reference and immediately accessing it. So there's no extraordinarily
simple and it's the exact same model that you're likely used to when
you write managed code, when you actually access WIN RT built-in
functionality. So things like accelerometer, gyro, location, et
cetera.
>>: So in the absence of these sensors, the data, the raw data that
from the sensor process the data and the output?
>> Albrecht Lindner: So the question is, when you access the sensor
API, can you get raw data out of it or what does it give you by
default?
Probably depends on what you mean by raw, like I mean the sensor
obviously is there's a driver sitting above it that's passing you that
data from the driver.
>>: On top of that ->> Albrecht Lindner:
Pardon.
>>: [inaudible] on top of the data?
>> Albrecht Lindner: I don't know the intimate details of how the
communication works between the accelerometer, gyro driver and the WIN
RT API, but the information that you get from it is basically raw.
Yes.
So let me show the app. So this is a Sphero. I don't have this phone
built up for DVL. I can use Wolf Vision. Doesn't look as good. Let
me see if I have the Sphero app. No, I don't. I'll use the Wolf
Vision. That's all right.
So one thing with -- the one thing you should recognize is with
bluetooth devices, before you access a bluetooth device from a
bluetooth device from a Windows Phone it must be paired. So I've
already paired this bluetooth device, which is here. This Sphero BRR.
So once you've paired it, it caches host information for actually
talking to it. Can you guys see that okay?
Okay. So and then I'm going to pop over to Jeff's Sphero app. I added
a fancy icon for it. And all we're doing here what it's doing when I
hit Find Devices it's using the peer finder API which is the bluetooth
API to go out enumerate all bluetooth devices paired with this phone.
I've paired this next two which is my robot. It's a Lego mindstorm
robot. I've also paired this Sphero right here. I'm going to hit
Sphero and I'm going to connect to it.
And you can see if you can see the Sphero, if you can't see it feel
free to stand up but the Sphero is lighting up. And then after I hit
calibrate, it's ready to go.
So if I then move then it basically has a stream socket that's running
over RFcom open to the Sphero. As I move my phone around it's pushing
the Sphero ball around. Which is pretty cool. I think one of the
more -- [applause].
I think some of the more satisfactory moments as a programmer you can
get are when the first time that you get like the ball to change color
or helicopter rotor blades, it's not just flying, it's the fact that
I'm talking to it. It's super cool, I think.
How this works with the device works with many devices or most devices
that are bluetooth-enabled on the market. Most of them run over RFcom.
We have a Sphero ball. Like I said, I have a robot -- excuse me, a
next-car. I flew a helicopter at build last week. I don't know if you
saw that. It was really running over sockets. But this communication
the bluetooth or capability is super cool here.
Okay. So and I should say that in good part what makes that possible
is adding C++ to the platform. Like my robot control application that
I use with the phone it's a purely managed application. And I can get
at the bluetooth APIs from that managed app.
However, this sphere row has an SDK that is shipped, that is already
written in C++. So you could take that C++ SDK and port it to managed
or, because you have access to C++ here, you could just plug it in.
The same exact story for the -- I demoed a quad copter at Build last
week where the Parrot team who built the AR drone device that I was
flying there they shipped a C++ SDK. You can use that C++ SDK on any
platform. You write your C++ app, you can use that engine to write
your C++ for Android, for IOS and now for Windows Phone.
So what we did with that quad copter is we took Parrot's C++ SDK and we
ported it, built it for the phone. And with some effort but relatively
minimal, especially if you compared taking that existing C++ SDK and
porting it to managed, C#.
So on a slide earlier where I had near the top was a question of
portability, these are some of the key reasons that we did it. There's
so many C++ OSS libraries, you say SQL light or SDKs out there built
for any platform that we would love to have access to.
And previously we were really pushing folks to port and manage. Port
them to C#. And adding this to the platform makes it so we don't have
to push like that. You just use it.
Okay.
Okay.
How am I doing on time?
I think I'm a little bit over.
Okay.
This will wrap up anyway.
So key take aways. If you want to use C++, any application in Windows
Phone can get at it. If you're managed, you are gated or forced to use
WIN RT as your interop layer. Once you get to C++ through WIN RT you
do whatever you want. Link in libs, load your DLLs, you have from ages
past, knock yourself out.
Primary reasons were around portability and code reuse. There's
obviously some serious benefits around perf. And last is I did focus a
fair bit on the Windows runtime, both the runtime piece or the
infrastructure piece and then the API piece. So I think as you're
building your C++ apps on the phone, you invariably will run into
needing to have a pretty decent base of Windows runtime knowledge. So
I would recommend spinning up on it pretty early. This is one thing I
would suggest.
And I was going to add a resources slide here. So there are a number
of things that I would suggest looking at. Herb Sutter's talk from a
year-ago Build is very applicable to what you're talking about here,
the C++ talk that he did. Peter Torre, did a talk last week at Build
specific for C++ phone. Kind of an expanded version of what I just
did. I'd recommend taking a look at it.
And then I mean otherwise it's like you should start -- there's pretty
good docs for C++ for the phone. You should start seeing more and more
content and samples from the developer team. Questions?
>>: [inaudible].
>> Albrecht Lindner: It was largely a question of cost and effort from
our perspective to continue supporting it. And WIN RT offers a great
interoperability method and consistent story for marshalling and so on
that we could -- basically it was -- it could 100 percent replace or
very nearly the P invoked scenarios, and it drastically simplified
things. That was why.
Other questions?
>>: Well, while you've been speaking I've been installing the SDK on my
laptop.
>> Albrecht Lindner:
Right.
>>: Once it finished, it tagged one of my C PUs call 100 percent saying
micro device processes, do you know anything about this? I'm also
struggling because it said hardware virtualization isn't supported.
>> Albrecht Lindner: So the question is about SDK install. I'll try
it, just because this is one actually interesting thing you should know
about when you install SDK. You need a slat-enabled machine in order
to run the emulator or to run the emulator on your box. I can show you
how to actually detect that use a tool called Core Info to find it.
That's probably what the virtualization problem that you're seeing is.
The other thing, I don't know, I'm happy to look at it with you, happy
to look at it with you after.
Other questions?
[applause]
Okay.
Thanks a lot for your time.