1. The Windows Runtime Martyn Lovell
4/16/ :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.

2. 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.

3. 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.

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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)

10. 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

11. 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

12. 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>

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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)

19. Projecting into Languages

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

21. 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

22. 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

23. 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)

24. 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

25. 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

26. 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

27. 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

28. 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";
}); }

29. 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);

30. 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);
});

31. 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

32. Q&A http://msdn.microsoft.com/windows
Windows 8:
Platform:
Windows Runtime:
Internals:

33. Backup

34. 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

35. 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

36. 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