posts - 644, comments - 2003, trackbacks - 137

My Links

News

Raffaele Rialdi website

Su questo sito si trovano i miei articoli, esempi, snippet, tools, etc.

Archives

Post Categories

Image Galleries

Blogs

Links

Deep diving su WinRT e le applicazioni Metro di Windows 8

Tempo di recuperare le prime informazioni su WinRT, ecco quanto ho saputo parlando direttamente con diverse persone di diversi team.

Esistono due stack in Windows 8 per costruire applicazioni:

  1. Modalità classica (Win32 / .NET)
  2. Modalità Metro-Style

La modalità classica è quella che tutti conosciamo, non cambierà e sarà mantenuta per il futuro. Le applicazioni WPF, Winform e Html continueranno a funzionare. Queste applicazioni funzionano nell'ambiente del desktop classico e vengono aperte in Explorer come lo conosciamo adesso.

Le applicazioni NON possono usare entrambe le modalità. Se usano WinRT non possono usare Win32. Se usano Win32 non possono usare WinRT e perciò non sono Metro (e quindi girano nel vecchio desktop).

Nel contesto di applicazioni server tutto ciò che oggi abbiamo con il .NET Framework non ha senso che venga cambiato. Il Framework c'è e rimarrà con tutto ciò che già conosciamo.

Nel contesto di applicazioni client, può rimanere tutto come era prima (che verrà supportato) ma non potrà avere lo stile Metro.l Per essere "Metro" una applicazione deve seguire un nuovo corso e nuove modalità (vedi sotto).

…prendere un bel respiro…

La modalità Metro-Style è completamente nuova ed ha una serie di interessantissime caratteristiche:

  • Metro non è solo uno stile grafico ma un insieme di specifiche per interagire con il sistema operativo. Il Metro di Windows 8 è radicalmente differente (come meccanismo) da quello di Windows Phone.
  • Ogni applicazione è isolata, può utilizzare solo ciò che viene permesso dall'utente. Lo sviluppatore richiede i permessi tramite un manifest che viene controllato da WinRT tramite un broker che funziona da supervisore sulle attività dell'applicazione. L'ambiente in cui gira l'applicazione non è una virtual machine, non è il .net framework
  • Il deploy delle applicazioni viene fatto tramite un package che contiene tutto ciò che serve allo Store per installare l'applicaizone sulla macchina. Le discussioni sullo Store privato (aziendale) sono tutt'ora sotto discussione.
  • Tra i meccanismi più interessanti ci sono i Contracts che permettono all'applicazione di dichiarare come vuole interagire con le altre app e il sistema operativo (leggere un feed, una pagina facebook, cercare, etc.)

WinRT:

  • È il Windows Runtime che espone le funzionalità del sistema operativo in modo Object Oriented.
  • Non è codice managed e non necessita del .NET Framework
  • Ha delle "Projection" che permettono ai vari linguaggi di interagire con il sistema operativo (C++, C#, VB.Net, Javascript)
  • I linguaggi managed sopra WinRT hanno sempre bisogno del CLR e il Framework fornito con Win8 è la versione 4.5
  • WinRT è costruito con tecnologia COM e conserva tutti i relativi meccanismi (IUnknown, AddRef/Release, Apartment per i modelli di threading, la message pump per gestire le STA).
  • WinRT semplifica molti concetti COM. Per esempio elimina i Connection Points per gli eventi e la IDispatch per permettere ai linguaggi dinamici di interagire con esso.
  • Il type system di WinRT è ristretto ma più ampio di quello COM. Per esempio non esiste più il BSTR ma la stringa ha un layout di memoria analogo a quella usata dal CLR. Questo permette di evitare le copie durante il marshalling e quindi di esporre la stessa zona di memoria sia al codice nativo che managed senza penalizzazioni di performance.
  • Tra le novità nel type system ci sono le collection (anche di tipo observable) che sono costruite/mappate automaticamente dalle projection.
  • Le projection di C++ mappano direttamente su strutture compatibili alle STL (Standard Template Library).
  • Le projection di WinRT sono customizzate linguaggio per linguaggio e permettono di fornire la migliore resa in performance.
  • È possibile scrivere estensioni di WinRT per esporre codice nativo custom alle applicazioni ma queste estensioni sono private di una applicazione e non possono essere condivise (niente regsvr32)
  • I Contratti di Metro sono esposti come interfacce COM e la maggior parte di developer non avrà mai bisogno di scendere a livello di interfaccia COM per fruirne
  • A livello più basso esiste WinRL, una libreria C++ usata dal team di Windows per costruire tutto ciò che WinRT espone. Si ritiene che nessuno ne abbia bisogno (tranne il sottoscritto ovviamenteSmile)
  • Il versioning di WinRT è basato sui concetti COM e prevede le estensioni che verranno nelle future versioni del sistema operativo

Il Framework.NET:

  • È utile a chi preferisce avere i servizi del CLR (Garbage Collection, etc.) e di conseguenza verrà usato C# e VB.NET
  • Non è indispensabile e perciò Javascript e C++ non ne hanno bisogno.
  • Molte librerie della BCL (Winform, e tutto ciò che fa I/O su video, disco e quant'altro) non sono utilizzabili dalle applicazioni Metro perché queste devono utilizzare solo WinRT. Tra questo tutto ciò che concerne XAML perché il suo engine (Metro-style) è stato riscritto in codice nativo.
  • Esiste un nuovo interprete XAML scritto in codice totalmente nativo che mappa i controlli XAML su quelli nativi WinRT
  • Allo stesso modo (stile phonegap per chi lo conosce) i tag html5 vengono mappati sui controlli nativi WinRT
  • XAML e Html5 sono paritetici, interscambiabili e siedono sopra l'engine grafico (basato su DirectX) che renderizza le applicazioni Metro

I Tools. Oltre a quanto già visto e detto nelle keynote:

  • Visual Studio 11 include tutto ciò che serve per creare il package e pubblicarlo sul Windows Store che non è ancora disponibile.
  • Lo store privato è in fase di definizione.
  • WinDBG rimane ma tutte le sue funzionalità sono state integrate dentro Visual Studio
  • Visual Studio 11 include i wizard per creare driver in kernel mode, user mode, i test (static analisys) e il remote debugging (compresi i reboot e l'installazione dei certificati sulla macchina remota)

Stay tuned. Questo è solo l'inizio.

Il mio commento? WOW, è fantastico e finalmente c'è la vera platform che aspettavo da Microsoft.

So che probabilmente ci saranno tante domande e commenti ma please abbiate pazienza perché qui a build il ritmo è frenetico.

Print | posted on giovedì 15 settembre 2011 12:10 |

Feedback

Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

Rileggila e dimmi se non ti sembra un paciugone di tecnologie: un po' Win32 un po' no, un po' managed un po' no, nativo ma con le projections, tipo COM ma più semplice però non compatiile, puoi programmare Win32 .Net Metro ma non si parlano ... fino a he non faranno una interoperability carpiata ...
Sono basito ma sarà solo la mia ormai scarsa competenza tecnica .. oppure MS è ripiombata nella confusione da mancanza di vision
PierG
15/09/2011 13:04 | PierG
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

>RIP Windows Phone 7.
mah direi di si nel senso che Windows Phone 8 immagino sarà Win8 senza le parti "accessorie" come la retrocompatibilità con Win7... che poi pensandoci è l'unica strada possibile.
anche apple "rompendo" la retrocompatibilità penso stia andando sulla stessa strada.
15/09/2011 13:14 | Diego Guidi
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

Rigorosamente NDA: Sotto WinRL c'è... WinRaf! (ma non ditelo a Synofsky...) :-)
15/09/2011 15:39 | Corrado Cavalli
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

Concordo pienamente con PierG...
15/09/2011 17:02 | Fabio
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

COM è morto, lunga vita a COM! ;-)
15/09/2011 19:03 | alexp
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

@CppRocks. Alcune Win32 sono chiamabili in quanto inerti. Per inerti si intende quelle funzioni che:
- non possono creare problemi di sicurezza
- impiegano meno di 50ms per essere eseguite
In pratica esiste una white-list che viene controllata dal broker (COM based per la cronaca) che controlla le funzioni prima che queste vengano eseguite.

Lo scopo delle applicazioni metro-style è di essere buone cittadine dell'ecosistema PC e totalmente autosufficienti. Questo significa che ogni tentativo di legare una applicazione metro ad altre cose installate nel desktop tradizionale non passeranno la certificazione dello store.

Avrei molto di più da dire ma mi manca il tempo ... :)
16/09/2011 12:50 | Raffaele Rialdi
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

Insomma, ora abbiamo COM#++. E scommetto che ci sarà un VBRT (o VBMetro) unamanaged pronto per fare sfracelli e schermate blu a gogò....
Io dico che entro 60 giorni ci sarà il primo virus per WinRT....
17/09/2011 02:25 | Gabriele Del Giovine
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

Gabriele, se vuoi farci sopra fantatecnica ci sei riuscito.
COM è la base da cui sono partiti perché fare diversamente non avrebbe avuto senso. L'infrastruttura base di COM è solida ed è già la base del framework.net.
Sono però state fatte grosse modifiche a COM che spiegherò nei prossimi post come anche il resto sui linguaggi.

Quanto a virus e schermate blu, stai facendo un gran miscelone che non ha nulla a che fare con WinRT.
18/09/2011 00:32 | Raffaele Rialdi
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

A quanto ci hanno spiegato è tutto molto più semplice.
Le chiamate Win32 ammesse sono in white list perché _certamente_ non possono prendere più tempo del massimo permesso.
Tutte le chiamate WinRT che _possono_ impiegare più di 50ms sono automaticamente async di default e non esiste la versione sincrona.

Non esiste, per quanto mi hanno detto fin'ora, nessun meccanismo di controllo a runtime per quanto riguarda la durata (anche perché la vedrei troppo complicata).
Il compito del broker è quello di filtrare per 'categoria' le chiamate a WinRT. In pratica tu esegui una chiamata. Se questa fa parte di quelle WinRT che richiedono delle permission (per esempio l'accesso alla webcam), allora passano dal broker che confronta con il manifest se è compatibile. Se lo è, viene richiesto il permesso all'utente con una UI specifica e quindi viene dato il permesso di proseguire.
19/09/2011 17:19 | Raffaele Rialdi
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

WinRL viene utilizzato in user mode e, a quanto mi è stato detto, è la libreria utilizzata dal team di windows per creare lo strato di librerie WinRT.
Per costruire app metro WinRL non dovrebbe servirti a nulla.
Potrebbe venire utile per creare componenti da affiancare a WinRT che espongano funzionalità simili per componenti custom. In questo caso il componente rimarrebbe comunque privato e utilizzabile dalla sola applicazione che lo include nel package.
20/09/2011 21:51 | Raffaele Rialdi
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

Con ritardo ti ringrazio della delucidazione, :)
27/09/2011 15:01 | Gian Maria
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

Per quanto riguarda il discorso bytecode, è verissimo che la compilazione jit può portare a risultati migliori e che la nativa ha bisogno di essere ricompilata in "n" versioni per ciascun microprocessore.
Infatti il framework.net calza a pennello in WinRT e tutto va a meraviglia al contrario di prima che ci voleva interoperabilità e pinvoke a vagonate.

Il problema di oggi è invece il requisito utente. 5 anni fa avevamo solo PC, quindi molta più memoria da vendere e la batteria non era un problema.
Oggi risparmiare jit può essere un vantaggio sia in termini di memoria che di durata della batteria.
L'architettura del software cambia in funzione dei requisiti, certo, ma anche dell'hardware che hai sotto.
27/11/2011 13:46 | Raffaele Rialdi
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

Buongiorno a tutti,
sono un programmatore dilettante, e sono molto interessato alle app di Windows 8.
Vorrei capire se è possibile per una app utilizzare un driver di un'interfaccia USB (dongle) che a sua volta si interfaccia con una rete CAN BUS o similare.
In sostanza sto cercando di utilizzare l'interfaccia Metro per comunicare con una rete locale di automazione.

Mi scuso per la banalità della domanda e ringrazio in anticipo per la risposta.
06/08/2012 01:03 | Paolo Martinello
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

Il mio consiglio è di comunicare via ethernet (socket o magari via servizi rest).
Diversamente è necessario creare un sensore (scrivendo un driver user-mode) per mappare le comunicazioni della periferica su un "sensor" di windows. Al momento non mi vengono in mente altre idee.
08/08/2012 11:32 | Raffaele Rialdi
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

Nessuna limitazione. Puoi installarti Win8 + Visual Studio (con il suo sdk), esplorare la documentazione e gli esempi sulla sensoristica o sul networking a seconda della strada che vuoi utilizzare.
Tieni conto che la versione finale di Win8 e Visual Studio è disponibile su MSDN (per gli abbonati) a partire dal 15 Agosto 2012.
Ciao
08/08/2012 11:34 | Raffaele Rialdi
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

In modalità Two Step l'utente può scegliere solo di copiare i dati nel file PST o di unire i dati dai file PST in un server.192.168.0.1
15/03/2015 14:55 | onderful
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

Need to find the framework on this project.
10/12/2016 06:38 | gelayihi
Comments have been closed on this topic.

Powered by:
Powered By Subtext Powered By ASP.NET