The Windows Runtime Martyn Lovell 4/16/2019 12:19 PM The Windows Runtime Martyn Lovell Development Manager Windows Runtime Experience Microsoft Corporation © 2010 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Agenda What is the Windows Runtime? The Windows Runtime Contract Projecting into Languages Call to Action During this talk, I’m going to help you understand how the new Windows Runtime platform in Windows 8 works. I’ll give you insight into how the Windows Runtime works. This should enable you to understand, debug, performance tune and confidently publish Windows Metro style applications. Most of the time our tools do a great job of guiding you in the right direction. But when things go wrong, this information will help you see how the pieces fit together.

What is the Windows Runtime? In this section I’m going to briefly recap the Windows Runtime for those of you who didn’t manage to see any of the //build content.

The Windows 8 Developer Experience The Windows Runtime is the solid, efficient foundation for building great Metro style apps Easy to build a Metro style app Dramatic improvements in developer experience Freedom of choice – language, library, markup Enabing a new generation of fast, fluid, responsive apps Immersive, Fluid, Metro style user experience Designed for touch Trustworthy Apps cooperate and compose Always connected and always fresh Use hardware to full potential

Design Principles Major improvement to developer experience Great intellisense & tooling Native, Managed, Dynamic all first-class citizens JavaScript, C#/VB and C++ initial targets Platform based Versioning Apps keep running on future Windows versions Simple low-level constructs; usability in projection Responsive and Fluid Apps Async APIs where they are needed Well-designed, consistent objects API surface is clear and consistent Backup App components isolated from each other Single well-designed API to achieve each goal Windows components don’t side-by-side App-Centric Platform Well managed app-to-app contracts Async tasks compose easily UI code still single-threaded and simple – but modal dialogs are async. Apps run unchanged on the next version of Windows

Metro style application APIs User Interface HTML5/CSS XAML DirectX Controls Input Accessibility Printing Data Binding Tiles SVG Devices Sensors Geolocation Portable NFC Communications & Data Contracts XML Web SMS Networking Notifications Local & Cloud Storage Streams Background Transfer Media Visual Effects Playback PlayTo Capture This is the Windows Runtime as a whole It has lots of APIs, and can build lots of Apps. But most of this is not of interest to us here at lang.next. So here’s another picture that focusses more on the Windows Runtime Foundations. Fundamentals Application Services Authentication Cryptography Globalization Memory Management Threading/Timers

Windows Runtime Architecture Windows 8 “Metro style” app Language Support (CLR, WinJS, CRT) Language Projection (Generated from Metadata) Windows Metadata & Namespace UI Pickers Controls Media Web Host (HTML, CSS, JavaScript)) XAML Storage Network … The whole of Windows provides the runtime foundation for your App No extra runtimes needed Simpler shipping and servicing Metadata describes the whole OS Languages project on top of that A projection is an automatically generated layer that makes it natural and familiar Windows Runtime is mostly protocol, with a little implementation Each language and the operating system have their own implementations the WinRT contracts An STL collection could expose a WinRT contract, as can a JavaScript array. Each language can have its own unique runtime code JavaScript and C# each have their own Garbage Collectors. C++ doesn’t need one. Each of JS, C++ and C# have their own way of storing objects in memory Windows Runtime Core Runtime Broker Windows Core

The Windows Runtime Contract Windows has lots of implementations of Windows Runtime objects. But at its heart the Windows Runtime is a set of contracts between objects that can be implemented in many ways. In this section I talk about the basics of the Windows Runtime Contracts

What is a Windows Runtime Object? Shell32.dll IInspectable IUnknown Object IStorageItemInformation IStorageItem FileInformation Runtime Class IStorageFile Interfaces A Windows Runtime object is a very simple, self-contained thing. Interfaces Vtables Metadata Runtime classes Activation Store Windows Metadata (Disk)

Windows Runtime Basic Types INT32, UINT64 * Pointers allowed in limited cases Strings HSTRING Avoids copying in multiple languages Enumerations enum AsyncStatus Flag or non-flag styles Structures struct Rect; Can contain strings, but not interfaces Simple Arrays INT32 [] For very basic collections Interfaces IInspectable All methods are defined as interfaces Generic Interfaces IVector<T> Type-generic interface. Not extensible Runtime Class Windows.Storage.StorageFile Binds interfaces to make a class IReference

Windows Runtime Patterns Collections IVector<T>, IVectorView<T>, IMap<T>, IObservableVector<T> Delegates delegate AsyncActionCompletedHandler Encapsulate the context to call back to an object Events IApplicationLayout::LayoutChanged Lists of callback recipients PropertySet interface IPropertySet Collection of items with varying types Async Operation ReceivePropertiesOperation A way to get a delayed result without blocking

Associative Collection Collections IInspectable IUnknown Array IVector<T> IVectorView<T> IObservableVector<T> IInspectable Need a standard way to share collections between languages Standard interfaces, not implementations Allows language to bind over existing collections Generic interfaces are type safe JavaScript projection applies simpler types where needed Variations Read only, Read & Write, Read & Write & Observe Vector, Map Removes need for copying IIDs automatically generated and unique IUnknown Associative Collection IMap<T> IMapView<T> IObservableMap<T>

Windows Metadata Concise, complete description of the Windows Runtime Full description of Windows ships in SDK and on system Use to describe your objects Generated natively from C++ or C#/VB Compiler Efficient binary format derived CLI Metadata Profile of ECMA 335, Partition II Same structures, different meanings Readable by existing tools Rich enough to allow multi-language projection generation Full intellisense on statically known information Ensures new APIs are immediately consumable when OS is released Also can be generated using IDL for traditionalists Allows other languages to target WinRT SDK contains metadata. Headers Semantics include iteration, async and other things that will be wrapped diversely also included for convenience of WRL users. No need to read headers at compile time or libs at link time

Versioning IInspectable IInspectable IUnknown IUnknown Future Windows Object Object Windows Runtime components version as a platform Future Windows will ship binary compatible versions of these components Windows 8 apps will run directly on Future Windows Future Windows will support the v.8 and v.9 behaviours Windows 9 can add new functions (via new interfaces). Windows 9 SDK metadata will describe both All metadata has version info They will have the same names If a major redesign is needed, a new class name will be chosen. There is no side-by-side story Windows Metadata v8 Projection App Windows Metadata v9 App Projection

Asynchronous Objects Basic requirement for Metro style apps Always responsive, ready “Long running” APIs must be delivered as async Simpler to allow apps to make synchronous calls But then bad apps can overwhelm quality of system Instead, build async into API shape And have language projections integrate it deeply Async protocol is low-level Language projection provides simplified high level view Where long running means read from file, put up dialog, etc

Threading Main UI Thread Threadpool App Code App Code App Code App Windows UI Object Windows Object Windows Object A Windows Runtime object is a very simple, self-contained thing. It App Code App Code App Code

Windows Runtime Threading Three main types of object Thread bound – works only on the thread where it was created – most UI Thread flexible – direct call and works on any thread, uses locking if needed to control simultaneous access – most others Brokered – out of process for resource protection UI runs in single threaded environment that is not reentrant (“Application STA”) Callbacks can only enter if they are related to an outgoing call Most non-UI runs in any thread Need to explicitly state if you want to allow reentrancy Web Workers JavaScript is single threaded unless you explictly use web workers

The Windows Namespace Windows.* Runtime objects are in a simple, unified, hierarchical namespace Great intellisense and browsing in Visual Studio One Clear type for each function Catalog is extensible but private Your apps can add objects Only visible in your app Objects can be seen from any language Makes it easy to find our recommended API Allows ‘using’ for relevant pieces Similar to DllGetClassObject Apps can only see their own objects and Windows’ (per user, per app, manifested)

Projecting into Languages

Projections IInspectable IUnknown Projection C++ App Projection Object Projection CLR C#/VB App Projection JS Chakra HTML App Windows Metadata

Projections Projections make Windows Runtime APIs natural and familiar in every language. Automatically generated at compile/run time Ensures you don’t wait for language/framework to catch up Windows exposes simple concepts – interfaces, functions Metadata shows how they compose Patterns allow projections to adapt Examples: classes, events, delegates, async and collections Each language expresses patterns differently Uses styles that are natural and familiar to their developers

Language Integration Will the Windows Runtime be at home in each language? Yes, but never perfectly Many aspects can adapt well object creation collections Naming typography(pascal vs.. camel vs. lower) Return value usage 4/16/2019

Language Integration Some other aspects must match function Parameter ordering Concept naming (e.g. file vs. item) Great interop with language types possible Depends on work from language teams Some overlap/duplication inevitable Some language semantics are more foreign We have side-effects, so functional language integration less natural Overlap with standard libraries inevitable Projection can reduce (e.g. System::String vs HSTRING) Some will remain (e.g. XML)

Designing your projection Map type systems 2 Way mapping for basic types Carefully consider round-trip typing Map patterns and abstractions Ensure your users collections can be passed to Windows Fit delegates/events into your call-back model Integrate threading and async Project async in simple way Consider promise/future approach Critical step to get this right

Designing your projection Harmonize object lifetime Windows Runtime objects deterministic Consider proxy object approach for GC languages Like CLR’s RCW/CCW. Take account of ICloseable semantics. Plan shutdown carefully Consider versioning Windows Runtime versions like the operating system Binary compatible Additive Users need to tell compiler/projection what version of platform they are targeting

Implementing your Projection Handle Errors Windows Runtime is HRESULT error code based Expected to map to exceptions in most languages Read and write Metadata Must Use our APIs to read metadata We will reorganise on-disk naming and structure Only way to correctly find all metadata for a type Ensure your written metadata is conformant Bind to types Use type resolution APIs to load metadata

Implementing Your Projection Adjust Standard Library Can only use Metro style APIs – e.g. No Console! Obscure types with natural analogues Don’t expose a Windows type with a tight mapping to a language type E.g. hide WinRT’s string, int32 Do expose if there are important semantic differences. Ensure efficient behaviour at projection boundary Don’t copy strings (pass by ref – we allow) Don’t copy collections

Windows Runtime in JavaScript function peerFinder_AcceptRequest() { // Accept the connection if the user clicks okay. ProximityHelpers.displayStatus("Connecting to " + requestingPeer.displayName + " ..."); ProximityHelpers.id("peerFinder_AcceptRequest").style.display = "none"; ProxNS.PeerFinder.connectAsync(requestingPeer).then( function (proximitySocket) { ProximityHelpers.displayStatus("Connect to " + requestingPeer.displayName + " succeeded"); startSendReceive(proximitySocket); }, function (err) { ProximityHelpers.displayError("Connect to " + requestingPeer.displayName + " failed with " + err); ProximityHelpers.id("peerFinder_Connect").style.display = "none"; }); }

Windows Runtime in C# async private void PeerFinder_Accept(object sender, RoutedEventArgs e) { rootPage.NotifyUser("", NotifyType.ErrorMessage); rootPage.NotifyUser("Connecting to " + _requestingPeer.DisplayName + "....", NotifyType.StatusMessage); PeerFinder_AcceptButton.Visibility = Visibility.Collapsed; try _socket = await PeerFinder.ConnectAsync(_requestingPeer); rootPage.NotifyUser("Connection succeeded", NotifyType.StatusMessage); PeerFinder_StartSendReceive(); } catch (Exception err) rootPage.NotifyUser("Connection to " + _requestingPeer.DisplayName + " failed: " + err.Message, NotifyType.ErrorMessage);

Windows Runtime in C++ void PeerFinderScenario::PeerFinder_Accept(Object^ sender, RoutedEventArgs^ e) { m_rootPage->NotifyUser("", NotifyType::ErrorMessage); m_rootPage->NotifyUser("Connecting to " + m_requestingPeer->DisplayName + "....", NotifyType::StatusMessage); PeerFinder_AcceptButton->Visibility = Visibility::Collapsed;   auto op = PeerFinder::ConnectAsync(m_requestingPeer); Concurrency::task<StreamSocket^> connectTask(op); connectTask.then([this](Concurrency::task<StreamSocket^> resultTask) { try { m_socket = resultTask.get(); m_rootPage->NotifyUser("Connection succeeded", NotifyType::StatusMessage); PeerFinder_StartSendReceive(); } catch(Exception^ e) { m_rootPage->NotifyUser("Connection to " + m_requestingPeer->DisplayName + " failed: " + e->Message, NotifyType::ErrorMessage); });

Call to Action The Windows Runtime is the solid, efficient foundation for the new Windows 8 developer platform Build Metro style apps easily with the Windows Runtime Windows available in your choice of language and environment Bring your language to the Windows runtime Create a language projection Make Windows a natural and familiar part of your world We can engage and help

Q&A http://msdn.microsoft.com/windows Email: martynl@microsoft.com Windows 8: http://channel9.msdn.com/Events/BUILD/BUILD2011/KEY-0001 Platform: http://channel9.msdn.com/Events/BUILD/BUILD2011/BPS-1005 Windows Runtime: http://channel9.msdn.com/Events/BUILD/BUILD2011/PLAT-874T Internals: http://channel9.msdn.com/Events/BUILD/BUILD2011/PLAT-875T

Backup

Windows Core OS Services Metro style Apps Desktop Apps View XAML HTML / CSS HTML JavaScript Model Controller C/C++ C#, VB JavaScript (Chakra) C C++ C# VB WinRT APIs New Set of APIs to access the OS and the Device Implemented in C++ and part of the operating system In memory interfaces with Direct Invocation – this means v-table dispatch. Very efficient, designed with performance in mind. New native type system optimized for projections Built-in reflection – to support dynamic languages We took - integrated and holistic approach we focused on consistency Optimized for writing Metro – not everything is possible When we compile Windows – we generate metadata, that we use for projecting to number of languages Feel natural in the language they just feel and behave right Communication & Data Graphics & Media Devices & Printing System Services Application Model Internet Explorer Win32 .NET SL Core Windows Core OS Services

Object Creation App Projection WinRT Object Manager WinRT Object Start App asks to create object Pass Name to RoActivateInstance Find DLL using Catalog Load DLL Call DllGet-ActivationFactory Object created by implementation code IInspectable returned Projection creates wrapper (using metadata) Object bound to wrapper Wrapper returned to App End App Projection WinRT Object Manager WinRT Object We just saw an object being created. Let’s walk through how that happened, and the layers of the system that are involved Names used at object creation time Map object name to implementation in catalog/metadata Object then loaded from DLL using DllGetActivationFactory

Brokered Objects IInspectable IUnknown Projection App RuntimeBroker.exe App Proxy Projection IInspectable IUnknown Object Some Windows Runtime objects live in the Runtime Broker process Placed there to control access to resources Calls on interfaces are marshalled to the broker Interfaces are most often async Behave like other async objects Using classic IMarshal technology