WEBVTT
00:00:00.000 --> 00:00:02.333
Okay, there we go.
00:00:02.333 --> 00:00:04.054
Hello, welcome.
00:00:04.054 --> 00:00:05.101
I'm Steve Teixeira.
00:00:06.700 --> 00:00:08.470
Really glad to be here
with you guys today.
00:00:08.470 --> 00:00:09.720
This is a really exciting day.
00:00:09.720 --> 00:00:13.350
We get to talk a lot about all
the work we've been doing for
00:00:13.350 --> 00:00:18.360
the past 18 months to 2
years on Windows 10 IoT, and
00:00:18.360 --> 00:00:21.510
so I'm gonna share some things
for the first time today,
00:00:21.510 --> 00:00:24.410
in this room, with you all,
so I'm delighted.
00:00:24.410 --> 00:00:27.053
I work on the engineering team,
in Windows IoT,
00:00:27.053 --> 00:00:28.993
I run the program
management team.
00:00:28.993 --> 00:00:31.682
You've seen a number of
things throughout the day, so
00:00:31.682 --> 00:00:34.603
you saw Kevin Dallas earlier
today go through at a high level
00:00:34.603 --> 00:00:37.421
a lot of the things that we're
going on with Windows IoT.
00:00:37.421 --> 00:00:39.630
Kind of a little bit of an
overview of the technical stuff.
00:00:40.670 --> 00:00:42.150
Also some of the ecosystem and
00:00:42.150 --> 00:00:44.580
business model stuff
just before this.
00:00:44.580 --> 00:00:47.122
You saw David Worster
come on stage.
00:00:47.122 --> 00:00:51.005
And David showed you a lot of
the business opportunity related
00:00:51.005 --> 00:00:51.534
to IoT.
00:00:51.534 --> 00:00:54.841
I'm gonna talk to you about what
we've built and what we want you
00:00:54.841 --> 00:00:58.110
to do with it and
how I wanna partner with you.
00:00:58.110 --> 00:01:03.400
So let me get back
to my slides here.
00:01:03.400 --> 00:01:08.080
And by the way, the great thing
about IoT, as you probably saw,
00:01:08.080 --> 00:01:12.060
we were kind of madly trying to
get all the pieces together for
00:01:12.060 --> 00:01:13.920
some of the demonstrations.
00:01:13.920 --> 00:01:18.190
So I've got my Surface and it's
connected to these MinnowBoard
00:01:18.190 --> 00:01:20.650
maxes, and I've got sensors
wired to these, and
00:01:20.650 --> 00:01:23.160
I've got a private
network back here.
00:01:23.160 --> 00:01:25.880
So it's exciting.
00:01:25.880 --> 00:01:28.270
Can I just say that exciting
is probably the right word?
00:01:28.270 --> 00:01:30.470
Exciting is probably
an understatement.
00:01:30.470 --> 00:01:33.570
I wanna start with
the journey that we've had on
00:01:33.570 --> 00:01:35.870
platform convergence
with Windows 10.
00:01:35.870 --> 00:01:39.476
This has been, and I think Don
Box touched on this a little bit
00:01:39.476 --> 00:01:41.188
yesterday, this has been.
00:01:41.188 --> 00:01:44.283
A significant journey for
us, and
00:01:44.283 --> 00:01:48.980
what I've mapped out here
is just sort of the Windows
00:01:48.980 --> 00:01:52.520
embedded/IOT additions
of Windows.
00:01:52.520 --> 00:01:55.830
But essentially we've gone
through this journey to try and
00:01:55.830 --> 00:01:58.475
get all of these things
aligned to be one thing,
00:01:58.475 --> 00:02:01.250
to be one Windows,
to be one core.
00:02:01.250 --> 00:02:03.810
Back in Windows 8,
we finally got a converged
00:02:03.810 --> 00:02:07.700
operating system's kernel not
just across the embedded and
00:02:07.700 --> 00:02:12.070
IoT editions, but also across
a phone and XBox as well.
00:02:12.070 --> 00:02:13.000
And then in Windows 8.1,
00:02:13.000 --> 00:02:15.810
we finally landed on
the ability to have a converged
00:02:15.810 --> 00:02:18.630
developer model,
a converged developer platform.
00:02:18.630 --> 00:02:21.680
And that enabled a developer
promise that said,
00:02:21.680 --> 00:02:24.560
if you build one thing,
you create one app,
00:02:24.560 --> 00:02:27.020
one source base,
you can compile that app and
00:02:27.020 --> 00:02:32.460
target both phones as well as
desktop editions of Windows.
00:02:32.460 --> 00:02:36.550
And with Windows 10, we've
kind of got these converged so
00:02:36.550 --> 00:02:38.640
they're literally
the same thing.
00:02:38.640 --> 00:02:41.930
We literally have one
Windows core that drives all
00:02:41.930 --> 00:02:47.250
the different editions of
Windows and I would add a couple
00:02:47.250 --> 00:02:51.860
additional bits of flavor to
this particular diagram as well.
00:02:51.860 --> 00:02:53.590
One as you see along the bottom,
00:02:53.590 --> 00:02:57.810
our Windows embedded
compact line of products.
00:02:57.810 --> 00:02:59.540
Many of you in this
room have probably used
00:02:59.540 --> 00:03:02.770
those products to build
devices even now ion the past,
00:03:02.770 --> 00:03:06.830
and what this shows is
that two things important.
00:03:06.830 --> 00:03:10.430
One is the embedded compact
product line continues,
00:03:10.430 --> 00:03:13.250
because it actually does have
some capabilities that are not
00:03:13.250 --> 00:03:14.530
present in Windows 10.
00:03:14.530 --> 00:03:18.269
So for example, some of our
customers require an operating
00:03:18.269 --> 00:03:21.201
system that has some
real time capabilities.
00:03:21.201 --> 00:03:23.929
And that's something that
embedded offers that is not
00:03:23.929 --> 00:03:25.240
offered in Windows 10.
00:03:25.240 --> 00:03:28.924
And what we are offering though
is for those devices for
00:03:28.924 --> 00:03:32.369
which it makes sense we want
to enable partners to be
00:03:32.369 --> 00:03:35.118
able to use a modern
version of Windows.
00:03:35.118 --> 00:03:37.650
And we wanna provide
some reporting tools, so
00:03:37.650 --> 00:03:41.070
that you can take your existing
code and move it into Windows.
00:03:41.070 --> 00:03:42.370
And I'll demonstrate
some of those
00:03:42.370 --> 00:03:44.615
porting tools in just a moment.
00:03:44.615 --> 00:03:45.630
And there's one more thing
00:03:45.630 --> 00:03:47.420
I'd like to show in
this diagram as well.
00:03:47.420 --> 00:03:50.880
I'd like to add, Windows on
devices was a program that we
00:03:50.880 --> 00:03:54.220
launched last year at
the Build Conference.
00:03:54.220 --> 00:03:57.276
We started with Intel Galileo
as the platform for
00:03:57.276 --> 00:04:00.851
Windows on Devices and this was
the idea of taking a modern
00:04:00.851 --> 00:04:04.427
version of Windows and shrinking
it down to get it to run on
00:04:04.427 --> 00:04:07.131
these small,
very constrained devices.
00:04:07.131 --> 00:04:09.890
And you saw the first edition
of that last year with
00:04:09.890 --> 00:04:11.078
Windows on Devices.
00:04:11.078 --> 00:04:13.644
Now that program simply
gets folded in and
00:04:13.644 --> 00:04:17.311
becomes a part of Windows 10,
where Windows 10 becomes
00:04:17.311 --> 00:04:20.992
an operating system that extends
to those devices as well.
00:04:24.069 --> 00:04:27.243
Now if you were in David
Werster's session just a few
00:04:27.243 --> 00:04:30.779
moments ago, Dave talked about
the different editions of
00:04:30.779 --> 00:04:33.610
Windows, for
different classes of devices.
00:04:33.610 --> 00:04:36.640
And you see I have those
depicted, on the graph or
00:04:36.640 --> 00:04:39.610
on this foil,
over to the far left.
00:04:39.610 --> 00:04:42.150
And let me just run through
these really quickly from top to
00:04:42.150 --> 00:04:45.310
bottom because they describe
some important characteristics.
00:04:45.310 --> 00:04:48.740
On the top you have Windows
10 IoT for industry devices.
00:04:50.870 --> 00:04:54.530
This addition of Windows will
run on the think of it as PC
00:04:54.530 --> 00:04:55.731
class hardware.
00:04:55.731 --> 00:05:00.188
So generally, these devices are
built around PC motherboards,
00:05:00.188 --> 00:05:03.845
but employed in some way that
is not a traditional PC.
00:05:03.845 --> 00:05:08.519
These devices are often
manifested as point of sales
00:05:08.519 --> 00:05:12.664
terminals, cash registers,
ATM machines,
00:05:12.664 --> 00:05:18.206
medical equipment such as MRIs,
Kiosks, digital signage.
00:05:18.206 --> 00:05:22.339
These are some examples of the
kinds of devices that get built
00:05:22.339 --> 00:05:26.637
around us which is fundamentally
the full desktop Windows with
00:05:26.637 --> 00:05:29.718
the ability to be tailored and
configured for
00:05:29.718 --> 00:05:31.441
an embedded IoT device.
00:05:31.441 --> 00:05:34.912
And then moving down a little
bit, Windows 10 IoT for
00:05:34.912 --> 00:05:36.045
mobile devices,
00:05:36.045 --> 00:05:40.047
this is the edition of Windows
that will target small devices,
00:05:40.047 --> 00:05:43.598
smaller screened devices
that require capabilities in
00:05:43.598 --> 00:05:47.543
computing power similar to that
of a mobile phone or a tablet.
00:05:47.543 --> 00:05:48.683
So typically,
00:05:48.683 --> 00:05:52.640
these are built around
ARM Cortex-A architecture.
00:05:52.640 --> 00:05:56.431
They tend to follow
the chassis specifications for
00:05:56.431 --> 00:06:00.749
a mobile phone and the typical
kinds of devices that you see
00:06:00.749 --> 00:06:05.260
in this category include things
like mobile point of sales.
00:06:05.260 --> 00:06:06.180
So some
00:06:06.180 --> 00:06:08.710
of the devices that Dave was
up here demonstrating earlier.
00:06:09.810 --> 00:06:13.560
Small handhelds to be able
to do mag stripe reading or
00:06:13.560 --> 00:06:16.760
to be able to do
bar-code scanning.
00:06:16.760 --> 00:06:20.177
Things like that and
then finally, Windows 10 IoT for
00:06:20.177 --> 00:06:23.667
small devices, a new edition
that we've introduced and
00:06:23.667 --> 00:06:25.863
launched here at
winhec this year.
00:06:25.863 --> 00:06:29.438
I'll show you some demos of this
edition of Windows running on,
00:06:29.438 --> 00:06:31.755
I have some MinnowBoard MAXs
up here, and
00:06:31.755 --> 00:06:34.419
I wanna show you some of
these things in action.
00:06:34.419 --> 00:06:37.236
But this one is fundamentally
different in a number of
00:06:37.236 --> 00:06:40.500
different ways and I'll show
you that in a subsequent slide.
00:06:41.600 --> 00:06:44.530
Now, across all these different
editions, for all these
00:06:44.530 --> 00:06:47.440
different devices ranging
from sort of the largest,
00:06:47.440 --> 00:06:50.900
most powerful computing devices,
PC class devices or
00:06:50.900 --> 00:06:54.690
server class devices down to
these small class devices,
00:06:55.780 --> 00:06:58.440
typically cortex a and
higher, however.
00:06:58.440 --> 00:07:01.200
We wanna deliver three
pillars of value
00:07:01.200 --> 00:07:02.670
across all of these
different things.
00:07:02.670 --> 00:07:05.710
The first pillar is this idea
of one Windows Platform.
00:07:05.710 --> 00:07:09.990
I've got one thing that I need
to target as a system builder,
00:07:09.990 --> 00:07:11.650
as a software developer,
as an OEM,
00:07:11.650 --> 00:07:14.950
as a maker, I have one platform
that I need to target.
00:07:16.170 --> 00:07:21.280
And Windows 10 truly is,
the platform that allows you to
00:07:21.280 --> 00:07:23.920
target the widest possible
range of devices.
00:07:25.520 --> 00:07:27.970
One core, scalable from
smallest to biggest.
00:07:29.070 --> 00:07:32.130
You heard Don talk yesterday
about the universal application
00:07:32.130 --> 00:07:35.650
platform and the idea that I
can build one application, or
00:07:35.650 --> 00:07:39.710
I can build one driver and I can
leverage that investment across
00:07:39.710 --> 00:07:42.120
all these different devices.
00:07:42.120 --> 00:07:44.400
And by the way,
that application or
00:07:44.400 --> 00:07:48.040
that driver you can leverage not
just across IoT devices, but
00:07:48.040 --> 00:07:52.830
really across any Windows
Universal Platform device.
00:07:54.180 --> 00:07:58.820
And finally, one approach to
being able to manage the device,
00:07:58.820 --> 00:08:02.030
provision the device,
to deploy the device.
00:08:02.030 --> 00:08:04.080
I just have one way that
I can do that stuff and
00:08:04.080 --> 00:08:07.150
I can treat all my devices,
like Windows assets.
00:08:07.150 --> 00:08:11.840
And what it enables, is,
as an OEN, as a device builder,
00:08:11.840 --> 00:08:15.100
you can build hardware that then
you can sell into enterprise,
00:08:15.100 --> 00:08:17.810
enabling that enterprise to
manage that device just like
00:08:17.810 --> 00:08:21.120
their Windows Desktop and
mobile corporate assets.
00:08:21.120 --> 00:08:21.740
Huge value.
00:08:22.840 --> 00:08:25.120
Now the second pillar
is around security.
00:08:25.120 --> 00:08:28.280
Being because these are built
around the same Windows core,
00:08:28.280 --> 00:08:31.970
we can deliver that strong
Windows security value
00:08:31.970 --> 00:08:34.840
proposition across this
broad range of devices.
00:08:34.840 --> 00:08:37.680
And I'll drill down into some
of the specifics of that in
00:08:37.680 --> 00:08:39.350
just a moment.
00:08:39.350 --> 00:08:42.940
Being able to tailor my device,
so I wanna lock it down.
00:08:42.940 --> 00:08:45.920
I wanna prevent people from
having access to components of
00:08:45.920 --> 00:08:47.490
the user interface
that shouldn't or I
00:08:47.490 --> 00:08:50.380
wanna prevent people from doing
certain things from the screen,
00:08:50.380 --> 00:08:53.210
or I want the device to
always be in a fresh state.
00:08:53.210 --> 00:08:55.510
Those are some of
the things that we support.
00:08:55.510 --> 00:09:00.090
And also on security, I used to
work in the information security
00:09:00.090 --> 00:09:04.290
space years ago and I always
found it was kind of this
00:09:04.290 --> 00:09:07.424
race between the bad guys and
the good guys.
00:09:07.424 --> 00:09:10.555
There will be an exploits
the good guy platform.
00:09:10.555 --> 00:09:12.652
Vendors would fix that exploit
then there would be another
00:09:12.652 --> 00:09:14.076
exploit and
it tends to be an arms race.
00:09:14.076 --> 00:09:18.001
And what you need is you need a
trusted partner that's gonna be
00:09:18.001 --> 00:09:21.182
there with you, so
that as this race is underway.
00:09:21.182 --> 00:09:23.702
We wanna be able to offer
continued support, so
00:09:23.702 --> 00:09:26.411
all these devices can
connect to Windows Update and
00:09:26.411 --> 00:09:28.994
continue to get security
updates over time, and
00:09:28.994 --> 00:09:32.144
you can count on the fact that
Microsoft is gonna continue to
00:09:32.144 --> 00:09:35.560
innovate in making these devices
increasingly safe over time.
00:09:37.490 --> 00:09:40.070
Finally, the third pillar
is around connectivity.
00:09:40.070 --> 00:09:43.510
Windows 10 IoT devices
are born to be connected.
00:09:43.510 --> 00:09:46.700
They're born to be connected
with other devices on a local or
00:09:46.700 --> 00:09:48.330
proximal network.
00:09:48.330 --> 00:09:50.570
And they're born to be
connected to the cloud.
00:09:50.570 --> 00:09:53.710
To be able to deliver
service based scenarios and
00:09:53.710 --> 00:09:56.858
I'll describe those
a little bit later as well.
00:09:56.858 --> 00:10:00.692
What's more, Kevin talked this
morning about being able to get
00:10:00.692 --> 00:10:03.258
services relevant to
my Windows devices.
00:10:03.258 --> 00:10:06.647
Where I wanna understand based
on the telemetry coming off my
00:10:06.647 --> 00:10:07.918
device Is it healthy?
00:10:07.918 --> 00:10:09.618
What's happening
with that device?
00:10:14.577 --> 00:10:18.367
So here's what we call a nested
doll depiction of the operating
00:10:18.367 --> 00:10:19.590
system additions.
00:10:21.050 --> 00:10:26.800
For engineers in the room like
me, this isn't 100% accurate.
00:10:26.800 --> 00:10:29.660
But it's a great mental model
for how to think about how these
00:10:29.660 --> 00:10:32.570
operating system additions
will relate to one another.
00:10:32.570 --> 00:10:34.250
And when I say it's not
completely accurate,
00:10:34.250 --> 00:10:38.610
I mean you see
the mobile shell in here
00:10:38.610 --> 00:10:43.160
as a sub set of the full Windows
industry shell, and it's not
00:10:43.160 --> 00:10:45.580
true that the industry devices
include the mobile shell.
00:10:45.580 --> 00:10:47.220
So there's some
differences here.
00:10:47.220 --> 00:10:51.000
But I do want to talk about,
as you look at this,
00:10:51.000 --> 00:10:54.510
the biggest part of this circle,
for industry devices.
00:10:54.510 --> 00:10:57.030
These are devices that have
the full desktop shell.
00:10:57.030 --> 00:10:58.360
I can configure it.
00:10:58.360 --> 00:11:00.780
I can make those devices
either run the shell,
00:11:00.780 --> 00:11:02.760
I can make them run
one application.
00:11:02.760 --> 00:11:06.030
I can still tailor that device
to what I want it to be.
00:11:06.030 --> 00:11:06.810
But it's a full
00:11:06.810 --> 00:11:09.320
version of Windows with all
the capabilities therein.
00:11:10.450 --> 00:11:13.180
For mobile, these are devices
that have smaller screens that
00:11:13.180 --> 00:11:15.040
run the mobile Windows shell.
00:11:15.040 --> 00:11:17.660
The devices conform to
the chassis requirements for
00:11:17.660 --> 00:11:19.020
Windows Mobile.
00:11:19.020 --> 00:11:21.360
From a RAM and
storage standpoint,
00:11:21.360 --> 00:11:25.195
they tend to require a minimum
of 512 megabytes of RAM and
00:11:25.195 --> 00:11:26.360
four gigabytes of storage.
00:11:27.390 --> 00:11:29.240
And then for small devices,
these are for
00:11:29.240 --> 00:11:31.460
small, dedicated devices.
00:11:31.460 --> 00:11:33.420
There's no Windows shell.
00:11:33.420 --> 00:11:35.000
So the personality for
00:11:35.000 --> 00:11:37.890
this device is not the Windows
shell personality.
00:11:37.890 --> 00:11:38.770
The personality for
00:11:38.770 --> 00:11:41.520
this device is the personality
that you create for it.
00:11:41.520 --> 00:11:44.390
It's the hardware that you
design, the industrial design,
00:11:44.390 --> 00:11:46.760
and it's the user interface and
the software and
00:11:46.760 --> 00:11:49.440
applications that you write
that run on that device.
00:11:49.440 --> 00:11:51.090
That make up what
the personality for
00:11:51.090 --> 00:11:52.640
that device needs to be.
00:11:53.820 --> 00:11:57.890
Because there's no shell, these
don't have any inbox Microsoft
00:11:57.890 --> 00:12:01.290
applications, so
you won't find the Cortana app.
00:12:01.290 --> 00:12:03.450
You won't find the travel app.
00:12:03.450 --> 00:12:06.320
You won't find notepad
on these devices.
00:12:06.320 --> 00:12:09.200
The apps that are there, the
ones you will write in addition
00:12:09.200 --> 00:12:12.890
to what's provided, just with
a core operating system.
00:12:12.890 --> 00:12:15.820
And there's no access to
the store application.
00:12:15.820 --> 00:12:19.750
So, because these devices can
have very different chassis,
00:12:19.750 --> 00:12:22.480
it doesn't make sense to run
the store in these devices,
00:12:22.480 --> 00:12:24.780
some of them don't
even have screens.
00:12:24.780 --> 00:12:27.320
These can be headless or
headed devices.
00:12:27.320 --> 00:12:30.976
From a system requirement
stand point In the headless
00:12:30.976 --> 00:12:33.827
configuration, that
is with no screen.
00:12:33.827 --> 00:12:38.286
Our target is to be able to
run inside of 256 MB of RAM.
00:12:38.286 --> 00:12:40.932
In a headed configuration
with a screen,
00:12:40.932 --> 00:12:44.800
our target is to be able to run
at a minimum of 512 MB of RAM.
00:12:46.120 --> 00:12:51.100
The storage specification,
2 GB We're actually designing
00:12:51.100 --> 00:12:54.650
the operating system itself
to fit inside of a gigabyte.
00:12:54.650 --> 00:12:56.090
And so far so good.
00:12:56.090 --> 00:12:59.300
It looks like we're well on
track to hitting that target.
00:12:59.300 --> 00:13:02.870
So that gives you
a gigabyte free to do
00:13:02.870 --> 00:13:07.120
swap file application storage,
application data,
00:13:07.120 --> 00:13:09.770
whatever applications you
want to put on that device.
00:13:09.770 --> 00:13:11.770
So most devices.
00:13:11.770 --> 00:13:13.680
Can ship with two
gigabytes of ram and
00:13:13.680 --> 00:13:16.680
be completely functional
including the operating system.
00:13:16.680 --> 00:13:19.400
But the great thing is that
this supports the entire
00:13:19.400 --> 00:13:22.260
full modern application
model and driver model.
00:13:22.260 --> 00:13:25.520
So I can literally write one
application the same application
00:13:25.520 --> 00:13:27.689
and run it across
all these editions.
00:13:28.950 --> 00:13:32.480
Now over here on the right-hand
side of this diagram,
00:13:32.480 --> 00:13:35.140
you can see all of
the Windows device services.
00:13:35.140 --> 00:13:36.160
These are available for
00:13:36.160 --> 00:13:40.260
all of these IOT additions,
extending the value of Windows
00:13:40.260 --> 00:13:44.170
not just to the bits that run
on some particular device but
00:13:44.170 --> 00:13:47.500
to be able to connect them
to a set of cloud services.
00:13:47.500 --> 00:13:50.410
And those services can
include gaining insights from
00:13:50.410 --> 00:13:53.820
my telemetry, and I'll talk
more about that later on.
00:13:53.820 --> 00:13:57.200
How I manage the updates
to my device.
00:13:57.200 --> 00:14:00.190
How I want my device to
interoperate with other devices
00:14:00.190 --> 00:14:01.440
through the Cloud.
00:14:01.440 --> 00:14:03.290
And it's ready for Azure IoT.
00:14:03.290 --> 00:14:06.290
One of the announcements made
earlier this week at a different
00:14:06.290 --> 00:14:09.430
conference was around Azure IOT
and I'll talk a little bit about
00:14:09.430 --> 00:14:12.790
that in the second hour of the
presentation, so you can kind of
00:14:12.790 --> 00:14:16.640
understand how Azure and Windows
IOT relate to one another, and
00:14:16.640 --> 00:14:21.310
how they can work together to
create best in class solutions.
00:14:21.310 --> 00:14:23.050
Now, one of the questions that
00:14:24.300 --> 00:14:26.780
can come up when you see
this diagram is great.
00:14:26.780 --> 00:14:30.160
Which Windows edition
should I use for my device?
00:14:30.160 --> 00:14:32.950
And there's a pretty simple
way to filter through this.
00:14:34.120 --> 00:14:38.050
The first question to ask is,
do you need the Windows desktop?
00:14:38.050 --> 00:14:38.900
The answer's yes.
00:14:38.900 --> 00:14:42.410
Well, there's one edition
that has a Windows desktop or
00:14:42.410 --> 00:14:44.690
if you need Win32 applications.
00:14:44.690 --> 00:14:48.720
Things that are written
in Win32 like MFC or
00:14:48.720 --> 00:14:52.800
full access to desktop .Net,
WPF, any of those full desktop
00:14:52.800 --> 00:14:56.340
technologies then yes,
you should use industry.
00:14:58.040 --> 00:15:01.680
If on the other hand you
don't need those things but
00:15:03.090 --> 00:15:06.970
you do need a Windows shell, so
you want the shell experience,
00:15:06.970 --> 00:15:09.505
you want to be able to
run multiple applications
00:15:09.505 --> 00:15:13.375
simultaneously and
share a screen experience.
00:15:13.375 --> 00:15:16.595
You want the Microsoft Windows
first party application
00:15:16.595 --> 00:15:17.835
on the device.
00:15:17.835 --> 00:15:21.625
Or you want the cellular voice
stack to be on the device.
00:15:21.625 --> 00:15:25.855
If any of those things are true,
then the appropriate operating
00:15:25.855 --> 00:15:29.410
system addition to select will
be the mobile edition for IoT.
00:15:29.410 --> 00:15:33.260
And finally if none
of that is true
00:15:33.260 --> 00:15:37.770
then you can run on Windows
10 IOT for small devices.
00:15:37.770 --> 00:15:40.470
So this represents kind
of the quick decision
00:15:40.470 --> 00:15:43.120
tree that you would
use to determine which
00:15:43.120 --> 00:15:45.119
operating system edition
that you might wanna run.
00:15:47.520 --> 00:15:50.410
Now I'd like to start by
talking about this one Windows
00:15:50.410 --> 00:15:51.920
platform value proposition.
00:15:51.920 --> 00:15:53.950
And going into a little
bit more detail for you.
00:15:56.170 --> 00:15:57.860
Let's start with
universal drivers.
00:15:59.295 --> 00:16:02.335
Universal drivers as Don
demonstrated yesterday
00:16:02.335 --> 00:16:06.015
provide you with
the ability to invest once
00:16:06.015 --> 00:16:08.995
in writing a Windows driver and
being able to leverage that
00:16:08.995 --> 00:16:11.945
investment across all
the different divisions.
00:16:11.945 --> 00:16:16.620
Today kind of sorry to
say that if you choose
00:16:16.620 --> 00:16:20.180
to invest in the Windows
embedded ecosystem today, and
00:16:20.180 --> 00:16:23.500
you want to build a piece of
hardware that requires a driver,
00:16:23.500 --> 00:16:25.320
you have to write three,
00:16:25.320 --> 00:16:27.780
to get it to run in all the
different editions of Windows.
00:16:27.780 --> 00:16:31.200
You would have to write
one driver, for Win32,
00:16:31.200 --> 00:16:33.780
for the desktop
version of Windows.
00:16:33.780 --> 00:16:36.560
You would have to write another
driver if you wanted that same
00:16:36.560 --> 00:16:40.040
device to be able to
work with Windows phone.
00:16:40.040 --> 00:16:43.160
And then if you wanted that same
device to be able to work with
00:16:43.160 --> 00:16:45.490
embedded compact,
that would be yet
00:16:45.490 --> 00:16:48.010
another driver with
a different driver model.
00:16:48.010 --> 00:16:49.730
So that's the past and
00:16:49.730 --> 00:16:52.560
we recognize that that really
introduced a lot of friction
00:16:52.560 --> 00:16:55.430
into the ecosystem
that isn't helpful.
00:16:55.430 --> 00:16:58.450
Moving forward into Windows
10 I can have one investment.
00:16:58.450 --> 00:16:59.760
I can build one driver.
00:16:59.760 --> 00:17:02.560
And then I can leverage
that one investment across,
00:17:02.560 --> 00:17:06.780
many different device classes,
including but
00:17:06.780 --> 00:17:09.330
beyond IOT devices.
00:17:09.330 --> 00:17:13.221
Now in order to come up with
this universal driver platform,
00:17:13.221 --> 00:17:14.976
we actually went through,
00:17:14.976 --> 00:17:18.868
we did the work to scan through
over a hundred thousand active
00:17:18.868 --> 00:17:22.684
real world device drivers to
understand how did they work,
00:17:22.684 --> 00:17:27.036
what operating system components
did they require, what API calls
00:17:27.036 --> 00:17:30.469
did they make that we should
want to make available for
00:17:30.469 --> 00:17:33.119
the modern universal
driver platform.
00:17:33.119 --> 00:17:37.101
And in doing so, we managed to
converge on a set that became
00:17:37.101 --> 00:17:41.412
the universal driver API set,
that then developers can use and
00:17:41.412 --> 00:17:45.830
hardware developers can use to
build out their device drivers.
00:17:46.900 --> 00:17:50.860
On the bottom of this slide you
can see examples of some of
00:17:50.860 --> 00:17:54.790
the varieties of drivers that
are kind of built into the model
00:17:54.790 --> 00:17:59.740
that you should be able to very
easily build with Windows 10.
00:17:59.740 --> 00:18:04.220
Both IoT but also frankly
broadly Windows 10 editions.
00:18:06.648 --> 00:18:11.580
There's a step-by-step process
here that I've depicted in order
00:18:11.580 --> 00:18:13.980
to build universal drivers.
00:18:15.580 --> 00:18:19.420
Step one is to download
Visual Studio.
00:18:19.420 --> 00:18:22.230
And, you probably saw the
announcement that there are some
00:18:22.230 --> 00:18:25.940
free Additions of Visual Studio
that makes this easier than it's
00:18:25.940 --> 00:18:27.150
ever been.
00:18:27.150 --> 00:18:29.030
In addition to Visual Studio,
00:18:29.030 --> 00:18:30.690
I need
the Windows Development Kit,
00:18:30.690 --> 00:18:33.650
the WDK, because that's
the thing that contains
00:18:33.650 --> 00:18:36.970
the necessary components for
driver writers.
00:18:36.970 --> 00:18:40.010
Now when I do that, I can build
and debug that universal driver,
00:18:40.010 --> 00:18:41.940
and I can do it on a PC.
00:18:41.940 --> 00:18:44.860
I don't need to do it on a small
device, because it's one model.
00:18:44.860 --> 00:18:47.490
I can kinda perfect it
on the PC first, and
00:18:47.490 --> 00:18:50.180
then move out to other
kinds of devices.
00:18:50.180 --> 00:18:53.650
I can test it using
the WDK testing tools.
00:18:53.650 --> 00:18:56.130
I can validate it on all
the boards I wanna run on.
00:18:56.130 --> 00:19:00.140
And of course we recommend that
you do validate that driver
00:19:00.140 --> 00:19:03.060
on a representative sample
of the kinds of hardware you
00:19:03.060 --> 00:19:04.430
like to run on.
00:19:04.430 --> 00:19:09.100
And finally I can submit
that driver for signing, so
00:19:09.100 --> 00:19:13.230
that it can be part of
the Windows driver ecosystem.
00:19:16.980 --> 00:19:21.770
Now, as you consider the move to
universal drivers, I wanted to
00:19:21.770 --> 00:19:25.030
give you a bit of a cheat sheet
to understand based on where you
00:19:25.030 --> 00:19:28.600
might be today In terms of
Windows driver development.
00:19:28.600 --> 00:19:34.660
How do you get to where you want
to go with universal drivers?
00:19:34.660 --> 00:19:38.260
So, if today,
you are using inbox drivers that
00:19:38.260 --> 00:19:40.930
are class drivers that
are built into Windows.
00:19:40.930 --> 00:19:43.270
You know, these are things
like USB storage,
00:19:43.270 --> 00:19:46.360
or mice of keyboards, or
those sorts of things.
00:19:46.360 --> 00:19:48.530
You don't have to do anything.
00:19:48.530 --> 00:19:51.330
Your peripheral will
automatically work if it's using
00:19:51.330 --> 00:19:52.280
a class driver today.
00:19:52.280 --> 00:19:54.380
It will automatically
work in Windows 10.
00:19:54.380 --> 00:19:58.528
So there's literally no work to
do for any Windows 10 edition.
00:19:58.528 --> 00:20:02.568
For kernel node drivers we've
had a goal of very high backward
00:20:02.568 --> 00:20:03.738
compatibility.
00:20:03.738 --> 00:20:05.265
Particular for
00:20:05.265 --> 00:20:11.028
those areas where the device
Surface area has converged.
00:20:11.028 --> 00:20:13.546
So typically what we see
are there are some changes that
00:20:13.546 --> 00:20:15.300
you might have to make.
00:20:15.300 --> 00:20:17.876
You have to retest
those changes, and
00:20:17.876 --> 00:20:21.831
then your driver will run on
all editions of Windows 10.
00:20:21.831 --> 00:20:26.222
And then finally for
user mode drivers and services,
00:20:26.222 --> 00:20:31.296
the big thing that you'll have
to become accustomed to is that
00:20:31.296 --> 00:20:36.274
the universal driver platform
include a smaller Win32 API
00:20:36.274 --> 00:20:41.550
surface area than the user mode
driver surface area today.
00:20:41.550 --> 00:20:44.000
So you may find yourself in
a situation where you're using
00:20:44.000 --> 00:20:47.300
some APIs that aren't available
in the modern driver platform.
00:20:47.300 --> 00:20:51.080
A lot of times there's
a replacement API to use,
00:20:51.080 --> 00:20:56.560
what we found is that as Win32
grew over 20, 30 years of Win32,
00:20:56.560 --> 00:21:01.470
we ended up in situations
that were API functions that.
00:21:02.790 --> 00:21:06.200
Maybe overlapping in
capability and in nature.
00:21:06.200 --> 00:21:08.890
And in those cases we kind
of sought to converge
00:21:08.890 --> 00:21:12.230
on a single way to do some
particular piece of behavior.
00:21:12.230 --> 00:21:14.918
So if you have that type of
situation there's a little bit
00:21:14.918 --> 00:21:15.932
of work for you to do.
00:21:15.932 --> 00:21:19.915
And in some cases there are APIs
that are not available because
00:21:19.915 --> 00:21:22.143
some functionality has changed.
00:21:22.143 --> 00:21:25.312
And in those cases,
there may be some redesign or
00:21:25.312 --> 00:21:28.031
re-implementation of
APIs necessary.
00:21:29.724 --> 00:21:33.636
Now, wanted to switch over and
do a driver demo, just to show
00:21:33.636 --> 00:21:37.724
you, give you a flavor for the
Visual Studio experience here.
00:21:37.724 --> 00:21:42.717
And let me, Let me see if I
00:21:42.717 --> 00:21:44.632
can get the appropriate
screen up here.
00:21:53.187 --> 00:21:54.418
Okay, so far so good.
00:22:01.198 --> 00:22:04.811
All right, so what I have here
is I have a virtual machine, and
00:22:04.811 --> 00:22:07.686
this virtual machine is
running Visual Studio.
00:22:07.686 --> 00:22:10.561
And inside of Visual Studio,
00:22:10.561 --> 00:22:14.820
I have driver project
that I'm working on.
00:22:14.820 --> 00:22:17.510
So, before we kind of jump into
the code and look at Visual
00:22:17.510 --> 00:22:20.430
Studio I want to describe a
little bit about what I'm doing.
00:22:20.430 --> 00:22:26.180
So what I have here is I have
an Intel MinnowBoard MAX.
00:22:26.180 --> 00:22:30.318
It's connected to this little
sensor that you see here and
00:22:30.318 --> 00:22:33.027
kinda wanted to this
show this to you.
00:22:33.027 --> 00:22:37.333
I'm gonna try something crazy
right now, and we'll see if this
00:22:37.333 --> 00:22:41.239
works, and if this works,
it'll be a great example of all
00:22:41.239 --> 00:22:45.167
the awesome value that you can
get out of Windows devices.
00:22:45.167 --> 00:22:47.294
And if it doesn't work,
we'll smile, and
00:22:47.294 --> 00:22:50.640
we'll all pretend together that
this worked really, really well.
00:22:52.380 --> 00:22:58.682
So, let's see,
if I come back to my device.
00:22:58.682 --> 00:22:59.343
Let's see here.
00:23:05.068 --> 00:23:06.912
Yes.
00:23:06.912 --> 00:23:10.032
It's gonna happen,
any moment now.
00:23:19.186 --> 00:23:20.006
Any moment now.
00:23:26.005 --> 00:23:28.425
Okay, we may be near the point
where we all smile and
00:23:28.425 --> 00:23:30.901
suggest that this worked really,
really well, but
00:23:30.901 --> 00:23:32.437
I'm gonna give it one more try.
00:23:35.876 --> 00:23:37.256
I'm gonna exit out of this.
00:23:40.891 --> 00:23:41.819
Watch it again.
00:23:52.654 --> 00:23:55.964
Okay, well what I had hoped to
show you, which clearly isn't
00:23:55.964 --> 00:23:59.272
working right now, is I hoped to
show you a kind of live video of
00:23:59.272 --> 00:24:02.565
what this thing looks like
up on the big screen.
00:24:02.565 --> 00:24:05.520
But instead, you'll have to
trust me that it looks really,
00:24:05.520 --> 00:24:09.360
really neat and it looks really
small from the back of the room.
00:24:09.360 --> 00:24:13.090
This guy is running live
right now, connect it up.
00:24:13.090 --> 00:24:17.670
I've got my sensor, this sensor
is an ultraviolet light sensor.
00:24:17.670 --> 00:24:21.390
And so, I have here a little
ultraviolet light flashlight and
00:24:21.390 --> 00:24:26.000
I can shine this onto the sensor
and I can get luminosity
00:24:26.000 --> 00:24:30.390
reading of how bright this
ultraviolet light might be.
00:24:30.390 --> 00:24:32.670
So this is a driver
that I wrote.
00:24:32.670 --> 00:24:34.760
Let me come back into my
driver just to show you.
00:24:36.760 --> 00:24:39.140
So here we go,
back into Visual Studio.
00:24:39.140 --> 00:24:41.790
And I didn't want to do
a big deep drill down,
00:24:41.790 --> 00:24:43.920
big deep dive on
driver development.
00:24:43.920 --> 00:24:46.280
But I did want to show you
that this universal driver,
00:24:46.280 --> 00:24:49.650
if you're familiar with Windows
driver writing, kind of adheres
00:24:49.650 --> 00:24:53.000
to the fundamental precepts
that you're probably accustomed
00:24:53.000 --> 00:24:56.820
to if you're coming from the
Windows driver eco-system today.
00:24:56.820 --> 00:25:00.770
So what we're looking at right
now is I've got this get data
00:25:00.770 --> 00:25:01.565
function.
00:25:01.565 --> 00:25:05.398
This is the function that gets
called whenever an application
00:25:05.398 --> 00:25:07.910
requests to read data
out of the device.
00:25:09.180 --> 00:25:11.260
If we drilled down into
this get data function,
00:25:11.260 --> 00:25:15.110
what we'll find deep down
is it ends up calling,
00:25:15.110 --> 00:25:18.620
I squared C sensor
read register.
00:25:18.620 --> 00:25:21.490
So, this is the function that
actually reads data, this
00:25:21.490 --> 00:25:26.120
particular device happens to be
connect to the I squared C bus.
00:25:26.120 --> 00:25:28.810
And so you can see this
function, and if I were to go
00:25:28.810 --> 00:25:34.160
down through this function you
would see a couple things.
00:25:34.160 --> 00:25:38.640
Typical driver development stuff
like Windows Driver framework,
00:25:38.640 --> 00:25:40.270
creating memory blocks,
00:25:40.270 --> 00:25:42.150
I would be able to
kind of drill down and
00:25:42.150 --> 00:25:46.470
see a Windows driver framework
reading a synchronize IO.
00:25:46.470 --> 00:25:48.100
So typical Windows driver,
00:25:48.100 --> 00:25:50.990
although this is built
as a universal driver.
00:25:52.510 --> 00:25:55.081
So let me head off and
see if I can take a look now.
00:25:55.081 --> 00:25:58.329
I'm running the driver right
now on this MinnowBoard MAX, so
00:25:58.329 --> 00:25:59.961
let me see if I can switch over.
00:26:05.148 --> 00:26:09.062
And if things go well, that's
the other neat thing I find,
00:26:09.062 --> 00:26:12.270
because I just have to
kinda pause for a minute.
00:26:12.270 --> 00:26:15.710
Because these things are running
Windows, I can turn on a mouse.
00:26:15.710 --> 00:26:18.340
And the mouse just sort of
automatically works with this
00:26:18.340 --> 00:26:21.220
device, which I don't know,
I just find fascinating.
00:26:22.450 --> 00:26:23.886
Let me run this application.
00:26:26.742 --> 00:26:30.130
And take a moment for this
application to kinda start up.
00:26:30.130 --> 00:26:31.020
So here we go.
00:26:31.020 --> 00:26:32.190
This is an application now,
00:26:32.190 --> 00:26:33.930
it's running now on
this MinnowBoard Max,
00:26:33.930 --> 00:26:35.900
what you're seeing.
00:26:35.900 --> 00:26:38.180
Right now, it's saying that
there's no ultraviolet light.
00:26:38.180 --> 00:26:41.040
So, whatever these very bright
lights that are shining on me,
00:26:41.040 --> 00:26:44.270
clearly aren't delivering
much ultraviolet light, so
00:26:44.270 --> 00:26:46.230
I probably won't get a sunburn.
00:26:47.250 --> 00:26:49.710
If I shine a light on here.
00:26:49.710 --> 00:26:50.370
Let's see, there we go.
00:26:50.370 --> 00:26:52.480
So you can see it
becomes very bright.
00:26:52.480 --> 00:26:56.080
Maybe if I pull away it'll
go out a little bit.
00:26:56.080 --> 00:26:58.055
So there you go, you can
see a nice step function.
00:26:58.055 --> 00:27:00.712
Hopefully you can see that
pretty well from the back of
00:27:00.712 --> 00:27:01.640
the room.
00:27:01.640 --> 00:27:02.820
Seems to be working okay.
00:27:02.820 --> 00:27:05.774
This particular one has
a reasonably slow refresh and
00:27:05.774 --> 00:27:07.552
about a second of latency or so.
00:27:07.552 --> 00:27:10.268
But other than that,
pretty cool.
00:27:10.268 --> 00:27:11.065
And again,
00:27:11.065 --> 00:27:14.975
leveraging my ability to create
a single Windows driver,
00:27:14.975 --> 00:27:19.850
I could, because I I built this
driver using a universal driver.
00:27:19.850 --> 00:27:23.062
I could connect this
device to another kind of
00:27:23.062 --> 00:27:25.596
board that also had an I2C bus,
and
00:27:25.596 --> 00:27:29.158
it would work just as well
with zero code changes.
00:27:31.897 --> 00:27:33.279
So now let me switch back over.
00:27:45.315 --> 00:27:45.959
Okay.
00:27:51.810 --> 00:27:55.650
Now in addition to the universal
driver platform and related,
00:27:55.650 --> 00:27:58.770
we also have the Universal
Application Platform.
00:27:58.770 --> 00:28:02.122
Again, converge set of
APIs enabling me to build
00:28:02.122 --> 00:28:04.085
an application that runs and
00:28:04.085 --> 00:28:06.886
scales across all
editions of Windows.
00:28:06.886 --> 00:28:11.009
And you saw some examples
of some of the kiosk
00:28:11.009 --> 00:28:15.138
applications in some
of the earlier demos.
00:28:15.138 --> 00:28:18.739
Literally, that's the same
application simply recompiled to
00:28:18.739 --> 00:28:22.005
target all these different
CPU architectures, all these
00:28:22.005 --> 00:28:25.073
different machine types
with different capabilities
00:28:25.073 --> 00:28:28.757
with different screen sizes but
one same application platform.
00:28:28.757 --> 00:28:33.136
And again, I could draw the same
analogy that I drew with
00:28:33.136 --> 00:28:38.073
drivers, where today when you
want to build an application for
00:28:38.073 --> 00:28:42.265
a windows device you sometimes
have to ask yourself,
00:28:42.265 --> 00:28:44.610
okay what framework do I use?
00:28:44.610 --> 00:28:46.380
What windowing model do I use?
00:28:46.380 --> 00:28:48.010
What language do we use?
00:28:48.010 --> 00:28:49.850
With the universal
application platform,
00:28:49.850 --> 00:28:53.050
what we've tried to do is open
this up and allow you to bring
00:28:53.050 --> 00:28:56.260
your skills to be able to build
applications for the platform.
00:28:56.260 --> 00:29:00.721
So, a variety of different
programming languages, including
00:29:00.721 --> 00:29:05.183
C++ Including C# and Visual
Basic, including JavaScript,
00:29:05.183 --> 00:29:08.994
Python, Node.JS,
also supported on the platform.
00:29:08.994 --> 00:29:13.719
In terms of UI frameworks,
the UI frameworks fundamentally
00:29:13.719 --> 00:29:17.793
either XAML based or
HTML 5 based with JavaScript or
00:29:17.793 --> 00:29:22.239
you can build an app with
DirectX, although typically,
00:29:22.239 --> 00:29:25.962
we don't see DirectX as
a common IoT scenario.
00:29:25.962 --> 00:29:29.892
Typically DirectX applications
will be more phone, PC,
00:29:29.892 --> 00:29:34.680
Xbox style high frame-rate
gaming style applications.
00:29:34.680 --> 00:29:39.760
Mostly we see folks doing
XAML or HTML5 style work.
00:29:39.760 --> 00:29:43.390
From an API standpoint, the
universal application platform
00:29:43.390 --> 00:29:47.210
actually includes applications
with the different
00:29:47.210 --> 00:29:49.880
application binary
interfaces from Windows.
00:29:49.880 --> 00:29:54.158
So for example,
they're not all WinRT APIs.
00:29:54.158 --> 00:29:58.296
There's a bunch of WinRT APIs
in there but in addition,
00:29:58.296 --> 00:30:01.555
you have access to
a number of Win32 APIs,
00:30:01.555 --> 00:30:03.858
you have access to .NET APIs.
00:30:03.858 --> 00:30:08.802
One of the new things that
we've done With Windows 10
00:30:08.802 --> 00:30:12.110
IoT is also allowed wiring APIs.
00:30:12.110 --> 00:30:14.940
So one of the things you'll
see is the ability to use
00:30:14.940 --> 00:30:18.470
Arduino Sketch wiring
langauge to be able to
00:30:18.470 --> 00:30:22.990
do bust style programming
in Windows with high
00:30:22.990 --> 00:30:25.640
fidelity with how folks would
do that in Arduino today.
00:30:27.090 --> 00:30:30.100
From a deployment standpoint
the deployment and
00:30:30.100 --> 00:30:34.000
packaging system for
modern applications is AppX.
00:30:34.000 --> 00:30:37.770
Of course there's some
applications that you can simply
00:30:37.770 --> 00:30:40.240
XCopy across, and
those work just fine.
00:30:40.240 --> 00:30:41.988
The advantage of the AppX model,
00:30:41.988 --> 00:30:45.548
it's self contained applications
are isolated from one another,
00:30:45.548 --> 00:30:48.422
there's a well-defined
servicing model.
00:30:48.422 --> 00:30:52.460
You kinda get out of this
old world of DLL hell where
00:30:52.460 --> 00:30:54.920
I've got shared DLLs
across applications and
00:30:54.920 --> 00:30:56.895
they may interfere
with one another.
00:30:56.895 --> 00:30:59.100
APEx provides a very
clean way to deploy and
00:30:59.100 --> 00:31:00.890
service applications.
00:31:00.890 --> 00:31:03.854
And in building these I use
Visual Studio, I use PowerShell,
00:31:03.854 --> 00:31:06.479
I kind of do things one way
across these applications.
00:31:12.128 --> 00:31:17.120
Want to say quick word also,
about a retail.
00:31:17.120 --> 00:31:21.158
And as I'm building this
application I may wanna build
00:31:21.158 --> 00:31:24.583
application that support
a barcode scanner or
00:31:24.583 --> 00:31:26.088
magstripe reader.
00:31:26.088 --> 00:31:30.199
Some of these we've shown of
an example we ever see printer,
00:31:30.199 --> 00:31:31.175
cash drawer.
00:31:31.175 --> 00:31:35.184
For all of these, cash drawer,
receipt printer, magstripe
00:31:35.184 --> 00:31:39.230
reader and barcode scanner
they're supported in the box.
00:31:39.230 --> 00:31:43.705
Either we added support recently
in Windows 8.1 or they're new to
00:31:43.705 --> 00:31:47.808
Windows 10 we've added support
for these types of devices.
00:31:47.808 --> 00:31:50.400
So we've included
the driver Inbox,
00:31:50.400 --> 00:31:54.230
the drivers adapted
from the UPOS standard.
00:31:54.230 --> 00:31:57.470
So supporting standards
based retail peripherals.
00:31:57.470 --> 00:31:58.600
For payment terminals,
00:31:58.600 --> 00:32:01.650
it's also supported via
third party libraries.
00:32:01.650 --> 00:32:06.440
So really it kind of accelerates
your ability to build retail
00:32:06.440 --> 00:32:11.370
style devices quickly using
off the shelf components and
00:32:11.370 --> 00:32:14.780
spending more time on
core differentiation and
00:32:14.780 --> 00:32:18.660
less time on building the boiler
plate types stuff that you need
00:32:18.660 --> 00:32:21.190
to build, for
any style of application.
00:32:22.370 --> 00:32:25.680
Now, I wanna show you another
example, I wanna drill into that
00:32:25.680 --> 00:32:29.060
retail demo that some of you
may have seen earlier and
00:32:29.060 --> 00:32:31.090
kinda look at some of
the attributes of that demo.
00:32:31.090 --> 00:32:33.121
So let me again switch back
over to Visual Studio.
00:33:01.384 --> 00:33:06.384
There we go, and what I have is
I've got Visual Studio running
00:33:06.384 --> 00:33:10.808
in a virtual machine here, so
let me log into my virtual
00:33:10.808 --> 00:33:14.095
machine, we'll close
this instance.
00:33:30.138 --> 00:33:31.297
So while this is opening,
00:33:31.297 --> 00:33:33.460
a couple things I'd
like to show you.
00:33:33.460 --> 00:33:36.130
One is,
I've got my application code.
00:33:36.130 --> 00:33:37.980
That's coming up,
we'll go over that in a minute.
00:33:37.980 --> 00:33:41.619
What you see on the right is
what we've built is we call this
00:33:41.619 --> 00:33:43.458
a watcher application.
00:33:43.458 --> 00:33:47.440
This looks for
instances of Windows 10 IoT for
00:33:47.440 --> 00:33:51.400
small devices on my local
network, and you can see that it
00:33:51.400 --> 00:33:53.760
found at least one instance
of that online and
00:33:53.760 --> 00:33:56.920
it tells me what the IP and
MAC address is of that device.
00:33:56.920 --> 00:34:00.150
So, it's seeing the devices
that I'm working with here.
00:34:00.150 --> 00:34:03.220
This makes it really easy
having this watcher application
00:34:03.220 --> 00:34:06.180
as I'm doing my development it's
constantly discovering what I'm
00:34:06.180 --> 00:34:09.180
connecting to my local
network to make it easier
00:34:09.180 --> 00:34:13.590
to work with these Windows 10
IoT for these small devices.
00:34:14.820 --> 00:34:18.640
Now, switching back over to VS
here, couple interesting things.
00:34:18.640 --> 00:34:23.390
So I'm running, I'm going to
run this application over here
00:34:23.390 --> 00:34:27.660
on this particular on this
particular minnow board max.
00:34:27.660 --> 00:34:30.290
I won't go through the
embarrassing exercise of trying
00:34:30.290 --> 00:34:32.300
to get phone video to show you,
but
00:34:32.300 --> 00:34:37.300
trust me, it looks really cool,
if you were able to come see it.
00:34:37.300 --> 00:34:39.820
This one, we actually built
a custom case for it.
00:34:39.820 --> 00:34:42.860
So you can see there's some
nice plastic and the sensor,
00:34:42.860 --> 00:34:45.530
instead of hanging free by the
wires, it's kind of mounted and
00:34:45.530 --> 00:34:46.090
screwed on.
00:34:46.090 --> 00:34:48.460
So Just looks a little nicer but
fundamentally,
00:34:48.460 --> 00:34:51.400
it's exactly the same piece of
hardware with a little bit of
00:34:51.400 --> 00:34:54.160
additional plastic put on it.
00:34:54.160 --> 00:34:58.100
For this demo, I wanna show
you the connecting these
00:34:58.100 --> 00:34:59.450
typical retail peripherals.
00:34:59.450 --> 00:35:03.751
So I have a magstripe reader
to read credit cards, and
00:35:03.751 --> 00:35:05.860
I have a barcode scanner.
00:35:07.802 --> 00:35:11.760
This magstripe reader we brought
from Redmond as we came in for
00:35:11.760 --> 00:35:13.220
the conference.
00:35:13.220 --> 00:35:17.340
We meant to also bring a barcode
scanner from Redmond but
00:35:17.340 --> 00:35:18.004
we forgot it.
00:35:18.004 --> 00:35:22.680
We left it at the office and we
kind of got here and yesterday
00:35:22.680 --> 00:35:25.650
we were getting a demo ready and
we looked at each other said,
00:35:25.650 --> 00:35:27.570
did you bring
the barcode scanner?
00:35:27.570 --> 00:35:29.490
No, I didn't bring
the barcode scanner,
00:35:29.490 --> 00:35:30.320
I thought you brought it.
00:35:30.320 --> 00:35:31.240
No, I didn't bring it either.
00:35:32.390 --> 00:35:34.460
So, somebody literally went out,
00:35:34.460 --> 00:35:38.510
you know changing on the street,
went to one of the local stores,
00:35:38.510 --> 00:35:41.860
bought this barcode scanner and
I thought that was kind of
00:35:41.860 --> 00:35:45.920
a cool thing to show I don't
need the special barcode scanner
00:35:45.920 --> 00:35:48.470
that we brought from
the Microsoft campus in Redmond.
00:35:48.470 --> 00:35:51.800
I can go out and I can simply
buy one that's USB connected,
00:35:51.800 --> 00:35:54.290
and it will work just
as well as any one,
00:35:54.290 --> 00:35:58.790
cuz it conforms to the barcode
scanner driver model.
00:35:58.790 --> 00:36:01.470
So, I'm gonna plug
in these guys.
00:36:08.386 --> 00:36:11.340
Let's see how, all right.
00:36:11.340 --> 00:36:14.610
So first we'll plug in this
magstripe reader, good.
00:36:15.650 --> 00:36:18.000
Then we'll plug in
this barcode scanner.
00:36:18.000 --> 00:36:21.980
And I thought it would be neat
just to kinda plug these in in
00:36:21.980 --> 00:36:22.520
real time.
00:36:22.520 --> 00:36:24.690
That's a very reassuring
beep that I've received.
00:36:26.200 --> 00:36:31.120
I have, I have taken out of my
wallet a credit card that I
00:36:31.120 --> 00:36:34.120
will swipe on the mag
stripe reader.
00:36:34.120 --> 00:36:36.988
So let's just kinda get down to
it, let's run this application.
00:36:39.659 --> 00:36:42.428
And I'm gonna switch
over now as visual studio
00:36:42.428 --> 00:36:44.276
is running this application,
00:36:44.276 --> 00:36:48.340
it's compiling it, it deploys it
over the network to this device.
00:36:48.340 --> 00:36:51.670
So that's what's kinda
happening in the background.
00:36:51.670 --> 00:36:53.790
I'll show you a little bit
more about how that happens in
00:36:53.790 --> 00:36:56.500
Visual Studio in a moment but
I just wanna switch over.
00:36:56.500 --> 00:36:59.350
Now what you see
on the screen is
00:36:59.350 --> 00:37:02.840
the video being rendered from
this MinnowBoard Max device,
00:37:02.840 --> 00:37:04.380
running on the Intel
hardware platform.
00:37:04.380 --> 00:37:08.930
So it seems like
that's working okay.
00:37:08.930 --> 00:37:13.300
Let me go ahead and
take my barcode scanner and
00:37:13.300 --> 00:37:16.320
remember dance central
that we looked at earlier.
00:37:16.320 --> 00:37:17.629
I'm gonna scan that.
00:37:18.960 --> 00:37:22.201
Hopefully Dance Central's
gonna come online for me,
00:37:22.201 --> 00:37:23.062
come on baby.
00:37:23.062 --> 00:37:28.650
[SOUND] Doesn't it make a
reassuring beeping noise though?
00:37:28.650 --> 00:37:30.730
Even though the screen
doesn't change.
00:37:30.730 --> 00:37:32.700
Let's see,
maybe something's going on here.
00:37:34.270 --> 00:37:35.270
Something's going on here.
00:37:37.280 --> 00:37:38.840
So I'm switching back
to my laptop and
00:37:38.840 --> 00:37:42.510
what I found is that I
had a break point set.
00:37:42.510 --> 00:37:45.930
And so
it was kind of just that easy.
00:37:45.930 --> 00:37:47.630
I'm on my device,
00:37:47.630 --> 00:37:51.040
I'm running on my device,
I'm debugging from my laptop.
00:37:51.040 --> 00:37:53.150
I set a break point and
00:37:53.150 --> 00:37:55.980
because the thing is
running just Windows it's
00:37:55.980 --> 00:38:00.330
running the Visual Studio remote
debugging agent on that device.
00:38:00.330 --> 00:38:02.160
I was able to simply
set a breakpoint.
00:38:02.160 --> 00:38:06.510
And as I did the barcode scan,
the breakpoint hit, and
00:38:06.510 --> 00:38:09.400
I happened to set this
breakpoint on this barcode
00:38:09.400 --> 00:38:13.860
received event, and
it's telling me like yes,
00:38:13.860 --> 00:38:17.250
I've got a barcode,
I've got this event.
00:38:17.250 --> 00:38:19.280
If I look at what's
packed inside of this
00:38:19.280 --> 00:38:20.690
event there we go.
00:38:20.690 --> 00:38:22.440
It will tell me all
about the different
00:38:22.440 --> 00:38:25.060
attributes of the barcode
that it just scanned.
00:38:25.060 --> 00:38:26.360
So really handy.
00:38:26.360 --> 00:38:28.050
I'm just gonna say OK.
00:38:28.050 --> 00:38:30.010
This is really awesome.
00:38:30.010 --> 00:38:31.170
Go ahead and continue running.
00:38:32.570 --> 00:38:35.880
And it hit a couple of times cuz
I scanned it more than once.
00:38:35.880 --> 00:38:36.880
Let's switch back over.
00:38:38.090 --> 00:38:40.100
Okay, and
00:38:40.100 --> 00:38:42.000
I think, yeah now we're
looking at Dance Central 3.
00:38:42.000 --> 00:38:44.220
So the applications
continue to run.
00:38:44.220 --> 00:38:47.880
Now we have a screen
view that includes this
00:38:47.880 --> 00:38:49.640
Dance Central 3 thing.
00:38:49.640 --> 00:38:52.230
Now, what I'm gonna do
is the second part of
00:38:52.230 --> 00:38:54.850
the demonstration
where we swipe a card.
00:38:56.068 --> 00:38:59.100
And I'm gonna try not
to break it because
00:38:59.100 --> 00:39:00.300
I'm liable to do that.
00:39:00.300 --> 00:39:01.460
I'm going to swipe my card.
00:39:03.110 --> 00:39:04.960
I don't see anything
going on there.
00:39:04.960 --> 00:39:07.615
Let's check Visual Studio, maybe
I set it up another break point.
00:39:07.615 --> 00:39:14.010
I did, so I also
00:39:14.010 --> 00:39:17.060
set a break point on this on
card receive function which is
00:39:17.060 --> 00:39:21.730
the event that gets called when
a magnetic stripe reader swipes.
00:39:21.730 --> 00:39:24.970
So that's great and
I can do my debugging here.
00:39:24.970 --> 00:39:26.910
I can see what
the card number was.
00:39:26.910 --> 00:39:29.660
I can do this all very
interactively with this device.
00:39:29.660 --> 00:39:32.090
You notice I'm not doing
complicated tethering.
00:39:33.550 --> 00:39:37.450
I'm not doing crazy
JTAG style debugging.
00:39:37.450 --> 00:39:40.080
This is just simple network
debugging across Windows
00:39:40.080 --> 00:39:41.090
devices.
00:39:41.090 --> 00:39:43.780
Let me go ahead and
start this running again.
00:39:43.780 --> 00:39:46.863
Now if we switch back.
00:39:46.863 --> 00:39:50.233
Okay, and you can see in
the middle at the top,
00:39:50.233 --> 00:39:53.777
now it applied a member
discount because I swiped
00:39:53.777 --> 00:39:56.545
my membership card,
or in this case,
00:39:56.545 --> 00:40:00.273
I swiped my credit card,
to be able to look at this.
00:40:00.273 --> 00:40:00.913
So.
00:40:00.913 --> 00:40:01.573
That's pretty neat.
00:40:01.573 --> 00:40:03.968
It's neat to be able to
run these devices and
00:40:03.968 --> 00:40:06.360
do this kind of
style of debugging.
00:40:06.360 --> 00:40:10.190
Let's switch back and take
a deeper dive in a couple things
00:40:10.190 --> 00:40:13.120
that are going on with this
particular application.
00:40:13.120 --> 00:40:20.950
So, as I look, you saw the
mag-stripe reader code just now,
00:40:20.950 --> 00:40:23.650
where it received
a particular event.
00:40:23.650 --> 00:40:24.780
Let me do this.
00:40:24.780 --> 00:40:29.169
Let me make this font just
a little bit easier for
00:40:29.169 --> 00:40:30.931
everybody to see.
00:40:40.787 --> 00:40:42.210
There we go.
A little bit easier for
00:40:42.210 --> 00:40:43.520
everybody to see.
00:40:43.520 --> 00:40:45.370
What I wanted to show
you is a couple of
00:40:45.370 --> 00:40:48.560
things on this particular
piece of code.
00:40:48.560 --> 00:40:51.540
One is I wanted to show you
the built-in support for
00:40:51.540 --> 00:40:54.094
devices like
a mag-stripe reader.
00:40:54.094 --> 00:40:58.481
So as we kinda walk down this
source code, there's a simple
00:40:58.481 --> 00:41:03.138
function to say okay,
magstripeReader.getDefaultAsync,
00:41:03.138 --> 00:41:06.737
which is built into
the retail peripheral API and
00:41:06.737 --> 00:41:11.389
it's saying give me the first
bar code or the first mag-stripe
00:41:11.389 --> 00:41:14.946
reader that you find
connected to the machine.
00:41:14.946 --> 00:41:15.683
I only have one so
00:41:15.683 --> 00:41:18.470
it finds the first one
connected to the machine.
00:41:18.470 --> 00:41:21.380
And then it keeps retrying
in case there are some
00:41:21.380 --> 00:41:23.920
issues trying to connect
to that particular device.
00:41:25.070 --> 00:41:27.360
I fire a couple events
when this thing gets
00:41:29.070 --> 00:41:32.150
connected just to be able
to do some house keeping.
00:41:32.150 --> 00:41:36.080
But the other interesting piece
of code is these few lines of
00:41:36.080 --> 00:41:40.660
code here which say, and
all these swipe events.
00:41:40.660 --> 00:41:43.160
Go ahead and connect all
these swipe events and
00:41:43.160 --> 00:41:46.520
call my function where one of
these swipe events happened.
00:41:46.520 --> 00:41:49.600
So that's really from
an application level standpoint.
00:41:49.600 --> 00:41:53.030
That's all the code I have to
write in my application to be
00:41:53.030 --> 00:41:55.190
able to support a standard
peripheral like,
00:41:55.190 --> 00:41:56.440
a mag-stripe reader.
00:41:56.440 --> 00:41:58.470
Really, really straightforward
to support this kind
00:41:58.470 --> 00:41:58.970
of hardware.
00:42:00.150 --> 00:42:05.049
If I were to look, And
you can see where I've set
00:42:05.049 --> 00:42:08.050
my break points here,
to be on the scanner claim.
00:42:10.750 --> 00:42:12.145
So, a mag-stripe reader,
00:42:12.145 --> 00:42:14.720
bar code scanner is what
I wanted to show you.
00:42:14.720 --> 00:42:18.030
And you look at this code, and
it's virtual identical except
00:42:18.030 --> 00:42:20.100
instead of mag-stripe reader,
it's bar code scanner.
00:42:20.100 --> 00:42:23.610
So, again surface in these point
of sales peripherals as apart of
00:42:23.610 --> 00:42:26.500
the API set making it really,
really easy for
00:42:26.500 --> 00:42:29.899
me to build this application
without too much fuss.
00:42:30.980 --> 00:42:34.450
Now this particular application
if I were to stop debugging and
00:42:34.450 --> 00:42:38.990
enter the standard
Visual Studio view, this is
00:42:38.990 --> 00:42:43.110
a universal application, so I
have the ability to change user
00:42:43.110 --> 00:42:47.530
interface to be able to look at
the different aspects of UI.
00:42:47.530 --> 00:42:50.255
If I were to drill down
into views I can look at
00:42:50.255 --> 00:42:52.060
mainview.xaml.
00:42:52.060 --> 00:42:55.150
This is gonna give me one
of the graphical views of
00:42:55.150 --> 00:42:56.580
the application, the screen.
00:42:56.580 --> 00:43:01.760
So, you'll see on the bottom
is XML XAML based language,
00:43:01.760 --> 00:43:04.490
which is the declarative
language that I would use to
00:43:04.490 --> 00:43:07.290
express my user interface.
00:43:07.290 --> 00:43:10.308
Up on top you see
the design view.
00:43:10.308 --> 00:43:13.835
So the visual design view and
the XML view for these stay
00:43:13.835 --> 00:43:17.940
insync with one another as
I'm working in Visual Studio.
00:43:17.940 --> 00:43:20.190
I have some other
interesting things here.
00:43:21.370 --> 00:43:24.490
I can set particular screen
resolutions in Visual Studio
00:43:24.490 --> 00:43:26.150
that I might want to work with.
00:43:26.150 --> 00:43:29.020
So you'll notice that I have
screen resolutions that
00:43:29.020 --> 00:43:33.290
represents sort of standard PC
and phone screen resolutions,
00:43:33.290 --> 00:43:36.000
but I'm also able to set
screen resolutions for
00:43:36.000 --> 00:43:39.270
IoT devices, which means
00:43:39.270 --> 00:43:41.830
IoT devices can have any
particular screen resolution.
00:43:41.830 --> 00:43:44.000
So I can set custom
resolutions and
00:43:44.000 --> 00:43:47.280
design for custom resolutions
right from the Visual Studio
00:43:47.280 --> 00:43:48.950
tool which is very, very handy.
00:43:50.210 --> 00:43:53.670
The other thing I wanted to
show is I have the ability to
00:43:53.670 --> 00:43:58.360
run this as I think
you saw a little bit
00:43:58.360 --> 00:44:02.840
earlier in the keynote,
00:44:02.840 --> 00:44:06.970
I can run this application
either on emulators I can run it
00:44:06.970 --> 00:44:09.620
on a local machine, I can
run it on a remote machine.
00:44:09.620 --> 00:44:11.690
Because this is a universal app,
00:44:11.690 --> 00:44:14.300
I can actually run it
locally here on my PC or
00:44:14.300 --> 00:44:16.800
I can deploy it to my phone and
run it on a phone.
00:44:16.800 --> 00:44:19.940
I happen to be deploying it
to this remote IoT device.
00:44:21.450 --> 00:44:26.152
And, if I were to look at
within this particular project,
00:44:29.414 --> 00:44:32.520
If I look at the properties for
this particular project,
00:44:32.520 --> 00:44:35.887
I just wanted to highlight sort
of the magic behind connecting
00:44:35.887 --> 00:44:37.450
this remote machine.
00:44:37.450 --> 00:44:38.220
Not really magic,
00:44:38.220 --> 00:44:40.960
I just need to know the IP
address of the machine.
00:44:40.960 --> 00:44:43.492
And given the IP address of
the machine and the appropriate
00:44:43.492 --> 00:44:46.128
credential to log into the
machine, that's what enables me
00:44:46.128 --> 00:44:48.365
to do this debugging
directly from Visual Studio.
00:45:03.004 --> 00:45:03.782
Okay.
00:45:03.782 --> 00:45:08.062
So I wanna say a little bit more
about building these IoT devices
00:45:08.062 --> 00:45:11.470
with the Universal
Application Platform.
00:45:11.470 --> 00:45:14.440
A few things that
are different for
00:45:14.440 --> 00:45:18.280
IoT devices that might be true
for just normal Windows and
00:45:18.280 --> 00:45:21.380
Windows Phone store apps
that you might build.
00:45:21.380 --> 00:45:23.930
The first one is,
I have the ability
00:45:23.930 --> 00:45:29.100
within the applications manifest
to set the embedded mode flag.
00:45:29.100 --> 00:45:32.810
And what the embedded mode flag
means is it gives me additional
00:45:32.810 --> 00:45:37.700
control, or additional access,
directly to machine hardware
00:45:37.700 --> 00:45:41.230
that I need to build
a great IoT device that
00:45:41.230 --> 00:45:44.220
would be inappropriate if I were
building a store application.
00:45:44.220 --> 00:45:47.840
The whole goal of
store applications is
00:45:47.840 --> 00:45:50.780
they're self-contained, they're
isolated, and they can't really
00:45:50.780 --> 00:45:54.070
manipulate machine state in
a permanent way directly.
00:45:54.070 --> 00:45:55.660
With IoT mode, of course, for
00:45:55.660 --> 00:46:00.240
IoT devices what IoT's often
about is writing software that
00:46:00.240 --> 00:46:02.590
directly manipulates
the state of the hardware.
00:46:02.590 --> 00:46:06.470
So we have this flag that I
can set to enable that for
00:46:06.470 --> 00:46:07.640
IoT devices.
00:46:10.180 --> 00:46:12.060
The other thing that's
different for IoT devices,
00:46:12.060 --> 00:46:15.010
is I often need access to
particular system settings,
00:46:15.010 --> 00:46:18.770
particularly in Windows
10 IoT for small devices,
00:46:18.770 --> 00:46:21.790
like that which is running on
these MinnowBoard Max boards.
00:46:21.790 --> 00:46:27.190
I need ways in code to do
many of those things that,
00:46:27.190 --> 00:46:30.880
in traditional Windows we
would do through the UI.
00:46:30.880 --> 00:46:33.424
For example,
joining wi-fi networks or
00:46:33.424 --> 00:46:37.132
pairing bluetooth devices, or
these sorts of things that we
00:46:37.132 --> 00:46:40.580
would normally do to our
Windows user interface.
00:46:40.580 --> 00:46:44.770
We need to enable API level
access through the UAP
00:46:44.770 --> 00:46:47.170
to do that for
certain IoT devices.
00:46:48.510 --> 00:46:53.530
We also offer APIs to access
the buses, I can access GPIO,
00:46:53.530 --> 00:46:55.610
I squared C, SPI.
00:46:55.610 --> 00:46:58.880
With a consistent API layer,
what you saw me do earlier
00:46:58.880 --> 00:47:04.400
was use a driver to get at
this I squared C device.
00:47:04.400 --> 00:47:08.740
I can also have direct access
now in Windows 10 to those
00:47:08.740 --> 00:47:10.750
devices, which is something
I can show you soon.
00:47:12.280 --> 00:47:15.780
And then also background
services for long-running tasks.
00:47:15.780 --> 00:47:18.940
One of the things that the
universal application platform
00:47:18.940 --> 00:47:24.160
offers is a process life cycle
00:47:24.160 --> 00:47:28.890
management set of policies that
the operating system can use to
00:47:28.890 --> 00:47:32.640
determine when an application
should stay in memory and
00:47:32.640 --> 00:47:35.070
what resources it
should have access to.
00:47:35.070 --> 00:47:39.500
This is what's used to great
effect on the phone OS, that
00:47:39.500 --> 00:47:42.470
since phones tend to be a more
resource constrained device,
00:47:42.470 --> 00:47:47.090
applications processes can get
harvested and shut down from
00:47:47.090 --> 00:47:50.150
time to time in order to make
room for other things to run.
00:47:50.150 --> 00:47:52.460
Well, for IoT devices of course,
00:47:52.460 --> 00:47:56.030
we as the device builders need
to be able to specify, actually,
00:47:56.030 --> 00:47:58.820
I need this piece of code to
always be running, because my
00:47:58.820 --> 00:48:02.170
device won't work unless this
piece of code is always running.
00:48:02.170 --> 00:48:06.651
And so, using background
services, you have the ability
00:48:06.651 --> 00:48:11.317
to declaratively assert you know
this task this piece of code
00:48:11.317 --> 00:48:15.628
needs to continuously run
it's monitoring hardware.
00:48:15.628 --> 00:48:18.706
It's sending video, it's doing
whatever it needs to do from my
00:48:18.706 --> 00:48:21.740
device, but don't ever shut it
down, it needs to always run.
00:48:22.840 --> 00:48:26.360
So these four things are some
of the interesting things that
00:48:26.360 --> 00:48:31.430
I'm able to do as an IoT device
builder with UAP applications
00:48:31.430 --> 00:48:34.190
that I may not be able
to do from a standard
00:48:34.190 --> 00:48:36.000
Window store style application.
00:48:37.590 --> 00:48:43.980
Now what I think I'll
do is do one more demo.
00:48:43.980 --> 00:48:48.450
The structure of the session is
we're gonna spend about hour
00:48:48.450 --> 00:48:50.240
talking about stuff.
00:48:50.240 --> 00:48:53.790
Then take a short break and
then come back for
00:48:53.790 --> 00:48:55.960
a second hour,
that's how we're scheduled.
00:48:55.960 --> 00:48:59.030
So I think what we'll do
is we'll do one more demo
00:48:59.030 --> 00:49:01.090
then take our break,
and then for
00:49:01.090 --> 00:49:03.240
those of you that
are enjoying yourselves,
00:49:03.240 --> 00:49:05.470
you're welcome to come back
in and we'll, we'll proceed.
00:49:05.470 --> 00:49:07.229
So let me do one more.
00:49:19.046 --> 00:49:19.975
Okay.
00:49:22.890 --> 00:49:25.386
So here we go, back into our
old friend Visual Studio.
00:49:41.905 --> 00:49:45.950
Okay, so here we go.
00:49:49.170 --> 00:49:51.345
What this demonstrates
is a couple things,
00:49:51.345 --> 00:49:54.104
and I want to find the right
part in the source code to kind
00:49:54.104 --> 00:49:55.538
of begin the conversation.
00:49:55.538 --> 00:49:58.580
So this shows from
application level code, so
00:49:58.580 --> 00:50:01.856
this is just an application,
it's not a driver,
00:50:01.856 --> 00:50:05.834
this is an application that has
the same Kind of behavior with
00:50:05.834 --> 00:50:09.344
the sensor where it can sense
my ultraviolet light and
00:50:09.344 --> 00:50:13.010
be able to show a graph based
on that ultraviolet light,
00:50:13.010 --> 00:50:15.670
but do it all in
application code.
00:50:15.670 --> 00:50:20.200
And this is doing it
with our new bus' APIs.
00:50:20.200 --> 00:50:22.890
So, I wanna show you, just walk
you through a couple of pieces
00:50:22.890 --> 00:50:24.890
of this particular application.
00:50:24.890 --> 00:50:29.620
So, a couple of things you'll
notice here is I'm declaring
00:50:29.620 --> 00:50:33.232
a couple of member variables.
00:50:33.232 --> 00:50:37.170
I-squared-C devices that
00:50:37.170 --> 00:50:42.010
represent two pins on this board
that I'm using to read from,
00:50:42.010 --> 00:50:45.170
to be able to read UV
values based on pin values.
00:50:45.170 --> 00:50:49.734
This I-squared-C device,
if you can read the tool tip,
00:50:49.734 --> 00:50:54.583
it says that this thing sits
in windows.devices.isquaredC
00:50:54.583 --> 00:50:56.080
Name space.
00:50:56.080 --> 00:51:00.530
So, this is a built in class
that's part of the UAPAPI
00:51:00.530 --> 00:51:05.270
surface area that makes it easy
for me to access the busses.
00:51:05.270 --> 00:51:05.890
So, great.
00:51:05.890 --> 00:51:08.470
I declare a couple of these
devices in the form of a couple
00:51:08.470 --> 00:51:09.090
of pins.
00:51:10.560 --> 00:51:14.130
A couple of other pieces of
code that I wanted to show you.
00:51:14.130 --> 00:51:17.690
One is how do I create
instances of these devices and
00:51:17.690 --> 00:51:20.960
again I can use the built
in I-squared-C bus class.
00:51:20.960 --> 00:51:22.800
I can call create device async.
00:51:22.800 --> 00:51:27.180
Create two instances
of these using
00:51:27.180 --> 00:51:31.440
the values that indicate the
pins that I want to access to.
00:51:31.440 --> 00:51:33.840
So that's another piece of code.
00:51:33.840 --> 00:51:38.540
And then finally, I wanna be
able to read from this and
00:51:38.540 --> 00:51:41.340
the code to read from it
is pretty straightforward.
00:51:41.340 --> 00:51:45.840
There, on this particular device
there's a tryRead function
00:51:45.840 --> 00:51:48.130
that I can call to read a value.
00:51:48.130 --> 00:51:50.990
And those three pieces of
code are really the core
00:51:50.990 --> 00:51:54.450
of what I need to write to
be able to get easy access
00:51:54.450 --> 00:51:57.910
to the I-squared-C bus from
application level code.
00:51:59.240 --> 00:52:02.500
So what I'm gonna do is I'm
gonna run this thing now.
00:52:02.500 --> 00:52:05.050
And again I have it set to
run on my remote machine, so
00:52:05.050 --> 00:52:05.770
let me hit Run.
00:52:05.770 --> 00:52:08.830
And then lets switch
back over to,
00:52:08.830 --> 00:52:15.070
to my application There we go.
00:52:15.070 --> 00:52:15.870
So now it's running.
00:52:17.170 --> 00:52:19.220
I've got my handy
dandy flashlight.
00:52:19.220 --> 00:52:21.660
I'm gonna try not to
fall off the stage.
00:52:23.750 --> 00:52:26.250
And so, yeah, that looks like
it's working pretty well.
00:52:26.250 --> 00:52:27.712
I can get closer, so
00:52:27.712 --> 00:52:31.910
that seems like it's
working pretty well, okay.
00:52:31.910 --> 00:52:32.940
That's pretty neat.
00:52:32.940 --> 00:52:35.540
So let's head back
over to Visual Studio.
00:52:37.950 --> 00:52:40.930
And I'll tell it to stop
debugging this application.
00:52:44.036 --> 00:52:46.316
Well, I didn't make
that sound but
00:52:46.316 --> 00:52:49.600
it was a very appropriate
sound to stop debugging.
00:52:49.600 --> 00:52:54.100
Let me now,
now the way this particular
00:52:54.100 --> 00:52:58.480
application is written is,
it's just on a simple timer.
00:52:58.480 --> 00:53:01.735
As this timer fires,
it takes another reading.
00:53:01.735 --> 00:53:06.740
And then it graphs that reading
on that display that you saw.
00:53:06.740 --> 00:53:09.960
So what I should be able to do
is I should be able to change
00:53:09.960 --> 00:53:13.460
the periodicity of that reading
to make it read, perhaps,
00:53:13.460 --> 00:53:14.370
more quickly,
00:53:14.370 --> 00:53:17.870
and maybe I can get a different
style of graph, so let me just
00:53:17.870 --> 00:53:21.036
change the time span here to
be a different time span.
00:53:26.245 --> 00:53:28.250
Let's say, 50.
00:53:28.250 --> 00:53:31.745
So we'll go from a second
to 50 milliseconds,
00:53:31.745 --> 00:53:35.590
and we'll see what kind of
change that that implies.
00:53:37.630 --> 00:53:38.910
So we'll run this.
00:53:38.910 --> 00:53:39.670
Looks like.
00:53:44.960 --> 00:53:47.176
What did I break?
00:53:49.419 --> 00:53:52.100
I got rid of a parentheses.
00:53:57.370 --> 00:53:58.080
There we go.
00:54:00.070 --> 00:54:01.280
Compilers are unforgiving.
00:54:03.820 --> 00:54:05.660
So here we are,
here's the application again.
00:54:05.660 --> 00:54:06.660
Now let's take a look.
00:54:11.245 --> 00:54:14.745
Seems less well-behaved now,
wouldn't you say?
00:54:14.745 --> 00:54:15.890
Let's try it one more time.
00:54:38.911 --> 00:54:42.196
Yes, yes, that's well behaved.
00:54:47.454 --> 00:54:49.590
I always say,
if it were working properly,
00:54:49.590 --> 00:54:51.740
we'd be shipping it already.
00:54:51.740 --> 00:54:54.070
We're not shipping it so
it's not quite working properly.
00:54:55.350 --> 00:54:59.310
So with that we're at 43
minutes past the hour.
00:54:59.310 --> 00:55:03.950
What I'd like to do is take our
break now and then at the end of
00:55:03.950 --> 00:55:07.390
the break which I believe is 20
minutes in duration, at the end
00:55:07.390 --> 00:55:10.990
of that break reconvene back
here for the second hour.
00:55:10.990 --> 00:55:13.036
So I'll see you shortly,
thank you.
00:55:13.036 --> 00:55:22.210
>> [APPLAUSE]
>> Okay.
00:55:22.210 --> 00:55:25.880
What do you say we
get started again?
00:55:28.300 --> 00:55:31.390
So just to kinda
kick things off I
00:55:31.390 --> 00:55:34.180
wanted to pick up
where we left off
00:55:34.180 --> 00:55:36.740
because I couldn't figure out
why things were going wrong.
00:55:36.740 --> 00:55:38.370
My good friend,
David Campbell and
00:55:38.370 --> 00:55:42.880
I, we just recycled this device,
and rebooted the power.
00:55:42.880 --> 00:55:45.840
And, it looks like the sensor
kinda went weird when
00:55:45.840 --> 00:55:47.340
the power went weird.
00:55:47.340 --> 00:55:49.990
And, then it seemed to
be fine for a while.
00:55:49.990 --> 00:55:52.800
So, it looks like we've got a
little bit of a hardware issue.
00:55:52.800 --> 00:55:56.150
But, I thought you
all were kind of
00:55:56.150 --> 00:55:58.140
wondering what the heck was
going on with the demo.
00:55:59.670 --> 00:56:02.661
Glad I can help.
00:56:02.661 --> 00:56:05.328
Let's pick up part two.
00:56:11.703 --> 00:56:17.036
All right, want to talk
a little bit about I've got
00:56:17.036 --> 00:56:23.524
some existing applications,
I've got some existing code.
00:56:23.524 --> 00:56:27.530
And I wanna bring that
to Windows 10 IoT for
00:56:27.530 --> 00:56:29.120
small devices.
00:56:29.120 --> 00:56:32.050
So, of course,
if you got existing code and
00:56:32.050 --> 00:56:35.580
it's in desktop Windows and
you wanna use Windows IoT for
00:56:35.580 --> 00:56:37.630
industry devices, that's fine.
00:56:37.630 --> 00:56:39.778
That stuff all still works.
00:56:39.778 --> 00:56:43.030
But this slide is specific
to small devices because
00:56:43.030 --> 00:56:47.190
Windows 10 IoT for small devices
is really a platform for
00:56:47.190 --> 00:56:50.130
UAP, for the Universal
Application Platform.
00:56:50.130 --> 00:56:52.080
So there's some things that
you have to do differently.
00:56:54.020 --> 00:56:57.280
First, I would say that
the Universal App Platform and
00:56:57.280 --> 00:56:59.590
universal drivers,
it's a big API subset.
00:56:59.590 --> 00:57:02.380
There's a lot you can do,
it's very, very rich, but
00:57:02.380 --> 00:57:07.080
it is smaller when
compared to full Win32.
00:57:07.080 --> 00:57:09.200
Full Win32 is bigger.
00:57:09.200 --> 00:57:15.000
So, a little bit of advice, if
you're using Win32 native code,
00:57:15.000 --> 00:57:18.190
a lot of that code
will still work.
00:57:18.190 --> 00:57:21.250
Turns out, you have to link with
a different library if you're
00:57:21.250 --> 00:57:22.340
a C++ developer.
00:57:22.340 --> 00:57:25.460
But other than that, some of
that code will continue to work.
00:57:25.460 --> 00:57:29.221
Some of it you'll need to find
the UAP equivalents of what you
00:57:29.221 --> 00:57:30.786
were doing for Win 32.
00:57:30.786 --> 00:57:31.869
For .NET,
00:57:31.869 --> 00:57:36.750
most .NET library stuff is
supported on UAP as well.
00:57:36.750 --> 00:57:39.590
So if I have some .NET
code that I wanna bring to
00:57:39.590 --> 00:57:42.720
these small devices, most of
that code will come over and
00:57:42.720 --> 00:57:44.080
that will just work as well.
00:57:45.380 --> 00:57:48.175
And finally, the one that might
be the most disruptive for
00:57:48.175 --> 00:57:54.060
bringing over existing
software to Windows 10 IoT for
00:57:54.060 --> 00:57:58.970
small devices is if you're doing
any sort of desktop windowing
00:57:58.970 --> 00:58:06.290
libraries, GDI, MSC,
WinForms, WPF, etc.
00:58:06.290 --> 00:58:09.540
None of those will work
on this new platform.
00:58:09.540 --> 00:58:12.720
Instead, it needs to
be built using UAP,
00:58:12.720 --> 00:58:17.780
using the XAML or the HTML5
model that I described earlier.
00:58:17.780 --> 00:58:20.720
So, those are kind of the key
points in bringing over
00:58:20.720 --> 00:58:23.110
existing source code.
00:58:23.110 --> 00:58:25.410
I talked about some tools
that we have available for
00:58:25.410 --> 00:58:27.390
bringing over
existing source code.
00:58:27.390 --> 00:58:30.840
So what I'd like to do is
actually show you a little bit
00:58:30.840 --> 00:58:32.190
about these tools
that we're building.
00:58:33.490 --> 00:58:35.700
Let me move over
to another demo.
00:58:46.828 --> 00:58:47.700
All right, so
00:58:47.700 --> 00:58:51.350
what I'll do is I'll start over
here in this Windows XP VM.
00:58:57.995 --> 00:59:01.440
All right, and then let's make
the screen a little bit bigger.
00:59:07.370 --> 00:59:08.760
There we go.
00:59:08.760 --> 00:59:12.980
So I'm in this Windows XP VM and
so
00:59:12.980 --> 00:59:17.040
this is intended to be what
we would call old school.
00:59:17.040 --> 00:59:19.800
I've got an application that
I've written here designed for
00:59:19.800 --> 00:59:20.850
Windows CE 6.
00:59:20.850 --> 00:59:24.420
How many people in the room
actually used Windows CE 6?
00:59:24.420 --> 00:59:25.400
Has anybody used this?
00:59:25.400 --> 00:59:26.320
A few guys,
00:59:26.320 --> 00:59:28.950
yeah, a number of people have
used Windows CE 6, that's cool.
00:59:30.240 --> 00:59:31.920
The development tool
I'm looking at here,
00:59:31.920 --> 00:59:34.890
this is Visual Studio 2005.
00:59:34.890 --> 00:59:37.100
Anybody use
Visual Studio 2005 ever?
00:59:38.640 --> 00:59:39.590
Couple guys in front.
00:59:40.610 --> 00:59:43.350
Visual Studio 2005 is
actually the first project
00:59:43.350 --> 00:59:45.170
I worked on at Microsoft.
00:59:45.170 --> 00:59:48.167
I've been at Microsoft for
ten years and
00:59:48.167 --> 00:59:53.190
the first thing I did was, yes
2005, you guys are gonna laugh,
00:59:53.190 --> 00:59:56.378
and I might need a little
help here, Dave.
00:59:56.378 --> 01:00:01.378
The surface just
blue-screened [LAUGH].
01:00:01.378 --> 01:00:07.738
So I'm running Windows
10 on my Surface.
01:00:07.738 --> 01:00:11.050
Kind of just a random
pre-released build of Windows 10
01:00:11.050 --> 01:00:12.610
on my Surface.
01:00:12.610 --> 01:00:16.920
And, everything had gone very,
very smoothly up to this point.
01:00:16.920 --> 01:00:22.010
But of course, at this point,
as my demo is about to start,
01:00:22.010 --> 01:00:23.610
that's when things go awry.
01:00:25.340 --> 01:00:27.880
I could tell you more stories
about Visual Studio 2005 if you
01:00:27.880 --> 01:00:30.670
want to hear Visual Studio
2005 stories.
01:00:30.670 --> 01:00:31.750
It was a long project.
01:00:32.840 --> 01:00:35.330
Took, I don't know,
four years to be able to
01:00:35.330 --> 01:00:39.850
release that piece of software,
large version of Visual Studio.
01:00:39.850 --> 01:00:42.740
And it had some
issues initially.
01:00:42.740 --> 01:00:44.500
We were glad to get
those issues worked out,
01:00:44.500 --> 01:00:46.330
but it took us some time
to get those worked out.
01:00:48.320 --> 01:00:50.240
And we're logging
into the new machine.
01:00:50.240 --> 01:00:53.400
As we log it in, we've got a
couple virtual machines that we
01:00:53.400 --> 01:00:56.340
need to fire up, so
we're gonna fire those guys up.
01:00:58.090 --> 01:01:00.692
Any questions while we're
getting this thing restored?
01:01:10.769 --> 01:01:12.635
I'm sorry, I'm having trouble
hearing that question.
01:01:12.635 --> 01:01:16.700
>> Where can we download
the demo source code?
01:01:16.700 --> 01:01:17.990
>> The demo source code.
01:01:17.990 --> 01:01:18.850
That's a great question.
01:01:18.850 --> 01:01:21.500
So it was, where can we
download the demo source code?
01:01:21.500 --> 01:01:25.800
I don't have the demo source
code available online yet, but
01:01:25.800 --> 01:01:28.480
that's a great cue.
01:01:28.480 --> 01:01:31.370
We should make this demo source
code available at the same time
01:01:31.370 --> 01:01:35.880
that we make Windows 10 IoT for
small devices broadly available.
01:01:37.430 --> 01:01:41.670
And we're thinking about Build,
the Build conference which is
01:01:41.670 --> 01:01:45.250
scheduled for late next month as
the point in time that we would
01:01:45.250 --> 01:01:49.200
make Windows 10 IoT for
small devices available broadly.
01:01:49.200 --> 01:01:52.603
So at that time, we'll kind of
include links to this stuff as
01:01:52.603 --> 01:01:54.350
well so that you can look at it.
01:01:55.370 --> 01:01:58.390
Meanwhile, there's really
nothing special about most of
01:01:58.390 --> 01:02:00.390
the code that I'm showing.
01:02:00.390 --> 01:02:03.210
Most of the code that I'm
showing is actually just
01:02:03.210 --> 01:02:07.950
universal drivers, universal
applications, the support that I
01:02:07.950 --> 01:02:12.970
showed for accessing I-squared-C
buses from application code,
01:02:12.970 --> 01:02:14.930
all that's just built
into Windows 10 today.
01:02:17.020 --> 01:02:19.220
One of the goals is that we
01:02:22.220 --> 01:02:24.100
didn't wanna make the IoT
platform different.
01:02:24.100 --> 01:02:26.760
We want it to be very consistent
with everything else we're doing
01:02:26.760 --> 01:02:30.060
in the IoT space or
in the Windows 10 space.
01:02:30.060 --> 01:02:30.886
So for that,
01:02:30.886 --> 01:02:34.651
you can kind of get started
immediately with Windows 10.
01:02:36.207 --> 01:02:37.472
How we doing on setup?
01:02:45.402 --> 01:02:48.489
Great.
01:02:48.489 --> 01:02:51.926
All right.
01:02:51.926 --> 01:02:53.051
Thank you.
01:02:56.276 --> 01:03:03.884
Okay, back to our XPVM.
01:03:03.884 --> 01:03:05.360
It worked so well for a while.
01:03:05.360 --> 01:03:07.700
So, we were doing surveys.
01:03:07.700 --> 01:03:09.360
Number of people had
experience with CE,
01:03:09.360 --> 01:03:12.570
number of people had experience
with Visual Studio 2005.
01:03:12.570 --> 01:03:16.960
This is Visual Studio 2005 with
Platform Builder built in.
01:03:16.960 --> 01:03:20.597
I can build this application,
this application is actually
01:03:20.597 --> 01:03:24.174
an implementation of the dining
philosophers algorithm.
01:03:24.174 --> 01:03:27.474
If you guys have heard of the
dining philosophers algorithm,
01:03:27.474 --> 01:03:30.076
the idea that you have
a number of philosophers,
01:03:30.076 --> 01:03:32.677
which are typically
implemented as threads that
01:03:32.677 --> 01:03:35.849
sit around a table, and there
are only as many chopsticks as
01:03:35.849 --> 01:03:37.258
there are philosophers.
01:03:37.258 --> 01:03:40.040
So in order for a philosopher to
eat, he has to get both a left
01:03:40.040 --> 01:03:42.420
and a right chopstick to
be able to eat the food.
01:03:42.420 --> 01:03:45.254
And then when he's done taking
a bite, he puts the chopsticks
01:03:45.254 --> 01:03:47.285
back on the table and
another philosopher.
01:03:47.285 --> 01:03:52.045
So it's a multi-threaded
puzzle algorithm.
01:03:52.045 --> 01:03:54.785
That's what's implemented here.
01:03:54.785 --> 01:03:59.218
And one of the things that this
particular piece of code does is
01:03:59.218 --> 01:04:02.541
it calls this function,
which is a legitimate
01:04:02.541 --> 01:04:06.973
function in Windows CE called
CE Set Thread Priority, and if I
01:04:06.973 --> 01:04:11.341
were to build this particular
project, should build okay.
01:04:17.539 --> 01:04:18.920
Should build okay.
01:04:18.920 --> 01:04:22.400
But it's an example of, as I
wanna move this code forward,
01:04:22.400 --> 01:04:27.810
the fact that the CE API
call starts with CE
01:04:27.810 --> 01:04:30.875
gives me an indication that this
might not be something that's
01:04:30.875 --> 01:04:35.410
gonna move forward outside
the world of Windows CE.
01:04:35.410 --> 01:04:38.080
So I might need to do some
work in order to import this
01:04:38.080 --> 01:04:42.370
particular piece of
code to modern Windows.
01:04:42.370 --> 01:04:44.305
So you can see my
build succeeded.
01:04:44.305 --> 01:04:46.452
I have an application
that runs here.
01:04:46.452 --> 01:04:52.987
Let me now head off of my XPVM
and go back into modern Windows.
01:05:06.326 --> 01:05:09.321
Okay, so here we are back
in modern Windows.
01:05:09.321 --> 01:05:10.969
This is our dining philosophers.
01:05:10.969 --> 01:05:13.326
Okay, here's my code.
01:05:13.326 --> 01:05:19.339
Now, I've got the same code
open in Visual Studio 2015.
01:05:19.339 --> 01:05:24.549
What I wanna do first, though,
before I go edit this code
01:05:24.549 --> 01:05:29.452
is I'd like to just kinda go
to the command line here.
01:05:39.877 --> 01:05:42.327
Okay, and what I'm gonna do is
I'm gonna run a command line
01:05:42.327 --> 01:05:43.860
tool that we've developed.
01:05:43.860 --> 01:05:47.730
What this command line tool will
do is it will scan a binary that
01:05:47.730 --> 01:05:48.260
I've built.
01:05:48.260 --> 01:05:52.572
So in this case, I'm gonna have
it scan this Windows CE app.exe,
01:05:52.572 --> 01:05:55.883
and it's gonna look for
API calls that exist within
01:05:55.883 --> 01:05:58.809
this binary that aren't
supported on UAP and
01:05:58.809 --> 01:06:02.353
then I can kinda have some idea
what I need to do with it.
01:06:02.353 --> 01:06:07.807
So, I'm gonna call this scan
binary for modern Win32 APIs and
01:06:07.807 --> 01:06:11.849
I'm gonna pass Win CE
app.exe as a parameter.
01:06:11.849 --> 01:06:13.490
And it's gonna give
me some feedback.
01:06:13.490 --> 01:06:15.610
Feedback tells me
a couple things.
01:06:15.610 --> 01:06:20.010
It scanned through this binary
and it's told me that there
01:06:20.010 --> 01:06:25.100
are a couple of APIs that
are supported but are remapped.
01:06:25.100 --> 01:06:25.790
They exist but
01:06:25.790 --> 01:06:29.830
they exist in a different DLL
than they exist in Windows CE.
01:06:29.830 --> 01:06:30.722
So, that's not a big deal.
01:06:30.722 --> 01:06:33.931
What that means is, if I just
rebuild from the source code,
01:06:33.931 --> 01:06:35.610
I'll be fine, that's okay.
01:06:35.610 --> 01:06:37.315
But there's this other
thing that's a little bit
01:06:37.315 --> 01:06:38.340
more troubling.
01:06:38.340 --> 01:06:43.380
It says I'm missing an API for
CE Set Thread Priority,
01:06:43.380 --> 01:06:48.300
so that's an API that there
is no equivalent API or
01:06:48.300 --> 01:06:51.980
that API itself does not
exist in the modern UAP.
01:06:51.980 --> 01:06:53.810
So now I can head back
into Visual Studio.
01:06:56.720 --> 01:06:57.250
And I can go,
01:06:57.250 --> 01:07:01.700
okay, this seems to be
the offending line of code.
01:07:01.700 --> 01:07:04.280
If you're like me, the way you
deal with a line of code that
01:07:04.280 --> 01:07:06.920
doesn't compile is you
comment it out, and
01:07:06.920 --> 01:07:10.530
then your code compiles fine,
and then hopefully it works.
01:07:10.530 --> 01:07:12.050
Sometimes it may not work,
01:07:12.050 --> 01:07:16.540
sometimes merely stemming out
the code is not the answer.
01:07:16.540 --> 01:07:17.150
In fact,
01:07:17.150 --> 01:07:22.440
sometimes I want to find
the right way to do this, and
01:07:22.440 --> 01:07:26.990
it turns out that I've learned
through my research that there's
01:07:26.990 --> 01:07:29.700
actually a function I can call
called Set Thread Priority.
01:07:33.060 --> 01:07:37.253
There's a constant
that I can pass to it.
01:07:37.253 --> 01:07:41.815
I can pass thread priority above
normal, which is a constant.
01:07:41.815 --> 01:07:46.134
Then I can try and rebuild
this particular application.
01:07:46.134 --> 01:07:50.463
Actually, I can just
compile this file, I think.
01:07:50.463 --> 01:07:51.830
Yeah.
01:07:51.830 --> 01:07:52.970
Let me just compile this file.
01:07:52.970 --> 01:07:56.270
And there we go.
01:07:56.270 --> 01:07:58.976
So I was able to take
this existing CE code,
01:07:58.976 --> 01:08:02.959
I was able to run it through
binary scanner and determine,
01:08:02.959 --> 01:08:07.262
okay, this CE binary is calling
some APIs that aren't supported.
01:08:07.262 --> 01:08:12.347
Then go into Visual Studio
2015 running on Windows 10,
01:08:12.347 --> 01:08:15.476
comment out that
offending API call,
01:08:15.476 --> 01:08:20.683
use the modern Win32 version
of that API, and move forward.
01:08:20.683 --> 01:08:22.750
Now I have an application
that'll run.
01:08:22.750 --> 01:08:25.971
I can run this dining
philosophers application on
01:08:25.971 --> 01:08:27.126
modern Windows.
01:08:39.420 --> 01:08:40.743
All right then.
01:08:44.785 --> 01:08:46.686
Back into our presentation.
01:09:00.119 --> 01:09:02.761
Okay, so
moving out of porting code,
01:09:02.761 --> 01:09:06.560
I wanted to just talk about
a couple of different topics
01:09:06.560 --> 01:09:10.290
relevant to building IoT
devices with Windows 10.
01:09:10.290 --> 01:09:14.560
And this is about how I do
configuration of the OS.
01:09:14.560 --> 01:09:17.920
So historically, we've had
different ways to do this for
01:09:17.920 --> 01:09:19.860
different editions of Windows.
01:09:19.860 --> 01:09:22.160
In order to build an image for
01:09:22.160 --> 01:09:26.430
my device in Windows Embedded
Industry, it's different than
01:09:26.430 --> 01:09:28.980
Windows Embedded Handheld,
and it's different than
01:09:28.980 --> 01:09:32.540
the Platform Builder approach
of Windows Embedded Compact.
01:09:32.540 --> 01:09:35.900
With Windows 10, there's one
approach, there's one Windows
01:09:35.900 --> 01:09:39.040
image configuration designer
tool, which we internally call
01:09:39.040 --> 01:09:44.580
ICD, and I use ICD to create
my machine images and
01:09:44.580 --> 01:09:47.830
target those images to all
different kinds of devices.
01:09:49.140 --> 01:09:51.960
As I'm using ICD,
ICD gives me the ability to say,
01:09:53.000 --> 01:09:54.690
what kind of device
am I creating?
01:09:54.690 --> 01:09:57.330
Is it an industry or
a mobile or a small device?
01:09:58.510 --> 01:10:00.598
What applications
go with my device?
01:10:00.598 --> 01:10:03.628
What drivers do I need to
be a part of my image?
01:10:03.628 --> 01:10:06.927
What is the lockdown
settings I wanna set up for
01:10:06.927 --> 01:10:08.628
my device to be able to.
01:10:08.628 --> 01:10:13.284
Tailor the device experience
to whatever I'm building.
01:10:13.284 --> 01:10:15.272
I can kind of design
all of that in,
01:10:15.272 --> 01:10:18.837
I can create an image from that,
and then I can use that image to
01:10:18.837 --> 01:10:22.610
then deploy that at scale
on many different machines.
01:10:22.610 --> 01:10:26.110
I did have a couple of shots
here that I wanted to show you
01:10:26.110 --> 01:10:29.280
of the ICD Tool.
01:10:29.280 --> 01:10:31.949
So this is an actual
screenshot of a ICD tool,
01:10:31.949 --> 01:10:34.284
that is currently
under development.
01:10:34.284 --> 01:10:37.092
Not quite, wasn't quite ready
for me to show here today, but
01:10:37.092 --> 01:10:39.201
it's something we're
actively working on.
01:10:39.201 --> 01:10:42.760
And this shows the idea of
beginning to create a new
01:10:42.760 --> 01:10:46.849
project in ICD to be able to
configure a new device image.
01:10:48.480 --> 01:10:51.961
And this screen shows the idea
of being able to say okay,
01:10:51.961 --> 01:10:55.827
what are the applications that
are gonna go onto this device?
01:10:55.827 --> 01:10:57.550
What dependencies does it have?
01:10:57.550 --> 01:10:58.910
Where should it start up?
01:10:58.910 --> 01:11:01.755
What kind of settings and what
kind of shell configuration do I
01:11:01.755 --> 01:11:04.117
want for my particular
device that I'm building.
01:11:04.117 --> 01:11:08.157
So that I can have something
that's easily deployable and
01:11:08.157 --> 01:11:11.702
ready for the devices that
I'm manufacturing or,
01:11:11.702 --> 01:11:14.070
I could be manufacturing these.
01:11:14.070 --> 01:11:15.900
Or, I could be
deploying these images
01:11:15.900 --> 01:11:17.800
in an Enterprise scenario,
as well.
01:11:17.800 --> 01:11:20.034
Works both for OEMs and
for Enterprises.
01:11:22.701 --> 01:11:27.141
Now, speaking of device
deployment, a lot of feedback
01:11:27.141 --> 01:11:32.053
that we got from customers,
particular around Windows 8 and
01:11:32.053 --> 01:11:37.320
Windows 8.1 for industry is that
activation was really hard.
01:11:37.320 --> 01:11:41.210
Activation required an Internet
connection to activate
01:11:41.210 --> 01:11:43.360
the device post-assembly.
01:11:43.360 --> 01:11:46.900
What we've done
with Windows 10 is
01:11:46.900 --> 01:11:49.300
gotten rid of
the activation headache.
01:11:49.300 --> 01:11:53.620
Made it really low-friction
to build these devices and
01:11:53.620 --> 01:11:54.430
get them deployed.
01:11:54.430 --> 01:11:58.610
So, if I'm building for
mobile or small devices,
01:11:58.610 --> 01:12:01.780
there actually is no activation
process for those devices.
01:12:01.780 --> 01:12:04.710
So, I don't have to worry about
it connecting to any Internet
01:12:04.710 --> 01:12:06.730
server and activating.
01:12:06.730 --> 01:12:09.890
But if I'm building for
industry devices,
01:12:09.890 --> 01:12:14.250
there is an activation process,
and it goes one of two ways.
01:12:14.250 --> 01:12:17.420
So, at the time of manufacture,
01:12:17.420 --> 01:12:19.640
a Windows product
key is included.
01:12:19.640 --> 01:12:22.320
Typically, I would include
that product key through ICD,
01:12:22.320 --> 01:12:23.649
the tool we just talked about.
01:12:25.420 --> 01:12:29.510
That device will get imaged,
that will get deployed.
01:12:29.510 --> 01:12:32.510
Now, from there it can go
one of two directions.
01:12:32.510 --> 01:12:36.790
If that device has never
connected to the Internet, so,
01:12:36.790 --> 01:12:40.800
let's say the typical example of
a device that never connects to
01:12:40.800 --> 01:12:44.320
the internet is an ATM machine,
cash machine.
01:12:44.320 --> 01:12:47.934
Often these cash machines
never connect to the Internet,
01:12:47.934 --> 01:12:50.451
they are only used in
a private network.
01:12:50.451 --> 01:12:54.811
So, devices that never connect
to the Internet never have to
01:12:54.811 --> 01:12:58.410
activate and the user
interface for that device.
01:12:58.410 --> 01:13:00.061
Never shows a watermark or
01:13:00.061 --> 01:13:03.888
never shows any indication that
it needs to be activated, so
01:13:03.888 --> 01:13:07.659
it's a fully functional,
fully capable Windows device.
01:13:07.659 --> 01:13:10.299
If on the other hand at
some point that device's
01:13:10.299 --> 01:13:13.005
lifetime it does get
connected to the Internet,
01:13:13.005 --> 01:13:16.243
it will go reach out to the
Microsoft activation servers.
01:13:16.243 --> 01:13:20.436
And it will activate using
the product key that
01:13:20.436 --> 01:13:25.165
is burned in at the time of
imaging and so either way,
01:13:25.165 --> 01:13:27.990
you will have no headaches.
01:13:27.990 --> 01:13:32.650
The only time that you may have
a concern is when a device goes
01:13:32.650 --> 01:13:35.900
to activate and it does
not have a product key or
01:13:35.900 --> 01:13:37.870
it has a product key
that is invalid.
01:13:37.870 --> 01:13:41.284
In those cases, which are
typically error cases that you
01:13:41.284 --> 01:13:42.783
want to test out anyway.
01:13:42.783 --> 01:13:45.148
That's where you would get
a watermark that says hey,
01:13:45.148 --> 01:13:47.367
this device needs to be
appropriately activated.
01:13:53.534 --> 01:13:58.162
Now once a device gets,
an image gets created,
01:13:58.162 --> 01:14:04.065
device gets deployed, device
is activated or doesn't need
01:14:04.065 --> 01:14:10.500
to be activated many OEMs sell
IOT devices into enterprises.
01:14:10.500 --> 01:14:12.850
It's very important to
enterprises to be able to manage
01:14:12.850 --> 01:14:16.610
those devices as they would
any other corporate IT asset.
01:14:18.310 --> 01:14:22.790
What this diagram depicts is,
how this works in Windows 10?
01:14:22.790 --> 01:14:26.140
So in Windows 10, for the first
time at the bottom of this,
01:14:26.140 --> 01:14:31.720
what you see is for all devices,
small mobile and industry, there
01:14:31.720 --> 01:14:37.440
is one device management stack,
all support the MDM protocol.
01:14:38.510 --> 01:14:41.600
The servicing stack for
all of these is converged and
01:14:41.600 --> 01:14:44.550
the CSPs that has
described configurable
01:14:44.550 --> 01:14:48.830
capabilities of the operating
system are common and converged.
01:14:48.830 --> 01:14:52.640
So what that means is if I
have a Windows 10 device,
01:14:52.640 --> 01:14:57.340
I manage it the same, no matter
if it's a PC kind of device or
01:14:57.340 --> 01:15:00.520
a phone kind of device or
a small kind of device
01:15:00.520 --> 01:15:03.810
I manage all of these
devices exactly the same way.
01:15:03.810 --> 01:15:07.390
From an enterprise IT asset
management standpoint,
01:15:07.390 --> 01:15:09.950
they all just look like
instances of Windows running out
01:15:09.950 --> 01:15:10.560
of my network.
01:15:11.900 --> 01:15:14.570
Now, because they
all speak OMA DM,
01:15:14.570 --> 01:15:18.500
they will talk up to
some MDM style tool.
01:15:18.500 --> 01:15:24.240
That could be Intune in the
cloud, a Microsoft product or
01:15:24.240 --> 01:15:27.400
System Center Configuration
Manager on premises,
01:15:27.400 --> 01:15:29.120
which another Microsoft product.
01:15:29.120 --> 01:15:32.173
Or it could be a third
party MDM tool that speaks
01:15:32.173 --> 01:15:33.818
the standard protocol,
01:15:33.818 --> 01:15:37.827
and that works fine too, we
support all of those scenarios.
01:15:37.827 --> 01:15:39.631
One approach to device
management, and
01:15:39.631 --> 01:15:41.867
they all work really,
really well out of the box.
01:15:41.867 --> 01:15:44.023
Now when we think
about management,
01:15:44.023 --> 01:15:47.784
we've taken a pretty holistic
approach to device management.
01:15:47.784 --> 01:15:51.363
Device management, you can
represent as a life cycle,
01:15:51.363 --> 01:15:53.876
going from I want to
enroll the device,
01:15:53.876 --> 01:15:56.784
I want to include
the device in my inventory.
01:15:56.784 --> 01:15:59.650
I want to be able to configure
it and secure it, and
01:15:59.650 --> 01:16:02.995
then I want to be able to manage
the applications that run on
01:16:02.995 --> 01:16:03.839
that device.
01:16:05.570 --> 01:16:07.790
If something goes wrong in that
device, I wanna be able to
01:16:07.790 --> 01:16:11.110
provide remote assistance to
the operator of that device.
01:16:11.110 --> 01:16:14.270
And then, if that device
ever leaves my inventory,
01:16:14.270 --> 01:16:17.980
I wanna be able to unenroll
it from Device Management.
01:16:17.980 --> 01:16:20.860
And so what we've done is we've
taken a pretty holistic approach
01:16:20.860 --> 01:16:24.890
to thinking through each of
these steps and making sure that
01:16:26.360 --> 01:16:30.980
We have a complete solution
that includes each of these
01:16:30.980 --> 01:16:33.930
important steps in
the MVM life cycle.
01:16:33.930 --> 01:16:35.550
So, in the first
one in enrollment,
01:16:35.550 --> 01:16:38.440
I'll just pick a couple what I
think are some of the important
01:16:38.440 --> 01:16:39.520
aspects here.
01:16:39.520 --> 01:16:42.560
So, to be able to initially
prevision my device at the time
01:16:42.560 --> 01:16:43.630
of enrollment.
01:16:43.630 --> 01:16:45.590
To be able to do
bulk enrollment.
01:16:45.590 --> 01:16:48.498
Very, very important if
I'm an enterprise and
01:16:48.498 --> 01:16:50.830
I'm taking in a new
set of handhelds.
01:16:50.830 --> 01:16:55.261
For example, let's say, I'm
a retailer and I've purchased
01:16:55.261 --> 01:16:59.117
a thousand handhelds for
point of service from an OEM.
01:16:59.117 --> 01:17:02.623
I wanna be able to bulk
provision that thousand devices,
01:17:02.623 --> 01:17:05.640
rather than having to
go device by device.
01:17:05.640 --> 01:17:09.240
That's something that we
include built in support for,
01:17:09.240 --> 01:17:12.170
and the other thing that we
support is integration with
01:17:12.170 --> 01:17:13.850
Azure Active Directory.
01:17:13.850 --> 01:17:16.150
So to get strong identity for
01:17:16.150 --> 01:17:17.970
the users of these
devices as well.
01:17:19.330 --> 01:17:22.360
Across inventory being able
to add these to inventory and
01:17:22.360 --> 01:17:25.320
then being able to configure and
secure the device.
01:17:25.320 --> 01:17:30.550
Here, we're talking about things
like certificate managements,
01:17:30.550 --> 01:17:34.380
being able to provision VPNs and
email.
01:17:34.380 --> 01:17:37.876
We're talking about being able
to control how this device
01:17:37.876 --> 01:17:38.803
gets updated,
01:17:38.803 --> 01:17:42.590
being able to control how
this device gets locked down.
01:17:42.590 --> 01:17:44.990
All supported in this
part of the life cycle.
01:17:46.780 --> 01:17:49.000
And then moving over to
application management.
01:17:50.070 --> 01:17:53.290
This is where,
you'll see capabilities like
01:17:53.290 --> 01:17:55.890
the ability to have
a curated Windows store.
01:17:55.890 --> 01:17:58.720
To be able to do
volume purchase of
01:17:58.720 --> 01:18:01.780
applications that will
reside on these devices.
01:18:01.780 --> 01:18:04.720
To be able to manage
Win32 applications that
01:18:04.720 --> 01:18:05.899
run on these devices.
01:18:08.170 --> 01:18:09.060
Remote assistance,
01:18:09.060 --> 01:18:12.070
I wanna be able to wipe devices
if something goes wrong.
01:18:12.070 --> 01:18:13.954
I wanna be able to lock them or
01:18:13.954 --> 01:18:16.159
reset pins if I
need to lock them.
01:18:16.159 --> 01:18:19.114
I wanna be able to do
geo-fencing and those kinds of
01:18:19.114 --> 01:18:22.630
scenarios to make sure it stays
within a particular region.
01:18:23.840 --> 01:18:26.250
And then finally,
when all is done,
01:18:26.250 --> 01:18:28.870
the ability to both unenroll but
01:18:28.870 --> 01:18:32.350
then also remove the appropriate
enterprise assets, like
01:18:32.350 --> 01:18:36.020
certificates from the device
at the point of unenrollment.
01:18:36.020 --> 01:18:39.767
So lots of detail here, but just
to illustrate how we thought
01:18:39.767 --> 01:18:43.077
through this whole lifecycle
of device management.
01:18:48.117 --> 01:18:50.826
Now, one of the things we
just touched on as a part of
01:18:50.826 --> 01:18:52.659
device management was updating.
01:18:52.659 --> 01:18:54.868
How devices get updated?
01:18:54.868 --> 01:18:58.434
And a number of servicing
options that you have available
01:18:58.434 --> 01:19:00.370
for Windows 10 IoT devices.
01:19:01.830 --> 01:19:02.783
The first one,
01:19:02.783 --> 01:19:05.867
is that devices can just
always be kept up to date.
01:19:05.867 --> 01:19:09.234
And when devices are always
kept up to date,
01:19:09.234 --> 01:19:13.511
devices will get all the latest
features and security,
01:19:13.511 --> 01:19:18.152
quality, reliability updates
as well, on a constant basis
01:19:18.152 --> 01:19:22.740
while that device is in
support and being updated.
01:19:22.740 --> 01:19:26.520
Devices can also be configured
to only receive updates for
01:19:26.520 --> 01:19:27.510
security purposes.
01:19:29.160 --> 01:19:31.334
And finally, for some devices,
01:19:31.334 --> 01:19:34.367
they can be configured
to never take updates.
01:19:34.367 --> 01:19:38.155
An example of a device that
you might want to configure
01:19:38.155 --> 01:19:41.617
to never take updates
would be a medical device.
01:19:41.617 --> 01:19:44.864
That goes through a rigorous
certification process, and
01:19:44.864 --> 01:19:47.978
any updates to the software
in that device might require
01:19:47.978 --> 01:19:51.980
recertification, or trigger
a recertification process.
01:19:51.980 --> 01:19:55.043
Sometimes we and partners
in those cases will set up
01:19:55.043 --> 01:19:57.475
devices so
that they never get updated.
01:19:57.475 --> 01:20:00.709
The only time they get updated
is when they're completely
01:20:00.709 --> 01:20:03.746
reflashed with a new image
that the OEM would configure
01:20:06.034 --> 01:20:10.295
Now looking a little bit deeper
at updates both OEM's and
01:20:10.295 --> 01:20:15.400
enterprises have control over
how update behavior occurs.
01:20:15.400 --> 01:20:17.989
So it can be driven
through policy, for
01:20:17.989 --> 01:20:21.449
example managed by an MDM or
directly on the device.
01:20:21.449 --> 01:20:24.534
So you can control when
things get downloaded,
01:20:24.534 --> 01:20:28.170
when they get installed,
when machine gets rebooted.
01:20:30.130 --> 01:20:33.640
Devices can either connect
directly to Windows Update, or
01:20:33.640 --> 01:20:37.983
they can connect indirectly
to Windows Update through
01:20:37.983 --> 01:20:41.705
what we call WSUS,
Windows Server Update Services.
01:20:41.705 --> 01:20:42.885
This is the ability for
01:20:42.885 --> 01:20:46.955
an enterprise to have a local
instance of Windows Update
01:20:46.955 --> 01:20:49.600
within the firewall
of their enterprise.
01:20:49.600 --> 01:20:52.656
So they can control which
updates go to devices or
01:20:52.656 --> 01:20:56.456
through an MDM which is another
way that updates can be pushed
01:20:56.456 --> 01:20:58.840
to these devices so
a lot of options for
01:20:58.840 --> 01:21:02.143
managing how Windows 10
devices become updated.
01:21:04.653 --> 01:21:08.727
And that was a lot to go through
in terms of one platform.
01:21:08.727 --> 01:21:12.373
I'd like to now touch on
the next pillar, which
01:21:12.373 --> 01:21:17.310
is around security and talking
about a few aspects of security.
01:21:19.520 --> 01:21:22.670
So first, how many of you
have seen something like this
01:21:22.670 --> 01:21:23.700
on the right.
01:21:23.700 --> 01:21:25.590
Like an industry device
that's sitting out there
01:21:25.590 --> 01:21:27.650
that has maybe
a Windows dialogue up?
01:21:27.650 --> 01:21:31.070
Anybody seen this on an ATM,
digital sign?
01:21:31.070 --> 01:21:32.060
Nobody's ever seen this?
01:21:33.070 --> 01:21:35.190
A couple of people have,
I see this quite frequently.
01:21:36.260 --> 01:21:38.660
Typically what that means is
that the developer of this
01:21:38.660 --> 01:21:42.150
device, or the application
that runs on this device,
01:21:42.150 --> 01:21:44.370
did not appropriately
lock down the device
01:21:44.370 --> 01:21:46.900
to prevent this
situation from occurring.
01:21:46.900 --> 01:21:49.960
What we've tried to do
with Windows 10 is make it
01:21:49.960 --> 01:21:51.970
as easy as possible.
01:21:51.970 --> 01:21:53.650
For both OEMs, and
01:21:53.650 --> 01:21:58.060
then enterprise is managing
these devices to configure and
01:21:58.060 --> 01:22:01.390
lock them down so that you don't
run into this situation where
01:22:01.390 --> 01:22:05.720
you go to an ATM and it tells
you the anti-virus is out of
01:22:05.720 --> 01:22:10.320
date or some application on the
system had experienced a crash.
01:22:12.550 --> 01:22:15.810
Now when we talk about Lockdown
it's a fairly generic term.
01:22:15.810 --> 01:22:19.340
There are a bunch of things that
are represented by Lockdown.
01:22:19.340 --> 01:22:21.960
One type of Lockdown is
something that we call input
01:22:21.960 --> 01:22:23.200
filters.
01:22:23.200 --> 01:22:26.542
Input filters mean,
I can lock out keyboard input.
01:22:26.542 --> 01:22:28.624
I can lock out mouse input.
01:22:28.624 --> 01:22:32.400
I can lock out certain
gestures from the screen.
01:22:32.400 --> 01:22:34.300
Lots of different
options I have for
01:22:34.300 --> 01:22:38.340
how I want to enforce
interaction with the device.
01:22:38.340 --> 01:22:41.600
So for example,
if I had a touch screen kiosk
01:22:41.600 --> 01:22:44.060
I may want to choose to
lock out keyboard mouse.
01:22:44.060 --> 01:22:47.610
Nobody can plugin a keyboard
mouse or vice versa,
01:22:47.610 --> 01:22:51.640
I may not allow someone
to do a swipe gesture and
01:22:51.640 --> 01:22:54.710
be able to bring up
some part of the UI.
01:22:54.710 --> 01:22:57.210
I may want to enforce
a certain interaction model.
01:22:57.210 --> 01:23:01.130
Input filters is
the way I can do that.
01:23:01.130 --> 01:23:06.950
I can use AppLocker to be
able to enforce restrictions
01:23:06.950 --> 01:23:09.850
on the use of certain
applications on this device.
01:23:09.850 --> 01:23:12.280
I can use the shell in
App Launcher to say hey.
01:23:12.280 --> 01:23:14.910
Rather than launching directly
into the Windows Shell,
01:23:14.910 --> 01:23:17.920
I want this device to just
launch into my application.
01:23:17.920 --> 01:23:19.830
And only show this
application and
01:23:19.830 --> 01:23:21.900
never bring up
the Windows Shell.
01:23:21.900 --> 01:23:23.840
Common for
an ATM-like experience.
01:23:25.420 --> 01:23:27.140
Write filters
provide a means for
01:23:27.140 --> 01:23:31.680
devices to sort of always
be in a fresh state, so
01:23:31.680 --> 01:23:36.050
that you don't run into
the situation where one user can
01:23:36.050 --> 01:23:40.200
come in, mess up a device and
then leave it unusable.
01:23:40.200 --> 01:23:42.780
For example like Kiosk for
the next user.
01:23:42.780 --> 01:23:45.770
In many cases a simple
reboot can then
01:23:45.770 --> 01:23:48.780
restore that device back to
its initial pristine state.
01:23:50.710 --> 01:23:56.010
The USB filter prevents
someone from plugging a USB
01:23:56.010 --> 01:23:58.640
storage device into
a USB port and
01:23:58.640 --> 01:24:01.830
doing things with that
USB storage device.
01:24:01.830 --> 01:24:04.990
And then finally, the ability
to do filters of dialogs and
01:24:04.990 --> 01:24:06.210
notifications.
01:24:06.210 --> 01:24:07.510
Something similar to
what you see here.
01:24:07.510 --> 01:24:12.174
So that if my device experience
is really this application that
01:24:12.174 --> 01:24:14.638
I've written to dispense cash,
01:24:14.638 --> 01:24:19.260
I can lock out all the other
notifications that may occur.
01:24:19.260 --> 01:24:21.420
That may perturb
the user experience.
01:24:23.460 --> 01:24:26.200
From its intended purpose,
which is dispensing cash.
01:24:28.490 --> 01:24:31.103
Adds up to two things,
a more secure device and
01:24:31.103 --> 01:24:34.124
a more predictable and
tailored device experience.
01:24:38.356 --> 01:24:41.825
Now talking a little bit more
about device experiences,
01:24:41.825 --> 01:24:44.650
one of the interesting
differences between.
01:24:45.670 --> 01:24:48.130
Hand held phone like devices and
01:24:48.130 --> 01:24:52.380
desktop like devices is desktops
are inherently multi user.
01:24:52.380 --> 01:24:55.200
When I use desktop Windows,
I have the ability to have
01:24:55.200 --> 01:24:57.960
multiple people log into
this Windows device and
01:24:57.960 --> 01:24:59.540
do interesting things.
01:24:59.540 --> 01:25:03.940
But my phone is not multi user.
01:25:03.940 --> 01:25:07.270
My phone is in fact kind
of hard-coded to me
01:25:07.270 --> 01:25:09.160
as the primary user
of this device.
01:25:10.500 --> 01:25:12.400
This is my phone.
01:25:12.400 --> 01:25:15.310
If my wife picks up my phone,
she doesn't get to log in as
01:25:15.310 --> 01:25:19.310
herself, she has to use my
phone and impersonate me.
01:25:19.310 --> 01:25:24.760
So what's we've done though is
we want handheld devices to also
01:25:24.760 --> 01:25:29.770
be able to be used in multi-user
scenarios, despite the kind of
01:25:29.770 --> 01:25:32.880
Windows identity being kind
of warm Windows identity.
01:25:32.880 --> 01:25:35.680
And so
what you see here is a series of
01:25:35.680 --> 01:25:38.870
screen shots of
Windows Ten mobile.
01:25:38.870 --> 01:25:43.710
Providing the capability for
role switching on a device.
01:25:43.710 --> 01:25:47.910
So on the left, for
a particular device,
01:25:47.910 --> 01:25:53.080
I can be part of the technician,
the manager, or the guest role.
01:25:53.080 --> 01:25:54.890
And when I choose
to switch roles,
01:25:54.890 --> 01:25:58.770
I can present a login and
authenticate that user based on
01:25:58.770 --> 01:26:00.810
the credentials that
they've provided.
01:26:00.810 --> 01:26:03.507
So let's say I've
typed in MacGyver.
01:26:03.507 --> 01:26:06.951
MacGyver's a manager,
MacGyver would see the user
01:26:06.951 --> 01:26:10.720
interface that's appropriate for
a manager.
01:26:10.720 --> 01:26:12.910
Inventory, time cards, calendar,
01:26:12.910 --> 01:26:16.570
instructions, also
an app to switch roles.
01:26:16.570 --> 01:26:18.050
But it's a set of
applications and
01:26:18.050 --> 01:26:22.050
it's a home screen experience
that's tailored for a manager.
01:26:22.050 --> 01:26:24.730
But I can take that same device,
I can log out as manager.
01:26:24.730 --> 01:26:28.020
I can switch roles and
login as a technician.
01:26:28.020 --> 01:26:30.730
And when I'm logged in as
a technician, I see a different
01:26:30.730 --> 01:26:34.470
home screen and a different set
of applications for that device.
01:26:34.470 --> 01:26:37.020
So what this enables me to do.
01:26:37.020 --> 01:26:40.470
Is if you think about
a scenario like retail.
01:26:40.470 --> 01:26:45.070
A scenario like retail, I can
have a bunch of generic devices
01:26:45.070 --> 01:26:48.360
that I can have plugged in on
a docking station, maybe a whole
01:26:48.360 --> 01:26:51.410
bunch of them, maybe a dozen,
two dozen devices.
01:26:51.410 --> 01:26:54.030
And in the morning
a worker can come by,
01:26:54.030 --> 01:26:56.020
they can pick up one
of these devices,
01:26:56.020 --> 01:26:59.660
they can log in as whoever they
are a technician for example.
01:26:59.660 --> 01:27:01.510
And then they can walk
around using that device
01:27:01.510 --> 01:27:02.230
during the day.
01:27:02.230 --> 01:27:05.570
When they're done with it, they
can place it back in the cradle.
01:27:05.570 --> 01:27:08.840
The next person can pick up,
maybe the same device, login as
01:27:08.840 --> 01:27:11.610
themselves and they can get the
tailored experience for them.
01:27:11.610 --> 01:27:15.741
So it allows the end enterprise
using these devices to be able
01:27:15.741 --> 01:27:19.305
to have one common pool of
devices used by a variety of
01:27:19.305 --> 01:27:22.707
employees that may occupy
different roles within
01:27:22.707 --> 01:27:24.017
an organization.
01:27:31.071 --> 01:27:35.127
Also, I'd like to touch more
directly on aspects of security
01:27:35.127 --> 01:27:36.767
outside user identity.
01:27:36.767 --> 01:27:38.902
One of the things we're very,
01:27:38.902 --> 01:27:43.179
very focused on is ensuring
protection against contemporary
01:27:43.179 --> 01:27:46.890
security threats from within
the operating system.
01:27:46.890 --> 01:27:49.640
And so, one of the pieces of
news that we talked about
01:27:51.010 --> 01:27:54.060
this week was this
Windows Hello.
01:27:54.060 --> 01:27:57.170
The idea that Windows
can identify me
01:27:57.170 --> 01:27:58.740
by looking at my face, and
01:27:58.740 --> 01:28:01.735
being able to Biometrically
identify me by face.
01:28:01.735 --> 01:28:04.155
But also, Windows supports
01:28:05.235 --> 01:28:08.595
next generation credentials
like two factor authentication.
01:28:08.595 --> 01:28:09.995
I need more than
just a username and
01:28:09.995 --> 01:28:13.742
password to be able to get
into a particular resource.
01:28:13.742 --> 01:28:16.612
Being able to provide advanced
01:28:16.612 --> 01:28:20.312
credential technology we think
is critical, particularly in
01:28:20.312 --> 01:28:23.772
the IOT space where security
can mean a number of things.
01:28:23.772 --> 01:28:28.962
In the IOT space we have devices
that have an interactive user.
01:28:28.962 --> 01:28:30.732
The phone example that
I just showed you is
01:28:30.732 --> 01:28:33.392
an example of a device that
has an interactive user.
01:28:33.392 --> 01:28:36.590
So I wanna be able to allow that
device to be used, based on
01:28:36.590 --> 01:28:39.420
whatever the credentials of
that interactive user are.
01:28:39.420 --> 01:28:42.220
On the other hand I have
lots of IOT devices
01:28:42.220 --> 01:28:44.470
that do not have
an interactive user.
01:28:44.470 --> 01:28:47.250
If we think about
video cameras and
01:28:47.250 --> 01:28:50.740
motion sensors, and
water pressure meters, and
01:28:50.740 --> 01:28:53.580
all the different kinds of IOT
devices that you can imagine
01:28:53.580 --> 01:28:57.690
that are connected in smart but,
are more ambient
01:28:57.690 --> 01:29:01.090
in the environments not about
having someone interactive.
01:29:01.090 --> 01:29:04.780
We kinda get into the space
where it's not just about secure
01:29:04.780 --> 01:29:07.710
identity, it's about making sure
that the very devices themselves
01:29:07.710 --> 01:29:10.690
are safe, that the devices
themselves are trustworthy.
01:29:12.370 --> 01:29:16.420
And, in that, we start to move
toward being able to ensure that
01:29:16.420 --> 01:29:19.720
the data on these devices
is secure and protected.
01:29:21.340 --> 01:29:24.290
That I have the ability to have
strong separation of application
01:29:24.290 --> 01:29:26.360
data across different
applications that may run
01:29:26.360 --> 01:29:27.410
on this device.
01:29:27.410 --> 01:29:30.611
And that my device is capable
of resisting various malware
01:29:30.611 --> 01:29:31.205
attacks.
01:29:31.205 --> 01:29:34.213
And I'll say a little
bit more about security.
01:29:37.840 --> 01:29:42.271
One of the investments that
Kevin Dallas talked a little bit
01:29:42.271 --> 01:29:45.283
about this morning was
the idea of TPM and
01:29:45.283 --> 01:29:47.710
supporting TPM in devices.
01:29:47.710 --> 01:29:51.925
Of course, in Windows we support
devices that both include and
01:29:51.925 --> 01:29:53.440
don't include a TPM.
01:29:53.440 --> 01:29:57.660
But, for devices that need to be
secure, for devices that need to
01:29:57.660 --> 01:30:02.128
be trustworthy, provides a very
interesting measure of security.
01:30:02.128 --> 01:30:06.506
So secure boot is one of the
great examples where by using
01:30:06.506 --> 01:30:11.258
secure boot or measured boot we
can determine if software has
01:30:11.258 --> 01:30:14.540
been inserted into
the boot path.
01:30:14.540 --> 01:30:16.610
That has this device been rooted
01:30:17.660 --> 01:30:21.170
in which case the device may
no longer be trustworthy.
01:30:21.170 --> 01:30:23.980
So if I think about ambient
devices that don't have
01:30:23.980 --> 01:30:27.860
an active user the cost of
that is potentially very,
01:30:27.860 --> 01:30:31.210
very great to have a device
that's been compromised.
01:30:31.210 --> 01:30:36.220
Think about
the agriculture space.
01:30:36.220 --> 01:30:39.310
So in the agriculture
space you have
01:30:39.310 --> 01:30:42.230
harvesting machines
that are instrumented.
01:30:42.230 --> 01:30:44.950
And you may think, well okay,
01:30:44.950 --> 01:30:48.040
there's the humble
harvesting machine
01:30:48.040 --> 01:30:52.160
that's collecting data on how
much wheat it's harvesting.
01:30:52.160 --> 01:30:55.050
But then,
somewhere in a big city,
01:30:55.050 --> 01:30:59.760
far away from that farmer,
there's a commodity trader
01:30:59.760 --> 01:31:01.649
that is trading on
the price of wheat.
01:31:02.790 --> 01:31:06.280
You think about, what kind of
exploits are possible here.
01:31:06.280 --> 01:31:11.340
What if, that commodities
trader were a bad guy, and
01:31:11.340 --> 01:31:13.580
had managed to exploit, and
01:31:13.580 --> 01:31:16.790
root some of the sensors that
are running on that device.
01:31:16.790 --> 01:31:21.760
They could use their
knowledge of actual yields,
01:31:21.760 --> 01:31:25.720
which they could
manipulate at the point of
01:31:25.720 --> 01:31:28.470
the device to be able to
make money on the trade.
01:31:30.000 --> 01:31:35.500
Just one example of the cost,
the potential
01:31:35.500 --> 01:31:39.590
cost of having devices that are
potentially insecure rendering
01:31:39.590 --> 01:31:44.830
data that feedback into
our nation's economies.
01:31:46.240 --> 01:31:48.690
You can think of other examples,
01:31:48.690 --> 01:31:50.850
security is another
great example.
01:31:50.850 --> 01:31:54.660
You don't want the security
camera to be compromised and
01:31:54.660 --> 01:31:58.840
showing perhaps showing a still
frame rather than a constant
01:31:58.840 --> 01:32:02.180
stream of videos of list
kind of goes on and on.
01:32:02.180 --> 01:32:05.720
Now, along with that being able
to protect the data that sits on
01:32:05.720 --> 01:32:06.940
this device.
01:32:06.940 --> 01:32:10.930
I had a colleague
who I kind of called
01:32:10.930 --> 01:32:13.820
this colleague
a white hat hacker.
01:32:13.820 --> 01:32:20.290
Someone who likes to hack
on devices not to go trade
01:32:20.290 --> 01:32:24.500
commodities in New York City but
to be able to point out to
01:32:24.500 --> 01:32:27.890
makers of devices that they've
got some flaws in their design.
01:32:27.890 --> 01:32:33.340
And one of the things that he
says is whenever I find an IoT
01:32:33.340 --> 01:32:37.110
device, the first thing I do,
is I look for the storage card.
01:32:38.520 --> 01:32:41.660
If I can find the storage
card I can figure out,
01:32:41.660 --> 01:32:43.490
can I root this device?
01:32:43.490 --> 01:32:45.140
Can I put software
on this device?
01:32:45.140 --> 01:32:47.450
Can I read the data that
exists on this device?
01:32:48.560 --> 01:32:51.030
And TPM provides again
01:32:51.030 --> 01:32:54.290
a first step security
protection against the rooting.
01:32:54.290 --> 01:32:59.070
But then also if you think
about the ability to BitLocker,
01:32:59.070 --> 01:32:59.920
a drive, and
01:32:59.920 --> 01:33:03.960
BitLocker's built into all
editions of Windows 10 IoT.
01:33:03.960 --> 01:33:07.430
So that if somebody pulls
the SD card out of my device,
01:33:07.430 --> 01:33:09.710
it's not immediately
compromised.
01:33:09.710 --> 01:33:13.300
There's extra measures that that
hacker would have to go through
01:33:13.300 --> 01:33:15.610
in order to hack that device.
01:33:15.610 --> 01:33:21.280
Similarly, I wanna be able to
have secure device identities
01:33:21.280 --> 01:33:24.500
in the form of certificates
protected by the TPM stored on
01:33:24.500 --> 01:33:28.940
that device so that a device has
the ability to render onto for
01:33:28.940 --> 01:33:32.130
example a cloud service or
to other devices on the network.
01:33:32.130 --> 01:33:33.180
This is who I am and
01:33:33.180 --> 01:33:36.230
I can securely tell you
exactly who I am based on
01:33:36.230 --> 01:33:39.789
the certificate that exists
inside of my certificate store.
01:33:44.794 --> 01:33:47.294
Now, I wanna talk a little
bit now about connectivity.
01:33:53.127 --> 01:33:56.727
Starting with a little bit
more about Windows 10 IoT for
01:33:56.727 --> 01:34:00.627
small devices, and thinking
about how connectivity reads on
01:34:00.627 --> 01:34:02.960
Windows 10 IoT for
small devices.
01:34:05.210 --> 01:34:09.510
For small devices, mobile
broadband data is supported.
01:34:09.510 --> 01:34:14.262
So for devices such as these,
although these particular
01:34:14.262 --> 01:34:18.127
devices don't have
a cellular radio in them.
01:34:18.127 --> 01:34:21.032
If they were to have a cellular
radio, Windows 10 IoT for
01:34:21.032 --> 01:34:23.380
small devices would
support data only.
01:34:23.380 --> 01:34:26.690
If I wanted voice,
I would need to use mobile.
01:34:26.690 --> 01:34:30.500
Windows 10 IoT for
mobile supports voice.
01:34:30.500 --> 01:34:34.160
But also out of the box
Wi-Fi supported and
01:34:34.160 --> 01:34:37.160
directly manipulatable via APIs.
01:34:37.160 --> 01:34:40.760
Bluetooth and Bluetooth low
energy directly supported,
01:34:40.760 --> 01:34:42.240
built into the operating system.
01:34:43.600 --> 01:34:46.940
And the ability to manage
various kinds of connections
01:34:46.940 --> 01:34:48.450
across devices.
01:34:48.450 --> 01:34:52.470
Whether mobile data, Wi-Fi data,
or Bluetooth data via API,
01:34:52.470 --> 01:34:56.030
via my applications that
I've written in user mode,
01:34:56.030 --> 01:34:59.070
all supported in Windows
10 IoT for small devices.
01:34:59.070 --> 01:35:01.570
So the attempt is to
really ensure that
01:35:01.570 --> 01:35:03.940
these devices are out of a box,
01:35:03.940 --> 01:35:05.820
meant to be connected to
the rest of the world.
01:35:07.590 --> 01:35:10.070
Now speaking of being connected
I wanted to talk a little bit
01:35:10.070 --> 01:35:11.400
more about AllJoyn.
01:35:12.500 --> 01:35:16.130
AllJoyn we've talked some about
here at winhec this week.
01:35:17.330 --> 01:35:20.440
What you see here is
a typical graph of devices
01:35:20.440 --> 01:35:22.250
that I might have in my home.
01:35:22.250 --> 01:35:25.830
I've got some phones and
I've got some wrist watches and
01:35:25.830 --> 01:35:29.580
I've got some light bulbs and
computers,
01:35:29.580 --> 01:35:34.100
audio video systems and
thermostats, and you name it.
01:35:34.100 --> 01:35:37.389
And each of these devices
has what you might call some
01:35:37.389 --> 01:35:39.044
standard capabilities.
01:35:39.044 --> 01:35:43.211
Standard capabilities could
include things like being able
01:35:43.211 --> 01:35:45.906
to send and
display notifications, or
01:35:45.906 --> 01:35:49.252
having a clock on board or
being a light-bulb and
01:35:49.252 --> 01:35:52.044
having a light be able
to turn on and off.
01:35:52.044 --> 01:35:54.572
These are all examples of just
sort of standard things that
01:35:54.572 --> 01:35:55.820
devices might be able to do.
01:35:57.740 --> 01:36:01.570
Now, if I were to sort of
depict how this works today,
01:36:01.570 --> 01:36:06.060
in a lot of modern homes,
you might depict this not as
01:36:06.060 --> 01:36:09.720
one graph, but
as a series of graphs.
01:36:09.720 --> 01:36:12.472
Because today the device and
01:36:12.472 --> 01:36:16.377
operability ecosystem
is fragmented.
01:36:16.377 --> 01:36:19.570
Vendor A, might have their
own ecosystem of devices that
01:36:19.570 --> 01:36:22.297
work together and
vendor B might have a different
01:36:22.297 --> 01:36:24.710
ecosystem of devices
that work together.
01:36:24.710 --> 01:36:25.635
And the protocol for
01:36:25.635 --> 01:36:28.780
A might not communicate well
with the protocol for B.
01:36:28.780 --> 01:36:32.527
And, at Microsoft, we have
the point of view that this
01:36:32.527 --> 01:36:35.627
is really just unacceptable for
customers.
01:36:35.627 --> 01:36:39.350
When you as a customer acquire
some devices your life should
01:36:39.350 --> 01:36:42.327
get better with every new
device that you buy and
01:36:42.327 --> 01:36:44.230
bring into your life.
01:36:44.230 --> 01:36:46.740
When you buy and bring a new
device into your life,
01:36:46.740 --> 01:36:49.530
it should be born
knowing how to work
01:36:49.530 --> 01:36:52.390
automatically with all
the other devices in your life.
01:36:52.390 --> 01:36:54.390
There should be standards
based protocols for
01:36:54.390 --> 01:36:56.860
these devices to interact
with one another.
01:36:56.860 --> 01:36:59.020
This is really our
point of view.
01:36:59.020 --> 01:37:02.220
And so if I think about
all the different things
01:37:02.220 --> 01:37:07.370
that I would have to standardize
to make that happen, how
01:37:07.370 --> 01:37:11.640
do I discover if two devices are
on the same proximal network,
01:37:11.640 --> 01:37:13.840
how do they discover
that they exist?
01:37:13.840 --> 01:37:16.590
And how do they connect and
01:37:16.590 --> 01:37:18.410
communicate with one
another securely?
01:37:19.700 --> 01:37:22.920
How do I manage these devices,
01:37:22.920 --> 01:37:25.780
not in a sort of IT pro
enterprise sort of way but
01:37:25.780 --> 01:37:29.060
just as maybe someone with
some devices in my home.
01:37:29.060 --> 01:37:31.920
How do I manage these
in a consistent way?
01:37:31.920 --> 01:37:33.460
How do I get them to inter-opp?
01:37:33.460 --> 01:37:36.740
How do I get device a,
which might be a switch,
01:37:36.740 --> 01:37:39.000
tell device b,
which might be a light bulb,
01:37:39.000 --> 01:37:41.879
when I go up you turn on,
when I go down you turn off?
01:37:43.870 --> 01:37:47.051
And finally, how do I do all of
this in a way that is both open
01:37:47.051 --> 01:37:52.100
and cross-platform so that it
doesn't matter if these devices
01:37:52.100 --> 01:37:55.860
are built on Windows or built
on Linux or built on Android or
01:37:55.860 --> 01:37:59.600
built in some embedded RTOS OS?
01:37:59.600 --> 01:38:03.000
They should all just out of the
box know how to work together.
01:38:03.000 --> 01:38:05.050
So again, that's really
our point of view and
01:38:05.050 --> 01:38:09.760
that's really why we've taken
the move of devoting a lot
01:38:09.760 --> 01:38:13.180
of our engineering resource
into supporting AllJoyn.
01:38:13.180 --> 01:38:16.600
AllJoyn is supported out of the
box for all Windows 10 editions
01:38:16.600 --> 01:38:21.650
including the IoT editions,
but also desktop and phone.
01:38:23.160 --> 01:38:25.720
So Windows devices come out
01:38:25.720 --> 01:38:28.740
knowing how to communicate
with other AllJoyn devices.
01:38:28.740 --> 01:38:32.478
And those building devices with
Windows 10 have a very easy
01:38:32.478 --> 01:38:36.071
path to supporting AllJoyn
based networks with the device
01:38:36.071 --> 01:38:38.211
that you build with Windows 10.
01:38:43.502 --> 01:38:46.174
I wanted to show you just
an example of some of
01:38:46.174 --> 01:38:49.788
the application level code that
I would write to be able to do
01:38:49.788 --> 01:38:51.540
AllJoyn from Windows 10.
01:38:51.540 --> 01:38:56.320
So you can see on the top like
a simple sample application.
01:38:57.650 --> 01:38:58.631
And today,
01:38:58.631 --> 01:39:03.545
again with different call them
wall of garden ecosystems.
01:39:03.545 --> 01:39:06.050
If I were to write an
application to manage my house I
01:39:06.050 --> 01:39:08.032
would have to do
something different for
01:39:08.032 --> 01:39:10.831
all my Bluetooth devices,
then something different for
01:39:10.831 --> 01:39:13.863
all my Z-Waves devices, then
something different for all my
01:39:13.863 --> 01:39:17.580
Zigby devices, then something
different for my Wi-Fi devices.
01:39:17.580 --> 01:39:21.840
With AllJoyn, if I have a set
of devices that support AllJoyn,
01:39:21.840 --> 01:39:25.120
the code's very simple,
attached to an AllJoyn bus.
01:39:26.440 --> 01:39:28.660
Watch the temperature,
the temperature sensor.
01:39:30.010 --> 01:39:31.460
Be able to await a change and
01:39:31.460 --> 01:39:33.810
receive a notification
of a change.
01:39:33.810 --> 01:39:36.830
There's actually a session
just following this one
01:39:36.830 --> 01:39:38.810
that Gavin Gear is doing.
01:39:38.810 --> 01:39:41.660
He's a program manager
that works on this
01:39:41.660 --> 01:39:43.170
technology full time.
01:39:43.170 --> 01:39:45.142
So, if you're
interested in AllJoyn,
01:39:45.142 --> 01:39:48.073
I would highly recommend that
you visit Gavin's session.
01:39:48.073 --> 01:39:48.992
But meanwhile,
01:39:48.992 --> 01:39:51.948
I'd like to say just a little
bit more about AllJoyn.
01:39:51.948 --> 01:39:57.448
So this shows a kind of sample
map of AllJoyn devices.
01:39:57.448 --> 01:40:01.770
The big pink circles represent
AllJoyn nodes The little pink
01:40:01.770 --> 01:40:05.159
circles represent AllyJoyn
thin clients, and
01:40:05.159 --> 01:40:09.497
the purple nodes represent non
AllJoyn ecosystem devices.
01:40:09.497 --> 01:40:12.350
Devices that connect
to some other proximal
01:40:12.350 --> 01:40:13.744
network ecosystem.
01:40:13.744 --> 01:40:17.176
And so, what this shows in the
middle I have a device that's
01:40:17.176 --> 01:40:21.021
built on Windows 10, and because
this device is built on Windows
01:40:21.021 --> 01:40:23.090
10 it means a couple of things.
01:40:23.090 --> 01:40:25.970
One, it means it can talk to
other all these other AllJoyn
01:40:25.970 --> 01:40:28.510
devices whether they're PCs or
01:40:28.510 --> 01:40:32.440
Windows phones or non Windows
phones or refrigerators or
01:40:32.440 --> 01:40:36.350
doorknobs or light bulbs or .NET
micro devices it knows how to
01:40:36.350 --> 01:40:39.760
talk to all these devices
kind of out of the box.
01:40:39.760 --> 01:40:42.780
The other thing it means is
we've done the work in Windows
01:40:42.780 --> 01:40:47.460
10 to make it easy to connect
this all AllJoyn network with
01:40:47.460 --> 01:40:51.420
other kinds of device networks,
and enable those other kinds of
01:40:51.420 --> 01:40:56.120
device networks to show up as
AllJoyn devices on this network.
01:40:56.120 --> 01:41:00.290
So kind of virtually bridges in
this case BACnet, Z-Wave, and
01:41:00.290 --> 01:41:03.590
Bluetooth device networks
into this AllJoyn network so
01:41:03.590 --> 01:41:08.490
they look and act like one big
device network in my house.
01:41:08.490 --> 01:41:11.360
That capability is built in, and
again Gavin will talk to you
01:41:11.360 --> 01:41:13.870
a little bit about that this
afternoon if you attend
01:41:13.870 --> 01:41:14.490
his session.
01:41:15.630 --> 01:41:18.280
The other important piece of
this is well, what if I've got
01:41:18.280 --> 01:41:20.950
some devices that aren't
physically in the same place,
01:41:20.950 --> 01:41:23.350
they're not physically
on the same network?
01:41:23.350 --> 01:41:27.880
In that case we're investing in
the Windows IoT AllJoyn cloud
01:41:27.880 --> 01:41:32.950
bridge, which will enable me to
bridge from one physical network
01:41:32.950 --> 01:41:36.080
through the cloud to another
physical AllJoyn network.
01:41:37.100 --> 01:41:41.520
So in this case this might
be my house, but this might
01:41:42.580 --> 01:41:48.470
be my summer house,
my car, my office.
01:41:48.470 --> 01:41:50.690
Different environments that I
wanna be able to work together
01:41:50.690 --> 01:41:54.830
and manage as if it's one set of
devices, and I want some device
01:41:54.830 --> 01:41:58.410
that maybe is in my office to be
able to talk to some device that
01:41:58.410 --> 01:42:01.490
might be in my home, and to do
that very easily and readily.
01:42:02.880 --> 01:42:07.975
The other set of investments
that is on our road map for
01:42:07.975 --> 01:42:12.120
this topology is to be able
to connect from that bridge
01:42:12.120 --> 01:42:14.950
also to third party
device clouds, so
01:42:14.950 --> 01:42:19.220
that if I have some devices that
speak directly to a device cloud
01:42:19.220 --> 01:42:22.070
I wanna be able to bridge
those also into my network, so
01:42:22.070 --> 01:42:25.450
that I really have
one view of my stuff.
01:42:25.450 --> 01:42:28.297
As a consumer I wanna have
one view of my stuff,
01:42:28.297 --> 01:42:31.874
and as a builder of devices I
want my devices to participate
01:42:31.874 --> 01:42:34.804
in one ecosystem that my
customers care about.
01:42:39.813 --> 01:42:43.791
Now, since we're talking about
the cloud I thought I'd say
01:42:43.791 --> 01:42:47.067
a few more things about how
Windows IoT connects to
01:42:47.067 --> 01:42:49.880
the cloud and
leverages the best of Azure.
01:42:51.040 --> 01:42:54.350
We see a few different scenarios
that folks are trying to solve
01:42:54.350 --> 01:43:00.300
for when they want to connect
devices to a cloud like
01:43:00.300 --> 01:43:04.640
Azure to be able to make their
businesses more efficient or
01:43:04.640 --> 01:43:08.925
more innovative or to be able to
implement new business models.
01:43:08.925 --> 01:43:14.650
An example of efficiency might
be hey, instead of sending
01:43:14.650 --> 01:43:20.120
a person to go check the status
of some machine I wanna be
01:43:20.120 --> 01:43:24.210
able to connect all my machines
to the cloud, and then be
01:43:24.210 --> 01:43:26.720
able to look at this cloud data
to make sure that all devices
01:43:26.720 --> 01:43:29.570
are running within
the bounds of normal.
01:43:29.570 --> 01:43:32.650
And we see a lot of folks that
are starting to do this today,
01:43:32.650 --> 01:43:36.250
and we've talked about partners
that are doing this such as
01:43:36.250 --> 01:43:38.270
in the people moving space.
01:43:39.650 --> 01:43:44.340
And then if I think about sort
of transforming businesses
01:43:44.340 --> 01:43:48.210
this speaks to the notion
that I can move from a model
01:43:48.210 --> 01:43:53.200
where I'm just selling a device
to a model where I'm providing
01:43:53.200 --> 01:43:56.850
a device that works as an
ongoing service to my customers.
01:43:56.850 --> 01:44:00.630
It's an ongoing piece of value,
and I could potentially
01:44:00.630 --> 01:44:03.690
change the business model
from if we look at for
01:44:03.690 --> 01:44:07.520
example how things like tractors
and jet engines are starting to
01:44:07.520 --> 01:44:12.920
be sold it's becoming less
a capital asset sale.
01:44:12.920 --> 01:44:15.900
Hey, I sold you a big engine,
I'll
01:44:15.900 --> 01:44:19.410
collect my millions of dollars
and let you use your engine to
01:44:19.410 --> 01:44:21.960
I could sell you
an engine as a service.
01:44:21.960 --> 01:44:25.560
Here's an engine, and I have my
engine well instrumented, and
01:44:25.560 --> 01:44:29.570
I can sell you by the hour
of usage of that engine.
01:44:29.570 --> 01:44:33.030
And it ends up looking more
like a leasing financial model
01:44:33.030 --> 01:44:36.280
than it does like a capital
asset sale financial model.
01:44:36.280 --> 01:44:38.390
So, interesting
opportunities for
01:44:38.390 --> 01:44:41.810
transforming how business
is done, and innovation.
01:44:41.810 --> 01:44:43.800
Just brand new kinds of things.
01:44:43.800 --> 01:44:46.710
One example that always
comes to my mind here is
01:44:47.790 --> 01:44:50.980
If you're familiar with
the humble parking meter, right?
01:44:50.980 --> 01:44:52.870
Parking meters on the street.
01:44:52.870 --> 01:44:55.620
The typical parking
meter is kind
01:44:55.620 --> 01:45:00.220
of a early 20th century style
technology, iron meter.
01:45:00.220 --> 01:45:03.220
I can drive up to that meter,
I can put in coins and
01:45:03.220 --> 01:45:06.310
then I can park next to that
meter for a period of time.
01:45:06.310 --> 01:45:11.710
As a municipality, as a city the
way that I engage it that is I
01:45:11.710 --> 01:45:15.960
go contract with somebody, I buy
a whole bunch of parking meters.
01:45:15.960 --> 01:45:18.790
I then ask my public works
department to then go and
01:45:18.790 --> 01:45:21.620
install those parking
meters on the street, and
01:45:21.620 --> 01:45:24.090
then I can start collecting
money every time somebody parks,
01:45:24.090 --> 01:45:27.810
and then some number of years
down the road I finally paid off
01:45:27.810 --> 01:45:30.500
those meters and I can start
generating revenue for my city.
01:45:31.940 --> 01:45:34.300
There's actually a company
called IPS that does something
01:45:34.300 --> 01:45:35.150
very different.
01:45:35.150 --> 01:45:38.010
They've used IoT to implement
a very different business model.
01:45:38.010 --> 01:45:40.760
They offer smart parking meters,
and
01:45:40.760 --> 01:45:44.560
they way that they do business
with a municipality is they
01:45:44.560 --> 01:45:48.350
don't sell a meter,
they sell parking as a service.
01:45:48.350 --> 01:45:51.130
They will sign a deal
with the city too.
01:45:51.130 --> 01:45:55.470
They will encumber the cost
of installing the meters.
01:45:55.470 --> 01:45:57.160
They will manage
their reliability.
01:45:57.160 --> 01:45:59.200
They will fix them
when they break.
01:45:59.200 --> 01:46:02.330
Every month they'll write
the municipality a check for
01:46:02.330 --> 01:46:06.000
how much money they're owed
minus the amount of money that
01:46:06.000 --> 01:46:09.710
IPS takes as a part of
providing your service, but
01:46:09.710 --> 01:46:10.960
it's kind of a win win.
01:46:10.960 --> 01:46:13.960
IPS comes up with a very
innovative new business model
01:46:13.960 --> 01:46:16.950
and municipalities don't have to
worry about this frustration and
01:46:16.950 --> 01:46:20.520
headache of managing
these capital assets, and
01:46:20.520 --> 01:46:21.660
these are smart meters.
01:46:21.660 --> 01:46:24.920
They can do things
like they can detect
01:46:24.920 --> 01:46:28.710
when you drive away
from the parking spot.
01:46:28.710 --> 01:46:31.107
So, the days when there was
time left on the meter and
01:46:31.107 --> 01:46:33.230
you can kind of pull in and
be the next person and
01:46:33.230 --> 01:46:36.020
still have time left in this
case it's not there anymore.
01:46:36.020 --> 01:46:38.910
Every new customer has to
pay again, which is bad for
01:46:38.910 --> 01:46:40.080
those of us who park, but
01:46:40.080 --> 01:46:42.830
good for cities if you
have smart parking meters.
01:46:46.130 --> 01:46:50.530
Now, Azure has the most
comprehensive set
01:46:50.530 --> 01:46:53.950
of technologies available
in the cloud today for
01:46:53.950 --> 01:46:57.990
building IoT solutions, and if
you look across really any kind
01:46:57.990 --> 01:47:03.110
of device type connecting
in a variety of ways lots
01:47:03.110 --> 01:47:07.612
of different storage mechanisms
to be able to do batch,
01:47:07.612 --> 01:47:12.440
real time, ML style analytics,
and to be able
01:47:12.440 --> 01:47:16.020
to take action on data as
it's received into the cloud.
01:47:16.020 --> 01:47:20.650
Using this suite of capabilities
you can really build any
01:47:20.650 --> 01:47:24.820
leading edge IOT style solution
from a lot of devices.
01:47:26.640 --> 01:47:29.490
One of the announcements
that was made this week
01:47:29.490 --> 01:47:33.720
is the Microsoft Azure IoT
Suite, and one of the promises
01:47:33.720 --> 01:47:36.830
of the IoT Suite is to say
not only does Azure have this
01:47:36.830 --> 01:47:40.620
very rich set of capabilities
for you to build IoT solutions,
01:47:40.620 --> 01:47:44.670
but Azure's also identified
what are the common patterns?
01:47:44.670 --> 01:47:47.500
What kinds of solutions do
people build with these IoT
01:47:47.500 --> 01:47:51.180
devices, and how can I
kind of get a head start?
01:47:51.180 --> 01:47:53.760
How can you automatically
wire together
01:47:53.760 --> 01:47:56.820
this service bus component
with the storage component
01:47:56.820 --> 01:47:58.850
with this real time
analytics component and
01:47:58.850 --> 01:48:00.440
be able to do something
interesting for me?
01:48:00.440 --> 01:48:04.460
And in fact that's exactly
what the IoT suite does.
01:48:04.460 --> 01:48:06.922
I can automatically have a
solution for remote monitoring.
01:48:06.922 --> 01:48:12.828
Say a vending machine, I want to
know when this syrup gets low or
01:48:12.828 --> 01:48:18.189
I wanna know when it's time
to go empty the coin tumbler.
01:48:18.189 --> 01:48:21.060
Being able to do
asset management.
01:48:21.060 --> 01:48:23.240
I wanna track where
all my stuff is and
01:48:23.240 --> 01:48:25.850
help me get the right amount
of data to track my stuff, or
01:48:25.850 --> 01:48:27.619
scenarios like
predictive maintenance.
01:48:28.700 --> 01:48:31.100
Predictive maintenance is
becoming a very interesting
01:48:31.100 --> 01:48:31.880
space on IoT.
01:48:31.880 --> 01:48:36.320
It's this idea of what signals
can I take in from a device
01:48:36.320 --> 01:48:39.300
that will help me predict that
a fault condition will occur in
01:48:39.300 --> 01:48:44.030
the future, and then how can I
preemptively perform maintenance
01:48:44.030 --> 01:48:47.100
on that device so that the fault
condition never occurs?
01:48:47.100 --> 01:48:52.080
And it can prevent unscheduled
maintenance events,
01:48:52.080 --> 01:48:53.680
emergency overtime for
01:48:53.680 --> 01:48:58.200
an employee that has to go fix
something without a schedule.
01:48:58.200 --> 01:49:01.560
Allow me to just run my
business in a more reliable,
01:49:01.560 --> 01:49:02.510
predictable cadence.
01:49:04.072 --> 01:49:08.920
So, if you take those
core capabilities what we
01:49:08.920 --> 01:49:12.640
see is people will typically go
from building a proof of concept
01:49:14.680 --> 01:49:18.560
to planning for
what they're gonna do to
01:49:18.560 --> 01:49:22.100
piloting out in some small
scale real world scenario.
01:49:22.100 --> 01:49:26.840
What we aim to enable is using
the the Azure IoT Suite to
01:49:28.360 --> 01:49:32.140
enable customers to go through
this process without having to
01:49:32.140 --> 01:49:37.780
make life changing modifications
to their solution.
01:49:37.780 --> 01:49:41.940
To be able to kinda start that
proof of concept smaller scale
01:49:41.940 --> 01:49:45.810
and scale up without having to
dramatically change codes, so
01:49:45.810 --> 01:49:49.430
both on the operating system
side as well on the cloud side
01:49:49.430 --> 01:49:52.810
I can literally start
with a solution and
01:49:52.810 --> 01:49:54.300
scale it up in terms of devices,
01:49:54.300 --> 01:49:57.930
scale it up in terms of cloud
capabilities, but in no way have
01:49:57.930 --> 01:50:00.959
a disruptive event as I
go through that process.
01:50:02.870 --> 01:50:05.800
And finally for Azure, I wanna
be able to build a solution.
01:50:05.800 --> 01:50:09.810
And of course I want to enable
Windows devices definitely, but
01:50:09.810 --> 01:50:13.545
I also want to include all
the non Windows devices in my
01:50:13.545 --> 01:50:14.070
ecosystem.
01:50:14.070 --> 01:50:15.560
I might have some Linux devices.
01:50:15.560 --> 01:50:19.100
I might have some Android
devices, iOS, embedded RTOS,
01:50:19.100 --> 01:50:20.100
whatever.
01:50:20.100 --> 01:50:23.515
I want all of them to be
included in my solution.
01:50:23.515 --> 01:50:27.211
And so, what you'll find as
a part of the Azure IoT Suite is
01:50:27.211 --> 01:50:30.908
a set of client side libraries
that are very cross platform
01:50:30.908 --> 01:50:34.304
that will enable me to work
across all of my devices not
01:50:34.304 --> 01:50:37.775
just my Windows devices,
which of course we like, but
01:50:37.775 --> 01:50:41.116
recognize that folks have
lots of different needs.
01:50:46.351 --> 01:50:49.756
One final word on Silicon
Support for, we've talked
01:50:49.756 --> 01:50:53.680
about some of the dev boards
that we're supporting.
01:50:53.680 --> 01:50:57.380
For Windows 10 you'll see
a support Silicon from
01:50:57.380 --> 01:51:02.280
partners like Intel, from AMD,
from Qualcomm, from Broadcom.
01:51:02.280 --> 01:51:06.382
So being able to use SOCs or
CPUs from a lot of different
01:51:06.382 --> 01:51:10.222
vendors across these
different editions of IoT.
01:51:10.222 --> 01:51:13.071
Depending on what features,
functionality,
01:51:13.071 --> 01:51:16.344
price your aiming for in your
device we think we've got
01:51:16.344 --> 01:51:19.358
platforms support what's
going to work for you.
01:51:19.358 --> 01:51:22.675
I have a call the action for
you.
01:51:22.675 --> 01:51:26.803
One is we have a hands on lab
where we'll make some of these
01:51:26.803 --> 01:51:30.415
memo boards available that
you can kinda come in,
01:51:30.415 --> 01:51:33.263
try it out,
let us know what you think.
01:51:33.263 --> 01:51:34.782
We're interested
in your feedback.
01:51:38.432 --> 01:51:41.671
And I'd like to ask everybody
please complete your evaluation.
01:51:41.671 --> 01:51:43.436
I'd love to here your feedback.
01:51:43.436 --> 01:51:45.530
I'd love to hear what
you have to say.
01:51:47.640 --> 01:51:51.810
And I'll let everybody
take a look at the [LAUGH]
01:51:51.810 --> 01:51:55.910
2D bar code there to be able
to provide feedback, and
01:51:55.910 --> 01:52:00.090
with that I really enjoyed my
time with you this afternoon.
01:52:00.090 --> 01:52:01.050
Hope you learned something.
01:52:01.050 --> 01:52:02.480
Hope you had some fun.
01:52:02.480 --> 01:52:05.010
I'll be around if anybody
has questions that you wanna
01:52:05.010 --> 01:52:08.730
ask I'm happy to stick
around and chat with you.
01:52:08.730 --> 01:52:11.730
Other than that,
thank you very much.
01:52:11.730 --> 01:52:12.483
Enjoy the rest of the show.
01:52:12.483 --> 01:52:17.436
[APPLAUSE]