Link alla notizia: http://www.hwupgrade.it/news/portatili/achitetture-arm-e-windows-8-nel-futuro-mobile_36450.html

Una strategia fatta di costanti incrementi nella potenza di elaborazione quella delle architetture ARM, verso un'unificazione dei modelli d'uso tra i vari dispositivi

Click sul link per visualizzare la notizia.

chiamare windows per desktop con lo stesso nome di un windows phone non credo che cambi le cose...l'approccio ad ARM non è una novità per Microsoft infatti prima di Android i migliori smartphone e palmari erano marchiati WinMobile; la novità non sarà nemmeno sulla questione portabilità di codice dato che i software x86 comunque non gireranno su ARM solo perchè si avrà windows 8 su entrambi gli HW; unica novità sarà la possibilità di non essere legati come salami agli upgrade di Firmware che sono poi sempre un po' Buggati ripiegando su soluzioni "cucinate" adhoc (esempio sugli HTC). si collega la pendrive, si installa windows su qualsiasi HW e via a lavorare! un tablet a mio parere dovrebbe restare più un PC senza tastiera che un enorme telefonino (vedi Ipad).

chiamare windows per desktop con lo stesso nome di un windows phone non credo che cambi le cose...l'approccio ad ARM non è una novità per Microsoft infatti prima di Android i migliori smartphone e palmari erano marchiati WinMobile; la novità non sarà nemmeno sulla questione portabilità di codice dato che i software x86 comunque non gireranno su ARM solo perchè si avrà windows 8 su entrambi gli HW; unica novità sarà la possibilità di non essere legati come salami agli upgrade di Firmware che sono poi sempre un po' Buggati ripiegando su soluzioni "cucinate" adhoc (esempio sugli HTC). si collega la pendrive, si installa windows su qualsiasi HW e via a lavorare! un tablet a mio parere dovrebbe restare più un PC senza tastiera che un enorme telefonino (vedi Ipad).

Cambia le cose, eccome: Windows Mobile e Windows Phone sono basati sul kernel di Windows CE, mentre invece Windows 8, anche in edizione per arm, sarà basato sul kernel NT (lo stesso di windows 2000, di XP, di vista e di 7), che è profondamente diverso!

E molti programmi gireranno indistintamente su x86 che su ARM, grazie al framework .NET (e all'onnipresente Java :D)

Quotone per la parte sui tablet, devono essere pc senza tastiera, non enormi telefonini.

Oltre a questo, sarei felicissimo di avere un netbook/notebook, o anche un piccolo desktop basato su arm, prima di essere usato come server domestico il mio Abaco Primo aveva proprio questa funzione, e devo dire che ne sento la mancanza, difatti sempre più spesso anche a casa uso il netbook.

Cambia le cose, eccome: Windows Mobile e Windows Phone sono basati sul kernel di Windows CE, mentre invece Windows 8, anche in edizione per arm, sarà basato sul kernel NT (lo stesso di windows 2000, di XP, di vista e di 7), che è profondamente diverso!

E molti programmi gireranno indistintamente su x86 che su ARM, grazie al framework .NET (e all'onnipresente Java :D)

Quotone per la parte sui tablet, devono essere pc senza tastiera, non enormi telefonini.

Oltre a questo, sarei felicissimo di avere un netbook/notebook, o anche un piccolo desktop basato su arm, prima di essere usato come server domestico il mio Abaco Primo aveva proprio questa funzione, e devo dire che ne sento la mancanza, difatti sempre più spesso anche a casa uso il netbook.
quoto anche io la penso così il vero tablet devono essere pc senza tastiera e non enormi cellulari

Infatti, la portabilità mica la darà il supporto x86, la daranno i framework applicativi quali java e .net.
Ad ogni modo sono solo curioso di vedere se diventerà un *mostro* poco ottimizzato, oppure se faranno subito le cose bene (si sa, di solito M$ fa le cose per bene con la versione 3.0).

...scusate ma già il .Net è pesante su pc normali...figurarsi su un processore ARM...bah qua non si tratta di vedere se posso far partire tutti i software ma di poterli poi usare...un software che richiede una certa potenza non può girare su sistemi datati/limitati dal tempo o dalla tecnologia in se residente.

so già che come con i primi Netbook qualcuno vorrà far girare un Photoshop su un tablet ARM...
..quando non si capisce la differenza tra le tecnologie si rischia proprio di fare un gran bel bidone di tutto e di niente!

Infatti, la portabilità mica la darà il supporto x86, la daranno i framework applicativi quali java e .net.
Ad ogni modo sono solo curioso di vedere se diventerà un *mostro* poco ottimizzato, oppure se faranno subito le cose bene (si sa, di solito M$ fa le cose per bene con la versione 3.0).

ti assicuro che per windows 8 la ms ha iniziato ha fare le cose bene dalla m1...
è leggerissima, tempo di avvio nullo in confronto a 7, inoltre ho visto girare windows 8 con aero su un tegra 2 senza il minimo problema o rallentamento, e stampare da uno snapdragon...
fai te...
comunque prevedo app universali e interfacce che si adattano al formato.
esempio windows 8 sul telefono con interfaccia da telefono, lo attacco a un 21" con mouse e tastiera e passa al desktop.... ecc...
si potrebbe fare!!!

Quoto tutti quelli che sopra dicono che un tablet dovrebbe essere più pc che telefono gigante.

ma io mi chiedo.....se ipotizziamo che un arm dual core sia molto più potente di un atom ma abbia un consumo risibile a confronto, la mia domanda è: perché non fanno un arm che consuma come un i7 ma che gli mangia in testa in quanto a prestazioni?

Cambia le cose, eccome: Windows Mobile e Windows Phone sono basati sul kernel di Windows CE, mentre invece Windows 8, anche in edizione per arm, sarà basato sul kernel NT (lo stesso di windows 2000, di XP, di vista e di 7), che è profondamente diverso!

E molti programmi gireranno indistintamente su x86 che su ARM, grazie al framework .NET (e all'onnipresente Java :D)

Quotone per la parte sui tablet, devono essere pc senza tastiera, non enormi telefonini.

Oltre a questo, sarei felicissimo di avere un netbook/notebook, o anche un piccolo desktop basato su arm, prima di essere usato come server domestico il mio Abaco Primo aveva proprio questa funzione, e devo dire che ne sento la mancanza, difatti sempre più spesso anche a casa uso il netbook.

Piuttosto che java se si parla di arm e windows allora punterei spaventosamente di piu su c sharp che java ma come hai detto tu sicuramente sarà presente anche lì, anche perché non vedo il motivo per cui qualcuno dovrebbe appesantire il sistema usando un linguaggio che si basa su una virtual machine su dei processori che sicuramente non saranno come quelli presenti sui desktop....
Ovvio che se si parla di quei programmini semplici in java, che tanti hanno imparato a fare nelle università ITALIANE (visto che in italia oggi in giorno per 3 anni trattano solo java, se vuoi imparare qualcos'altro devi scriverti a dei corsi speciali del terzo anno che duranno soli 3 mesi ), allora non senti la pesantezza ma per i programmi seri tutto cambia. Mi ricordo un software che aveva come scopo trasformate di fourier e laplace con tanto di gui fatto in java era lento da morire, lo stesso software fatto in c sharp era un'altra cosa (testati su ambiente windows e linux), la versione in c++ poi era ovviamente una scheggia, ma pur di vantarsi dell'open source la gente é disposta a tutto...ma aspetta...anche c sharp é open??!?! ahhh si scusa mi sono dimenticato che é frutto di microsoft...allora é il male assoluto

W8 su tablet via arm e x86... Confusione.

Ovvio che se si parla di quei programmini semplici in java, che tanti hanno imparato a fare nelle università ITALIANE (visto che in italia oggi in giorno per 3 anni trattano solo java, se vuoi imparare qualcos'altro devi scriverti a dei corsi speciali del terzo anno che duranno soli 3 mesi ), allora non senti la pesantezza ma per i programmi seri tutto cambia. Mi ricordo un software che aveva come scopo trasformate di fourier e laplace con tanto di gui fatto in java era lento da morire, lo stesso software fatto in c sharp era un'altra cosa (testati su ambiente windows e linux), la versione in c++ poi era ovviamente una scheggia, ma pur di vantarsi dell'open source la gente é disposta a tutto...ma aspetta...anche c sharp é open??!?! ahhh si scusa mi sono dimenticato che é frutto di microsoft...allora é il male assoluto

Guarda che Java è stato adottato da scuole ed università ANNI PRIMA che Sun dichiarasse di voler aprire i sorgenti ecc. ecc.
Il motivo era che serviva un nuovo linguaggio "didattico" supportato dal maggior numero di S.O. e piattaforme hardware, relativamente semplice ecc. ecc.
Microsoft .Net è arrivato molto tempo dopo ed anche volendo usare solo C# c'è voluto tempo prima che arrivasse Mono ecc. ecc.

Una volta che ti è chiara la teoria, ci metti molto meno che tre mesi per passare ad un nuovo linguaggio o ad un nuovo ambiente di sviluppo.

In altre parole: C# non è il male assoluto, solo che è arrivato tardi e non è che sia una panacea per tutti i mali del mondo. ;)

Ad esempio, se poi intendi specializzarti nello sviluppo di applicazioni embedded o ti serve roba che deve avere le prestazioni più elevate possibile, torna molto più utile il C/C++, solo che per studenti alle prime armi ha funzionalità che complicano l'apprendimento invece che facilitarlo.

Per questo Java in molti corsi aveva sostituito pure C/C++ nonostante fossero disponibili da molto prima ed avessero maggiori funzionalità orientate alle prestazioni (tipo l'aritmetica dei puntatori) o (nel caso del C++) più sofisticate tipo i template (che solo in seguito furono aggiunti a Java).

...scusate ma già il .Net è pesante su pc normali...figurarsi su un processore ARM...bah qua non si tratta di vedere se posso far partire tutti i software ma di poterli poi usare...un software che richiede una certa potenza non può girare su sistemi datati/limitati dal tempo o dalla tecnologia in se residente.

so già che come con i primi Netbook qualcuno vorrà far girare un Photoshop su un tablet ARM...
..quando non si capisce la differenza tra le tecnologie si rischia proprio di fare un gran bel bidone di tutto e di niente!

per smentire questa affermazione basta ricordare che .net è meno pesante di java e va persino piu veloce essendo alla compilato e non interpretato quindi o nessun telefonino usa giava oppure hai sbagliato previsione...direi la seconda.
Anche un programma scritto in assembly è pesante se è scitto male.

...scusate ma già il .Net è pesante su pc normali...figurarsi su un processore ARM...bah qua non si tratta di vedere se posso far partire tutti i software ma di poterli poi usare...un software che richiede una certa potenza non può girare su sistemi datati/limitati dal tempo o dalla tecnologia in se residente.

so già che come con i primi Netbook qualcuno vorrà far girare un Photoshop su un tablet ARM...
..quando non si capisce la differenza tra le tecnologie si rischia proprio di fare un gran bel bidone di tutto e di niente!

ti assicuro che per windows 8 la ms ha iniziato ha fare le cose bene dalla m1...
è leggerissima, tempo di avvio nullo in confronto a 7, inoltre ho visto girare windows 8 con aero su un tegra 2 senza il minimo problema o rallentamento, e stampare da uno snapdragon...
fai te...
comunque prevedo app universali e interfacce che si adattano al formato.
esempio windows 8 sul telefono con interfaccia da telefono, lo attacco a un 21" con mouse e tastiera e passa al desktop.... ecc...
si potrebbe fare!!!

Piuttosto che java se si parla di arm e windows allora punterei spaventosamente di piu su c sharp che java ma come hai detto tu sicuramente sarà presente anche lì, anche perché non vedo il motivo per cui qualcuno dovrebbe appesantire il sistema usando un linguaggio che si basa su una virtual machine su dei processori che sicuramente non saranno come quelli presenti sui desktop....
Ovvio che se si parla di quei programmini semplici in java, che tanti hanno imparato a fare nelle università ITALIANE (visto che in italia oggi in giorno per 3 anni trattano solo java, se vuoi imparare qualcos'altro devi scriverti a dei corsi speciali del terzo anno che duranno soli 3 mesi ), allora non senti la pesantezza ma per i programmi seri tutto cambia. Mi ricordo un software che aveva come scopo trasformate di fourier e laplace con tanto di gui fatto in java era lento da morire, lo stesso software fatto in c sharp era un'altra cosa (testati su ambiente windows e linux), la versione in c++ poi era ovviamente una scheggia, ma pur di vantarsi dell'open source la gente é disposta a tutto...ma aspetta...anche c sharp é open??!?! ahhh si scusa mi sono dimenticato che é frutto di microsoft...allora é il male assoluto

Tanto per fare un piccolo appunto, non è C# a fare la differenza, ma il framework .net su cui gira, ormai programmare in C# o VB.net è quasi la stessa cosa :D

Vorrei però far notare che tra gli "optional" per i core arm c'è anche Jazelle, il set di istruzioni per l'accelerazione hardware di java, ma non so quanto potrebbe incidere...

Inoltre, invito djfix a provare qualche applicazione su Windows Phone 7 (stiamo sempre parlando di .net) o di qualche gioco XNA sempre su WP7 o su xbox, sempre tramite .net

per smentire questa affermazione basta ricordare che .net è meno pesante di java e va persino piu veloce essendo alla compilato e non interpretato quindi o nessun telefonino usa giava oppure hai sbagliato previsione...direi la seconda.
Anche un programma scritto in assembly è pesante se è scitto male.

quoto in pieno

Tanto per fare un piccolo appunto, non è C# a fare la differenza, ma il framework .net su cui gira, ormai programmare in C# o VB.net è quasi la stessa cosa :D

Lo è sempre stato, VB.Net è praticamente "C# con una sintassi diversa", ha persino parecchie incompatibilità praticamente deliberate con VB6 perchè renderlo "più compatibile" avrebbe fatto venir meno la corrispondenza 1:1 tra VB.Net e C#.

I tablet son sempre stati dei "notebook senza tastiera" (slate) o comunque dei "notebook con tastiera a scomparsa" (convertibili), solo che non se li e' mai filati nessuno, fino a quando non e' uscito l'iPad, basato su ARM. -_-''

Oltre a questo, gia' ora esistono dei netbook ARM: Toshiba, per esempio, ne ha uno con lo stesso hardware dei tablet da 400 € (vedi Olipad) e che recentemente viene svenduto a 200 €, in quanto inusabile.
Al momento, infatti, un sistema ARM deve per forza essere basato su Android o Windows Phone, 2 architetture che richiedono uno schermo touch, cosa che un netbook non offre.

Al massimo avrebbe senso realizzare un netbook/notebook convertibile, basato su ARM e privo di touchpad, cosi' da poter avere una tastiera fisica grande e comoda.

LMCH wrote:
> [...] VB.Net è praticamente "C# con una sintassi diversa" [...]

A parita' del livello di astrazione (interpretato, pre-compilato, ...), qualsiasi linguaggio e' "uguale ad un altro ma con una sintassi diversa". ^^''

I linguaggi di programmazione son sempre la solita minestra.
Cio' che puo' cambiare sono gli ambienti di sviluppo, le librerie a disposizione e cosi' via, ovvero l'infrastruttura a piu' alto livello, creata spesso dagli ideatori stessi del linguaggio, per facilitare i programmatori.

Ormai non esistono piu' i puriusti d'un tempo (per fortuna), che campavano solo di editor ASCII. :p

LMCH wrote:
> [...] VB.Net è praticamente "C# con una sintassi diversa" [...]

A parita' del livello di astrazione (interpretato, pre-compilato, ...), qualsiasi linguaggio e' "uguale ad un altro ma con una sintassi diversa". ^^''


Ma (per citare Orwell) alcuni sono più uguali degli altri. :read:

Ad esempio in VB6 l'istruzione DIM per dichiarare array prevedeva la possibilità di specificare un indice minimo oltre a quello massimo, per esempio:
Dim a(50 to 100) As Long
in VB6 dichiara un array di 51 elementi con indice che va da 50 a 100
es: a(51) è il secondo elemento dell'array.

In VB.Net invece non si può fare e devi modificare i sorgenti scrivendo
Dim a(50) As Long
ed ogni volta che accedi ad a() devi scrivere a(i-50), può sembrare una cosa da poco, ma è solo un esempio delle "incompatibilità" che ti costringono a rimettere mano a tutti i sorgenti e ricontrollare tutto a con i tuoi stessi occhi (ci sono anche dei tool di conversione "automatici" ma non è che fanno un lavoro sufficientemente completo, alla fine bisogna ricontrollare tutto).

E si tratta solo della punta dell'iceberg, pure le librerie "standard" di VB con VB.Net praticamente non ci sono o sono solo parzialmente retrocompatibili.
Per questo chi per varie ragioni aveva sviluppato roba relativamente grossa in VB, quando è giunto il momento di fare il porting, spesso lo ha fatto direttamente verso C# o anche verso Java (tanto in ogni caso bisognava rivoltare i sorgenti come un calzino) o ha riscritto tutto.

Ma (per citare Orwell) alcuni sono più uguali degli altri. :read:

Ad esempio in VB6 l'istruzione DIM per dichiarare array prevedeva la possibilità di specificare un indice minimo oltre a quello massimo, per esempio:
Dim a(50 to 100) As Long
in VB6 dichiara un array di 51 elementi con indice che va da 50 a 100
es: a(51) è il secondo elemento dell'array.

In VB.Net invece non si può fare e devi modificare i sorgenti scrivendo
Dim a(50) As Long
ed ogni volta che accedi ad a() devi scrivere a(i-50), può sembrare una cosa da poco, ma è solo un esempio delle "incompatibilità" che ti costringono a rimettere mano a tutti i sorgenti e ricontrollare tutto a con i tuoi stessi occhi (ci sono anche dei tool di conversione "automatici" ma non è che fanno un lavoro sufficientemente completo, alla fine bisogna ricontrollare tutto).

E si tratta solo della punta dell'iceberg, pure le librerie "standard" di VB con VB.Net praticamente non ci sono o sono solo parzialmente retrocompatibili.
Per questo chi per varie ragioni aveva sviluppato roba relativamente grossa in VB, quando è giunto il momento di fare il porting, spesso lo ha fatto direttamente verso C# o anche verso Java (tanto in ogni caso bisognava rivoltare i sorgenti come un calzino) o ha riscritto tutto.

Ma guarda, tralasciando questioni puramente sintattiche, ci sono differenze grosse quanto un grattacielo di 2500 piani tra VB6 e VB.Net :

1) VB6 NON è un linguaggio OO, per quanto ne vogliano dire....(un linguaggio che non supporta l'ereditarietà tra classi e tutto ciò che ne deriva, può essere definito orientato agli oggetti!!?)

2) In VB6 che io ricordi non c'è mai stato un supporto nativo ed esaustivo al Multithreading,

3) VB6 (ovviamente) non si appoggia al Framework .Net ed ha un processo di compilazione totalmente diverso dai linguaggi .Net.

E' un pò come la storia del C e del C++, le chiamano estensioni, linguaggi migliorati etc etc...ma la sostanza è che sono strutturalmente diversi, è un po come dire che Windows XP è identico a Seven solo perchè il pulsante Start è sempre in basso a sinistra!!! (relativo alla somiglianza sintattica dei due linguaggi)...

Ma guarda, tralasciando questioni puramente sintattiche, ci sono differenze grosse quanto un grattacielo di 2500 piani tra VB6 e VB.Net :

1) VB6 NON è un linguaggio OO, per quanto ne vogliano dire....(un linguaggio che non supporta l'ereditarietà tra classi e tutto ciò che ne deriva, può essere definito orientato agli oggetti!!?)

2) In VB6 che io ricordi non c'è mai stato un supporto nativo ed esaustivo al Multithreading,

3) VB6 (ovviamente) non si appoggia al Framework .Net ed ha un processo di compilazione totalmente diverso dai linguaggi .Net.

E' un pò come la storia del C e del C++, le chiamano estensioni, linguaggi migliorati etc etc...ma la sostanza è che sono strutturalmente diversi, è un po come dire che Windows XP è identico a Seven solo perchè il pulsante Start è sempre in basso a sinistra!!! (relativo alla somiglianza sintattica dei due linguaggi)...

Il problema è che il C++ è "nato" completamente retrocompatibile con il C (ci sono alcune incompatibilita dovute agli standard più recenti del C, ma quando fu ideato C++ era retrocompatibile al 100% col C).
E si parla di passare da un linguaggio non ad oggetti ad un linguaggio ad oggetti a tutti gli effetti, ecc. ecc. eppure con C++ si possono ancora usare tutte le librerie standard del C.

Mentre nel passaggio da VB6 a VB.Net è evidente che a Microsoft gli fregava poco della retrocompatibilità, volevano solo qualcosa che somigliasse a VB6 per non impaurire troppo quelli che erano abituati alla sua sintassi.

Secondo me è una gran baggianata l'affermazione:
"Verrà pertanto a scemare, nel corso del tempo, quel divario prestazionale che separa da sempre dispositivi mobile a quelli di più elevate dimensioni, il cui scenario di utilizzo tipico è quello seduti alla scrivania."
Magari un domani i dispositivi mobile avranno prestazioni dei PC attuali, ma non è che i produttori di processori e hardware da oggi si mettono a dormire sugli allori e non innovano + nulla, non siamo mica al capolinea dell'innovazione dei PC fissi....
Sarà che, chi ha scritto l'articolo ama solamente i dispositivi mobile...

Windows con l'8 cercherà di coprire anche questo grande mercato in espansione.