In parole semplici, Windows Runtime Library (WinRT) è l'interfaccia predefinita di programmazione delle applicazioni (API) utilizzata da Windows 8. Non sostituisce l'API Win32 che è stata eseguita sotto tutte le applicazioni Windows, ma piuttosto la aumenta. È un'API nativa non gestita che può essere sfruttata da molte lingue diverse attraverso un meccanismo chiamato proiezione della lingua (potete leggere di più sulle proiezioni più avanti nella mia risposta).
Caratteristiche di Windows Runtime:
- Tutte le parti dell'API sono progettate per essere asincrone.
- L'API è sandboxed e progettata per la facile creazione di applicazioni self-contained o app store-ready.
- It exposes the WPF/Silverlight XAML UI model to developers.
- The API definitions are in a metadata format, which is the same as the one used for .NET (ECMA 335).
- It wraps both the Win32 API and the new UI system together.
- It has a simple programming model for creating UIs. It is especially tailored for Windows developers who do not need to learn the Win32 API or terms like LPARAM or WndProc.
- The Silverlight/WPF XAML UI model is exposed to developers.
- It implements the look of Windows (formerly known as Metro)
WinRT consists of 109 new namespaces. These namespaces share the Windows. prefix. They seem to be logically grouped under the following 14 categories:
- ApplicationModel
- Data
- Devices
- Foundation
- Globalization
- Graphics
- Management
- Media
- Networking
- Security
- Storage
- System
- UI
- Web
More about WinRT:
Proiezioni WinRT
Quello che noi chiamiamo "binding" Microsoft ora lo chiama "proiezioni". Le proiezioni sono il processo di esposizione delle API a tre ambienti: Nativo (C e C++), HTML/Javascript e .NET.
Se si scrive un componente in C++ o in un linguaggio .NET, la sua API sarà memorizzata in un file WinMD e sarà possibile consumarla da tutti e tre gli ambienti (Nativo, JavaScript e .NET). Anche in C++ non siete esposti a COM. L'uso di COM è nascosto dietro gli strumenti di proiezione del C++. Si usa quello che sembra un'API orientata agli oggetti in C++.
Per supportare i vari costrutti di WinRT, la piattaforma sottostante definisce un set di base di tipi e le loro mappature ai vari ambienti. In particolare, gli oggetti di raccolta in WinRT sono mappati a costrutti che sono nativi per ogni ambiente.
Api asincrone
Microsoft ritiene che quando uno sviluppatore può scegliere tra un'API sincrona e una asincrona, gli sviluppatori sceglieranno la semplicità di un'API sincrona. Il risultato di solito funziona bene sul sistema dello sviluppatore, ma è terribile quando viene usato in natura.
Con WinRT, Microsoft ha seguito una semplice regola: se ci si aspetta che un'API impieghi più di 50 millisecondi per essere eseguita, l'API è asincrona.
L'idea, naturalmente, è quella di garantire che ogni applicazione Metro sia progettata per rispondere sempre all'input dell'utente e per non bloccarsi, bloccarsi o fornire una scarsa esperienza utente.
Per semplificare questo processo, C# e VB sono stati estesi per supportare il pattern await/async ispirato a F#, trasformando la programmazione asincrona in una gioia. Il C++ ha un setup che è buono come si può ottenere con i lambda del C++ e Javascript usa le promesse e "then ()".
È .NET o no?
Alcuni sviluppatori sono confusi sul fatto che .NET ci sia o meno, dato che non tutte le API .NET sono presenti (File I/O, Sockets), molte sono state spostate e altre sono state introdotte per integrarsi con WinRT.
Quando si usano C# e VB, si sta usando l'intero framework .NET. Ma hanno scelto di esporre un sottoinsieme più piccolo delle API agli sviluppatori per spingere la nuova visione di Windows 8.
E questa nuova visione include sistemi di sicurezza/sandboxed e programmazione asincrona. Questo è il motivo per cui non si ottiene l'accesso diretto al file system o l'accesso ai socket e perché le API sincrone che eravate abituati a consumare non sono esposte.
Ora, notate che ho detto "esposto" e non "andato".
Quello che hanno fatto è che hanno esposto al compilatore solo un insieme di API quando si punta al profilo Metro. Così la vostra applicazione non chiamerà accidentalmente File.Create per esempio. A runtime però, il CLR caricherà l'intera libreria di classi, proprio quella che contiene File.Create, quindi internamente, il CLR potrebbe chiamare qualcosa come File.Create, è solo che voi non avrete accesso ad esso.
Questa divisione è simile a ciò che è stato fatto in passato con Silverlight, dove non tutte le API erano esposte, e dove a mscorlib venivano dati diritti che la vostra applicazione non aveva per garantire la sicurezza del sistema.
Potreste pensare che potete usare qualche trucco (referenziare la libreria GAC invece del riferimento al compilatore o usare reflection per arrivare alle API private, o P/Invoking in Win32). Ma tutti questi usi saranno catturati dall'applicazione di revisione AppStore e non sarete in grado di pubblicare la vostra app attraverso lo store di Microsoft. Semplicemente non sarà possibile pubblicarlo attraverso l'AppStore.
Infine, il team .NET ha colto questa opportunità per fare un po' di pulizie di primavera. mscorlib.dll e System.dll sono stati divisi in varie librerie e hanno spostato alcuni tipi in giro.
Fonti: WinRT demistificato, Cos'è WinRT?, DevExpress Data Blog, Pagina su Metrocompanionapps.com.