Link alla notizia: http://www.hwupgrade.it/news/telefonia/e-un-vaio-il-windows-10-mobile-che-non-t-aspetti_60734.html

VAIO solleva il sipario sul nuovo Phone Biz, un phablet Windows 10 Mobile di fascia media caratterizzato da una dotazione hardware molto curata. La scocca è in alluminio, il display da 5.5" ha risoluzione FullHD, SoC e RAM permettono di sfruttare la modalità Continuum

Click sul link per visualizzare la notizia.

alleauja!


dio non voglia che qualcuno oltre a Microsoft cominci a produrre qualche bel tel con quasto os...


secondo me il non annuncio di nuovi telefoni lumia è dato dal fatto che Microsoft mollerà sulla fascia bassa e media... faranno un solo telefono all'anno di fascia alta con qualche prerogativa particolare e venderanno l'os e i servizi (non così malvagi) ad altri...


vedremo......

Ne sono stati già annunciati svariati.

Ma intendono venderlo solo in Giappone che il mercato con la più scarsa diffusione di WP al mondo?

Se lo esportassero, quel marchio stampigliato Vaio avrebbe lo stesso traino che Nokia ebbe coi primi Lumia.
E con la nuova build .71 a bordo magari, sarebbero un bel passo avanti.

Ma a non più di 399 euri tasse incluse

purtroppo non capisco...

Ma come si fa a chiamare CONTINUUM un qualcosa che si muove su ARM?!?!?

Se voglio "continuità" tra lavoro-mobile e lavoro-desktop DEVO avere anche esigenze diverse, come, magari, installare applicativi dedicati al business o, stupidamente, una STAMPANTE o un device particolare...

bene...

questo come fa ad avvenire su ARM? ma è così impensabile l'utilizzo di UNA CPU ATOM X86 che da mobile passa a desktop e mi da veramante continuità operativa? avrei un PC in tasca che altro non è che il terminale che uso in qualsiasi cosa... non ho bisogno di sincronizzare niente poichè, nativamente, è tutto lì...

Questo DEVE essere CONTINUUM...

Chiaramante non è un problema di VAIO, ma un concetto nato male (IMHO) dalla teste di M$

IMHO

tanto sara' un'altra roba rimarcata con su una rom diversa

purtroppo non capisco...

Ma come si fa a chiamare CONTINUUM un qualcosa che si muove su ARM?!?!?

Se voglio "continuità" tra lavoro-mobile e lavoro-desktop DEVO avere anche esigenze diverse, come, magari, installare applicativi dedicati al business o, stupidamente, una STAMPANTE o un device particolare...

bene...

questo come fa ad avvenire su ARM? ma è così impensabile l'utilizzo di UNA CPU ATOM X86 che da mobile passa a desktop e mi da veramante continuità operativa? avrei un PC in tasca che altro non è che il terminale che uso in qualsiasi cosa... non ho bisogno di sincronizzare niente poichè, nativamente, è tutto lì...

Questo DEVE essere CONTINUUM...

Chiaramante non è un problema di VAIO, ma un concetto nato male (IMHO) dalla teste di M$

IMHO

Da quanto ricordo, ma potrei sbagliare, i nuovi device supportano dispositivi come stampanti.

Anche io aspetto un device con continuum esattamente come lo descrivi, e guardando l'evoluzione di Windows 10, che ora integra le funzioni del telefono, forse è un idea che esiste in casa Microsoft. Aspettiamo e vediamo

rom diversa? rimarcata? non e' sony, e' vaio, il suo primo smartphone prodotto



si supportano stampanti wifi

e per esempio su usb supportano: microfoni (anche per regsitrare audio), webcam, mouse, tastiera, pednrive, monitor (con adattatore usb-c -> hdmi)...

e su bluetooth: mouse, tastiere...

anche io aspetto un X86 che sia veramente continuum (lo aspetto e lo ripeto da anni, prima ancora che a Microsoft venisse in mente il concetto di Win10 e di Continuum).

Penso che quello a cui si riferisce Cappej siano anche applicativi che girano SOLO su Windows "classico desktop".
Roba che viene in mente e che serve a me:
ETS, software Biamp, software Crestron, ma in ogni campo ci sono software che girano SOLO su Windows desktop, basta un qualunque applicativo web-based che fa uso di plugin particolari installati in locale e sei bloccato a Win.

non capisco perche' hai quotato me? non parlavo di software, ma semplicemente dei dispositivi che possono essere connessi :)

boh forse perchè era l'ultima risposta della discussione :D
O perchè parlavi di dispositivi connessi come se fosse un punto di forza di Windows Mobile, quando è una cosa che si dovrebbe dare per scontata su qualunque smartphone; e quindi volevo riportare l'attenzione sulle mancanze che ancora ha l'ecosistema Win10/Continuum.

PS: sia chiaro che io sono sostenitore di Microsoft in questo caso, se non lo fa lei uno smartphone veramente Continuum, non lo fa nessuno.

purtroppo non capisco...

Ma come si fa a chiamare CONTINUUM un qualcosa che si muove su ARM?!?!?

Se voglio "continuità" tra lavoro-mobile e lavoro-desktop DEVO avere anche esigenze diverse, come, magari, installare applicativi dedicati al business o, stupidamente, una STAMPANTE o un device particolare...

bene...

questo come fa ad avvenire su ARM? ma è così impensabile l'utilizzo di UNA CPU ATOM X86 che da mobile passa a desktop e mi da veramante continuità operativa? avrei un PC in tasca che altro non è che il terminale che uso in qualsiasi cosa... non ho bisogno di sincronizzare niente poichè, nativamente, è tutto lì...

Questo DEVE essere CONTINUUM...

Chiaramante non è un problema di VAIO, ma un concetto nato male (IMHO) dalla teste di M$

IMHO
Perché mai tutte queste cose non si potrebbero fare con un processore ARM?

Per cosa pensi sia stata introdotta la Universal Windows Platform?
Cosa pensi che sia possibile fare con Windows 10 Mobile e continuum?

Esattamente questo.
Puoi usare applicativi business (recentemente è stato annunciato il rilascio della nuova Universal Windows Apps di Saleforce, che naturalmente supporta anche continuum), le stampanti wireless funzionano (non tutte ma al lancio c'erano quasi 2000 stampanti supportate).

Non è l'architettura della CPU a fare di un desktop tale.

sony ha venduto vaio anni fa quindi non bisogna associare i due marchi


Perché mai tutte queste cose non si potrebbero fare con un processore ARM?

Per cosa pensi sia stata introdotta la Universal Windows Platform?
Cosa pensi che sia possibile fare con Windows 10 Mobile e continuum?

noi vogliamo un pc con funzioni telefoniche, che cambia GUI a seconda delle dimensioni dello schermo, perchè magari abbiamo un software o una periferica particolare che funziona solo con windows x86, di universal non ce ne frega niente è solo un fastidio e le SH non si impegnano a sviluppare app al pari dei programmi veri e propri

dateci un telefono così e sganciamo anche 500-600€, per un 950xl se li possono tenere dove stanno...

sony ha venduto vaio anni fa quindi non bisogna associare i due marchi




noi vogliamo un pc con funzioni telefoniche, che cambia GUI a seconda delle dimensioni dello schermo, perchè magari abbiamo un software o una periferica particolare che funziona solo con windows x86, di universal non ce ne frega niente è solo un fastidio e le SH non si impegnano a sviluppare app al pari dei programmi veri e propri

dateci un telefono così e sganciamo anche 500-600€, per un 950xl se li possono tenere dove stanno...

quoto. come avevo già scritto, ci sono programmi che girano SOLO su Win x86.

purtroppo non capisco...

Ma come si fa a chiamare CONTINUUM un qualcosa che si muove su ARM?!?!?

Se voglio "continuità" tra lavoro-mobile e lavoro-desktop DEVO avere anche esigenze diverse, come, magari, installare applicativi dedicati al business o, stupidamente, una STAMPANTE o un device particolare...

bene...

questo come fa ad avvenire su ARM? ma è così impensabile l'utilizzo di UNA CPU ATOM X86 che da mobile passa a desktop e mi da veramante continuità operativa? avrei un PC in tasca che altro non è che il terminale che uso in qualsiasi cosa... non ho bisogno di sincronizzare niente poichè, nativamente, è tutto lì...

Questo DEVE essere CONTINUUM...

Chiaramante non è un problema di VAIO, ma un concetto nato male (IMHO) dalla teste di M$

IMHO

L'idea è proprio quella di rendere ininfluente la piattaforma, sostituendo il software desktop con UWP (o anche solo roba web based) dove possibile

ovviamente non mi aspetto AutoCAD UWP (anche se l'appena rilasciato Rise of the Tomb Raider lo è, e non parliamo di un'appettina da data management)

riguardo ai device, UWP supporta le stampanti e permette la gestione di device custom

rom diversa? rimarcata? non e' sony, e' vaio, il suo primo smartphone prodotto

la parte in grassetto è quella che potrebbe far pensare che sia un ODM :D

Perché mai tutte queste cose non si potrebbero fare con un processore ARM?

Per cosa pensi sia stata introdotta la Universal Windows Platform?
Cosa pensi che sia possibile fare con Windows 10 Mobile e continuum?

Esattamente questo.
Puoi usare applicativi business (recentemente è stato annunciato il rilascio della nuova Universal Windows Apps di Saleforce, che naturalmente supporta anche continuum), le stampanti wireless funzionano (non tutte ma al lancio c'erano quasi 2000 stampanti supportate).

Non è l'architettura della CPU a fare di un desktop tale.

*

noi vogliamo un pc con funzioni telefoniche, che cambia GUI a seconda delle dimensioni dello schermo, perchè magari abbiamo un software o una periferica particolare che funziona solo con windows x86, di universal non ce ne frega niente è solo un fastidio e le SH non si impegnano a sviluppare app al pari dei programmi veri e propri

Il problema che vi potente è solo ideologico: l'idea che i "programmi veri e propri" siano solo le applicazioni Win32.

Le Universal Apps sono esattamente il tipo di apps che possono soddisfare queste richieste perché girano indistintamente su x86 e su ARM, su PC o smartphone e possono fare qualunque cosa possano fare quelli che tu chiami "programmi veri e propri".

Le Universal Apps sono un vantaggio per le software house (almeno nel medio-lungo periodo) e un vantaggio per l'utente, che può utilizzare la sua apps su qualunque dispositivo voglia, adattando la UI ad esso (cosa che le Win32 non possono in alcun modo fare) acquistandola una sola volta, senza problemi di installazione, reinstallazione, aggiornamenti e varie ed eventuali.

Dubito che gli sviluppatori possano non essere felici di avere la possibilità di razionalizzare e semplificare il loro lavoro e poter raggiungere una ampissimo bacino di utenti.
Il problema però è se gli utenti vanno avanti con commenti pregiudizievoli e si fanno problemi ideologici

Dubito che gli sviluppatori possano non essere felici di avere la possibilità di razionalizzare e semplificare il loro lavoro e poter raggiungere una ampissimo bacino di utenti.

Tu come sviluppatore ne sei felice ?


Il problema però è se gli utenti vanno avanti con commenti pregiudizievoli e si fanno problemi ideologici
Eh certo quello è un grosso problema.
Allora segnaliamoli questi utenti, insomma basta con i commenti pregiudizievoli.
Anzi, facciamo così, basta commenti. Permettiamo solo quelli approvati dal partito unico della solidarietà e dell'amore universale.

Tu come sviluppatore ne sei felice ?

Mi chiedo: perché uno sviluppatore NON dovrebbe essere "felice"?

Il problema che vi potente è solo ideologico: l'idea che i "programmi veri e propri" siano solo le applicazioni Win32.


Ok, allora forse il fatto che ho alcuni programmi e device che funzionano SOLO con determinate versioni di Windows non è una limitazione tecnica del prodotto, è solo un mio problema ideologico.
Proverò a installare ETS4 e il gateway usb-KNX sul mio nuovo Lumia 830.
Anzi mi compro il 950 perchè ormai abbiamo stabilito che funziona, era solo un mio problema ideologico.

Ok, allora forse il fatto che ho alcuni programmi e device che funzionano SOLO con determinate versioni di Windows non è una limitazione tecnica del prodotto, è solo un mio problema ideologico.
Proverò a installare ETS4 e il gateway usb-KNX sul mio nuovo Lumia 830.
Anzi mi compro il 950 perchè ormai abbiamo stabilito che funziona, era solo un mio problema ideologico.

Credo non vi stiate capendo :D

Forse intendeva: anche le Universal Windows App sono "programmi veri". O meglio, pure su questa piattaforma possono essere scritti software "di livello", mica solo le app da telefonino.

Poi è ovvio che il software Win32 di oggi giri solo su "desktop".

Ok, allora forse il fatto che ho alcuni programmi e device che funzionano SOLO con determinate versioni di Windows non è una limitazione tecnica del prodotto, è solo un mio problema ideologico.
Proverò a installare ETS4 e il gateway usb-KNX sul mio nuovo Lumia 830.
Anzi mi compro il 950 perchè ormai abbiamo stabilito che funziona, era solo un mio problema ideologico.

scrivi allo sviluppatore che supporti UWP, non mi pare difficile. se non lo fai e ti lamenti che non c'è supporto ti comporti come quelli che lamentano del governo e non vanno a votare.

Perché mai tutte queste cose non si potrebbero fare con un processore ARM?

Per cosa pensi sia stata introdotta la Universal Windows Platform?
Cosa pensi che sia possibile fare con Windows 10 Mobile e continuum?

Esattamente questo.
Puoi usare applicativi business (recentemente è stato annunciato il rilascio della nuova Universal Windows Apps di Saleforce, che naturalmente supporta anche continuum), le stampanti wireless funzionano (non tutte ma al lancio c'erano quasi 2000 stampanti supportate).

Non è l'architettura della CPU a fare di un desktop tale.

Il problema è che tutti quelli che vogliono usare un "vero S.O." o usare "applicazioni Windows" in realtà stanno parlando di applicazioni win32 per x86 che stanno venendo portate moolto lentamente (SE vengono portate).
E' la fossa che Microsoft si è scavata con le sue stesse mani e da cui sta tentando di uscire sempre più disperatamente prima che sia troppo tardi.

Il motivo è che per una serie di decisioni idiote hanno reso difficile la transizione già quando uscirono con (l'allora nuovo) runtime .Net e come se non bastasse, l'attuale dirigenza Microsoft non ha una reale esperienza "sul campo" di cosa comporta tutto questo a livello di sviluppo software e di porting.

scrivi allo sviluppatore che supporti UWP, non mi pare difficile. se non lo fai e ti lamenti che non c'è supporto ti comporti come quelli che lamentano del governo e non vanno a votare.

Stai/state capovolgendo la visuale del problema.
Ci sono tantissimi software (pesanti e/o particolari) che allo stato attuale girano su win32, prodotti da software house piccole/medie/enormi.
Microsoft vuole far convergere il mondo mobile e desktop. Ottima cosa che io apprezzo.
Però lo sta facendo in modo che solo alcune applicazioni possano girare in questa nuova piattaforma convergente, tutte le altre possono girare solo sulla "vecchia" piattaforma win32.
Virgoletto il "vecchia" perchè (allo stato attuale delle decisioni prese) questa piattaforma continuerà ad esistere, quindi non è vecchia ma ancora attuale.

Ora, perchè queste software house piccole/medie/enormi devono aggiornare i loro programmi alla nuova piattaforma convergente? Chi dovrebbe spingerle a farlo?
Dovrebbero fare questo lavoro enorme perchè lo 0,1% della loro utenza ha un device "convergente"?
Oppure è Microsoft che, anche considerando le sue percentuali di vendita, dovrebbe piegarsi e trovare una soluzione per rendere le sue soluzioni convergenti più appetibili e realmente convergenti?

Ora, perchè queste software house piccole/medie/enormi devono aggiornare i loro programmi alla nuova piattaforma convergente? Chi dovrebbe spingerle a farlo?
Dovrebbero fare questo lavoro enorme perchè lo 0,1% della loro utenza ha un device "convergente"?
Oppure è Microsoft che, anche considerando le sue percentuali di vendita, dovrebbe piegarsi e trovare una soluzione per rendere le sue soluzioni convergenti più appetibili e realmente convergenti?
Un comitato di pari, tramite messaggi privati, ha giudicato il tuo commento come pregiudizievole e ideologico.
Presto arriveranno quattro squardisti a rimproverarti, e riportarti sulla retta via del pensiero dell'amore verso Microsoft. :asd:


E invece seriamente mi sembra che sia una battaglia già persa, *nix stravince sui server e sul mobile, e di lì non lo schiodano neanche con tutti gli aggiornamenti a win10 imposti e gratuiti che vogliono.
Anzi si stanno facendo odiare pure sul desktop, dando un imprinting disastroso che durerà anni.

scrivi allo sviluppatore che supporti UWP, non mi pare difficile. se non lo fai e ti lamenti che non c'è supporto ti comporti come quelli che lamentano del governo e non vanno a votare.
Fallo tu, e poi scrivi su questo thread la risposta.

E se non lo fai e ti lamenti, ti comporti come quelli che si lamentano del governo e non vanno a votare.

Perché mai tutte queste cose non si potrebbero fare con un processore ARM?

Per cosa pensi sia stata introdotta la Universal Windows Platform?
Cosa pensi che sia possibile fare con Windows 10 Mobile e continuum?

Esattamente questo.
Puoi usare applicativi business (recentemente è stato annunciato il rilascio della nuova Universal Windows Apps di Saleforce, che naturalmente supporta anche continuum)(AirDroid?), le stampanti wireless funzionano (non tutte ma al lancio c'erano quasi 2000 stampanti supportate).

Non è l'architettura della CPU a fare di un desktop tale.

Il problema che vi potente è solo ideologico: l'idea che i "programmi veri e propri" siano solo le applicazioni Win32.

Le Universal Apps sono esattamente il tipo di apps che possono soddisfare queste richieste perché girano indistintamente su x86 e su ARM, su PC o smartphone e possono fare qualunque cosa possano fare quelli che tu chiami "programmi veri e propri".

Le Universal Apps sono un vantaggio per le software house (almeno nel medio-lungo periodo) e un vantaggio per l'utente, che può utilizzare la sua apps su qualunque dispositivo voglia, adattando la UI ad esso (cosa che le Win32 non possono in alcun modo fare) acquistandola una sola volta, senza problemi di installazione, reinstallazione, aggiornamenti e varie ed eventuali.

Dubito che gli sviluppatori possano non essere felici di avere la possibilità di razionalizzare e semplificare il loro lavoro e poter raggiungere una ampissimo bacino di utenti.
Il problema però è se gli utenti vanno avanti con commenti pregiudizievoli e si fanno problemi ideologici

La visione futura è chiara ma la stai facendo troppo semplice, soprattuto in campo aziendale. Chi ha sviluppato software proprio che a tutt'oggi funziona, perchè deve sbattersi (e spendere) per rifare una nuova UWP?

In futuro è chiaro (spero) che sarà così anche perchè da quel che ho letto sembra semplice realizzarla.

IL problema è M$ sta andando al contrario!

Adesso che le UWP non ci sono (poichè è così...) era giusto creare terminali X86 che potessero dare un Continuum REALE!
Con il tempo e l'arrivo massiccio delle UWP sarebbero potuti passare ad ARM in scioltezza...
Adesso questo passaggio non è facile e il Continuum non esiste... o meglio esiste esattamente nella stessa forma in cui usavo l'APP su Android (che non ricordo il nome)(AirDroid?) sul PC... inviavi SMS, accesso al registro chiamate, le email... niente di più... un uso a mezzo
Peccato, hanno perso il treno IMHO

Infatti un conto è cosa potresti farci con le nuove API delle universal app, e tutt'altra cosa è l'ATTUALE, IMMENSO, parco software win32/64, che non verrà certo convertito dall'oggi al domani. Tutt'altro.

Fatemi vedere com'è facile, veloce, ed economico portare WinUAE (http://www.winuae.net) in versione universal app, e mi rimangerò quello che ho detto.

Tu come sviluppatore ne sei felice ?
Se invece di dover fare diverse versioni per diversi dispositivi della mia applicazione ne posso fare una certo che ne sono felice, se poi posso raggiungere oltra agli utenti di smartphone, anche quelli di tablet e pc, oltre ad Xbox (per non citare anche Hololens e dispositivi IoT), aprendo nuovi tipi di scenari e nuove opportunità per il mio business ne sono ancora più felice.


Eh certo quello è un grosso problema.
Allora segnaliamoli questi utenti, insomma basta con i commenti pregiudizievoli.
Anzi, facciamo così, basta commenti. Permettiamo solo quelli approvati dal partito unico della solidarietà e dell'amore universale.

Questa polemica non l'ho capita.
Ho solo detto che è una questione solo ideologica pensare che solo le apps Win32 possano essere "programmi veri e propri", anche perché altrimenti non lo sarebbero le applicazioni di OSX e di Linux che non sono Win32.

Quello che vogli dire è che se le apps su uno smartphone sono più semplici di un'applicazione su un PC desktop non è dovuto a dei limiti tecnici intrinseci delle apps mobile o delle piattaforme di sviluppo.

La semplicità invece è frutto di scelte progettuali degli ingegneri che hanno realizzato la piattaforma di sviluppo e della necessità di soddisfare alcune esigenze in alcuni specifici scenari di utilizzo.

Tanto per fare un esempio al di fuori di Windows: iOS non permetteva di eseguire due applicazioni contemporaneamente, da un lato c'erano sicuramente per limiti prestazionali (almeno nei primi modelli), dall'altro perché non si sentiva una grossa esigenza simile, inoltre ci sono sempre le questioni di usabilità che va valutata.
Ora che Apple ha presentato un dispositivo come l'iPad Pro ha sentito l'esigenza di introdurre la possibilità di eseguire 2 applicazioni affiancate.

Questo per dire che le piattaforme di sviluppo evolvono con l'evolvere delle necessità.

La UWP è una piattaforma realizzata con l'intento sia di soddisfare le esigenze dei dispositivi mobile, ma anche quelle dei dispositivi desktop.
Non è perfetta, avrà sicuramente bisogno di migliorie e verrà migliorata, ma una UWA può sostituire in tutto e per tutto la maggior parte del software Win32 senza molti problemi.

Ceto fino ad oggi le cose erano divise in compartimenti stagni, da un lato c'era Android ed iOS con le loro API, la loro interfaccia, e con specifiche esigenze, dall'altro c'era Windows, OSX, Linux, ecc... che avevano le loro API e le loro interfacce che erano diverse e non interoperabili e che dovevano soddisfare altre necessità.

Ora è arrivato Windows 10 che rompe questa compartimentazione ma non perché con Windows 10 si può usare sia come desktop che come tablet, ma perché introducendo una piattaforma di sviluppo comune che cerca di soddisfare le esigenze sia di scenari mobile, sia di scenari desktop.
Per questo dico che stare qui a pensare che siccome l'app gira su ARM allora è sicuramente un'app mobile allora deve essere semplice e limitata è solo una questione ideologica, perché si basa sull'idea che sia così, ignorando il fatto che nella realtà una UWP può essere complessa tanto quanto un'app Win32.

Ok, allora forse il fatto che ho alcuni programmi e device che funzionano SOLO con determinate versioni di Windows non è una limitazione tecnica del prodotto, è solo un mio problema ideologico.
Proverò a installare ETS4 e il gateway usb-KNX sul mio nuovo Lumia 830.
Anzi mi compro il 950 perchè ormai abbiamo stabilito che funziona, era solo un mio problema ideologico.
Certo è un problema ideologico perché c'è l'ideologia che solo apps Win32 possano compiere certe attività.

Ma, ma, certo non puoi collegare (ancora) un gateway KNX e configurare i dispositivi, ma Windows 10 integra le API Alljoyn (fra l'altro è possibile controllare, al momento, anche dispositivi ZegBee, Z-Wave e BACNet) e nello Store c'è un'app per configurare i dispositivi Alljoyn.

Certo tu dirai che usi dispositivi KNX e non Alljoyn, ma questo ti dimostra che è possibile e c'è anche una implementazione pratica.

Ed ecco dove viene a galla il problema ideologico il quale è legato al fatto che siccome si tratta di un dispositivo ARM e siccome è uno smartphone allora non possa necessariamente fare determinate cose.

Credo non vi stiate capendo :D

Forse intendeva: anche le Universal Windows App sono "programmi veri". O meglio, pure su questa piattaforma possono essere scritti software "di livello", mica solo le app da telefonino.

Poi è ovvio che il software Win32 di oggi giri solo su "desktop".
Io l'ho capito benissimo, lui non ha capito me, comunque era questo quello che intendevo

Il problema è che tutti quelli che vogliono usare un "vero S.O." o usare "applicazioni Windows" in realtà stanno parlando di applicazioni win32 per x86 che stanno venendo portate moolto lentamente (SE vengono portate).
E' la fossa che Microsoft si è scavata con le sue stesse mani e da cui sta tentando di uscire sempre più disperatamente prima che sia troppo tardi.

Il motivo è che per una serie di decisioni idiote hanno reso difficile la transizione già quando uscirono con (l'allora nuovo) runtime .Net e come se non bastasse, l'attuale dirigenza Microsoft non ha una reale esperienza "sul campo" di cosa comporta tutto questo a livello di sviluppo software e di porting.
Parli come se Windows 10 fosse uscito da un secolo, ma il porting di applicazioni esistenti è cosa complessa e costosa e Microsoft non forza la migrazione, la incoraggia, e fornisce gli strumenti necessari per renderla più semplice, efficace ed economica.

Stai/state capovolgendo la visuale del problema.
Ci sono tantissimi software (pesanti e/o particolari) che allo stato attuale girano su win32, prodotti da software house piccole/medie/enormi.
Microsoft vuole far convergere il mondo mobile e desktop. Ottima cosa che io apprezzo.
Però lo sta facendo in modo che solo alcune applicazioni possano girare in questa nuova piattaforma convergente, tutte le altre possono girare solo sulla "vecchia" piattaforma win32.
Virgoletto il "vecchia" perchè (allo stato attuale delle decisioni prese) questa piattaforma continuerà ad esistere, quindi non è vecchia ma ancora attuale.

Ora, perchè queste software house piccole/medie/enormi devono aggiornare i loro programmi alla nuova piattaforma convergente? Chi dovrebbe spingerle a farlo?
Dovrebbero fare questo lavoro enorme perchè lo 0,1% della loro utenza ha un device "convergente"?
Oppure è Microsoft che, anche considerando le sue percentuali di vendita, dovrebbe piegarsi e trovare una soluzione per rendere le sue soluzioni convergenti più appetibili e realmente convergenti?
Per far si che queste applicazioni legacy possano utilizzare funzione come continuum, soprattutto se vogliamo che siano utilizzabili anche quando non si ha un monitor, una tastiera ed un mouse a disposizione, hanno comunque bisogno di essere aggiornate.

Già il semplice fatto, dopo appena 6 mesi, Windows 10 è su oltre 200 milioni di PC è un buon incentivo a far si che uno sviluppatore decida di supportare la UWP, la quale non solo gli permette di poter raggiungere nuove tipologie di dispositivi, ma potrebbero aprirsi nuovi scenari ai quali non aveva pensato (per dire una cosa banale, restando nell'home automation, pensa alla possibilità di controllare i dispositivi della propria casa con l'Xbox o in futuro con hololens).

La visione futura è chiara ma la stai facendo troppo semplice, soprattuto in campo aziendale. Chi ha sviluppato software proprio che a tutt'oggi funziona, perchè deve sbattersi (e spendere) per rifare una nuova UWP?

In futuro è chiaro (spero) che sarà così anche perchè da quel che ho letto sembra semplice realizzarla.

IL problema è M$ sta andando al contrario!

Adesso che le UWP non ci sono (poichè è così...) era giusto creare terminali X86 che potessero dare un Continuum REALE!
Con il tempo e l'arrivo massiccio delle UWP sarebbero potuti passare ad ARM in scioltezza...
Adesso questo passaggio non è facile e il Continuum non esiste... o meglio esiste esattamente nella stessa forma in cui usavo l'APP su Android (che non ricordo il nome)(AirDroid?) sul PC... inviavi SMS, accesso al registro chiamate, le email... niente di più... un uso a mezzo
Peccato, hanno perso il treno IMHO
La UWP non è nata così perché qualcuno si è svegliato con una voglia strana, ma perché evidentemente un MS si sono posti il problema se e quanto potevano andare avanti con le vecchie API ed hanno convenuto che non era praticabile.
Il problema è che il software Win32 anzitutto non rientra nell'application model di WP7.x\8.x\W8.x10\Mobile e questo è un primo problema che Microsoft avrà parzialmente risolto quando rilascerà Project Centennial, poi c'è un discorso di API, non tutte le API Win32 sono disponibili in Windows 10 Mobile (non so se sono bloccate via policies software o sono fisicamente rimosse), queste sono due problematiche evidenti, magari ce ne saranno altre che noi non conosciamo.
La UWP è una piattaforma pensata fin dall'inizio per poter funzionare indipendentemente dal tipo di dispositivo ed adattarsi ad essa, successivamente hanno pensato di sfruttare questa caratteristica anche in questo modo introducendo continnum, quindi mentre per le UWP il supporto a continnum è naturale (tanto è vero che gli sviluppatori non devono fare, a livello di codice, assolutamente nulla di specifico per supportarlo) per le apps Win32 c'è bisogno di apportare delle modifiche a come funzionano (stando attenti a non rompere la compatibilità) per far si che funzionino.
A questo aggiungici anche che l'interesse di Microsoft è di spingere sulle UWA, se anche le Win32 girano su continnum può non incentivare la realizzazione di quelle tipologie di apps.

Per questo Microsoft ha esplicitamente dichiarato che sebbene ci abbiano pensato e stiano valutando, il supporto alle apps Win32 con continnum non è una priorità.

Infatti un conto è cosa potresti farci con le nuove API delle universal app, e tutt'altra cosa è l'ATTUALE, IMMENSO, parco software win32/64, che non verrà certo convertito dall'oggi al domani. Tutt'altro.

Fatemi vedere com'è facile, veloce, ed economico portare WinUAE (http://www.winuae.net) in versione universal app, e mi rimangerò quello che ho detto.

Beh molto dipende anche dal tipo di progetto e dal linguaggio utilizzato, se è in C++ o C# non c'è problema, ma se vengono utilizzati altri linguaggi allora la cosa diventa molto complicata.
Una parte della business logic e tutto ciò che non è specifico di Windows può essere sicuramente riutilizzato quasi del tutto così com'è (a meno che non venga utilizzata qualche funzione di C++ non supportata da VC++, ma dovrebbero essere casi limite), l'interfaccia andrebbe rifatta tutta.

Non so quello specifico progetto se sia portabile e con quanto lavoro, comunque nello Store si trovano alcuni emulatori di vecchi Nintendo, in linea teorica quindi gli emulatori non sono qualcosa di impossibile da realizzare, non ho idea se quello sia realizzabile e se si con quanta difficoltà.

Sicuramente Project Centennial aiuterà chi vuole fare questa conversione perché permette di mixare le due cose e rende possibile un passaggio graduale e più economico da Win32 a UWP

WinUAE è scritto in C/C++ (e sfrutta anche DirectDraw oppure Direct3D per il rendering durante l'emulazione), ma non ho idea se abbia delle parti in assembly. So per certo che ha un JIT Motorola 68K -> x86/x64, e utilizza QEMU per emulare anche il PowerPC (con annesso JIT -> x86/x64).

La parte di business logic è separata, e infatti esistono anche port per altri s.o./piattaforme, ma WinUAE offre la migliore GUI in assoluto. Ha numerosissime opzioni che puoi settare dall'interfaccia grafica (abbastanza estesa (https://www.youtube.com/watch?v=Ihtkq9VE5rM)), e non credo che Toni Wilen (l'attuale maintainer) abbia tutta questa voglia di riscrivere tutto.

Non ho dubbi che esistano altri emulatori nello store, ma WinUAE è uno dei più complessi (e completi) che esistano nel suo genere, per cui dubito fortemente che farlo diventare UWP sia una passeggiata, pur usando tool che possano aiutare.

Ma il punto fondamentale rimane lo stesso: perché impiegare tante risorse per farlo? Funziona già benissimo così, e trattandosi di un progetto open source è già tanto che sia arrivato a questo livello di funzionalità e utilizzabilità. Ed talmente ben fatto che anche su Linux è preferibile usarlo con WINE, anziché affidarsi a qualche port "nativo", ma che non offre la stessa esperienza.

Non credo che WinUAE sia un caso unico del suo genere. Esiste una vastità di applicazioni Win32/64, e di cui non sarà mai possibile la conversione o perché progetti "morti" (di cui esistono solo i binari) o perché le aziende non hanno alcuna intenzione di investirci o perché non ci sono "braccia" per poterlo fare (pur avendo i sorgenti).

Nel bene e nel male, Microsoft ha fatto la sua fortuna con queste API, e non si può pensare di buttarle via dall'oggi al domani. Non c'è riuscita nemmeno con .NET, che è già in circolazione da parecchi anni, e adesso si presenta con una piattaforma nuova che soffre e soffrirà sempre delle stesse problematiche.

Quindi il punto è che dovrebbe consentire di far girare queste applicazioni anche nelle sue nuove piattaforme, altrimenti si perderebbe troppo software.

Dovrebbe lasciare ai suoi clienti la possibilità di poter decidere cosa fare. L'user experience non sarà certo la migliore, ma fra quello e il nulla, meglio avere qualcosa di sgangherato ma che almeno gira.

Poi se nel frattempo qualche applicazione verrà convertita in UWP, tanto di guadagnato.

Anche perché nel lungo termine l'obbiettivo è eliminare il vecchio Win32 proprio perché vincolato a certe architetture/istruzioni, mentre MS con Win10 vuole fare un s.o. che sia utilizzabile a prescindere dalla piattaforma hardware e per farlo punta sulle uni app progettate proprio per quel motivo e che nel tempo rimpiazzeranno il vecchio win32, adesso siamo solo in un periodo di transizione

Ok tutto molto bello e tutto molto vero, in ottica futuro.
Io lamentavo il fatto (e anche altri penso) che OGGI (e anche DOMANI, forse la situazione si risolverà dopodomani) non esiste un'architettura veramente continuum, non per quello che serve a me.

Quindi, visto che siamo in un periodo di transizione, è Microsoft che deve trovare una soluzione per rendere il tutto veramente convergente.

Io oggi non me ne faccio nulla di sapere che tra 5 anni potrò usare le universal app per programmare un impianto knx o disegnare in autocad, io vorrei farlo ora.
Tra 5 anni, SE tutto sarà portato, mi comprerò sicuramente un device continuum. Come dicevo, lo sto aspettando da anni.
Oggi, se devo scegliere tra un Lumia 930 e 950, rinuncio a Continuum e scelgo il primo tenendomi i soldi in tasca (a parte il fatto che ho appena preso un 830).
Avrei fatto una scelta se avessero usato un Atom e S.O. capace di far girare le applicazioni che mi servono.
Stop, tutto qui. Di quello che succederà tra 5 anni non è che mi importi molto ora.
Magari tra 2 anni AMD o Intel tirano fuori un'architettura più efficente e con meno consumi e gli ARM passano di moda [molto difficile a dire il vero]


PS: Ovvio, voglio farlo ora quando sono attaccato alla docking con un monitor 24", non penso di farlo sul 5" dello smartphone. Ma questo è indipendente dal discorso che stiamo facendo.

quello che cerchi, per ora, è fattibile solo con smartphone x86 con su Win10 normale o con i tablet x86 che hanno sempre win 10 normale e non mobile, solo che i primi sono ad ora introvabili, i secondi ce ne sono di tutti i tipi in commercio

quello che cerchi, per ora, è fattibile solo con smartphone x86 con su Win10 normale o con i tablet x86 che hanno sempre win 10 normale e non mobile, solo che i primi sono ad ora introvabili, i secondi ce ne sono di tutti i tipi in commercio

eh beh grazie!
Il succo del mio discorso è: non si sono smartphone x86 con su Win10 normale!!!
Quindi lo so anche io che sono introvabili. Ed è quello che rimproveravo a Microsoft!!!

WinUAE è scritto in C/C++ (e sfrutta anche DirectDraw oppure Direct3D per il rendering durante l'emulazione), ma non ho idea se abbia delle parti in assembly. So per certo che ha un JIT Motorola 68K -> x86/x64, e utilizza QEMU per emulare anche il PowerPC (con annesso JIT -> x86/x64).

La parte di business logic è separata, e infatti esistono anche port per altri s.o./piattaforme, ma WinUAE offre la migliore GUI in assoluto. Ha numerosissime opzioni che puoi settare dall'interfaccia grafica (abbastanza estesa (https://www.youtube.com/watch?v=Ihtkq9VE5rM)), e non credo che Toni Wilen (l'attuale maintainer) abbia tutta questa voglia di riscrivere tutto.

Non ho dubbi che esistano altri emulatori nello store, ma WinUAE è uno dei più complessi (e completi) che esistano nel suo genere, per cui dubito fortemente che farlo diventare UWP sia una passeggiata, pur usando tool che possano aiutare.

Ma il punto fondamentale rimane lo stesso: perché impiegare tante risorse per farlo? Funziona già benissimo così, e trattandosi di un progetto open source è già tanto che sia arrivato a questo livello di funzionalità e utilizzabilità. Ed talmente ben fatto che anche su Linux è preferibile usarlo con WINE, anziché affidarsi a qualche port "nativo", ma che non offre la stessa esperienza.
Non lo so perché dovrebbe farlo, tu hai chiesto se si poteva fare.
Comunque la presenza di un JIT ci sa la risposta: non è possibile realizzare compilatori JIT.
E' uno dei motivi per cui non è possibile avere browser di terze parti su WP che non utilizzino Chackra e Trident/EdgeHTML.
Ma se il JIT non è fondamentale e/o può essere sostituito in qualche altro modo e le D3D che utilizza fanno parte di quelle esposte anche da WinRT, aumentano le probabilità che possa essere migrato

Comunque non si tratta di un'applicazione semplice, come tu stesso hai detto, ed ovviamente maggiore è la complessità, maggiore è la difficoltà.
Inoltre non è neanche un tipo di applicazione comune, nel senso che non è che gli emulatori rappresentano la principale categoria di software rilasciati sul mercato.


Non credo che WinUAE sia un caso unico del suo genere. Esiste una vastità di applicazioni Win32/64, e di cui non sarà mai possibile la conversione o perché progetti "morti" (di cui esistono solo i binari) o perché le aziende non hanno alcuna intenzione di investirci o perché non ci sono "braccia" per poterlo fare (pur avendo i sorgenti).

Nel bene e nel male, Microsoft ha fatto la sua fortuna con queste API, e non si può pensare di buttarle via dall'oggi al domani. Non c'è riuscita nemmeno con .NET, che è già in circolazione da parecchi anni, e adesso si presenta con una piattaforma nuova che soffre e soffrirà sempre delle stesse problematiche.

Quindi il punto è che dovrebbe consentire di far girare queste applicazioni anche nelle sue nuove piattaforme, altrimenti si perderebbe troppo software.

Dovrebbe lasciare ai suoi clienti la possibilità di poter decidere cosa fare. L'user experience non sarà certo la migliore, ma fra quello e il nulla, meglio avere qualcosa di sgangherato ma che almeno gira.

Poi se nel frattempo qualche applicazione verrà convertita in UWP, tanto di guadagnato.
Infatti Microsoft non le butta dall'oggi al domani, le Win32 continuano ad essere utilizzabili e Microsoft consiglia di utilizzare le API che si desidera lì dove ha senso.
Le apps Win32 girano sulle nuove piattaforme, non girano su una sottoclassi di dispositivi (gli smartphone ed i tablet <8") sui quali comunque non hanno mai girato.

Microsoft dice che se si ha software funzionante e non si è interessati ai nuovi mercati ed alle nuove funzionalità si può di continuare con le Win32, se si vogliono invece raggiungere nuove tipologie di utenti, nuovi mercati e si vogliono sfruttare le nuove funzionalità dei nuovi dispositivi o stai realizzando una nuova applicazione consiglia di migrare alla UWP.

In ogni caso così come fra i tablet e i PC Microsoft ha messo i 2-1, fra le apps Win32 e le UWA ci ha messo Project Centennial che permette allo sviluppatore di migrare la sua applicazione con i tempi che sono più congeniali al suo business.

Il caso di studio da te proposto non sarà sicuramente unico, ci sono situazioni in cui non è possibile adottare la UWP o non lo è in modo facile, ci sono casi in cui il problema sta nelle prestazioni, altri in cui è l'application model ad essere un problema (ad esempio non è facile far comunicare due processi fra di loro), altri dove alcune policies lo sono (ad esempio non è possibile realizzare un Windows service).
Questo nessuno lo nega, tantomeno Microsoft.
Si tratta di una questione di scelte politiche e commerciali, Microsoft ha detto che sta investigando la possibilità di eseguire applicazioni Win32 tramite continuum su uno smartphone x86, ma che non rappresenta una priorità, adesso per Microsoft la priorità è la UWP non perché le Win32 ora fanno schifo ma perché, evidentemente, preferisce lasciarle legate a scenari legacy (se vogliamo considerare i PC tradizionali come dispositivi legacy in confronto ai moderni dispositivi mobili), sia per una questione tecnologica che commerciale.

Immagino che Microsoft, dopo il rilascio di Windows 7 ed ha iniziato a pianificare Windows 8 si sia chiesta se poteva continuare ad andare avanti aggiornando le Win32 o se creare un nuovo set di API.
Immagino che hanno trovato più conveniente realizzare un nuovo set di API che consentisse di sfruttare meglio il nuovo hardware, inoltre ne avranno approfittato per cambiare alcune cose e rompere alcune compatibilità con il passato cosa che altrimenti non avrebbero potuto fare.

Sul perché uno sviluppatore dovrebbe abbracciare il nuovo set di API beh non c'è una risposta univoca, ogni sviluppatore può valutare se conviene alla sua app, potrebbe magari voler raggiungere nuovi utenti in nuovi mercati, potrebbe voler sfruttare alcune funzionalità messe a disposizione dai nuovi dispositivi o da Windows 10.

Ok tutto molto bello e tutto molto vero, in ottica futuro.
Io lamentavo il fatto (e anche altri penso) che OGGI (e anche DOMANI, forse la situazione si risolverà dopodomani) non esiste un'architettura veramente continuum, non per quello che serve a me.

Quindi, visto che siamo in un periodo di transizione, è Microsoft che deve trovare una soluzione per rendere il tutto veramente convergente.

Io oggi non me ne faccio nulla di sapere che tra 5 anni potrò usare le universal app per programmare un impianto knx o disegnare in autocad, io vorrei farlo ora.
Tra 5 anni, SE tutto sarà portato, mi comprerò sicuramente un device continuum. Come dicevo, lo sto aspettando da anni.
Oggi, se devo scegliere tra un Lumia 930 e 950, rinuncio a Continuum e scelgo il primo tenendomi i soldi in tasca (a parte il fatto che ho appena preso un 830).
Avrei fatto una scelta se avessero usato un Atom e S.O. capace di far girare le applicazioni che mi servono.
Stop, tutto qui. Di quello che succederà tra 5 anni non è che mi importi molto ora.
Magari tra 2 anni AMD o Intel tirano fuori un'architettura più efficente e con meno consumi e gli ARM passano di moda [molto difficile a dire il vero]


PS: Ovvio, voglio farlo ora quando sono attaccato alla docking con un monitor 24", non penso di farlo sul 5" dello smartphone. Ma questo è indipendente dal discorso che stiamo facendo.

Non è che le cose avvengono così per magia.
Potresti programmare impianti KNX con uno smartphone anche oggi, non dipende da Microsoft, Microsoft ha messo la tecnologia a disposizione, ora dipende da KNX quando vorrà sfruttare questa possibilità.
Potresti quindi anche prendertela con KNX e chiedere loro di sfruttare una tecnologia che è disponibile oggi, non fra 5 anni.

Il tuo post scriptum non è indipendente, anzi è fondamentale per il discorso che sitiamo facendo, perché se volessi che la tua applicazione sia usabile sempre in ogni situazione allora sicuramente le Win32 non sarebbero in nessun modo la via perché tecnicamente quelle API non sono in grado di soddisfare scenari simili, diversamente la questione è prima di tutto politica (tralasciando eventuali problemi di UX), ma non credo si possa biasimare così tanto Microsoft se vuole incentivare la sua ultima creatura, specie se questa poi può portare dei venefici anche agli utenti

Il tuo post scriptum non è indipendente, anzi è fondamentale per il discorso che sitiamo facendo, perché se volessi che la tua applicazione sia usabile sempre in ogni situazione allora sicuramente le Win32 non sarebbero in nessun modo la via perché tecnicamente quelle API non sono in grado di soddisfare scenari simili, diversamente la questione è prima di tutto politica (tralasciando eventuali problemi di UX), ma non credo si possa biasimare così tanto Microsoft se vuole incentivare la sua ultima creatura, specie se questa poi può portare dei venefici anche agli utenti
Forse non ci capiamo perchè facciamo discorsi diversi.
Io NON voglio che la mia applicazione sia usabile sempre e comunque anche sullo schermo dello smartphone.
Io voglio che il mio dispositivo (smartphone) mi permetta di eseguire applicazioni "desktop" (chiamo io impropriamente "applicazioni desktop" quelle per le quali è fondamentale uno schermo grande e una tastiera/mouse).
Ecco dicevo, io voglio che il mio smartphone mi permetta di eseguire TUTTE le applicazioni desktop ATTUALI quando lo collego alla docking station, e mi permetta, quando lo stacco dalla docking station, di essere usato come uno smartphone, così come ho sempre usato il mio Lumia 625 e ora uso il mio 830.

Esiste uno smartphone del genere? NO
Cosa vorrei io da Microsoft? VORREI CHE LO PRODUCESSE
Cosa faccio a riguardo? MI LAMENTO DEL FATTO CHE NON ESISTE.

Poi potrebbe anche crearlo benissimo Asus, o Lenovo, o Samsung, o Fiat, o Barilla, o Geox, però diciamo che Microsoft sarebbe il produttore pià adatto allo scopo quindi mi lamento di Microsoft.

Potrei lamentarmi con tutti gli sviluppatori di software? Boh sinceramente non ne capisco il motivo, davvero.
Se proprio vogliamo fare i filosofici, lo scopo di avere il computer è usare determinati programmi, quindi il computer deve essere adatto ai programmi. Non è che i programmi nascono per sfruttare le potenzialità del computer, ma appunto il contrario, il computer nasce per far girare i programmi.
Poi si ha anche il viceversa, quando escono nuove architetture migliori, e le software house trovano conveniente il passaggio, migrano su queste nuove architetture. Ma non è lo scopo principale dello scrivere codice.

Non lo so perché dovrebbe farlo, tu hai chiesto se si poteva fare.
Comunque la presenza di un JIT ci sa la risposta: non è possibile realizzare compilatori JIT.
E' uno dei motivi per cui non è possibile avere browser di terze parti su WP che non utilizzino Chackra e Trident/EdgeHTML.
Ma se il JIT non è fondamentale e/o può essere sostituito in qualche altro modo e le D3D che utilizza fanno parte di quelle esposte anche da WinRT, aumentano le probabilità che possa essere migrato
Il JIT non è fondamentale per i giochi (che sono per lo più 2D; ma dovrei vedere come si comporta con capolavori come Elite e Frontier, che sono 3D, e che avevano bisogno di processori veloci), ma lo è per le applicazioni, ovviamente, dove le prestazioni si fanno sentire molto.

L'uso di D3D è molto limitato, perché serve soltanto per accelerare il rendering del framebuffer elaborato (che è in 2D).
Comunque non si tratta di un'applicazione semplice, come tu stesso hai detto, ed ovviamente maggiore è la complessità, maggiore è la difficoltà.
Inoltre non è neanche un tipo di applicazione comune, nel senso che non è che gli emulatori rappresentano la principale categoria di software rilasciati sul mercato.
L'impossibilità di generare codice eseguibile a runtime è una grossissima limitazione.

A parte che gli emulatori ne fanno ampio uso (più si va avanti, e più vengono emulate piattaforme più moderne, per cui si rende necessario), ma non sono i soli ad avere problematiche del genere. Anche software di virtualizzazione ne possono far uso, a seconda dei casi, e non parliamo di robetta realizzata per puro divertimento.

Idem per i simulatori, virtual machine, analizzatori di pacchetti di rete, ecc. ecc.

Microsoft DEVE trovare il modo di reintrodurlo in qualche modo.
[...]
Si tratta di una questione di scelte politiche e commerciali, Microsoft ha detto che sta investigando la possibilità di eseguire applicazioni Win32 tramite continuum su uno smartphone x86, ma che non rappresenta una priorità, adesso per Microsoft la priorità è la UWP non perché le Win32 ora fanno schifo ma perché, evidentemente, preferisce lasciarle legate a scenari legacy (se vogliamo considerare i PC tradizionali come dispositivi legacy in confronto ai moderni dispositivi mobili), sia per una questione tecnologica che commerciale.
[...]
Il tuo post scriptum non è indipendente, anzi è fondamentale per il discorso che sitiamo facendo, perché se volessi che la tua applicazione sia usabile sempre in ogni situazione allora sicuramente le Win32 non sarebbero in nessun modo la via perché tecnicamente quelle API non sono in grado di soddisfare scenari simili, diversamente la questione è prima di tutto politica (tralasciando eventuali problemi di UX), ma non credo si possa biasimare così tanto Microsoft se vuole incentivare la sua ultima creatura, specie se questa poi può portare dei venefici anche agli utenti
Ho lasciato fuori la parte tecnica dalla discussione, perché non è certo quella il problema (i vantaggi delle UWP sono indubbi, a parte qualche grave lacuna; vedi sopra), ma la politica di Microsoft, che continua a essere miope e, di conseguenza, fallimentare anche per i suoi stessi piani.

A livello di mercato Microsoft è indietro sul mobile, e lo sanno anche le pietre.

Sarebbe stato più sensato presentare fin dall'inizio prodotti in grado di far girare software Win32/64 in qualche modo, assieme alla sua nuova piattaforma, in modo da capitalizzare il grande valore aggiunto che da sempre Windows si porta dietro rispetto alla concorrenza: l'immenso parco software.

Ballmer ha sbagliato a non puntare subito sul mobile e Nadella sta sbagliando impuntandosi nel non voler supportare il vecchio software. Sono scelte commercialmente suicide, che faranno sparire la piattaforma mobile di Microsoft. A quanto pare Windows RT non ha insegnato nulla.

Inoltre se fosse stato aggiunto il supporto a Win32/64 fin dall'inizio, IMO l'effetto sarebbe stato il contrario: contribuendo alla diffusione della piattaforma mobile (che sarebbe possibile usare anche come "desktop", per l'appunto), gli sviluppatori sarebbero stati più invogliati a portare, man mano, le loro applicazione su UWP, con gli strumenti che hai citato, perché l'esperienza d'uso su mobile è di gran lunga migliore con UWP.

Perché non è certo l'ambito desktop rappresentato da Windows, che è la piattaforma dominante, a poter contribuire alla diffusione delle app UWP, visto che tutto il software Win32/64 gira già senza problemi. Ci sarà un passaggio, sicuramente, perché gli sviluppatori amano smanettare con strumenti nuovi, ma non sempre ciò sarà possibile (vedi discorso di prima).

Ci sarà un passaggio, sicuramente, perché gli sviluppatori amano smanettare con strumenti nuovi, ma non sempre ciò sarà possibile (vedi discorso di prima).

Su questo non sono assolutamente certo; anche se agli sviluppatori piace fare esperimenti con i nuovi strumenti, il passaggio dalla fase di "divertimento" a quella di produzione è legato anche al market share.

Comunque ho una domanda per chi già ha esperienza con UWP: fin dove è possibile, ad esempio, utilizzare codice in C++ "standard" in una universal app?

Ma infatti quella frase è legata alla precedente, che parla proprio della diffusione della piattaforma UWP. ;)

Ma infatti quella frase è legata alla precedente, che parla proprio della diffusione della piattaforma UWP. ;)

Mea culpa. :D

Comunque ho una domanda per chi già ha esperienza con UWP: fin dove è possibile, ad esempio, utilizzare codice in C++ "standard" in una universal app?

Se il codice usa API win32 come una tipica applicazione "legacy" .. devi morire.
E visto che la maggior parte delle persone preferiscono vivere, questo spiega la mancanza di entusiasmo nel fare porting verso UWP in assenza di un committente che ti paghi profumatamente per farlo.

Se il codice usa API win32 come una tipica applicazione "legacy" .. devi morire.
E visto che la maggior parte delle persone preferiscono vivere, questo spiega la mancanza di entusiasmo nel fare porting verso UWP in assenza di un committente che ti paghi profumatamente per farlo.

Ok, e per il codice "multipiattaforma"? (Cioè, quello che era stato scritto usando il C++ "standard", senza API Win32)

Ci sono delle limitazioni, in tal senso, nella UWP? Oppure si tratta "solo" di riscrivere ciò che è legato alle API legacy?

Forse non ci capiamo perchè facciamo discorsi diversi.
Io NON voglio che la mia applicazione sia usabile sempre e comunque anche sullo schermo dello smartphone.
Io voglio che il mio dispositivo (smartphone) mi permetta di eseguire applicazioni "desktop" (chiamo io impropriamente "applicazioni desktop" quelle per le quali è fondamentale uno schermo grande e una tastiera/mouse).
Ecco dicevo, io voglio che il mio smartphone mi permetta di eseguire TUTTE le applicazioni desktop ATTUALI quando lo collego alla docking station, e mi permetta, quando lo stacco dalla docking station, di essere usato come uno smartphone, così come ho sempre usato il mio Lumia 625 e ora uso il mio 830.

Esiste uno smartphone del genere? NO
Cosa vorrei io da Microsoft? VORREI CHE LO PRODUCESSE
Cosa faccio a riguardo? MI LAMENTO DEL FATTO CHE NON ESISTE.

Poi potrebbe anche crearlo benissimo Asus, o Lenovo, o Samsung, o Fiat, o Barilla, o Geox, però diciamo che Microsoft sarebbe il produttore pià adatto allo scopo quindi mi lamento di Microsoft.
Io ho capito benissimo, ma mentre tu dicevi che è irrilevanti io ti dicevo che non è affatto irrilevante, anzi.

Potrei lamentarmi con tutti gli sviluppatori di software? Boh sinceramente non ne capisco il motivo, davvero.

Mettiamo che sul mercato esista un telefono che integra il GPS, che esponga delle semplici e comode API per poterlo sfruttare e che n esistano applicazioni che utilizzino questa funzionalità.
C'è da lamentarsi con il produttore del dispositivo perché nessuno sfrutta questa caratteristica o si potrebbe semplicemente chiedere agli sviluppatori di farlo?

Certo l'esempio non è rigoroso nel caso specifico di continuum la questione è più complessa, ma il punto è se un dispositivo mette a disposizione una funzionalità perché non chiedere agli sviluppatori di sfruttarla?



Se proprio vogliamo fare i filosofici, lo scopo di avere il computer è usare determinati programmi, quindi il computer deve essere adatto ai programmi. Non è che i programmi nascono per sfruttare le potenzialità del computer, ma appunto il contrario, il computer nasce per far girare i programmi.
Poi si ha anche il viceversa, quando escono nuove architetture migliori, e le software house trovano conveniente il passaggio, migrano su queste nuove architetture. Ma non è lo scopo principale dello scrivere codice.

In realtà sono vere tutte e due le cose, i programmi nascono per adattarsi ai dispositivi ed i dispositivi nascono per adattarsi ai programmi.
Ma hardware e software vanno a braccetto.

Lo scopo principale di scrivere codice è quello di risolvere dei problemi, per risolvere i quali c'è bisogno di algoritmi che descrivono i passaggi necessari e di hardware che esegua i compiti descritti dagli algoritmi.
Se gli algoritmi non descrivono sufficientemente bene i passaggi o l'hardware non è in grado di eseguire le operazioni descritte dagli algoritmi il problema non lo risolvi.

C'è un motivo perché si parla di hardware e software e non ha a che fare con il porno.
Ha a che fare con il fatto che il software e modificabile, è "programmabile" mentre l'hardware (semplificando il discorso) no.
Il motivo per cui è nato il software è proprio perché l'hardware non è modificabile ma con il software era possibile sfruttare il rigido hardware e riadattarlo per i compiti ai quali si era interessati.

Il JIT non è fondamentale per i giochi (che sono per lo più 2D; ma dovrei vedere come si comporta con capolavori come Elite e Frontier, che sono 3D, e che avevano bisogno di processori veloci), ma lo è per le applicazioni, ovviamente, dove le prestazioni si fanno sentire molto.

L'uso di D3D è molto limitato, perché serve soltanto per accelerare il rendering del framebuffer elaborato (che è in 2D).

L'impossibilità di generare codice eseguibile a runtime è una grossissima limitazione.

A parte che gli emulatori ne fanno ampio uso (più si va avanti, e più vengono emulate piattaforme più moderne, per cui si rende necessario), ma non sono i soli ad avere problematiche del genere. Anche software di virtualizzazione ne possono far uso, a seconda dei casi, e non parliamo di robetta realizzata per puro divertimento.

Idem per i simulatori, virtual machine, analizzatori di pacchetti di rete, ecc. ecc.

Microsoft DEVE trovare il modo di reintrodurlo in qualche modo.
Da quello che mi è parso di capire (non sono un ingegnere del software) è sostanzialmente un problema di sicurezza, per poter jittare codice dovrebbe essere concessi dei permessi che attualmente le applicazioni non hanno.


Ho lasciato fuori la parte tecnica dalla discussione, perché non è certo quella il problema (i vantaggi delle UWP sono indubbi, a parte qualche grave lacuna; vedi sopra), ma la politica di Microsoft, che continua a essere miope e, di conseguenza, fallimentare anche per i suoi stessi piani.

A livello di mercato Microsoft è indietro sul mobile, e lo sanno anche le pietre.

Sarebbe stato più sensato presentare fin dall'inizio prodotti in grado di far girare software Win32/64 in qualche modo, assieme alla sua nuova piattaforma, in modo da capitalizzare il grande valore aggiunto che da sempre Windows si porta dietro rispetto alla concorrenza: l'immenso parco software.

Ballmer ha sbagliato a non puntare subito sul mobile e Nadella sta sbagliando impuntandosi nel non voler supportare il vecchio software. Sono scelte commercialmente suicide, che faranno sparire la piattaforma mobile di Microsoft. A quanto pare Windows RT non ha insegnato nulla.

Inoltre se fosse stato aggiunto il supporto a Win32/64 fin dall'inizio, IMO l'effetto sarebbe stato il contrario: contribuendo alla diffusione della piattaforma mobile (che sarebbe possibile usare anche come "desktop", per l'appunto), gli sviluppatori sarebbero stati più invogliati a portare, man mano, le loro applicazione su UWP, con gli strumenti che hai citato, perché l'esperienza d'uso su mobile è di gran lunga migliore con UWP.

Perché non è certo l'ambito desktop rappresentato da Windows, che è la piattaforma dominante, a poter contribuire alla diffusione delle app UWP, visto che tutto il software Win32/64 gira già senza problemi. Ci sarà un passaggio, sicuramente, perché gli sviluppatori amano smanettare con strumenti nuovi, ma non sempre ciò sarà possibile (vedi discorso di prima).
Ricordiamoci che stiamo parlando della possibilità di far girare applicazioni Win32 sugli smartphone, perché queste non hanno nessunissimo problema a girare su tablet.

Credo che il tuo discorso avrebbe estremamente senso se non fosse vero che sui tablet possano girare applicazioni Win32.
Ma stiamo parlando di uno scenario d'uso limitato al particolare ambito degli smartphone.

Il vecchio software è supportato e continuerà ad essere supportato.
Ma se vuoi raggiungere nuovi mercati, sfruttare i nuovi dispositivi, raggiungere nuove tipologie di utenti, allora utilizza le nuove tecnologie che ti mettiamo a disposizione

Da un lato credo che ci siano delle problematiche tecniche che dovrebbero essere risolte per consentire ad un'app Win32 di giare su smartphone e che non sappiamo quanto tempo necessitino per essere risolte, questo avrebbe potuto influire e magari si sono detti in Microsoft intanto che risolviamo queste problematiche usciamo così poi vediamo se riusciamo a risolvere tutti i problemi buttiamo dentro anche le Win32 e credo che abbiano dato una priorità relativamente bassa a questa cosa.
Credo che la scelta di Microsoft di mettere in secondo piano la compatibilità con le Win32 su continnum sia stata influenzata anche dal passato dove si è dimostrato che quando fornisci una soluzione transitori ci sia il rischio che da transitoria la soluzione deve diventare definitiva vengono a crearsi troppe dipendenze da essa (se non ricordo male una volta questa cosa dovrebbe essere stata citata in qualche blog o in qualche video di qualche Build di qualche program manager di MS, ma ne ho un ricordo molto vago).

Credo abbia influito anche il fatto che sugli smartphone non riescono ad essere così tanto presenti ed avranno ritenuto che per quanto avrebbe potuto aiutare le vendite forse non sarebbe stato un traino così grosse alla diffusione di W10 (dopo tutto le principale piattaforme per smartphone non supportano le Win32 e non sembra essere un così grande problema)

Comunque guardando i numeri adesso sembrano confortanti, il tasso di adozione di W10 è altissimo (anche più alto di Windows 7) ed i dispositivi 2-1 sembrano essere gli unici in crescita con le vendite.
Se Windows 10 continua a diffondersi pesantemente su desktop e gli sviluppatori continuano ad adottare la UWP su desktop, continnum ne trae automaticamente beneficio (perché continuum per lo sviluppatore è a costo 0, una volta che l'app è basata sulla UWP l'app funziona automaticamente su continuum).

Su questo non sono assolutamente certo; anche se agli sviluppatori piace fare esperimenti con i nuovi strumenti, il passaggio dalla fase di "divertimento" a quella di produzione è legato anche al market share.

Comunque ho una domanda per chi già ha esperienza con UWP: fin dove è possibile, ad esempio, utilizzare codice in C++ "standard" in una universal app?
Sono un programmatore amatoriale che usa prettamente C# e non conosco bene la parte C++, ma dipende da cosa vuoi farci, il C++/CX sono delle estensioni che nascondono parte della complessità nell'interazione con i componenti di WinRT, quindi risulta necessario quando si vuole interagire quando si vuole chiamare le API di WinRT.
In alternativa è possibile utilizzare Windows Runtime Library (https://msdn.microsoft.com/en-us/library/Hh438466.aspx) per scrivere codice completamente in C++ standard, aumentando però la complessità del codice.

Se il codice usa API win32 come una tipica applicazione "legacy" .. devi morire.
E visto che la maggior parte delle persone preferiscono vivere, questo spiega la mancanza di entusiasmo nel fare porting verso UWP in assenza di un committente che ti paghi profumatamente per farlo.
Ma non è assolutamente vero.

Ok, e per il codice "multipiattaforma"? (Cioè, quello che era stato scritto usando il C++ "standard", senza API Win32)

Ci sono delle limitazioni, in tal senso, nella UWP? Oppure si tratta "solo" di riscrivere ciò che è legato alle API legacy?
Ma non è vero, lascialo stare. Ed ancora meno vero sarà quando Microsoft rilascerà il bridge Project Centennial che consente di mixare insieme le API Win32 e con le API della UWP.

Come dicevo prima dipende da cosa vuoi fare.
l'elenco delle API Win32 esposte anche in WinRT lo trovi qui:
Win32 and COM for UWP apps (https://msdn.microsoft.com/en-us/library/windows/apps/mt592904.aspx)

Un elenco delle API alternative alle Win32 presenti nella UWP lo trovi qui:
Alternatives to Windows APIs in Universal Windows Platform (UWP) apps (https://msdn.microsoft.com/en-us/library/windows/apps/mt592894.aspx).

Il codice cross-platform dovrebbe funzionare senza problemi, come dicevo prima il C++/CX serve per interagire con i componenti WinRT.

Comunque sul sito di Channel9 sono disponibili alcune sessioni delle ultime 3-4 Build dove parlano del codice C++ con WinRT, a esempio in questo video (https://channel9.msdn.com/Events/Build/2015/3-714?format=html5#time=32m55s) mostrano come è possibile usare C++ per scrivere codice cross platform per Android e Windows, certo questa sessione è centrata sullo sviluppo mobile, il concetto dovrebbe essere estendibile a tutti gli altri scenari

Da quello che mi è parso di capire (non sono un ingegnere del software) è sostanzialmente un problema di sicurezza, per poter jittare codice dovrebbe essere concessi dei permessi che attualmente le applicazioni non hanno.
Il motivo è comprensibile, ma sembra che ci sia la possibilità di eseguire codice "jittato" (https://social.msdn.microsoft.com/Forums/en-US/d76e99ec-5506-4969-8054-afcd2ffae71f/uwpcode-generation-capability?forum=wpdevelop), anche se ho qualche riserva per questo motivo (https://msdn.microsoft.com/en-us/library/windows/apps/ms679350.aspx) (per architetture diverse da x86/x64).
Ricordiamoci che stiamo parlando della possibilità di far girare applicazioni Win32 sugli smartphone, perché queste non hanno nessunissimo problema a girare su tablet.

Credo che il tuo discorso avrebbe estremamente senso se non fosse vero che sui tablet possano girare applicazioni Win32.
Anche su tablet con schermo < 8"?
Ma stiamo parlando di uno scenario d'uso limitato al particolare ambito degli smartphone.
Ne parlo meglio dopo.
Il vecchio software è supportato e continuerà ad essere supportato.
Ma se vuoi raggiungere nuovi mercati, sfruttare i nuovi dispositivi, raggiungere nuove tipologie di utenti, allora utilizza le nuove tecnologie che ti mettiamo a disposizione
Assolutamente, ma i nuovi dispositivi potrebbero anche far eseguire vecchio codice, che poi è il motivo per cui stiamo discutendo.
Da un lato credo che ci siano delle problematiche tecniche che dovrebbero essere risolte per consentire ad un'app Win32 di giare su smartphone e che non sappiamo quanto tempo necessitino per essere risolte, questo avrebbe potuto influire e magari si sono detti in Microsoft intanto che risolviamo queste problematiche usciamo così poi vediamo se riusciamo a risolvere tutti i problemi buttiamo dentro anche le Win32 e credo che abbiano dato una priorità relativamente bassa a questa cosa.
E' possibile, come sarebbe anche stato possibile far girare tutte le applicazioni Win32 in una sandbox isolata, in modo da non compromettere la sicurezza della piattaforma.
Credo abbia influito anche il fatto che sugli smartphone non riescono ad essere così tanto presenti ed avranno ritenuto che per quanto avrebbe potuto aiutare le vendite forse non sarebbe stato un traino così grosse alla diffusione di W10 (dopo tutto le principale piattaforme per smartphone non supportano le Win32 e non sembra essere un così grande problema)
Il punto credo sia proprio questo: la piattaforma "phone" di Microsoft non ha la stessa base software delle concorrenti, e Win32 avrebbe potuto aiutare.

All'epoca sarebbe stato un vantaggio non da poco, mentre adesso che è passato troppo tempo Microsoft deve pensare a sopravvivere.

Rimane comunque una buona carta da potersi ancora giocare.
Comunque guardando i numeri adesso sembrano confortanti, il tasso di adozione di W10 è altissimo (anche più alto di Windows 7) ed i dispositivi 2-1 sembrano essere gli unici in crescita con le vendite.
Se Windows 10 continua a diffondersi pesantemente su desktop e gli sviluppatori continuano ad adottare la UWP su desktop, continnum ne trae automaticamente beneficio (perché continuum per lo sviluppatore è a costo 0, una volta che l'app è basata sulla UWP l'app funziona automaticamente su continuum).
Sì, i vantaggi sono indiscutibili. Ma pensa se con Continuum fosse possibile anche far girare applicazioni Win32 quando lo smartphone è collegato alla dock, o a un monitor + tastiera + mouse: è un valore aggiunto che nessun'altra piattaforma ti dà e ti potrà mai dare.

Questo servirebbe anche a invogliare il porting del software su UWP, perché a un certo punto un utente potrebbe chiedersi: ma perché non posso usare questo programma anche quando sono in giro? Magari con l'interfaccia un po' ritoccata, visto che ho solo il touch.

Potrebbe innescarsi un circolo virtuoso, a vantaggio di UWP e della piattaforma "phone" di Microsoft.

Che poi se ci pensi bene gli smartphone di oggi hanno una discreta potenza di calcolo. Tanto per fare un esempio, il PC che ho a Catania è ormai un Compute Stick con Atom quad core, 2GB di ram, 32GB di eMMC per lo storage, e Windows 10 (a 32 bit): gira tranquillamente, e ho potuto lavorarci persino con PyCharm (che è un mattone di IDE).

Perché non potrei fare la stessa con uno smartphone, che ha una potenza di calcolo comparabile ormai? Così evito pure di comprare un altro PC o un Computer Stick, dirottando la spesa su uno smartphone più potente.

Ok, e per il codice "multipiattaforma"? (Cioè, quello che era stato scritto usando il C++ "standard", senza API Win32)

Ci sono delle limitazioni, in tal senso, nella UWP? Oppure si tratta "solo" di riscrivere ciò che è legato alle API legacy?

Se si usa un runtime multipiattaforma ed è già stato portato, si tratta solo di aggirare alcune limitazioni ed alcune funzionalità che non ci sono più per motivi di sicurezza o altre ragioni.
Molto più semplice perche non devi riscrivere tutto il codice lato UI o peggio.

Il motivo è comprensibile, ma sembra che ci sia la possibilità di eseguire codice "jittato" (https://social.msdn.microsoft.com/Forums/en-US/d76e99ec-5506-4969-8054-afcd2ffae71f/uwpcode-generation-capability?forum=wpdevelop), anche se ho qualche riserva per questo motivo (https://msdn.microsoft.com/en-us/library/windows/apps/ms679350.aspx) (per architetture diverse da x86/x64).
interessante


Anche su tablet con schermo < 8"?
Per i tablet con schermo inferiore ad 8" è previsto Windows 10 Mobile


Assolutamente, ma i nuovi dispositivi potrebbero anche far eseguire vecchio codice, che poi è il motivo per cui stiamo discutendo.
Parliamo sempre di smartphone


E' possibile, come sarebbe anche stato possibile far girare tutte le applicazioni Win32 in una sandbox isolata, in modo da non compromettere la sicurezza della piattaforma.
è quello che fanno le Windows Apps, così come anche Project Centennial fa esattamente questo: pacchettizza le apps Win32 in un'appx (che è il pacchetto utilizzato per la distribuzione delle Windows Apps) utilizzando una tecnologia che ricorda per certi versi App-V.
Il problema è che questo comportano alcune limitazioni e richiederebbe comunque del lavoro extra da parte dello sviluppatore.

Attualmente Project Centennial è previsto solo per Windows Desktop, non è detto che non possano sfruttarlo anche per permettere alle applicazioni Win32 di girare anche sugli smartphone.



Il punto credo sia proprio questo: la piattaforma "phone" di Microsoft non ha la stessa base software delle concorrenti, e Win32 avrebbe potuto aiutare.

All'epoca sarebbe stato un vantaggio non da poco, mentre adesso che è passato troppo tempo Microsoft deve pensare a sopravvivere.

Rimane comunque una buona carta da potersi ancora giocare.
Può darsi, personalmente non credo che sarebbe stato un traino così grande per la massa, dopo tutto non hanno rappresentato un traino così grosso neanche per i tablet

Sì, i vantaggi sono indiscutibili. Ma pensa se con Continuum fosse possibile anche far girare applicazioni Win32 quando lo smartphone è collegato alla dock, o a un monitor + tastiera + mouse: è un valore aggiunto che nessun'altra piattaforma ti dà e ti potrà mai dare.

Questo servirebbe anche a invogliare il porting del software su UWP, perché a un certo punto un utente potrebbe chiedersi: ma perché non posso usare questo programma anche quando sono in giro? Magari con l'interfaccia un po' ritoccata, visto che ho solo il touch.

Potrebbe innescarsi un circolo virtuoso, a vantaggio di UWP e della piattaforma "phone" di Microsoft.

Che poi se ci pensi bene gli smartphone di oggi hanno una discreta potenza di calcolo. Tanto per fare un esempio, il PC che ho a Catania è ormai un Compute Stick con Atom quad core, 2GB di ram, 32GB di eMMC per lo storage, e Windows 10 (a 32 bit): gira tranquillamente, e ho potuto lavorarci persino con PyCharm (che è un mattone di IDE).

Perché non potrei fare la stessa con uno smartphone, che ha una potenza di calcolo comparabile ormai? Così evito pure di comprare un altro PC o un Computer Stick, dirottando la spesa su uno smartphone più potente.

Il punto è quello: innescare un circolo virtuoso che spinga gli utenti a volere e chiedere più Universal Apps e gli sviluppatori a realizzarle.

Ciò che cambia è come innescare questo circolo, le strategie potrebbero essere molte, Microsoft avrà fatto le sue valutazione ed avrà ritenuto opportuno partire così.

Ma non è assolutamente vero.

Hai visto l'ondata travolgente di porting :sofico: che c'e' stata negli anni scorsi da applicazioni API Win32 a .Net ? :rolleyes:

Ed ora hai visto la nuova ondata travolgente di porting verso UWP ?

Il grosso per ora sono porting di applicazioni .Net ( e non tutte, anche li chi ha roba grossa preferisce andarci con calma dopo le idiozie fatte da Microsoft in proposito) o nuove applicazioni scritte da zero.

E cosa c'entra?

Se uno chiede se è possibile riusare codice C++ standard e/o codice che fa uso delle Win32, la risposta è semplicemente si.

Potrebbero essere anche 0 le apps di cui sarebbe stato fatto il porting ma la risposta rimano comunque si.