Una domanda : Perchè creare un nuovo framework e doverne usare due "affiancati" invece di modificare quello esistente in modo da poter rispondere a tutte le esigenze?

perché c'è sempre stata ed è lì, in alto a destra, quando leggi l'articolo?

magnum44 ha scritto:

Una domanda : Perchè creare un nuovo framework e doverne usare due "affiancati" invece di modificare quello esistente in modo da poter rispondere a tutte le esigenze?

è stata fatta questa scelta perché WinRT è un nuovo framework creato ad hoc per le app Metro. è interoperabile con n linguaggi/runtime. di fatto, puoi scrivere in HTML+JS, XAML+C#/VB, XAML+C++ e ci pensa in automatico WinRT ad "adattarsi" al tuo ambiente, tramite le projection. non avresti comunque potuto riciclare molto lato UI, perché le differenze per avere un design basato su Metro, rispetto ad un'app desktop, sarebbero notevoli. è un non-problema, se vogliamo, perché di fatto continui ad utilizzare tool e strumenti, quello che cambia è la parte di UI, ma non sarebbe stato possibile diversamente, date le premesse.

IE 10 sì, ma perché di fatto è lo stesso engine, utilizzato in due modi diversi.
Le app metro vivono in un modo proprio e sebbene puoi scrivere su disco in cartelle randomiche preassegnate dal sistema, ipoteticamente ci puoi anche accedere da un'app desktop, ma sarebbe solo un trucchetto. Non esiste questo genere di possibilità ufficiale, se non usando un storage remoto, come servizi dove posizionare e recuperare il profilo di un utente per una propria app.
Non è uno scenario su cui ora si concentrano, anzi avere la stessa app su metro e desktop sulla stessa macchina non ha molto senso. Su un desktop win7 e un metro win8 magari sì, però appunto usi servizi remoti