Link alla notizia: http://www.hwupgrade.it/news/sistemi-operativi/windows-10-microsoft-rilascia-l-sdk-per-lo-sviluppo-di-app-universali_56579.html

Il kit di sviluppo per la realizzazioni di app universali per Windows 10 è già disponibile al download

Click sul link per visualizzare la notizia.

"Microsoft vuole un unico sistema operativo per tutte le tipologie di dispositivi disponibili sul mercato".. Sai che novità.. E' dagli anni '80 che Microsoft detiene un monopolio disonesto sulle macchine informatiche.. In questo caso il lupo non ha perso né il pelo, né il vizio.. Bill sei un vecchio marpione..

Ora si... mi piace questa nuova M$
Oh per lo meno... per adesso, a parole... vediamo i fatti!

io speravo gia che per Win 8 la cosa fosse realmente così e l'ho presa nel di dietro con app differenziate come sviluppo tra desktop e mobile!

Ora aspetto effettivamente come saranno le cose con 10 prima di pensarci ancora.

"Microsoft vuole un unico sistema operativo per tutte le tipologie di dispositivi disponibili sul mercato".. Sai che novità.. E' dagli anni '80 che Microsoft detiene un monopolio disonesto sulle macchine informatiche.. In questo caso il lupo non ha perso né il pelo, né il vizio.. Bill sei un vecchio marpione..

:doh:

Non so se ti sei accorto, ma "Bill" non è più a capo di Microsoft da svariati anni...Primo

Cosa centra il monopolio con il fatto cha ha rilasciato un SDK per lo sviluppo di app universali? .. secondo

Non ha più un monopolio visto che i grossi businnes si fanno nel mondo Mobile ... Terzo

Guarda caso sta rilasciando software anche per i sistemi concorrenti, compresa la suite office, proprio in questi giorni ha rilasciato Skype 4.3 per Linux.. quarto

Al primo commento già il primo flame..

Probabilmente è l'unica strategia possibile per recuperare le settore mobile. Anche se non credo che da sola basti.

"Microsoft vuole un unico sistema operativo per tutte le tipologie di dispositivi disponibili sul mercato".. Sai che novità.. E' dagli anni '80 che Microsoft detiene un monopolio disonesto sulle macchine informatiche.. In questo caso il lupo non ha perso né il pelo, né il vizio.. Bill sei un vecchio marpione..

Molti mercati tecnologici sono caratterizzati da monopoli. E' curioso come la percezione di Ms sia ancora quella di una bad company quando Google tutto sommato è anche peggio visto che ha un monopolio sulle ricerche, e quindi sull'informazione, sulla pubblicità online e negli os da mobile...

Microsoft ha realizzato una serie di API semplificate che consentono un facile adattamento di una singola runtime su interfacce estremamente diverse e pensate per dispositivi anche agli antipodi fra di loro.
Questa è la parte più difficile. Non so come faranno ad adattare bene i programmi a schermi così diversi e con sistemi di puntamento così diversi. Sono un po' scettico ma vedremo cosa ne viene fuori. Bravi se ci riescono.
Speriamo solo che non esagerino con la Modern UI dato che è una interfaccia caotica e che personalmente non mi piace.

Questa è la parte più difficile. Non so come faranno ad adattare bene i programmi a schermi così diversi e con sistemi di puntamento così diversi. Sono un po' scettico ma vedremo cosa ne viene fuori. Bravi se ci riescono.
Speriamo solo che non esagerino con la Modern UI dato che è una interfaccia caotica e che personalmente non mi piace.

credo che per Modern UI ora come ora si intenda la struttura sotto la programmazione universale e non l'interfaccia in se; in win10 tale interfaccia è stata di nuovo relegata fuori dall'ambiente desktop (che in tutti i casi via mouse è fastidiosa) e presente solo al lancio di alcune App (impostazioni) charmbar sparite ed al momento io ne sono soddisfatto; anche il fatto di aver ricevuto il messaggio da parte nostra (insiders) che aprire una finestra a parte per le reti WIFI era assurdo, ecco che loro le integrano nella barra delle app come era giusto che fosse.
Quindi mi pare che per la questione App sia più la piattaforma di sviluppo che altro ad interessare M$.

Quindi.. facendo un riassunto.. (se ho capito giusto)

C'è un ambiente di base che consente l'esecuzione di app specifiche su dispostivi ARM o X86 di vari formati (dal tablet al pc alla TV).
Quindi le APP per questo ambiente sono e restano APP.

Per quanto riguarda il pc invece abbiamo il solito windows con il desktop, i programmi ecc, che IN PIU' ha in esecuzione questo ambiente di base di cui sopra su cui far girare le stesse app del tablet/telefono/smart tv..

Cioè facendo un paragone fuori dal mondo MS:
E' come avere un desktop con linux sul quale è in esecuzione anche una vm java che mi consente di installare ed usare le app per android.

GIUSTO? O non ci ho capito una mazza?

Altra domanda: ma le app android girano su una vm java.. queste di MS?

"La nuova piattaforma universale (UAP) si rivela molto interessante sul piano funzionale per l'utente, e al tempo stesso potrebbe permettere a Microsoft di raggiungere il proprio fine, ovvero riuscire a convincere l'utente ad utilizzare il proprio store ufficiale - e comprare dallo stesso - ed utilizzare le nuove app basate su interfaccia Modern."

Comprare?
Oggi come oggi il 90% delle applicazioni mobile si scaricano gratuitamente, anche su ios di app a pagamento ne sono rimaste pochine, forse giusto alcuni giochi vengono ancora acquistati.
Il mercato delle app oramai é inflazionato, c'é tantissima concorrenza e per ogni applicazione di successo ne escono almeno 4 che fanno la stessa cosa, addirittura si sta andando verso una convergenza delle interfacce tra ios e android e per alcune applicazioni si fà fatica a trovare differenze tra le due versioni.
La strategia di microsoft non credo proprio che voglia puntare sulla vendita di app dal proprio store, semmai cercano in tutti i modi di diffondersi su un mercato che non sono ancora riusciti ad attaccare e che li vede miseramente al 3% di market share solo grazie a terminali dozzinali da 99 euro.
L'idea di base é anche interessante, poter scrivere un'applicazione e riciclarla contemporaneamente su 10 dispositivi diversi é una cosa formidabile, il problema é che di dispositivi windows non se ne vendono ora e non se ne venderanno dopo.

si diciamo che il succo e' quello... le app di MS sono codice .NET a tutti gli effetti, solo che non devi creare l'installer, ma il pacchetto da caricare sullo store da dove sono scaricabili e installabili per l'utente finale (unico metodo ufficiale) ... essendo API nuove, ancora sono "complete" come il classico software .NET "desktop" che e' stato usato fino ad ora

Perfetto.
Quindi alla base invece di java c'è framework.net attivo di default sia su tablet che su pc.

L'idea mi sembra buona, alla fine così il pc resta quello classico e l'ambiente net per le app è una cosa extra che può tornare comoda.
Vedremo come si svilupperà il tutto!

Questa è la parte più difficile. Non so come faranno ad adattare bene i programmi a schermi così diversi e con sistemi di puntamento così diversi. Sono un po' scettico ma vedremo cosa ne viene fuori. Bravi se ci riescono.
Speriamo solo che non esagerino con la Modern UI dato che è una interfaccia caotica e che personalmente non mi piace.

per le interfacce: usano un'estensione dei VisualStates di XAML (già presenti su tutte le piattaforme XAML, quindi anche Silverlight e WPF)
fondamentalmente i VisualStates sono delle modifiche da fare all'interfaccia "di base" (sia che sia un controllo solamente o l'intera pagina), solo che adesso hanno aggiunto il concetto di Trigger: in pratica invece di settarli a mano vengono settati quando si verificano certe condizioni (quindi puoi avere un VisualState per le interfacce "strette e lunghe" come gli smartphone, uno per i tablet, uno per l'xbox ecc ecc)

per i sistemi di puntamento: viene gestito tutto dal Windows Runtime per le app XAML, per le app HTML5/JavaScript vengono usati i Pointer Event

Quindi.. facendo un riassunto.. (se ho capito giusto)

C'è un ambiente di base che consente l'esecuzione di app specifiche su dispostivi ARM o X86 di vari formati (dal tablet al pc alla TV).
Quindi le APP per questo ambiente sono e restano APP.

Per quanto riguarda il pc invece abbiamo il solito windows con il desktop, i programmi ecc, che IN PIU' ha in esecuzione questo ambiente di base di cui sopra su cui far girare le stesse app del tablet/telefono/smart tv..

Cioè facendo un paragone fuori dal mondo MS:
E' come avere un desktop con linux sul quale è in esecuzione anche una vm java che mi consente di installare ed usare le app per android.

GIUSTO? O non ci ho capito una mazza?

Altra domanda: ma le app android girano su una vm java.. queste di MS?

più o meno ci siamo, la differenza è che le app gireranno anche in finestra, quindi sarà difficile per l'utente medio differenziare tra un programma desktop e un'app UAP

riguardo al paragone: diciamo che è più come avere Android sia sul PC che sul telefono con un'app che si adatta automaticamente alla piattaforma, con la possibilità di eseguire all'occorrenza i normali programmi Linux, ma anche questo è molto forzato come paragone

le app girano tutte sul Windows Runtime, e sopra di esso possono girare nativamente (scrivendole in C++) o su .NET (C#/VB/F# ecc ecc) o su Chakra (l'engine JS di IE/Spartan, quindi usando HTML5 o JS)

occhio che il Windows Runtime di suo non è un ambiente managed come .NET o Java, è 100% nativo

una cosa interessante è che il Runtime è estensibile: nessuno ti vieta di usare Java sulla JVM, devi "solo" fornire i binding necessari (RemObjects lo sta facendo con Silver, il suo tool per programmare in Swift su Java/.NET/WinRT)

si diciamo che il succo e' quello... le app di MS sono codice .NET a tutti gli effetti
Non facciamo confusione, le Windows Store Apps non sono codice .NET a tutti gli effetti, al limite potrebbero trattarsi di codice C# (che è ben diverso), ma lo sviluppatore potrebbe anche decidere di usare C++ o JavaScript per la sua app che nulla hanno a che fare con .NET.

Giusto per precisare poi: apps scritte in C# girano in una VM, quelle in C++ no, quelle in JavaScript girano in Chakra (il JavaScript Engine di IE)

Perfetto.
Quindi alla base invece di java c'è framework.net attivo di default sia su tablet che su pc.

No, alla base c'è WinRT, Windows Runtime (che in realtà non è un vero e proprio runtime propriamente detto), un framework comune a tutte le piattaforme che fornisce API comuni a tutte le piattaforme e degli strumenti comuni a tutte le piattaforme, al quale il .NET Framework ha prestato una piccola parte dei suoi strumenti (i linguaggi e una speciale versione del runtime del .NET il CoreCLR, con la sua BCL).

Se Microsoft riuscirà ad espandere la sua presenza nel segmento mobile (smartphone e tablet) ed il kit di sviluppo riuscirà davvero a risultare sufficiente flessibile da adattarsi, in modo trasparente, ai vari ambienti, in modo da minimizzare peculiarità di codice ed, al contempo, manterrà una buona compatibilità con sistemi antecedenti, allora potrebbe pure ampliare il suo monopolio.
Intendiamoci, non penso sia un bene, ma dal punto di vista del produttore si tratta sicuramente di un'approccio intelligente.

Per me il mercato dimostra il suo fallimento, ogni volta avvengono simili concentrazioni di potere, cosa che accade pure in altri settori, con altri soggetti, dove alle fine il conto sarà sempre pagato dall'utenza finale, dato che in ogni caso le aziende scaricano qualsiasi costo di servizi o prodotti, a chi stà in basso alla catena alimentare.

Ciao ragazzi, avendo letto il post sul blog di windows (tutti i link alle fonti in basso o integrati nel testo), in particolare gli articoli di Cliff Simpkins e Somasegar, vorrei rispondere ad un paio di domande fatte da altri utenti. Chiedo scusa se parti del post possono sembrare ridondanti rispetto al contributo offerto già da altri utenti.
DISCLAIMER ( :D:D:D ) : Conoscendo un pochino da lettore l'utenza del sito (ehm Pier2xxx, emiliano84, coff coff) premetto che, anche se per alcune cose non sono proprio entusiasta, non c'è nessun tentativo di flame o trolling ma la ricerca di un confronto serio, perché sinceramente non so bene che pensare di questo OS.


Metodi di input
A quanto pare, leggendo l'intervento di Cliff Simpkins, non sarà una cosa completamente automatica, ma si dovrà usare il classico "if". Riporto lo screen d'esempio (https://utth6g-dm2306.files.1drv.com/y2pNU8j_WmSlaHDZoLsPGq5JUVFgJ0xy3wdj0x0108LhxDyHufryCEZHCd0HuuDdEx-qn_uVQXE0mkrvHTx9L1vUYtoLAT7mGm-9z_EsFtxTm70mmHBiswMmho0fu_SzWlsQU91795EzXQyUQdsG41DJg/lightup-win10.png?psid=1) postato sul blog.
Praticamente in fase di scrittura si va a mappare una azione su un set di periferiche di input in grado di eseguirla (ad esempio uno swipe su un touch screen oppure un drag and drop per mouse e tastiera). La cosa non sarà automatica come si sperava, ma è comunque un enorme passo avanti rispetto al passato e qualcosa di molto simile a quanto già avviene con JavaFX. Praticamente anche MS ha *finalmente* (fra asterischi perché potrei essermi perso qualcosa e non sono sicurissimo che questa cosa non fosse già possibile in passato) reso semplice l'adozione del paradigma di programmazione Control-Model-View con in più il fatto che l'implementazione della view è molto simile al (qualcuno oserebbe dire presa direttamente da) "responsive design" dei siti internet moderni (ahem, capito redazione? :D:D), cosa che ci porta direttamente al...


Adaptive UI
Praticamente l'idea di base è di avere una cosa molto simile al responsive web design, in cui data una struttura di base del sito (ad esempio un header, 3 colonne, una sezione commenti in fondo) questo si adatta alle capacità dello schermo del device che si sta connettendo (un ottimo esempio è il sito della testata concorrente): se lo schermo è troppo stretto, le colonne vengono "incolonnate" (scusate il gioco di parole) una sopra l'altra, il menù se è troppo largo viene spostato in un apposito "hamburger menu" a destra (tipo quello di gmail sul droide per intenderci) e così via.
Un buon esempio mostrato un mesetto fa da MS stessa è quello di Power Point (o anche Excel volendo). La parte interessante quindi non è più solo separare il modello dalla vista, ma il fatto che la stessa "view" si adatta a device differenti in modo dinamico e "pseudo" trasparente per lo sviluppatore (questo secondo MS, nei prossimi giorni ne sapremo di più sentendo il feedback dei devs grossi).
Fra le novità più golose segnalo che finalmente la funzione per ottenere i DPI del monitor funziona bene e non ritorna più 92 di base, cosa che dovrebbe aiutare non poco nella gestione degli schermi super risoluti.

Compilazione ed Esecuzione
Una volta finita la GUI, in fase di compilazione si deve scegliere il od i dispositivi target, come per W8.x. Chiaramente sono stati rilasciati i tool per vedere come il software si adatterà alle diverse interfacce e ai diversi metodi di input (emulati e/o nativi - si parla del testing).
Ora, finalmente c'è la parte interessante, il runtime. La particolarità del Windows Runtime è che si adatta alla macchina su cui gira *NATIVAMENTE*, senza bisogno di VM od altro. Ovvero, per una volta negli ultimi anni MS è veramente avanti proponendo qualcosa di nuovo ed inedito: un vero codice universale che in teoria dovrebbe funzionare senza problemi e con implementazioni specifiche per ogni tipo di device/piattaforma. Questo significa che no, non c'è overhead per l'interpretazione del codice, che sì, anche i devices ARM saranno supportati da codice nativo e compilato per quella piattaforma etc etc.


Ora, finita la parte nozionistica, io vorrei sapere se a parte le App MS (e anche qui ci sarebbe da dire qualcosa, visto che office è universal, mentre Evernote universal non è minimamente paragonabile alla versione desktop e la stessa MS sta mantenendo due teams di sviluppo software, uno mobile/universal ed uno "desktop tradizionale"), dicevo, vorrei sapere se a parte le app MS esiste qualche produttore indipendente che è riuscito a scrivere una app bella e funzionale su ogni dispositivo per la PRODUZIONE DI CONTENUTI.
La mia impressione è che questo modo di strutturare le interfacce sia l'ideale per messaggistica e app di pura consultazione, mentre per i programmi di produzione pura (Suite Adobe, IDE vari, CAD, grafica 3d, simulazione meccanica etc) potrebbero esserci dei problemi: tipo, ve l'immaginate photoshop con adaptive ui che si ridimensiona (tutto sull'asse verticale fra parentesi) quando ridimensionate la finestra lasciando tutti i comandi nascosti nel "hamburger menu" a sinistra? Io no. E' cristallino che comunque rimarranno le care vecchie applicazioni desktop, ma il senso del mio dubbio è: io sviluppatore di software per la produttività sono in qualche modo incentivato ad usare questo nuovo paradigma/runtime? Per me ha qualche vantaggio la scrittura di software per un tablet? O è solo una seccatura?
Ed in che modo può questo concetto di app universale aiutarmi? Ribadisco che sto chiedendo per i software di produttività. Io stesso da programmatore non riesco a capirne l'utilità in certi casi, mentre in altri (tipo il nuovo photo viewer (http://winsupersite.com/windows-10/photos-preview-universal-app-updated-microsoft-windows-10)) mi chiedo se stanno bene di testa alla MS o se veramente vogliono farmi usare quella roba sul mio 27".

La realtà è che da programmatore sono abbastanza contento e mi rendo conto dell'enorme evoluzione segnata da WinRT+UAP+Store, ma mi chiedo se ne valga la pena veramente, quanto lavoro dovrò fare per rendere l'app veramente universale, o se dovrò continuare a tenermene alla larga perché comunque dovrei avere due team di sviluppo (vedi caso evernote).

My 2 cents

PS scusate eventuali typos ma sono di frettissima ché' devo tornare a lavoro. Ciao gente! :)

EDIT se qualcuno notasse imprecisioni o castronerie segnalatele che correggo immediatamente! :) Grazie ancora

FONTI:
http://blogs.windows.com/buildingapps/2015/03/23/windows-10-developer-tooling-preview-now-available-to-windows-insiders/
http://blogs.msdn.com/b/somasegar/archive/2015/03/23/visual-studio-tools-for-windows-10-technical-preview.aspx
http://bgr.com/2015/03/24/windows-10-universal-apps/
http://www.windowscentral.com/what-is-a-universal-windows-app

No, alla base c'è WinRT, Windows Runtime (che in realtà non è un vero e proprio runtime propriamente detto), un framework comune a tutte le piattaforme che fornisce API comuni a tutte le piattaforme e degli strumenti comuni a tutte le piattaforme, al quale il .NET Framework ha prestato una piccola parte dei suoi strumenti (i linguaggi e una speciale versione del runtime del .NET il CoreCLR, con la sua BCL).

mm.. ok, prendo tutto per buono così come è perche comunque sia non ne so di programmazione pertanto riesco a inquadrare le cose ma solo a livello di concetto.. sullo specifico mi perdo.

Quindi diciamo che su windows desktop gira (come servizio?) anche windows runtime che è una versione light di NET framework e serve come base per l'esecuzione di app.
Gli altri dispositivi (smartphone, tv e tablet) hanno un sistema diverso (per ARM) sul quale però gira sempre windows runtime e le relative app.

Mi dovrei essere avvicinato.. :stordita:

@Pino90

Contrariamente a ciò che pensi considero il tuo intervento finalmente costruttivo di persona che conosce la materia.
Ricordo tempo fa che questi commenti erano la norma, non l'eccezione, ma i tempi cambiano e al primo commento si leggono cose senza senso..

Metodi di input
se ti riferisci all'uso di tastiere e mouse o touch, vengono gestiti automaticamente, senza bisogno di scrivere codice, a meno che non vuoi andare a sovrascrivere il comportamento di default... lo screenshot da te postato indica il pulsante back, che e' incluso solo negli smartphone (anche in quelli che non hanno quello hardware, ma comunuq hanno quello della barra a scmparsa sul touchscreen), mentre i tablet e pc non hanno un pulsante back hardware/software (si parla che MS vuole inserirne uno sulla taskbar)

Penso che quello fosse un esempio per la gestione dei pulsanti su diverse piattaforme. Se guardi i commenti sotto il post di Cliff ci sono ulteriori spiegazioni dell'autore che sembrerebbero confermare la mia tesi. Non era tanto l'uso di tastiere e mouse o schermi touch, quanto proprio metodi di input differenti per fare la stessa cosa su piattaforme diverse: un drag-and-drop su touch screen è scomodissimo, mentre con mouse e tastiera è naturale. Mi riferivo a questo e al fatto che purtroppo ci sarà ancora da gestirlo a mano.
Tuttavia se fosse come dici tu (e lo spero) sarebbe infinitamente meglio.



Adaptive UI
sono molto curioso di vedere come sara' per win10, se sara' tipo responsive sul web o no... perche' su win 8, devi gestire le varie risoluzioni a "mano" tramite codice


Che fregatura per W8. A quanto pare adesso dovrebbe essere automatico... aspettiamo il feedback di qualche big dev e vediamo che succede, sono molto ma molto curioso (e nutro forti speranze nel futuro di questo sistema).

Compilazione ed Esecuzione
Quoto, il fatto che le app siano compilate e non girino in una VM, e' quello che mi fa' preferire di gran lunga .NET (e simili) a Java

Te pensa che per lavoro io invece sviluppo in Java e Python (analisi di dati scientifici, generazione di modelli e sistemi etc) ma mi trovo completamente d'accordo con te: questa sembrerebbe essere su carta una soluzione decisamente migliore.

PRODUZIONE DI CONTENUTI
Anche io la vedo dura, sostituire gli attuali software di un certo livello con queste "app" ... a partire dal fatto che almeno fino a win8.1 non puoi usare database di un certo livello, ma solo un "semplice" SQLite (e inizialmente non era supportato nessun DB)

Quoto, e grazie per le aggiunte tecniche di cui non ero a conoscenza. Io mi ero immaginato uno scenario in cui magari la suite adobe 2017 viene presentata come UAP e mi chiedevo come intendessero affrontare il problema...

OT
@Pier2204

Grazie, è solo che molte volte avrei voluto esprimere una opinione contraria al senso comune su questo forum e invece ho desistito memore dei continui flame/attacchi/battutine da parte di tutti gli schieramenti. Ad esempio, non volendo attaccare te in particolare e senza voler assolutamente aprire un mega OT, io trovo molte mancanze nella UI di W8.1 e non riesco ad essere produttivo, e avrei anche delle argomentazioni che ritengo valide, ma tante volte ho deciso di non postare (tant'è che questo è il mio secondo messaggio) proprio per evitare di essere etichettato come hater/fanboy. Purtroppo non è solo la direzione editoriale ad influenzare i contenuti postati dall'utenza, ma anche la community stessa.

Ribadisco che questo non vuole essere un attacco a te o ad un particolare schieramento, vale la stessa cosa per altri utenti (il piccolo snitch o "griglia gareggiatore turbo 350") e fazioni, era solo un esempio.

Scusate l'OT.

Praticamente anche MS ha *finalmente* (fra asterischi perché potrei essermi perso qualcosa e non sono sicurissimo che questa cosa non fosse già possibile in passato) reso semplice l'adozione del paradigma di programmazione Control-Model-View con in più il fatto che l'implementazione della view è molto simile al (qualcuno oserebbe dire presa direttamente da) "responsive design" dei siti internet moderni (ahem, capito redazione? :D:D), cosa che ci porta direttamente al...
Io non conosco JavaFX, ma Aps.NET MVC ti dice qualcosa?
Esiste tipo da 6-7 anni.
Inoltre il .NET e WinRT supportano diversi pattern del genere (nello sviluppo di apps per Windows e WP va molto l'MVVM), ufficialmente Microsoft non ha implementato nativamente, a differenza di quando fatto con Asp.NET, un pattern del genere perché vuole lasciare allo sviluppatore la facoltà di svegliere quale pattern usare e quali framework e librerie.

Comunque l'immagine che hai postato te si riferisce ad un'altra funzionalità, non ho ancora approfondito bene questo aspetto, ma in pratica serve a correggere un aspetto del modo in cui le Universal App lavorano adesso (per chi non lo sapesse):
in W8.1 e WP8.1 per realizzare una Universal App il progetto viene diviso in 3 parti, una parte comune a tutti i dispositivi, le altre parti sono specifiche per una piattaforma (Windows, o Windows Phone), inoltre fra le parti comuni in alcuni casi si può utilizzare la compilazione condizionale in modo che quelle 2-3 righe di codice non vengano compilate per una data piattaforma quando Visual Studio crea il pacchetto da inviare allo Store, questo implica che VS debba creare almeno 2 pacchetti distinti, tutti e due i pacchetti contengono il codice comune, poi uno contiene anche la parte specifica per WP e l'altro contiene anche la parte specifica per Windows.
Già ora le API specifiche per la piattaforma non sono tantissime ce ne sono alcune (si vocifera che dovrebbero essere circa il 10%, non ci sono numeri ufficiali, qualcuno di Microsoft lo ha accennato in qualche video o in qualche post) ora non solo con W10 hanno incrementato le API condivise (sembra siano arrivati al 96%, e non si arriverà mai al 100% perché resteranno sempre delle differenze fra le piattaforme, basti pensare al tasti back di WP, al controller della Xbox o ai dispositivi IoT senza display), ma hanno introdotto questo meccanismo delle API contracts che elimina la necessità di avere un progetto comune ed altri separati per ogni piattaforma e la necessità di usare la compilazione condizionale.

Nell'esempio dell'immagine che hai postato si fa vedere un'API che io ho bisogno che sia eseguita solo su WP per il semplice motivo che su Windows non ci sono i tasti fisici di Windows Phone e questa API serve per registrarsi all'evento della pressione del tasto back e se quindi voglio che pezzo di codice sia eseguito solo su WP devo fare:
#if windows_phone_app
Windows.Phone.UI.Input.HardwareButtons.BackPressed += HardwareButtons_BackPressed;
#endif


Obbligando Visual Studio a creare due binari diversi. Inserire il codice solo nel progetto specifico restituisce lo stesso risultato di avere pacchetti separati.

Sostituendo questo con il codice che hai postato tu Visual Studio crea un solo binario ed un solo pacchetto perché il codice non viene più controllato e separato preventivamente dal compilatore, ma il codice viene controllato e saltato o eseguito a runtime.


Compilazione ed Esecuzione
Una volta finita la GUI, in fase di compilazione si deve scegliere il od i dispositivi target, come per W8.x. Chiaramente sono stati rilasciati i tool per vedere come il software si adatterà alle diverse interfacce e ai diversi metodi di input (emulati e/o nativi - si parla del testing).
Ora, finalmente c'è la parte interessante, il runtime. La particolarità del Windows Runtime è che si adatta alla macchina su cui gira *NATIVAMENTE*, senza bisogno di VM od altro. Ovvero, per una volta negli ultimi anni MS è veramente avanti proponendo qualcosa di nuovo ed inedito: un vero codice universale che in teoria dovrebbe funzionare senza problemi e con implementazioni specifiche per ogni tipo di device/piattaforma. Questo significa che no, non c'è overhead per l'interpretazione del codice, che sì, anche i devices ARM saranno supportati da codice nativo e compilato per quella piattaforma etc etc.
Mi stupisce come mai molti, anche sviluppatori, cadono in questo equivoco:
E' fin dal rilascio di Windows 8 che non si era legati ad una VM!
Il Windows Runtime è un nativo, non ha bisogno di per se di un runtime (anche se nel nome c'è la parola runtime...).
Le apps possono anche essere scritte in C++, lo XAML per l'interfaccia, in origine implementato in C#, per Windows 8 è stato re-implementato in C++.
Ciò che permette alla stessa app di girare su più device è semplicemente il fatto che su tali device sono disponibili le stesse librerie.
E' come sviluppare un'app con le Qt, questa girerà sia su Windows che su Linux che su OSX nonostante sia una libreria C++, ma solo perché esiste sia la versione per Windows che per Linux che per OSX (ed esiste un compilatore C++ per tutti questi sistemi).
Solo le applicazioni scritte in C# hanno la necessità di utilizzare una VM


mi chiedo se ne valga la pena veramente, quanto lavoro dovrò fare per rendere l'app veramente universale, o se dovrò continuare a tenermene alla larga perché comunque dovrei avere due team di sviluppo (vedi caso evernote).
Beh come per ogni cosa dipende molto sia dall'obiettivo commerciale che si vuole raggiungere, sia dal tipo di software che si vuole realizzare, sia dall'obiettivo tecnico che si vuole raggiungere.
Tanto per dire, un programma di rendering non vedo molta utilità nel portarlo su tablet/smartphone, dubito che esista qualche grafico che farebbe certi lavori su questo tipo di device, ma una versione di AutoCAD da portarmi sul tablet quando vado a fare i rilievi mi sarebbe molto comoda (maledetta sia tu Autodesk :ncomment:).

Dal punto di vista dello sviluppatore (per sviluppatore intendo dire la compagnia che pubblica software) non c'è motivo di preoccuparsi di fare una scelta esclusiva, almeno nel breve / medio (ma secondo me anche lungo) termine, può fare invece una scelta inclusiva e decidere di sfruttare questo nuovo canale commerciale dove crede che abbia senso per il suo business.

Non facciamo confusione, le Windows Store Apps non sono codice .NET a tutti gli effetti, al limite potrebbero trattarsi di codice C# (che è ben diverso), ma lo sviluppatore potrebbe anche decidere di usare C++ o JavaScript per la sua app che nulla hanno a che fare con .NET.

beh, le app scritte in C# sono compilate in CIL, che è codice .NET[/QUOTE]

La cosa bella è che piano piano sarà possibile sostituire tutti gli attuali programmi desktop con delle app con un grandissimo vantaggio per l'utente medio.
Si pensi al fatto che si installa da store, si backuppa automaticamente su onedrive (se attivato ovviamente) e dovrebbe essere (vedremo come saranno i controlli) privi di virus, toolbar e simili.

Insomma la pacchia dei nonni, mogli, suoceri, ecc. :D

esatto, non vedo l'ora :D

No, alla base c'è WinRT, Windows Runtime (che in realtà non è un vero e proprio runtime propriamente detto), un framework comune a tutte le piattaforme che fornisce API comuni a tutte le piattaforme e degli strumenti comuni a tutte le piattaforme, al quale il .NET Framework ha prestato una piccola parte dei suoi strumenti (i linguaggi e una speciale versione del runtime del .NET il CoreCLR, con la sua BCL).

no: .NET non ha prestato nulla a RT, semplicemente alcuni tipi del Runtime sono mappati su tipi equivalenti di .NET (tipo Platform::String è mappato su System.String)... sono i binding di cui parlavo prima, se tu volessi portare Java su WinRT probabilmente mapperesti Platform::String su java.lang.String

allo stesso tempo .NET si sta muovendo verso un'unificazione interna grazie a CoreCLR, che viene usato anche per il binding con WinRT

Ciao ragazzi, avendo letto il post sul blog di windows (tutti i link alle fonti in basso o integrati nel testo), in particolare gli articoli di Cliff Simpkins e Somasegar, vorrei rispondere ad un paio di domande fatte da altri utenti. Chiedo scusa se parti del post possono sembrare ridondanti rispetto al contributo offerto già da altri utenti.
DISCLAIMER ( :D:D:D ) : Conoscendo un pochino da lettore l'utenza del sito (ehm Pier2xxx, emiliano84, coff coff) premetto che, anche se per alcune cose non sono proprio entusiasta, non c'è nessun tentativo di flame o trolling ma la ricerca di un confronto serio, perché sinceramente non so bene che pensare di questo OS.uello screen


Metodi di input
A quanto pare, leggendo l'intervento di Cliff Simpkins, non sarà una cosa completamente automatica, ma si dovrà usare il classico "if". Riporto lo screen d'esempio (https://utth6g-dm2306.files.1drv.com/y2pNU8j_WmSlaHDZoLsPGq5JUVFgJ0xy3wdj0x0108LhxDyHufryCEZHCd0HuuDdEx-qn_uVQXE0mkrvHTx9L1vUYtoLAT7mGm-9z_EsFtxTm70mmHBiswMmho0fu_SzWlsQU91795EzXQyUQdsG41DJg/lightup-win10.png?psid=1) postato sul blog.
Praticamente in fase di scrittura si va a mappare una azione su un set di periferiche di input in grado di eseguirla (ad esempio uno swipe su un touch screen oppure un drag and drop per mouse e tastiera). La cosa non sarà automatica come si sperava, ma è comunque un enorme passo avanti rispetto al passato e qualcosa di molto simile a quanto già avviene con JavaFX. Praticamente anche MS ha *finalmente* (fra asterischi perché potrei essermi perso qualcosa e non sono sicurissimo che questa cosa non fosse già possibile in passato) reso semplice l'adozione del paradigma di programmazione Control-Model-View con in più il fatto che l'implementazione della view è molto simile al (qualcuno oserebbe dire presa direttamente da) "responsive design" dei siti internet moderni (ahem, capito redazione? :D:D), cosa che ci porta direttamente al...

quello screen si riferisce alla gestione del tasto back hardware (che non tutti i dispositivi hanno/avranno): ovviamente prima di settare un handler per un evento di un tasto opzionale, devi assicurarti che esista :D

riguardo al pattern MVC: è da WPF (~Vista) che esiste il pattern MVVM (Model-View-ViewModel) ;)

Adaptive UI
Praticamente l'idea di base è di avere una cosa molto simile al responsive web design, in cui data una struttura di base del sito (ad esempio un header, 3 colonne, una sezione commenti in fondo) questo si adatta alle capacità dello schermo del device che si sta connettendo (un ottimo esempio è il sito della testata concorrente): se lo schermo è troppo stretto, le colonne vengono "incolonnate" (scusate il gioco di parole) una sopra l'altra, il menù se è troppo largo viene spostato in un apposito "hamburger menu" a destra (tipo quello di gmail sul droide per intenderci) e così via.
Un buon esempio mostrato un mesetto fa da MS stessa è quello di Power Point (o anche Excel volendo). La parte interessante quindi non è più solo separare il modello dalla vista, ma il fatto che la stessa "view" si adatta a device differenti in modo dinamico e "pseudo" trasparente per lo sviluppatore (questo secondo MS, nei prossimi giorni ne sapremo di più sentendo il feedback dei devs grossi).
Fra le novità più golose segnalo che finalmente la funzione per ottenere i DPI del monitor funziona bene e non ritorna più 92 di base, cosa che dovrebbe aiutare non poco nella gestione degli schermi super risoluti.

ho scritto in un post sopra come funziona la gestione della UI ;) è una variante dei VisualState

Compilazione ed Esecuzione
Una volta finita la GUI, in fase di compilazione si deve scegliere il od i dispositivi target, come per W8.x. Chiaramente sono stati rilasciati i tool per vedere come il software si adatterà alle diverse interfacce e ai diversi metodi di input (emulati e/o nativi - si parla del testing).
Ora, finalmente c'è la parte interessante, il runtime. La particolarità del Windows Runtime è che si adatta alla macchina su cui gira *NATIVAMENTE*, senza bisogno di VM od altro. Ovvero, per una volta negli ultimi anni MS è veramente avanti proponendo qualcosa di nuovo ed inedito: un vero codice universale che in teoria dovrebbe funzionare senza problemi e con implementazioni specifiche per ogni tipo di device/piattaforma. Questo significa che no, non c'è overhead per l'interpretazione del codice, che sì, anche i devices ARM saranno supportati da codice nativo e compilato per quella piattaforma etc etc.

e questa cosa c'è da 8.0, ti basta fare un'app in C++
poi in 8.1 hanno introdotto .NET Native e l'hanno attivato di default su 10, quindi anche con C# si hanno prestazioni estremamente vicine a C++

Ora, finita la parte nozionistica, io vorrei sapere se a parte le App MS (e anche qui ci sarebbe da dire qualcosa, visto che office è universal, mentre Evernote universal non è minimamente paragonabile alla versione desktop e la stessa MS sta mantenendo due teams di sviluppo software, uno mobile/universal ed uno "desktop tradizionale"), dicevo, vorrei sapere se a parte le app MS esiste qualche produttore indipendente che è riuscito a scrivere una app bella e funzionale su ogni dispositivo per la PRODUZIONE DI CONTENUTI.
La mia impressione è che questo modo di strutturare le interfacce sia l'ideale per messaggistica e app di pura consultazione, mentre per i programmi di produzione pura (Suite Adobe, IDE vari, CAD, grafica 3d, simulazione meccanica etc) potrebbero esserci dei problemi: tipo, ve l'immaginate photoshop con adaptive ui che si ridimensiona (tutto sull'asse verticale fra parentesi) quando ridimensionate la finestra lasciando tutti i comandi nascosti nel "hamburger menu" a sinistra? Io no. E' cristallino che comunque rimarranno le care vecchie applicazioni desktop, ma il senso del mio dubbio è: io sviluppatore di software per la produttività sono in qualche modo incentivato ad usare questo nuovo paradigma/runtime? Per me ha qualche vantaggio la scrittura di software per un tablet? O è solo una seccatura?
Ed in che modo può questo concetto di app universale aiutarmi? Ribadisco che sto chiedendo per i software di produttività. Io stesso da programmatore non riesco a capirne l'utilità in certi casi, mentre in altri (tipo il nuovo photo viewer (http://winsupersite.com/windows-10/photos-preview-universal-app-updated-microsoft-windows-10)) mi chiedo se stanno bene di testa alla MS o se veramente vogliono farmi usare quella roba sul mio 27".

occhio che il modello di sviluppo di Office è più complesso: è vero che ci sono dei team dedicati ad ogni piattaforma, ma il grosso del codice è condiviso tra tutte le versioni (ed è in C++)

La realtà è che da programmatore sono abbastanza contento e mi rendo conto dell'enorme evoluzione segnata da WinRT+UAP+Store, ma mi chiedo se ne valga la pena veramente, quanto lavoro dovrò fare per rendere l'app veramente universale, o se dovrò continuare a tenermene alla larga perché comunque dovrei avere due team di sviluppo (vedi caso evernote).


il vantaggio delle UAP è proprio quello di scrivere un'app e averla disponibile su PC, tablet, telefoni e console :D
poi se vuoi condividere codice con le altre piattaforme bisogna valutare una strategia caso per caso

mm.. ok, prendo tutto per buono così come è perche comunque sia non ne so di programmazione pertanto riesco a inquadrare le cose ma solo a livello di concetto.. sullo specifico mi perdo.

Quindi diciamo che su windows desktop gira (come servizio?) anche windows runtime che è una versione light di NET framework e serve come base per l'esecuzione di app.
Gli altri dispositivi (smartphone, tv e tablet) hanno un sistema diverso (per ARM) sul quale però gira sempre windows runtime e le relative app.

Mi dovrei essere avvicinato.. :stordita:

no, .NET Core gira SOPRA a WinRT
.NET è il runtime managed (da poco open source), WinRT è nativo

questa slide è un po' vecchiotta, ma dovrebbe rendere l'idea (https://digitalmindignition.files.wordpress.com/2012/03/apps-windows-8.png)

Microsoft ha pubblicato una serie di video che illustrano alcune caratteristiche:

In questo video mostrano il concetto delle API contract e degli Extension SDK (che in pratica sarebbero le API che non sono comuni a tutta la piattaforma, come quelle alle quali accennavo prima):
http://channel9.msdn.com/Series/Developers-Guide-to-Windows-10-Preview/04

Qui invece parlano di come lo sviluppatore può rendere la UI adattiva:
http://channel9.msdn.com/Series/Developers-Guide-to-Windows-10-Preview/09

Qui invece mostrano i controlli che hanno il compito di semplificare la realizzazioni di layout responsive:
http://channel9.msdn.com/Series/Developers-Guide-to-Windows-10-Preview/08
http://channel9.msdn.com/Series/Developers-Guide-to-Windows-10-Preview/05

Tutta la serie di video è disponibile qui:
http://channel9.msdn.com/Series/Developers-Guide-to-Windows-10-Preview

Bene, vedo che la mia scelta di puntare su Qt diventa sempre più pagante. :ciapet:

Nel senso che le app universali stanno guardacaso convergendo su soluzioni simili a quelle supportate da Qt (con le dovute differenze) e questo semplifica le cose quando verrà attivato il supporto ufficialmente per esse.

Ecosistemi supportati da Qt:
[x] Win32
[x] Win64
[x] WinCE
[x] WinRT (e tra poco supporto completo app universali)
[x] Linux
[x] Android
[x] OS/X
[x] iOS
[x] Blackberry OS 10
[x] RTOS vari (QNX, Integrity, VxWorks, ...)

Poter divertirsi a leggere tutte le discussioni "era meglio prima/è meglio questo", "il mio OS è migliore", ecc.
e potersi concentrare solo sullo sviluppo delle proprie applicazioni:
NON HA PREZZO :D

Bene, vedo che la mia scelta di puntare su Qt diventa sempre più pagante. :ciapet:

Nel senso che le app universali stanno guardacaso convergendo su soluzioni simili a quelle supportate da Qt (con le dovute differenze) e questo semplifica le cose quando verrà attivato il supporto ufficialmente per esse.

Ecosistemi supportati da Qt:
[x] Win32
[x] Win64
[x] WinCE
[x] WinRT (e tra poco supporto completo app universali)
[x] Linux
[x] Android
[x] OS/X
[x] iOS
[x] Blackberry OS 10
[x] RTOS vari (QNX, Integrity, VxWorks, ...)

Poter divertirsi a leggere tutte le discussioni "era meglio prima/è meglio questo", "il mio OS è migliore", ecc.
e potersi concentrare solo sullo sviluppo delle proprie applicazioni:
NON HA PREZZO :D

ma sai che proprio ieri (mentre maledivo XDE.exe perché non mi fa partire gli emulatori di WP 10) pensavo proprio di dare un'occhiata a Qt? hai qualcosa da cui partire?

beh, le app scritte in C# sono compilate in CIL, che è codice .NET
Il codice CIL è codice CIL, il .NET è solo una implementazione del CLI.
Runtime e la BCL sono una parte del .NET Framework, il resto della FCL è un'altra parte del .NET Framework.


no: .NET non ha prestato nulla a RT, semplicemente alcuni tipi del Runtime sono mappati su tipi equivalenti di .NET (tipo Platform::String è mappato su System.String)... sono i binding di cui parlavo prima, se tu volessi portare Java su WinRT probabilmente mapperesti Platform::String su java.lang.String
Lo so bene, quello che intendevo dire è Microsoft ha creato un nuovo ambiente, quasi da zero e per questo nuovo ambiente ha voluto integrare anche tecnologie già in suo possesso e che fanno parte di un altro strumento quale il .NET Framework, come C# ed ovviamente runtime (più precisamente derivandolo dal runtime di Silverlight) e la BCL


allo stesso tempo .NET si sta muovendo verso un'unificazione interna grazie a CoreCLR, che viene usato anche per il binding con WinRT
Da quello che mi è parso di capire fra video e post nel breve/medio esisteranno 2 implementazioni: CoreCLR che è destinato alle app "moderne" e per gli scenari cross-platform ed il CLR "full" (il quale è un superset del CoreCLR) per lo sviluppo di applicazioni Desktop "legacy". Certo uno del team di .NET diceva che il codice nel repository di GitHub del CoreCLR finisce automaticamente anche nel repository (interno) del CLR, ma credo che questa dualità ce la porteremo avanti ancora per molto

mentre maledivo XDE.exe perché non mi fa partire gli emulatori di WP 10)

Ma non è che è Cortana che su su W10 ha le sue cose?
Anche a me ieri l'emulatore funzionava, stasera non vuole andare...

Il codice CIL è codice CIL, il .NET è solo una implementazione del CLI.
Runtime e la BCL sono una parte del .NET Framework, il resto della FCL è un'altra parte del .NET Framework.

questo si, ma il Windows Runtime non è una versione speciale di .NET come qualcuno diceva prima :D e le app scritte in C# sotto sotto sono normali .exe .NET che chiamano le API di RT

Da quello che mi è parso di capire fra video e post nel breve/medio esisteranno 2 implementazioni: CoreCLR che è destinato alle app "moderne" e per gli scenari cross-platform ed il CLR "full" (il quale è un superset del CoreCLR) per lo sviluppo di applicazioni Desktop "legacy". Certo uno del team di .NET diceva che il codice nel repository di GitHub del CoreCLR finisce automaticamente anche nel repository (interno) del CLR, ma credo che questa dualità ce la porteremo avanti ancora per molto

esattamente... in uno dei post del blog avevo anche letto che l'obiettivo è aumentare le API supportate da CoreCLR

Ma non è che è Cortana che su su W10 ha le sue cose?
Anche a me ieri l'emulatore funzionava, stasera non vuole andare...

che problema ti da? non riesce a caricare la SKU di WP?

ma sai che proprio ieri (mentre maledivo XDE.exe perché non mi fa partire gli emulatori di WP 10) pensavo proprio di dare un'occhiata a Qt? hai qualcosa da cui partire?

http://qt-project.org/

Qt è la libreria con i suoi tool di supporto
La si può scaricare come sorgente da compilare da se oppure in versione precompilata
per host Windows, Linux e OS/X e target per quei S.O. e pure per Android ed iOS (solo come target, ovviamente).

Qt Creator è l'IDE multipiattaforma scritta in C++ con libreria Qt
(ma si possono usare anche Visual Studio con l'apposito addIn, Eclipse, ecc. solo che bisogna configurareil tutto per benino).

Essenzialmente per seguire il percorso più semplice per compilare un applicazione per Qt si deve avere:
1) una toolchain (uno dei tanto compilatori supportati)
2) una versione di Qt precompilata per quel compilatore e target
3) un IDE o fare tutto con le proprie manine.

Io quando posso utilizzo Qt Creator, sia perche è multipiattaforma e sia perche semplifica enormemente lo sviluppo multipiattaforma con i kit
("triplette" compilatore+libreria_precompilata+debugger)
un progetto può avere più kit in questo modo da uno stesso progetto si può passare velocemente da un target all'altro ecc.
e con opzioni specifiche per le toolchain di target specifici (Android, Blackberry, ecc.).

Ogni libreria precompilata include anche tutta la sua documentazione specifica accessibile dall'IDE o con Qt Assistant ( e reperibile anche in html dal sito di Qt o rigenerabile a partire dai sorgenti) e naturalmente vi sono poi i vari esempi, ecc.

La maggior differenza rispetto ad altre "librerie per C++" è che include praticamente un ecosistema completo multipiattaforma, per tanta roba per cui con altre librerie si deve ricorrere a funzioni dipendenti dal S.O. target mentre con Qt la si ha in versione portabile
ed in generale efficiente.
Non è perfetto (ad esempio il sistema di gestione "generico" dell'SQL sarebbe da migliorare, come pure alcune cose che riguardano il multithreading) ma per quel che ho visto sino ad ora, tutte le altre alternative crossplatform non sono migliori e non sono altrettanto portabili.
L'importante è leggere bene la documentazione e se si hanno dubbi chiedere POI nei forum con domande ben specifiche (sia sul forum di Qt che su stackoverflow).

@damxxx
Grazie mille delle precisazioni, è molto apprezzata. No, non avevo mai sentito parlare di asp.net MVC perché come ho scritto non sviluppo per Windows e vista la vastità del software MS faccio un po' di difficoltà a seguire tutto.
Grazie ancora di questa aggiunta e di tutte le altre precisazioni. :)

Per completezza, JavaFX (nato nel 2007 se non sbaglio) è un framework per la realizzazione di GUI basato sul paradigma MVC: hai i controller che generano i dati, i modelli che li rappresentano in maniera molto naturale (ad esempio una stringa diventa una StringProperty) e ad ogni modello puoi associare una o più viste specificate in formato FXML (una leggera estensione dell'XML).

@Unrealizer
Grazie mille anche a te.

@Tutti
Wow, era un bel pezzo che non mi capitava di imparare qualcosa sui commenti di una news, grazie mille a tutti. :)

questo si, ma il Windows Runtime non è una versione speciale di .NET come qualcuno diceva prima :D
Beh no, anche se per le apps viene usata una versione speciale del CLR.


esattamente... in uno dei post del blog avevo anche letto che l'obiettivo è aumentare le API supportate da CoreCLR
Non so se hai seguito i video della dotnetConf su Channel9, ma in uno di essi uno del team del .NET Core accennava alla difficoltà di portare certe API sugli altri OS a causa differenti comportamenti dell'OS o di funzionalità mancanti, quindi per alcune API Microsoft implementerà le queste API in modo diverso su Windows, Linux ed OSX, mentre per altre sarà semplicemente impossibile per altre, almeno fino a che non sarà (se mai avverrà) il sistema operativo a fornirà la funzionalità



che problema ti da? non riesce a caricare la SKU di WP?
inizia a caricare l'OS ma poi ad un certo punto si interrompe e si chiude XDE.

Poi però dopo diversi tentativi e provando a lanciare altre immagini ha iniziato a funzionare.


@damxxx
Grazie mille delle precisazioni, è molto apprezzata. No, non avevo mai sentito parlare di asp.net MVC perché come ho scritto non sviluppo per Windows e vista la vastità del software MS faccio un po' di difficoltà a seguire tutto.
Grazie ancora di questa aggiunta e di tutte le altre precisazioni. :)


Come dice stesso il nome Asp.NET MVC è un framework che implementa il pattern MVC per Asp.NET, fra l'altro Aps.NET MVC è open source e disponibile per Linux e OSX grazie a Mono da diverso tempo, mentre da qualche settimana anche grazie al .NET Core, una implementazione Open Source ed ufficiale di Microsoft del CLR per Windows, Linux ed OSX.