Windows Desktop Windows Phone Windows 10 Xbox IoT HoloLens Surface Hub ONE CORE OS ONE APP PLATFORM ONE STORE.
Download ReportTranscript 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.