E' un VAIO il Windows 10 Mobile che non t'aspetti

[LMCH]

Originariamente inviato da damxxx

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.

[deggial]

Originariamente inviato da PeK

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?

[battilei]

Originariamente inviato da deggial

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.


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.

[battilei]

Originariamente inviato da PeK

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.

[Cappej]

Originariamente inviato da damxxx

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.

Originariamente inviato da damxxx

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

[cdimauro]

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 in versione universal app, e mi rimangerò quello che ho detto.

[damxxx]

Originariamente inviato da battilei

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.

Originariamente inviato da battilei

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.

Originariamente inviato da deggial

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.

Originariamente inviato da GTKM

Credo non vi stiate capendo

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

Originariamente inviato da LMCH

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.

Originariamente inviato da deggial

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).

Originariamente inviato da Cappej

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à.

Originariamente inviato da cdimauro

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 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

[cdimauro]

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), 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.

[BulletHe@d]

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

[deggial]

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.

[BulletHe@d]

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

[deggial]

Originariamente inviato da BulletHe@d

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!!!

[damxxx]

Originariamente inviato da cdimauro

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), 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.

Originariamente inviato da cdimauro

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.

Originariamente inviato da deggial

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

[deggial]

Originariamente inviato da damxxx

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.

[cdimauro]

Originariamente inviato da damxxx

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).

[GTKM]

Originariamente inviato da cdimauro

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?

[cdimauro]

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

[GTKM]

Originariamente inviato da cdimauro

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

Mea culpa.

[LMCH]

Originariamente inviato da GTKM

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.

[GTKM]

Originariamente inviato da LMCH

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?