Windows Desktop Windows Phone Windows 10 Xbox IoT HoloLens Surface Hub ONE CORE OS ONE APP PLATFORM ONE STORE.

Download Report

Transcript Windows Desktop Windows Phone Windows 10 Xbox IoT HoloLens Surface Hub ONE CORE OS ONE APP PLATFORM ONE STORE.

Windows Desktop
Windows Phone
Windows 10
Xbox
IoT
HoloLens
Surface Hub
ONE CORE OS
ONE APP PLATFORM
ONE STORE
Phone
Phablet
Small Tablet
2-in-1s
(Tablet or Laptop)
Large Tablet
Classic
Laptop
Desktops
& All-in-Ones
Windows 10
Surface Hub
Xbox
Holographic
IoT
Windows
for PCs
Windows
for phones
Windows
on Xbox
Windows
for …
Familiar desktop shell
Familiar mobile shell
10’ shell experience
Broad hardware ecosystem
Rich telephony
Shared gaming experiences
Form factor–appropriate
shell experience
Windows desktop
application compatibility
Windows phone app
compatibility
Xbox One
game and app compatibility
One Core OS
Base OS
App and Device platform
Runtimes and frameworks
Device-specific scenario
support
Adaptive
user interface
Natural
user inputs
Common
toolset
Common
store
and dev center
One App Platform
Common APIs
and SDK
Common
development
hardware
Common
validation
suite
Common
toolset
Common
hardware
dev center
One Device Platform
Common DDIs
and WDK
Develop to a single API/DDI
Same API for Desktop, Tablet, Phone, IoT
Build once for all Windows editions
One binary per instruction set, not per device family
Runs on all Windows devices
Phone, Tablet, Desktop, Server, IoT
Universal
Driver
Apps built on the Windows universal app platform are
called Windows apps
In contrast with Windows desktop applications that run on PCs only
Windows app
Windows desktop application
Runs on all Windows device families
Runs on PCs only
Can access WinRT, COM, and subset of Win32 APIs
Can access WinRT, COM, and Win32 APIs
Has strong app identity (static and dynamic)
Raw EXEs and processes
Declarative APPX manifest
Opaque binaries
Self-contained APPX package
Loose files or MSI
Isolated per-user/per-app storage
(local and roaming)
Shared user profile
Participate in app resource management and PLM
Process-level lifecycle
Neither Windows apps nor Windows desktop
applications can…
•
•
•
•
•
•
•
Directly access physical hardware resources
Directly access IP blocks on silicon
Respond to Windows I/O calls (e.g., ReadFile, WriteFile)
Integrate into device tree, device manager, etc
Adapt new hardware to established APIs (e.g., winsock, DirectX)
Respond to full range of power state changes
Directly interact with the internals of the kernel
To do any of these, you need a Windows driver
A Windows driver is an executable (.sys) that exports a DriverEntry function
Sets up dispatch table for OS to invoke I/O, power, PnP, routines
Windows defines technology specific APIs (for ISVs) and DDIs (for IHVs)
Winsock/NDIS, DirectX/WDDM, etc
Windows ships with in-box class drivers where hardware standardization no longer
warrants 3rd party drivers
Some DDIs defined as miniport drivers that replace generic driver-isms with domainspecific entry points
Windows Driver Framework (WDF) simplifies both user-mode (UMDF) and kernel-mode
(KMDF) drivers
Kernel-mode Driver
Kernel-mode Driver
User-mode Driver
Kernel-mode Driver
Kernel-mode Driver
SCM-based Service
Kernel-mode Driver
Kernel-mode Driver
Windows app
Kernel-mode Driver
Kernel-mode
Driver
Windows desktop
application (PC only)
User mode
Kernel mode
ntoskrnl.exe (Kernel)
I/O Manager
Object
Management
Kernel-mode Driver
Kernel-mode Driver
Kernel-mode Driver
Memory
Management
Interprocess
Communication
Dispatcher (kernel)
Process
Management
An Application Programming Interface (API) is a set
of specific entry points for use by applications
An Device Driver Interface (DDI) is a set of specific
entry points for use by drivers
An Application Binary Interface (ABI) is a set of rules
for invoking code across independently deployed
modules (drivers or applications)
Both APIs and DDIs conform to an ABI
Windows app
Windows API
Windows
Windows DDI
Windows driver
The Windows universal device platform defines a single DDI that spans all
Windows 10 device families
Kernel-mode drivers are implicitly scoped to a single DDI specification
User-mode drivers have access to both the DDI and API surface of
Windows
•
User-mode DDI is common across device families
•
User-mode API is distinctly partitioned for user-mode drivers, Windows apps, and Windows desktop
applications
The Windows API has three distinct patterns that define the ABI
rules for functions, interfaces, and classes
API Type
Win32
COM
WinRT
Abstraction
Functions
Interfaces
Classes
Definition
C header file (text)
IDL file (text)
WINMD file (binary)
Callable from C/C++
Yes
Yes
Yes
Callable from CLR (C#, VB, etc) Yes (manual)
Yes (manual)
Yes (automatic)
Callable from Javascript
No
Yes
No
WinRT APIs
Win32/COM APIs
Windows apps
Windows universal system code
Windows
desktop
applications,
system code
windowsapp.lib
onecoreuap.lib
onecoreuap.lib
kernel32.lib, advapi32.lib, etc.
WinRT Methods
WinRT Methods
WinRT Methods
Visual Studio provides an IDE, build tools, and the Windows SDK
•
Visual Studio Community Edition available for free at http://visualstudio.com
•
All you need to write Windows apps and Windows desktop applications
Driver development requires the Windows Driver Kit (WDK) which
adds tools, headers, and libs to the SDK
•
Available for free at https://msdn.microsoft.com/en-us/windows/hardware/
Driver projects can target Desktop, Phone, or Universal
•
The former two ease transition from existing codebases that have dependencies on desktop
and/or phone-specific APIs
•
The latter produces drivers that can be deployed on all Windows 10 devices
Windows Driver Framework
WDF implements the best practices for driver development
• WDF contains non-trivial code due to asynchrony and complex state machines
In Windows 8.1, WDF was only available as an opaque binary
• Cannot easily debug interactions between your code, WDF, and Windows
• Cannot easily understand how WDF is implemented
With Windows 10, we are now making WDF source code
available on GitHub
Windows Driver Framework and GitHub
WDF code available on GitHub
https://www.github.com/Microsoft/windows-driver-frameworks
Private symbols available through Microsoft symbol server
• Debugger automatically finds the right symbol
Source code available to debugger through source server
• Debugger automatically finds the right source file
• No Need to copy source code manually to local machine
Windows hardware dev boards
Windows now supports both x86 and ARM-based development
boards for both commercial and enthusiast developers
Easy physical access to I/O to support device prototyping and
pre-production development
Supports multiple device family OS editions based on instruction
set compatibility
Retail availability from multiple electronics suppliers
Sharks Cove & MinnowBoard MAX
Both boards support Windows 10
Sharks Cove
• Intel ® Atom™ Processor Z3735G, 2M Cache, 4 Core,
1.33GHz up to 1.88GHz
• Supports Connected Standby
• 32-bit UEFI firmware
• Headers for Camera, MIPI Display, USB, I2C, SDIO,
UART, GPIO, UART-to-USB for debug
MinnowBoard MAX
•
•
•
•
•
Intel® Atom™ E3800 processor
64-bit & 32-bit UEFI firmware
Can also be used as an UEFI Development Kit
PWM capable GPIO (2 pins of 8 total GPIO)
Open Hardware Platform (Gerbers & Layout)
Raspberry Pi 2
Bringing the power of Windows to the
Maker community
Hardware specs:
• Broadcom 2836 900MHz quad-core ARM
Cortex-A7 CPU
• 1GB LPDDR2 SDRAM
• MicroSD, Ethernet, USB, HDMI
• GPIO, I2C, I2S, SPI
Attend the session on Building Devices
with Windows IoT to learn more
Qualcomm DragonBoard™ 410C
Build innovative solutions using Windows
& Qualcomm Snapdragon
Hardware specs:
• Qualcomm Snapdragon 410 (APQ8016)
• 1GB LPDDR3, 4GB eMMC
• MicroSD, WiFi 802.11a/b/g/n, BT4.1 + LE, GPS
• GPIO, I2C, I2S, SPI
Attend the session on Create Intelligent
Devices with Snapdragon and Windows
to learn more
Sensor app
Windows API
Windows API
Windows API
Windows for PCs
Windows for IoT
Windows for Phones
Windows DDI
Windows DDI
Windows DDI
Sharks Cove
MinnowBoard Max
Dragonboard
Sensor driver
Device Imaging: Full Flash Update
All Windows 10 device families support imaging and
manufacturing based on Full Flash Update (FFU)
• Existing workflow/tools still supported (e.g., production media, WIM) for PC
FFU image format is sector-based and describes all partitions on
disk
FFU images created using Windows Imaging and Configuration
Designer (WICD) or command-line tools (imageapp.exe)
FFU images flashed to up to 8 USB-tethered devices using
ffutool.exe or directly to disk using WICD or dism.exe
OEMInput.xml
OS-Package.cab
OS-Package.cab
OS Packages
FeatureManifest.xml
OS-Package.cab
OS-Package.cab
BSP Packages
FeatureManifest.xml
FeatureManifest.xml
Kernel-mode Driver
Kernel-mode Driver
Driver Packages
FeatureManifest.xml
CustomApp.appx
CustomApp.appx
CustomApp.appx
Device-Image.ffu
FeatureManifest.xml
FeatureManifest.xml
OEMCustomization.xml
WICD
or
IMAGEAPP
Device-Image.ffu
Flash to up-to 8 tethered Windows devices
Device-Image.ffu
…
FFUTOOL
or
EFI Partition
WICD
or
DISM
Write directly to disk
Windows 10 allows a single driver to span multiple device families (PCs,
Phones, Tablets, IoT)
Driver development is made simpler with Windows Driver Framework,
now available on GitHub
Windows 10 supports a range of x86 and ARM development boards
Windows 10 provides a single FFU-based toolchain to support imaging
and manufacturing Windows devices
(c) 2015 Microsoft Corporation. All rights reserved. This document is provided "as-is." Information and views
expressed in this document, including URL and other Internet Web site references, may change without notice. You
bear the risk of using it. This document does not provide you with any legal rights to any intellectual property in any
Microsoft product. You may copy and use this document for your internal, reference purposes.
Some information relates to pre-released product which may be substantially modified before it’s commercially
released. Microsoft makes no warranties, express or implied, with respect to the information provided here.