Link alla notizia: http://www.hwfiles.it/news/windows-su-arm-microsoft-ne-mostra-i-dettagli_40683.html

Arrivano, da parte di Microsoft, i dettagli relativi alla versione di Windows 8 per soluzioni ARM: rimane il desktop mode, insieme alla presenza di Office 15

Click sul link per visualizzare la notizia.

il sistema operativo ottimizzato per queste piattaforme integrerà al suo interno la suite Office 15 con accesso a Word, Excel, PowerPoint e OneNote. Queste applicazioni office sono le stesse che sarà possibile trovare sulla versione desktop: trovano conferma perciò quelle indiscrezioni che vedevano la nuova suite Office ottimizzata per l'utilizzo con interfacce touchscreen.

Rimane anche il desktop mode, che garantisce agli utenti di Windows 8 di andare ad accedere al tanto comune esplora risorse, a Internet Explorer 10 e tutte le altre funzionalità. Questo elemento permetterà a Windows di avere un sistema operativo unico e uguale sia per i tablet basati su piattaforma Intel sia per quelli sviluppati su piattaforma ARM.

:O

Gran cosa, magari fosse possibile installarlo anche su device Android :asd: Secondo me potrebbero venire fuori delle belle cose; vi immaginate un Netbook Arm con la batteria che dura giorni :D

Metro style apps in the Windows Store can support both WOA and Windows 8 on x86/64. Developers wishing to target WOA do so by writing applications for the WinRT (Windows APIs for building Metro style apps) using the new Visual Studio 11 tools in a variety of languages, including C#/VB/XAML and Jscript/ HTML5. Native code targeting WinRT is also supported using C and C++, which can be targeted across architectures and distributed through the Windows Store. WOA does not support running, emulating, or porting existing x86/64 desktop apps. Code that uses only system or OS services from WinRT can be used within an app and distributed through the Windows Store for both WOA and x86/64. Consumers obtain all software, including device drivers, through the Windows Store and Microsoft Update or Windows Update.

A quanto pare Windows 8 ARM avrà solo le API WinRT, niente applicazioni old style.

I casi sono 2, o microsoft riesce nel traformare il pc in stupide scatole con SO giocattolo e applicazioni a quadrettoni (nemmeno Apple, che vorrebbe fortemente farlo, ci ha provato. Giusto timidi accenni di convergenza tra Lion e iOS) o Win8 ARM avrà solo la faccia di Win8 x86 a quel punto il desktop se lo potevano risparmiare, sul touch tanto valeva lasciare solo metro.

A quanto pare Windows 8 ARM avrà solo le API WinRT, niente applicazioni old style.

I casi sono 2, o microsoft riesce nel traformare il pc in stupide scatole con SO giocattolo e applicazioni a quadrettoni (nemmeno Apple, che vorrebbe fortemente farlo, ci ha provato. Giusto timidi accenni di convergenza tra Lion e iOS) o Win8 ARM avrà solo la faccia di Win8 x86 a quel punto il desktop se lo potevano risparmiare, sul touch tanto valeva lasciare solo metro.


scusa ma chi te lo ha detto questo?

MS ha deciso di lasciarti tutta l'interfaccia desktop standard che a te servirà soprattutto per la gestione del file system (cosa che riuscirà facile a tutti visto che explorer di base è sempre simile nelle varie versioni), per il resto hai metro e tutte le sue app, non ti basta? Il faceva prima a toglierlo non lo comprendo, ti sto dando un qualcosa di più rispetto alle interfacce standard da tablet e tu mi dici che tanto valeva non metterlo?

la frase che invece riprendi all'inizio è trita e ritrita, ma finchè non si ha in mano un prodotto in cui MS dichiara di mettere l'interfaccia definitiva, non si sa come si può passare tra metro e desktop e quindi snon si sa che rapporto ci sarà tra fissi e mobili

scusa ma chi te lo ha detto questo?

MS ha deciso di lasciarti tutta l'interfaccia desktop standard che a te servirà soprattutto per la gestione del file system (cosa che riuscirà facile a tutti visto che explorer di base è sempre simile nelle varie versioni), per il resto hai metro e tutte le sue app, non ti basta? Il faceva prima a toglierlo non lo comprendo, ti sto dando un qualcosa di più rispetto alle interfacce standard da tablet e tu mi dici che tanto valeva non metterlo?

Parli dell'inusabile interfaccia desktop? Non è la prima volta che viene propinata in ambito touch/tablet e si sa già che fine ha fatto :mbe: Spero che non sia mai da usare.

Che le applicazioni "old style" non avrebbero funzionato credo fosse una cosa ovvia e risaputa.
Ancora non ho capito bene quale sarà invece il destino delle applicazioni .NET, se ci sarà la possibilità di vederle ricompilate e funzionanti anche per ARM.

Mi ha sorpreso la presenza del desktop classico, che a mio parere è una notizia decisamente positiva ed evita di creare quell'abisso che ci si sarebbe potuto aspettare tra la versione x86 e quella ARM.
Certo, i programmini a cui siamo abituati non funzioneranno, ma ho idea che quelli appositi non tarderanno ad arrivare.
Non avremo il "tutto e subito" ma secondo me ci sono buone premesse per un sistema abbastanza competitivo.

scusa ma chi te lo ha detto questo?

MS ha deciso di lasciarti tutta l'interfaccia desktop standard che a te servirà soprattutto per la gestione del file system (cosa che riuscirà facile a tutti visto che explorer di base è sempre simile nelle varie versioni), per il resto hai metro e tutte le sue app, non ti basta? Il faceva prima a toglierlo non lo comprendo, ti sto dando un qualcosa di più rispetto alle interfacce standard da tablet e tu mi dici che tanto valeva non metterlo?

la frase che invece riprendi all'inizio è trita e ritrita, ma finchè non si ha in mano un prodotto in cui MS dichiara di mettere l'interfaccia definitiva, non si sa come si può passare tra metro e desktop e quindi snon si sa che rapporto ci sarà tra fissi e mobili

per me intendeva dire che se tanto le applicazioni classiche nn vanno ma ci sarà per forza bisogno di quelle realizzate appositamente per metro a che serve una versione "pc"? e condivido! sta news è molto striminzita, altrove si riportano maggiori dettagli. woa, windows on arm, anche su pc sarà praticamente come la versione tablet e, office a parte (e neanche tutto), nn gireranno le applicazioni classiche. a che serve un pc del genere? mi pare molto limitato. sicuramente microsoft butta le basi per il futuro ma le applicazioni d'ora in poi dovranno esser realizzate per metro per poter girare sia su normali pc x86 che arm. mha nn saprei, mi sa che finiremo per avere normali pc cn applicazioni da cellulare mentre i programmi di un certo livello difficilmente arriveranno su arm. se devo farmi un piccolo pc a sto punto meglio un atom o meglio ancora la soluzione di amd. se devo prendermi un tablet perché dovrei preferire win8 ad android o ios?

FATNTASTICO!!!!

Questi commenti espandono bene ciò che volevo dire.

Parli dell'inusabile interfaccia desktop? Non è la prima volta che viene propinata in ambito touch/tablet e si sa già che fine ha fatto :mbe: Spero che non sia mai da usare.

Che le applicazioni "old style" non avrebbero funzionato credo fosse una cosa ovvia e risaputa.
Ancora non ho capito bene quale sarà invece il destino delle applicazioni .NET, se ci sarà la possibilità di vederle ricompilate e funzionanti anche per ARM.


Per .NET dipende tutto da che .NET VM implementerà MS, in realtà moltissime applicazioni sarebbero tagliate fuori comunque, non è raro che in .NET si ricorra a P/Invoke e ad accedere direttamente alle API Win32, che non saranno presenti su ARM.

per me intendeva dire che se tanto le applicazioni classiche nn vanno ma ci sarà per forza bisogno di quelle realizzate appositamente per metro a che serve una versione "pc"? e condivido! sta news è molto striminzita, altrove si riportano maggiori dettagli. woa, windows on arm, anche su pc sarà praticamente come la versione tablet e, office a parte (e neanche tutto), nn gireranno le applicazioni classiche. a che serve un pc del genere? mi pare molto limitato. sicuramente microsoft butta le basi per il futuro ma le applicazioni d'ora in poi dovranno esser realizzate per metro per poter girare sia su normali pc x86 che arm. mha nn saprei, mi sa che finiremo per avere normali pc cn applicazioni da cellulare mentre i programmi di un certo livello difficilmente arriveranno su arm. se devo farmi un piccolo pc a sto punto meglio un atom o meglio ancora la soluzione di amd. se devo prendermi un tablet perché dovrei preferire win8 ad android o ios?
Quoto, non vedo l'utilità dell'intefaccia desktop su un tablet che può lanciare solo app metro, ne di un PC arm che non può lanciare applicazioni classiche. L'unico senso è nei tablet x86 (se mai ne faranno), ma nessuno ha mai detto di eliminare metro per le interfacce touch.

per me intendeva dire che se tanto le applicazioni classiche nn vanno ma ci sarà per forza bisogno di quelle realizzate appositamente per metro a che serve una versione "pc"? e condivido! sta news è molto striminzita, altrove si riportano maggiori dettagli. woa, windows on arm, anche su pc sarà praticamente come la versione tablet e, office a parte (e neanche tutto), nn gireranno le applicazioni classiche. a che serve un pc del genere? mi pare molto limitato. sicuramente microsoft butta le basi per il futuro ma le applicazioni d'ora in poi dovranno esser realizzate per metro per poter girare sia su normali pc x86 che arm. mha nn saprei, mi sa che finiremo per avere normali pc cn applicazioni da cellulare mentre i programmi di un certo livello difficilmente arriveranno su arm. se devo farmi un piccolo pc a sto punto meglio un atom o meglio ancora la soluzione di amd. se devo prendermi un tablet perché dovrei preferire win8 ad android o ios?
detto così lo capisco meglio, cerco di risponderti per quel poco che posso,
innanzitutto MS ha il potere per convincere i grandi a abbandonare win32 in favore di winRT e quindi rendere le applicazioni multipiattattaforma, inoltre, con la base di .NET, è possibile ricompilare (in teoria senza troppi problemi) tutti i software scritti con quel linguaggio e eventuali porting di applicazioni non troppo complesse non dovrebbe essere difficile, per quelle più complesse, si spera che MS sganci e costringa chi di dovere, come detto sopra, a far realizzare le nuove applicazioni come si deve

@nickmot
aggiungo qui che non avevo visto il tuo messaggio
una cosa è dire che per te è inutile, nessuno ti costringe a usarla, e poi bisogna vedere sempre come metro e l'interfaccia desktop si integreranno. Per MS cmq serve principalmente per un motivo, secondo me, convincere la gente a comprare i suoi tablet perchè si troveranno in un ambiente molto simile al proprio PC

detto così lo capisco meglio, cerco di risponderti per quel poco che posso,
innanzitutto MS ha il potere per convincere i grandi a abbandonare win32 in favore di winRT e quindi rendere le applicazioni multipiattattaforma, inoltre, con la base di .NET, è possibile ricompilare (in teoria senza troppi problemi) tutti i software scritti con quel linguaggio e eventuali porting di applicazioni non troppo complesse non dovrebbe essere difficile, per quelle più complesse, si spera che MS sganci e costringa chi di dovere, come detto sopra, a far realizzare le nuove applicazioni come si deve

@nickmot
aggiungo qui che non avevo visto il tuo messaggio
una cosa è dire che per te è inutile, nessuno ti costringe a usarla, e poi bisogna vedere sempre come metro e l'interfaccia desktop si integreranno. Per MS cmq serve principalmente per un motivo, secondo me, convincere la gente a comprare i suoi tablet perchè si troveranno in un ambiente molto simile al proprio PC

Già... ma un con un dispositivo come il transformer che fai?

Oppure un net/ultra/notebook con ARM? ;)

Gran cosa avere l'explorer. Quello che non mi piace è la grafica dell'interfaccia desktop. L'hanno fatta spigolosa per renderla simlare alla metro ma son due cose diverse. Non mi piace molto. Anche qell'azzurrino scolorito che da 7 ha preso posto come colore delle barre...

detto così lo capisco meglio, cerco di risponderti per quel poco che posso,
innanzitutto MS ha il potere per convincere i grandi a abbandonare win32 in favore di winRT e quindi rendere le applicazioni multipiattattaforma, inoltre, con la base di .NET, è possibile ricompilare (in teoria senza troppi problemi) tutti i software scritti con quel linguaggio e eventuali porting di applicazioni non troppo complesse non dovrebbe essere difficile, per quelle più complesse, si spera che MS sganci e costringa chi di dovere, come detto sopra, a far realizzare le nuove applicazioni come si deve

@nickmot
aggiungo qui che non avevo visto il tuo messaggio
una cosa è dire che per te è inutile, nessuno ti costringe a usarla, e poi bisogna vedere sempre come metro e l'interfaccia desktop si integreranno. Per MS cmq serve principalmente per un motivo, secondo me, convincere la gente a comprare i suoi tablet perchè si troveranno in un ambiente molto simile al proprio PC
se ha fatto tanta "fatica" microsoft con office figuriamoci gli altri! cmq sicuramente un futuro le cose andranno meglio ma secondo ci si concentrerà maggiormente sull'interfaccia metro e di conseguenza anche su pc ci ritroveremo a usare tante applicazioni stile smartphone :stordita: nn ce la vedo proprio l'interfaccia metro su pc, mentre mi pare ottima su dispositivi touch!
Ora è da vedere se i tablet cn cpu intel avranno limitazioni simili o se potranno eseguire senza problemi le applicazioni "classiche"! sarebbe un vantaggio enorme per le soluzioni intel (e si spera amd) anche se a costo di un "po'" di autonomia!!

Trovo queste notizie molto positive!
Il desktop per ARM anche solo per nei limiti di IE10, Explorer e Office credo sia utilissimo. Ovvio ci saranno app Office per Metro limitate nell'utilizzo e quindi verrà bene la versione desktop più completa per apportare modifiche più pesanti... e sarà già compresa.
Non è detto poi che Ms non estenda il codice nativo di Win32 anche per altri sviluppatori... anche se questo è da vedere.
Anche se l'app Desktop non sarà di facile utilizzo con il touch nulla vieterà di usare un mouse e di avere un'esperienza completa anche su tablet in questo modo.

Intel e Microsoft comunque stanno spingendo molto l'acceleratore sui tablet x86 che sicuramente saranno pronti per l'inverno. li si avranno quindi anche app Classic Win32.

forse è un problema del video o del mio flash player, ma sembra bello scattoso di brutto eh? a voi no? :stordita:

Già... ma un con un dispositivo come il transformer che fai?

Oppure un net/ultra/notebook con ARM? ;)

Gran cosa avere l'explorer. Quello che non mi piace è la grafica dell'interfaccia desktop. L'hanno fatta spigolosa per renderla simlare alla metro ma son due cose diverse. Non mi piace molto. Anche qell'azzurrino scolorito che da 7 ha preso posto come colore delle barre...

se ha fatto tanta "fatica" microsoft con office figuriamoci gli altri! cmq sicuramente un futuro le cose andranno meglio ma secondo ci si concentrerà maggiormente sull'interfaccia metro e di conseguenza anche su pc ci ritroveremo a usare tante applicazioni stile smartphone :stordita: nn ce la vedo proprio l'interfaccia metro su pc, mentre mi pare ottima su dispositivi touch!
Ora è da vedere se i tablet cn cpu intel avranno limitazioni simili o se potranno eseguire senza problemi le applicazioni "classiche"! sarebbe un vantaggio enorme per le soluzioni intel (e si spera amd) anche se a costo di un "po'" di autonomia!!

ma infatti per casi come il trasformer o i futuri armbook, si spera che MS abbia costretto a utilizzare le nuove api.
una curiosità zephir, della fatica dove hai letto? Che magari trovo anche qualche info sulle limitazioni di office che vorrei approfondire il discorso.
Cmq che MS abbia faticato, penso dipenda pure dal fatto che sta ancora testando winrt, mentre gli altri si trovano dei framework già completi e stabili

ma infatti per casi come il trasformer o i futuri armbook, si spera che MS abbia costretto a utilizzare le nuove api.
una curiosità zephir, della fatica dove hai letto? Che magari trovo anche qualche info sulle limitazioni di office che vorrei approfondire il discorso.
Cmq che MS abbia faticato, penso dipenda pure dal fatto che sta ancora testando winrt, mentre gli altri si trovano dei framework già completi e stabili
da diverse notizie sull'argomento dove si diceva che microsoft lavorara appunto alla versione per ARM ma era un bel lavoro e nn davano neanche la cosa per certa! alla fine ce l'hanno fatta ma nn portando tutto il pacchetto ma solo i programmi più usati.

Suvvia sono certo che se non sarà MS ci saranno programmatori capaci a realizzare un supporto per l'emulazione del codice x86 sotto ARM. Magari non si riuscirà a far girare tutto, ma scommetto che qualcuno non vedrebbe l'ora di dire "sono riuscito a farci girare sopra Crysis" :D

Dunque si profila il solo supporto per WinRT... questo signfica l'eventuale abbandono di Win32, un passo epocale per chi sviluppa.

WinRT consentirà di programmare nativamente secondo un paradigma object oriented (win32 sono api pure C).

I programmi .NET invece, salvo casi particolari (ad esempio uso di librerie native), gireranno comunque senza bisogno di essere ricompilati.

Eventuale abbandono di Win32? Si sta parlando di ARM... mentre Intel sta studiando x86 a bassissimo consumo...

Le soluzioni per l'emulazione di x86 sarebbero dispendiose sia in fatto di consumi sia di prestazioni, non è detto che il risultato finale sarebbe comunque decente...

da diverse notizie sull'argomento dove si diceva che microsoft lavorara appunto alla versione per ARM ma era un bel lavoro e nn davano neanche la cosa per certa! alla fine ce l'hanno fatta ma nn portando tutto il pacchetto ma solo i programmi più usati.

Eppure al CES 2011 (se non sbaglio) hanno presentato una versione di WOA che nonostante usasse la GUI di Win7 riusciva ad eseguire perfettamente Office 2010, girando su ARM

Suvvia sono certo che se non sarà MS ci saranno programmatori capaci a realizzare un supporto per l'emulazione del codice x86 sotto ARM. Magari non si riuscirà a far girare tutto, ma scommetto che qualcuno non vedrebbe l'ora di dire "sono riuscito a farci girare sopra Crysis" :D

L'emulazione di un'architettura come x86 è molto dispendiosa in termini di risorse, penso sia difficile che la facciano :D

Se non sbaglio le soluzioni adottate da Apple durante il passaggio da 68k a PPC e da PPC a x86 erano proprio layer di emulazione per la compatibilità delle vecchie applicazioni, accompagnate da eseguibili contenenti codice per entrambe le architetture, ma le prestazioni erano piuttosto scarse... Difficilmente MS adotterà la stessa strada...

Sarà interessante sapere quanto sarà supportato .NET nell'ambiente desktop su ARM (P/Invoke a parte)

Eppure al CES 2011 (se non sbaglio) hanno presentato una versione di WOA che nonostante usasse la GUI di Win7 riusciva ad eseguire perfettamente Office 2010, girando su ARM

sarà stata una presentazione preparata per l'occasione :sofico:

sarà stata una presentazione preparata per l'occasione :sofico:

Beh, ovviamente era preparata per l'occasione :D
Comunque, se non sbaglio, il tizio (non ricordo chi :D) che sul palco presentava questi sistemi insieme a Ballmer ha detto che avevano semplicemente ricompilato Office:

ecco il video: http://youtu.be/rvzJmRBS84w

Beh, ovviamente era preparata per l'occasione :D
Comunque, se non sbaglio, il tizio (non ricordo chi :D) che sul palco presentava questi sistemi insieme a Ballmer ha detto che avevano semplicemente ricompilato Office:

ecco il video: http://youtu.be/rvzJmRBS84w
immaginavo :sofico: ma chissà che prestazioni potrebbe mai avere nell'uso quotidiano office realizzato così su arm!! Anche sul nokia n900 (quello con maemo) grazie a easydebian si riesce ad avere opeoffice, tale e quale quello per pc però le prestazioni sn quello che sono :D

immaginavo :sofico: ma chissà che prestazioni potrebbe mai avere nell'uso quotidiano office realizzato così su arm!! Anche sul nokia n900 (quello con maemo) grazie a easydebian si riesce ad avere opeoffice, tale e quale quello per pc però le prestazioni sn quello che sono :D

L'n900 ha un OMAP3430, che è composto da una PowerVR SGX530 e da un A8 a 600 MHz, mentre la demo con powerpoint girava su un Tegra 2, e il più scarso Tegra 2 ha due A9 a 1GHz ;)

Powerpoint è accelerato in hardware, e Tegra 2 è supportato per questo, mentre openoffice non credo lo sia :D

L'n900 ha un OMAP3430, che è composto da una PowerVR SGX530 e da un A8 a 600 MHz, mentre la demo con powerpoint girava su un Tegra 2, e il più scarso Tegra 2 ha due A9 a 1GHz ;)

Powerpoint è accelerato in hardware, e Tegra 2 è supportato per questo, mentre openoffice non credo lo sia :D
si certamente i nuovi processori sn molto più potenti ma siamo ancora lontani dai un intel tipo i3 (senza citare i5 o i7). Poi vedi, dubito fortemente che "semplicemente" ricompilando da x86 ad arm si riesca ad avere l'accelerazione in hardware per powerpoint anche su un tegra2!
in ogni caso il "grosso" è adattare l'interfaccia grafica, fosse stata una cosa semplice penso che microsoft avrebbe mostrato direttamente la versione finale di office per arm e con tutti i programmi del pacchetto completo :D

si certamente i nuovi processori sn molto più potenti ma siamo ancora lontani dai un intel tipo i3 (senza citare i5 o i7). Poi vedi, dubito fortemente che "semplicemente" ricompilando da x86 ad arm si riesca ad avere l'accelerazione in hardware per powerpoint anche su un tegra2!
in ogni caso il "grosso" è adattare l'interfaccia grafica, fosse stata una cosa semplice penso che microsoft avrebbe mostrato direttamente la versione finale di office per arm e con tutti i programmi del pacchetto completo :D

Non proprio, avendo dei driver compatibili DirectX, e portando lo stack DirectX ovviamente, il grosso è già fatto (ci sono "solo" da scrivere i driver)

Comunque, che intendi con "il grosso è adattare l'interfaccia grafica"? Intendi "convertire" tutte le chiamate alle API Win32 necessarie per disegnarla? Non so come abbiano fatto, ma la mia ipotesi è che in WOA sia presente una versione "ARM" delle Win32, o qualcosa del genere... ovviamente sono solo (fumose) ipotesi mie :D

Non proprio, avendo dei driver compatibili DirectX, e portando lo stack DirectX ovviamente, il grosso è già fatto (ci sono "solo" da scrivere i driver)

Comunque, che intendi con "il grosso è adattare l'interfaccia grafica"? Intendi "convertire" tutte le chiamate alle API Win32 necessarie per disegnarla? Non so come abbiano fatto, ma la mia ipotesi è che in WOA sia presente una versione "ARM" delle Win32, o qualcosa del genere... ovviamente sono solo (fumose) ipotesi mie :D
no dico che il grosso del lavoro che ha fatto microsoft per realizzare la versione per ARM ha riguardato la nuova interfaccia, cioè riadattare office a metro oltre a qualche "ottimizzazione"! poi nn so se per caso office usa anche qualche istruzione presente sui proci intel o amd, tipo SSE per intenderci, ma penso proprio di si! su arm non ci sono quindi ricompilando devi farne a meno oppure realizzare qualcosa di analogo usando qualche funzione specifica dei processori arm. qui mi sa che diventa un po' più complicato perché nn tutti hanno lo stesso set di istruzioni, ogni produttore di CPU ha ampi possibilità di personalizzazione e su android ad esempio lo si vede bene. sicuramente la "cerchia" sull'hardware prestabilito serve per evitare proprio questi inconvenienti e poter usare istruzioni comuni. Però rimane il fatto che mi sembra difficile che basti una "semplice" ricompilata da x86 ad arm visto soprattutto che parliamo di programmi abbastanza complessi!

no dico che il grosso del lavoro che ha fatto microsoft per realizzare la versione per ARM ha riguardato la nuova interfaccia, cioè riadattare office a metro oltre a qualche "ottimizzazione"! poi nn so se per caso office usa anche qualche istruzione presente sui proci intel o amd, tipo SSE per intenderci, ma penso proprio di si! su arm non ci sono quindi ricompilando devi farne a meno oppure realizzare qualcosa di analogo usando qualche funzione specifica dei processori arm. qui mi sa che diventa un po' più complicato perché nn tutti hanno lo stesso set di istruzioni, ogni produttore di CPU ha ampi possibilità di personalizzazione e su android ad esempio lo si vede bene. sicuramente la "cerchia" sull'hardware prestabilito serve per evitare proprio questi inconvenienti e poter usare istruzioni comuni. Però rimane il fatto che mi sembra difficile che basti una "semplice" ricompilata da x86 ad arm visto soprattutto che parliamo di programmi abbastanza complessi!

Ma per ricompilare mica si intende convertire le istruzioni x86 nell'equivalente ARM, ci pensa il loro crosscompilatore a generare codice eseguibile per ARM e x86 a partire dallo stesso codice :D

Comunque, l'Office 2010 del CES 2011 e la preview di Office 15 presentata ieri girano nell'ambiente Desktop, non in Metro... semplicemente per Office 15 hanno modificato un po' il ribbon per renderlo più simile a Metro, ma non penso che un loro programmatore ci stia più di 2 ore a fare questa modifica (probabilmente anche meno)

Parli dell'inusabile interfaccia desktop? Non è la prima volta che viene propinata in ambito touch/tablet e si sa già che fine ha fatto :mbe: Spero che non sia mai da usare.

Se guardi il video ti fa vedere come col mouse funzioni l'interfaccia normale, e con il touch funzioni la metro. Penso che sappiano anche loro che l'interfaccia classica fa a cazzotti con i touch.

Dunque si profila il solo supporto per WinRT... questo signfica l'eventuale abbandono di Win32, un passo epocale per chi sviluppa.

WinRT consentirà di programmare nativamente secondo un paradigma object oriented (win32 sono api pure C).

I programmi .NET invece, salvo casi particolari (ad esempio uso di librerie native), gireranno comunque senza bisogno di essere ricompilati.

Penso sia un'evoluzione dovuta oramai :) Cmq io sto ancora aspettando il kernel modulare :) E' già dai tempi in cui 7 era in perM1 che sto aspettando sperando ogni volta sia quella buona :asd: E anche a questo nulla. E mi sa anche al prossimo. Forse mai :asd: o forse non si chiamerà più Windows. Magari si staccherà un ramo come è successo con NT e poi si proseguirà su quello se va bene :)

birmarco, NT è modulare, ora... Con il progetto MinWin, Microsoft è riuscita ad isolare ogni parte del Kernel dal core dello stesso e nel tempo a rendere modulare il suo kernel.. ad oggi si parla adddirittura di utilizzare NT per Windows Phone 8...

Ma per ricompilare mica si intende convertire le istruzioni x86 nell'equivalente ARM, ci pensa il loro crosscompilatore a generare codice eseguibile per ARM e x86 a partire dallo stesso codice :D

Comunque, l'Office 2010 del CES 2011 e la preview di Office 15 presentata ieri girano nell'ambiente Desktop, non in Metro... semplicemente per Office 15 hanno modificato un po' il ribbon per renderlo più simile a Metro, ma non penso che un loro programmatore ci stia più di 2 ore a fare questa modifica (probabilmente anche meno)
ma se il programma sfrutta determinate istruzioni tipo le sse per far meglio qualcosa, ricompilando senza poter sfruttare queste istruzioni il programma va per forza peggio. ci sn diverso programmi che su windows nn vanno proprio se nn hai una cpu cn istruzioni sse. quindi per portare il programma su arm, che già sn più scarse, devi per forza rimediare mettendo mano al codice e sfruttando meglio le istruzioni messe a disposizione da queste cpu. cn i lettori multimediali su android si vede bene sta cosa, ci sn vari codec specifici per sfruttare le istruzioni delle varie cpu tipo tipo Neon!

birmarco, NT è modulare, ora... Con il progetto MinWin, Microsoft è riuscita ad isolare ogni parte del Kernel dal core dello stesso e nel tempo a rendere modulare il suo kernel.. ad oggi si parla adddirittura di utilizzare NT per Windows Phone 8...

Di MinWin lo sapevo ma non sono sicuro che sia veramente modulare. Non vorrei sbagliare ma dovrebbe essere modulare solo in parte. CIoè un ibrido tra il kernel monolitico e quello supermodulare in stile singularity

birmarco, NT è modulare, ora... Con il progetto MinWin, Microsoft è riuscita ad isolare ogni parte del Kernel dal core dello stesso e nel tempo a rendere modulare il suo kernel.. ad oggi si parla adddirittura di utilizzare NT per Windows Phone 8...

Il kernel NT era nato modulare, anzi, era nato come microkernel (tenere solo lo strettamente necessario nel kernel e delegare il resto a task e processi in user mode). :read:

Forse è il caso di ricordare che Windows NT 4.0 (TUTTO il S.O., mica solo il kernel) girava su pc con 16MB di ram e cpu 486 a 25Mhz.
Buona parte delle str... delle problematiche derivano da quello che Microsoft ha poi infilato a forza nel kernel.

Infatti MinWin è stato in primo luogo una enorme operazione di damage control (a forza di aggiunte, si erano venute a creare interdipendenze assurde, driver che per una sola funzione richiedevano il caricamento di roba che poi non serviva ma se ne restava li in memoria, roba che in un S.O. scritto come si deve dovrebbe girare come task user mode che invece girava come thread del kernel ecc. ecc.).

ma se il programma sfrutta determinate istruzioni tipo le sse per far meglio qualcosa, ricompilando senza poter sfruttare queste istruzioni il programma va per forza peggio. ci sn diverso programmi che su windows nn vanno proprio se nn hai una cpu cn istruzioni sse. quindi per portare il programma su arm, che già sn più scarse, devi per forza rimediare mettendo mano al codice e sfruttando meglio le istruzioni messe a disposizione da queste cpu. cn i lettori multimediali su android si vede bene sta cosa, ci sn vari codec specifici per sfruttare le istruzioni delle varie cpu tipo tipo Neon!

Le cpu ARM hanno le loro istruzioni SIMD (come ad esempio le NEON che hai citato), ed è compito del compilatore sfruttarle ;)

E Microsoft ha già un buon compilatore ARM, capace di sfruttare anche l'accelerazione grafica e sicuramente anche le istruzioni SIMD (altrimenti non esisterebbero lo Zune HD, basato su Tegra, e WP7, basato su Snapdragon :D)

Le cpu ARM hanno le loro istruzioni SIMD (come ad esempio le NEON che hai citato), ed è compito del compilatore sfruttarle ;)

E Microsoft ha già un buon compilatore ARM, capace di sfruttare anche l'accelerazione grafica e sicuramente anche le istruzioni SIMD (altrimenti non esisterebbero lo Zune HD, basato su Tegra, e WP7, basato su Snapdragon :D)
si ok, ma non è che se gli do' il codice di un programma fatto per sfruttare le appositamente le SSE il compilatore magicamente "converte" tutto per Neon (o altro) :stordita: Poi mica hanno istruzioni sempre analoghe! Non basta una semplice ricompilatina per passare da un'architettura all'altra se la si vuol sfruttare come si deve!

si ok, ma non è che se gli do' il codice di un programma fatto per sfruttare le appositamente le SSE il compilatore magicamente "converte" tutto per Neon (o altro) :stordita: Poi mica hanno istruzioni sempre analoghe! Non basta una semplice ricompilatina per passare da un'architettura all'altra se la si vuol sfruttare come si deve!
Certo... ottimizzazioni "fini" a parte, necessarie solo per alcuni tipi di software, non penserai davvero di scrivere tu nel codice le istruzioni SIMD per sfruttarle, vero? :D

si ok, ma non è che se gli do' il codice di un programma fatto per sfruttare le appositamente le SSE il compilatore magicamente "converte" tutto per Neon (o altro) :stordita: Poi mica hanno istruzioni sempre analoghe! Non basta una semplice ricompilatina per passare da un'architettura all'altra se la si vuol sfruttare come si deve!

Ma il compito del compilatore è proprio questo :D

Certo... ottimizzazioni "fini" a parte, necessarie solo per alcuni tipi di software, non penserai davvero di scrivere tu nel codice le istruzioni SIMD per sfruttarle, vero? :D

Beh, certi software hanno porzioni di assembly direttamente nel codice per ottimizzare le prestazioni in certi punti, ma non penso sia il caso di office :D

Certo... ottimizzazioni "fini" a parte, necessarie solo per alcuni tipi di software, non penserai davvero di scrivere tu nel codice le istruzioni SIMD per sfruttarle, vero? :D
no ovvio ma se realizzi un software basandoti su certe istruzioni che funzionano in un certo modo ottenendo certe prestazioni nn è mica detto che compilando su un'altra architettura cn altre istruzioni si ottenga lo stesso risultato.

Le applicazioni scritte in WinRT non devono essere necessariamente per Metro.

Metro e' una GUI.
Il Desktop Classico e' una GUI.

In WinRT posso scrivere un'applicativo in modalita' desktop classico, e e'pressoche' certo che molti lo faranno.

Le applicazioni scritte in WinRT non devono essere necessariamente per Metro.

Metro e' una GUI.
Il Desktop Classico e' una GUI.

In WinRT posso scrivere un'applicativo in modalita' desktop classico, e e'pressoche' certo che molti lo faranno.

È la prima volta che sento una cosa simile, ne sei sicuro?

Penso che ne sapremo di più con l'uscita della prossima preview di Visual Studio 11

F-A-N-T-A-S-T-I-C-O.

Un OS unificato per tutti i dispositivi, desktop, notebook, tablet e smartphone. Compatibilita' al 100%, comunicazione senza problemi tra i vari dispositivi (un po' come tra un Macbook e un iPod, se non funziona significa che e' saltato qualcosa di hardware).

Io sono contentissimo di Windows 7 e con Windows 8 saro' al settimo cielo. Manca solo un'ultima cosa: l'abbandono definitivo del registro di sistema.

Per quanto riguarda la versione ARM mi piacerebbe sapere i requisiti minimi, in modo da sapere quanta potenza serve (CPU, se dual core o anche single core e la frequenza), quanta ram (se 512MB sono sufficienti oppure serve almeno 1GB) e quanto spazio su disco occupa. Potro' installarmi Windows 8 sul Desire HD? :ciapet: Magari...

F-A-N-T-A-S-T-I-C-O.

Un OS unificato per tutti i dispositivi, desktop, notebook, tablet e smartphone. Compatibilita' al 100%, comunicazione senza problemi tra i vari dispositivi (un po' come tra un Macbook e un iPod, se non funziona significa che e' saltato qualcosa di hardware).

Io sono contentissimo di Windows 7 e con Windows 8 saro' al settimo cielo. Manca solo un'ultima cosa: l'abbandono definitivo del registro di sistema.

Per quanto riguarda la versione ARM mi piacerebbe sapere i requisiti minimi, in modo da sapere quanta potenza serve (CPU, se dual core o anche single core e la frequenza), quanta ram (se 512MB sono sufficienti oppure serve almeno 1GB) e quanto spazio su disco occupa. Potro' installarmi Windows 8 sul Desire HD? :ciapet: Magari...

Beh, i primi tempi (ai tempi della build 7650, considera che Win7 SP1 è la build 7601) debuggavano su smartphone windows mobile visto che non c'erano ancora molti tablet ARM quindi le probabilità ci sono... confida in XDA :D

F-A-N-T-A-S-T-I-C-O.

Un OS unificato per tutti i dispositivi, desktop, notebook, tablet e smartphone. Compatibilita' al 100%, comunicazione senza problemi tra i vari dispositivi (un po' come tra un Macbook e un iPod, se non funziona significa che e' saltato qualcosa di hardware).

Ne dubito, in Microsoft hanno sempre di questi momenti "multipiattaforma", ma poi inevitabilmente il lato aziendale peggiore prevale e succedono cose ai confini della realtà.

Il kernel NT era nato supportando ben 4 cpu diverse (x86, Alpha , PowerPC e Sparc) poi il tutto si ridusse velocemente a solo x86 ed Alpha (limitato a 32bit mentre era un 64bit nativo) e quando venne il momento di supportare anche l'Itanium furono dolori.
Il motivo era che non avevano minimamente considerato il porting a 64bit nonostante una delle prime cpu supportate da NT lo fosse ed il fatto che poi "avevano lasciato perdere la portabilità" (inserendo troppo codice che implicitamente era fatto per girare solo su x86).

Poi c'è stato il momento di Windows CE (pensato per essere "il Windows per i PDA ed i sistemi embedded"), pure esso nato multipiattaforma e che proprio per questo motivo "è stato lasciato indietro" perchè ogni cosa implementata nella versione desktop doveva essere reimplementata quasi da zero per CE (e spesso omettendo pure roba giudicata superflua da MS ma che complicava poi la vita agli sviluppatori che su CE dovevano reimplementarla a modo loro).

Poi c'e' stato il momento di .Net ... che a causa delle troppe dipendenze da win32 (vedere l'uso ed abuso di P/Invoke) è parzialmente multipiattaforma solo tra S.O. Microsoft ed a patto di installare il runtime giusto.

Ora, dopo tutti i casini precedenti )se sono vere le notizie filtrate sulla versione per ARM) sembrano ritornati alla strategia iniziale di NT (un kernel per tutti, ecc. ecc.) ma anche se fosse vero, visti i precedenti viene da chiedersi quanto dura.

Ne dubito, in Microsoft hanno sempre di questi momenti "multipiattaforma", ma poi inevitabilmente il lato aziendale peggiore prevale e succedono cose ai confini della realtà.

Il kernel NT era nato supportando ben 4 cpu diverse (x86, Alpha , PowerPC e Sparc) poi il tutto si ridusse velocemente a solo x86 ed Alpha (limitato a 32bit mentre era un 64bit nativo) e quando venne il momento di supportare anche l'Itanium furono dolori.
Il motivo era che non avevano minimamente considerato il porting a 64bit nonostante una delle prime cpu supportate da NT lo fosse ed il fatto che poi "avevano lasciato perdere la portabilità" (inserendo troppo codice che implicitamente era fatto per girare solo su x86).

Poi c'è stato il momento di Windows CE (pensato per essere "il Windows per i PDA ed i sistemi embedded"), pure esso nato multipiattaforma e che proprio per questo motivo "è stato lasciato indietro" perchè ogni cosa implementata nella versione desktop doveva essere reimplementata quasi da zero per CE (e spesso omettendo pure roba giudicata superflua da MS ma che complicava poi la vita agli sviluppatori che su CE dovevano reimplementarla a modo loro).

Poi c'e' stato il momento di .Net ... che a causa delle troppe dipendenze da win32 (vedere l'uso ed abuso di P/Invoke) è parzialmente multipiattaforma solo tra S.O. Microsoft ed a patto di installare il runtime giusto.

Ora, dopo tutti i casini precedenti )se sono vere le notizie filtrate sulla versione per ARM) sembrano ritornati alla strategia iniziale di NT (un kernel per tutti, ecc. ecc.) ma anche se fosse vero, visti i precedenti viene da chiedersi quanto dura.

Buttare nel cesso tutto solo perche' "non hanno voglia" e' un suicidio. Ormai la gente si aspetta un Windows 8 che giri su x86 e su ARM. Inoltre c'e' anche Windows Phone 8 che in pratica e' Windows 8 per ARM.

Non so quanti server ci siano con Itanium, ma Alpha, PowerPC e Sparc non le ho quasi nemmeno sentite nominare... Se il tempo di sviluppo era troppo lungo e dispendioso, per quei 4 pc al mondo con questi processori contro i milioni con x86, direi che non hanno fatto niente di sbagliato. Ci volevano provare, hanno visto che era una cosa inutilmente dispendiosa e hanno lasciato perdere.

ARM e' ovunque tra tablet e smartphone, inoltre con Asus si e' visto che a molti non serve avere un processore x86 per avere un "notebook" (il tablet + docking station) e quello che preme di piu' e' l'autonomia. Un tablet con docking station che lo trasforma in portatile, con processore ARM e Windows 8 sarebbe praticamente il sogno di molti.

E poi gia' hanno rilasciato la versione developer per ARM, buttare via tutto ora e' come prendersi a schiaffi in faccia da soli.


L'unico mio dubbio e': ma la "cd-key" sara' diversa? Ovvero le chiavi per x86 e per ARM saranno incompatibili tra di loro?

Te pareva che sto sito schifoso non funzionasse, per l'ennesima volta...

Post doppio, ovviamente...

...e addirittura triplo. E ho avuto difficolta' pure a modificare sti 2 post...

Non so quanti server ci siano con Itanium, ma Alpha, PowerPC e Sparc non le ho quasi nemmeno sentite nominare... Se il tempo di sviluppo era troppo lungo e dispendioso, per quei 4 pc al mondo con questi processori contro i milioni con x86, direi che non hanno fatto niente di sbagliato. Ci volevano provare, hanno visto che era una cosa inutilmente dispendiosa e hanno lasciato perdere.


Alpha, PowerPC e Sparc non erano architetture tanto peregrine, anzi per molti versi erano superiori agli x86. Anche la loro diffusione inoltre non era tale da giustificare un'eliminazione solo per ragioni numeriche.

Buttare nel cesso tutto solo perche' "non hanno voglia" e' un suicidio. Ormai la gente si aspetta un Windows 8 che giri su x86 e su ARM. Inoltre c'e' anche Windows Phone 8 che in pratica e' Windows 8 per ARM.

Non so quanti server ci siano con Itanium, ma Alpha, PowerPC e Sparc non le ho quasi nemmeno sentite nominare... Se il tempo di sviluppo era troppo lungo e dispendioso, per quei 4 pc al mondo con questi processori contro i milioni con x86, direi che non hanno fatto niente di sbagliato. Ci volevano provare, hanno visto che era una cosa inutilmente dispendiosa e hanno lasciato perdere.

ARM e' ovunque tra tablet e smartphone, inoltre con Asus si e' visto che a molti non serve avere un processore x86 per avere un "notebook" (il tablet + docking station) e quello che preme di piu' e' l'autonomia. Un tablet con docking station che lo trasforma in portatile, con processore ARM e Windows 8 sarebbe praticamente il sogno di molti.

E poi gia' hanno rilasciato la versione developer per ARM, buttare via tutto ora e' come prendersi a schiaffi in faccia da soli.


L'unico mio dubbio e': ma la "cd-key" sara' diversa? Ovvero le chiavi per x86 e per ARM saranno incompatibili tra di loro?
mha, qua finora è stato detto che per passare da un'architettura a un'altra basta una semplice ricompilata :sofico: fosse stato così semplice avrebbero supportato più piattaforme da tempo e invece nn è affatto così!
anche adesso nn sarà così, windows x86 e arm rimangono separati, uniti solo tramite winRT, quindi applicazioni nuove!
Inoltre come dice anche la notizia nn potrai assemblarti il tuo bel computer cn arm e comprare la licenza a parte! o compri tutto già pronto e fatto o nisba! Io continuo a vedere una versione per windows su pc, una per smartphone e una terza per tablet con arm :fagiano: in futuro magari convergerà tutto su un unico sistema operativo, ma per ora nn si sembra così

mha, qua finora è stato detto che per passare da un'architettura a un'altra basta una semplice ricompilata :sofico: fosse stato così semplice avrebbero supportato più piattaforme da tempo e invece nn è affatto così!
anche adesso nn sarà così, windows x86 e arm rimangono separati, uniti solo tramite winRT, quindi applicazioni nuove!
Inoltre come dice anche la notizia nn potrai assemblarti il tuo bel computer cn arm e comprare la licenza a parte! o compri tutto già pronto e fatto o nisba! Io continuo a vedere una versione per windows su pc, una per smartphone e una terza per tablet con arm :fagiano: in futuro magari convergerà tutto su un unico sistema operativo, ma per ora nn si sembra così

Semmai due versioni, una per x86 e una per ARM. Tra uno smartphone e un tablet cambia veramente poco.

Ne dubito, in Microsoft hanno sempre di questi momenti "multipiattaforma", ma poi inevitabilmente il lato aziendale peggiore prevale e succedono cose ai confini della realtà.

Il kernel NT era nato supportando ben 4 cpu diverse (x86, Alpha , PowerPC e Sparc) poi il tutto si ridusse velocemente a solo x86 ed Alpha (limitato a 32bit mentre era un 64bit nativo) e quando venne il momento di supportare anche l'Itanium furono dolori.
Il motivo era che non avevano minimamente considerato il porting a 64bit nonostante una delle prime cpu supportate da NT lo fosse ed il fatto che poi "avevano lasciato perdere la portabilità" (inserendo troppo codice che implicitamente era fatto per girare solo su x86).

Poi c'è stato il momento di Windows CE (pensato per essere "il Windows per i PDA ed i sistemi embedded"), pure esso nato multipiattaforma e che proprio per questo motivo "è stato lasciato indietro" perchè ogni cosa implementata nella versione desktop doveva essere reimplementata quasi da zero per CE (e spesso omettendo pure roba giudicata superflua da MS ma che complicava poi la vita agli sviluppatori che su CE dovevano reimplementarla a modo loro).

Poi c'e' stato il momento di .Net ... che a causa delle troppe dipendenze da win32 (vedere l'uso ed abuso di P/Invoke) è parzialmente multipiattaforma solo tra S.O. Microsoft ed a patto di installare il runtime giusto.

Ora, dopo tutti i casini precedenti )se sono vere le notizie filtrate sulla versione per ARM) sembrano ritornati alla strategia iniziale di NT (un kernel per tutti, ecc. ecc.) ma anche se fosse vero, visti i precedenti viene da chiedersi quanto dura.

Verissimo quello che dici, ma ora c'è un aspetto da considerare, la diffusione di x86 rispetto alle piattaforme che hai menzionato era quasi la totalità dei (PC in ogni casa), le altre piattaforme erano perlopiù workstation con percentuali infime, ARM è dappertutto, non credo che siano così pazzi da lavorare su questa piattaforma così diffusa per abbandonarla, veramente sarebbero da ricovero.

Semmai due versioni, una per x86 e una per ARM. Tra uno smartphone e un tablet cambia veramente poco.
per quello che si sa adesso la versione smartphone sarà cmq ben diversa da quella per tablet! Per WP8 si parla di un kernel "alleggerito" dove gireranno solo applicazioni per WP! La versione tablet invece sarà uguale a quella pc

Verissimo quello che dici, ma ora c'è un aspetto da considerare, la diffusione di x86 rispetto alle piattaforme che hai menzionato era quasi la totalità dei (PC in ogni casa), le altre piattaforme erano perlopiù workstation con percentuali infime, ARM è dappertutto, non credo che siano così pazzi da lavorare su questa piattaforma così diffusa per abbandonarla, veramente sarebbero da ricovero.
arm è sempre stato dappertutto! e infatti microsoft aveva (ha) windows CE. la differenza è che ora arm si sta affacciando anche in ambito "desktop" (anche se la vedo ancora un po' dura) e server! secondo me per un bel po' di tempo i processori arm nn usciranno oltre al recenti dei tablet, soprattutto se le versioni di Windows On Arm manterranno queste "restrizioni". A me tutto questo fa pensare che microsoft nn crede che intel possa mai proporre (se nn in tempi ancora più lunghi) valide alternative ad ARM in ambito mobile, altrimenti nn avrebbe mai fatto un passo del genere! :fagiano:

F-A-N-T-A-S-T-I-C-O.

Un OS unificato per tutti i dispositivi, desktop, notebook, tablet e smartphone. Compatibilita' al 100%, comunicazione senza problemi tra i vari dispositivi (un po' come tra un Macbook e un iPod, se non funziona significa che e' saltato qualcosa di hardware).

Io sono contentissimo di Windows 7 e con Windows 8 saro' al settimo cielo. Manca solo un'ultima cosa: l'abbandono definitivo del registro di sistema.

Per quanto riguarda la versione ARM mi piacerebbe sapere i requisiti minimi, in modo da sapere quanta potenza serve (CPU, se dual core o anche single core e la frequenza), quanta ram (se 512MB sono sufficienti oppure serve almeno 1GB) e quanto spazio su disco occupa. Potro' installarmi Windows 8 sul Desire HD? :ciapet: Magari...

Il registro è la soluzione migliore rispetto a quella dei file ini dispersi per il disco

Il registro è la soluzione migliore rispetto a quella dei file ini dispersi per il disco

:eek: :eek: :eek:

:cry: :cry: :cry:

PS i file di configurazione in genere sono raggruppati nella stessa cartella e non in giro per il mondo

Non so quanti server ci siano con Itanium, ma Alpha, PowerPC e Sparc non le ho quasi nemmeno sentite nominare... Se il tempo di sviluppo era troppo lungo e dispendioso, per quei 4 pc al mondo con questi processori contro i milioni con x86, direi che non hanno fatto niente di sbagliato. Ci volevano provare, hanno visto che era una cosa inutilmente dispendiosa e hanno lasciato perdere.

le altre piattaforme erano perlopiù workstation con percentuali infime, ARM è dappertutto, non credo che siano così pazzi da lavorare su questa piattaforma così diffusa per abbandonarla, veramente sarebbero da ricovero.

Vorrei far notare ad entrambi che Linux (e tutto il software che ci gira sopra) continua a supportare tutti i processori supportati ora ed in passato dai kernel NT, tutti i processori supportati ora ed in passato da Windows CE ed anche qualcuno di più.
Inoltre lo fa con risorse inferiori (sia in termini di tempo, persone e risorse varie) a quelle che Microsoft dedica alla sola versione desktop e se considerate quando software ci gira sopra per semplice ricompilazione riescono ad avere una retrocompatibilità spettacolare rispetto a Windows (e con una mole di software comparabile).

La differenza sta tutta nel metodo e nella mentalità che c'è dietro.

Ripeto, anche ora Microsoft con Windows 8 "sta reinventando la ruota ARM" quando da più di un decennio avevano il kernel Windows CE per ARM.
Il motivo è che si sono svaccati di brutto ed hanno trascurato il lato embedded e mobile e poi si sono accorti che oltre ad aver fatto varie cavolate mostruose ora devono reinventare da capo tutto (e come si è visto con WP7, ripetendo pure i loro errori precedenti e quelli fatti dalla concorrenza). :doh:

OK, anche se mi par strano le app .NET vecchie non andranno su ARM :confused:
Quindi niente Office senza ricompilazione, insomma!! E su arm non va il mulo se qalcuno non lo compila :cry:

Avevo capito che fosse un linguaggio interpretato alla JAVA, no? Quindi? Come fa a non girare su ARM :confused: ?

In ogni caso se io con VS11 un'applicazione usando le API WinRT cosa ottengo? Un unico eseguibile .NET che va sia su X86 e sia su ARM? Due eseguibili dallo stesso sorgente pronti per andare su X86 e su ARM? O cosa :cry: ?

Vorrei far notare ad entrambi che Linux (e tutto il software che ci gira sopra) continua a supportare tutti i processori supportati ora ed in passato dai kernel NT, tutti i processori supportati ora ed in passato da Windows CE ed anche qualcuno di più.


Quindi? Cosa c'entra con la news?


Inoltre lo fa con risorse inferiori (sia in termini di tempo, persone e risorse varie) a quelle che Microsoft dedica alla sola versione desktop e se considerate quando software ci gira sopra per semplice ricompilazione riescono ad avere una retrocompatibilità spettacolare rispetto a Windows (e con una mole di software comparabile).

La differenza sta tutta nel metodo e nella mentalità che c'è dietro.


E questo chi te lo dice? Esistono fior di persone che lavorano in quell'ambito e vengono comunque pagate, senza contare i vari finanziamenti da parte di alcuni big del settore, vedi IBM.

Relativamente al discorso della ricompilazione dipende tutto dal codice che è stato scritto, comunque mi sembra che le architetture alternative ad x86 abbiano molti meno pacchetti disponibili.


Ripeto, anche ora Microsoft con Windows 8 "sta reinventando la ruota ARM" quando da più di un decennio avevano il kernel Windows CE per ARM.
Il motivo è che si sono svaccati di brutto ed hanno trascurato il lato embedded e mobile e poi si sono accorti che oltre ad aver fatto varie cavolate mostruose ora devono reinventare da capo tutto (e come si è visto con WP7, ripetendo pure i loro errori precedenti e quelli fatti dalla concorrenza). :doh:

1985: un PC su ogni scrivania, questo era il motto Microsoft e direi che la sua missione l'ha ben completata.

Fino a prova contraria anche oggi su desktop ARM ha una quota praticamente nulla.

Laptop con ARM ancora non se ne vedono, eccezion fatta per quei tablet con tastiera, che comunque si contano sulle dita di 1 mano.

E comunque anche MS aveva le sue quote mobile, certamente i guadagni all'epoca non erano gli stessi dell'ambito desktop...

Ripeto ciò che ho sempre detto, fino a qualche tempo fa nessuno avrebbe scommesso un euro sul fatto che MS fosse anche solo stata in grado di portare Windows su ARM.

Inoltre nessuno ci pensa ma proprio Windows potrebbe essere il tramite per ARM per entrare nell'ambito desktop.

OK, anche se mi par strano le app .NET vecchie non andranno su ARM :confused:


Beh questo è tutto da vedere, se MS metterà a disposizione le vecchie versioni dei framework potrebbero girare tranquillamente.


Quindi niente Office senza ricompilazione, insomma!! E su arm non va il mulo se qalcuno non lo compila :cry:

Avevo capito che fosse un linguaggio interpretato alla JAVA, no? Quindi? Come fa a non girare su ARM :confused: ?


Ma infatti chi te lo ha detto che non gira su ARM? I problemi ce li potrebbero avere solo quelle applicazioni che sfruttano (pesantemente) librerie native, esterne al framework stesso, ma questo è un problema comune con tutte le piattaforme basate su una VM.


In ogni caso se io con VS11 un'applicazione usando le API WinRT cosa ottengo? Un unico eseguibile .NET che va sia su X86 e sia su ARM? Due eseguibili dallo stesso sorgente pronti per andare su X86 e su ARM? O cosa :cry: ?

WinRT sono delle API, punto.

Puoi scegliere di usarle con uno dei linguaggi .NET piuttosto che con C++ nativo o Javascript.

Se usi solo ed esclusivamente le WinRT, per i programmi nativi dovrai semplicemente ricompilare, mentre per i programmi .NET non ce ne sarà bisogno.

Questo sulla carta, non dispongo di un dispositivo ARM per fare le prove...

OK, anche se mi par strano le app .NET vecchie non andranno su ARM :confused:
Quindi niente Office senza ricompilazione, insomma!! E su arm non va il mulo se qalcuno non lo compila :cry:

Avevo capito che fosse un linguaggio interpretato alla JAVA, no? Quindi? Come fa a non girare su ARM :confused: ?

In ogni caso se io con VS11 un'applicazione usando le API WinRT cosa ottengo? Un unico eseguibile .NET che va sia su X86 e sia su ARM? Due eseguibili dallo stesso sorgente pronti per andare su X86 e su ARM? O cosa :cry: ?

Ancora non si sa molto su come si comporterà .NET su arm (probabilmente verrà portato anche lui)

Office è stato ricompilato per ARM :D

.NET è un linguaggio "interpretato" (viene ricompilato al volo), ma non tutti i software girano su .NET, quasi tutti quelli più famosi sono scritti in codice nativo, legato a Win32 e x86.

WinRT != .NET => sono due cose diverse, un eseguibile ottenuto con la versione attuale di VS11 è un'applicazione Metro :D (e non ho ancora ben chiaro se si avranno due eseguibili, un unico eseguibile managed oppure un fat binary come gli eseguibili 68k/PPC o PPC/x86 per mac os!)

Relativamente al discorso della ricompilazione dipende tutto dal codice che è stato scritto, comunque mi sembra che le architetture alternative ad x86 abbiano molti meno pacchetti disponibili.
debian ha gli stessi pacchetti sia per x86, che arm e mi pare pure per altre architetture! ovviamente solo per il codice open source :)

Quindi? Cosa c'entra con la news?
Era una risposta all'obiezione riguardo l'impossibilità di MS di supprotare tutte le architetture, che come avevo già scritto era più una questione di metodo che di mezzi.



E questo chi te lo dice? Esistono fior di persone che lavorano in quell'ambito e vengono comunque pagate, senza contare i vari finanziamenti da parte di alcuni big del settore, vedi IBM.

Infatti ho parlato di tempo, personale e risorse varie e non dei soldi, che sul lato Linux sono difficili da quantificare.


Relativamente al discorso della ricompilazione dipende tutto dal codice che è stato scritto, comunque mi sembra che le architetture alternative ad x86 abbiano molti meno pacchetti disponibili.

Perchè ognuno ricompila e rende disponibile in pacchetti sul repository quello che gli serve, non è che uno ricompila libreoffice per schede industriali powerpc giusto per il gusto di farlo.


1985: un PC su ogni scrivania, questo era il motto Microsoft e direi che la sua missione l'ha ben completata.

Sono passati 26 anni e nel frattempo di cose ne sono successe parecchie e di cantonate Microsoft ne ha prese una bella cifra.
Basta ricordare come al lancio di Windows 95 pensavano che il futuro non sarebbe stato internet ma "Microsoft Network". :ciapet:


Fino a prova contraria anche oggi su desktop ARM ha una quota praticamente nulla.

Ma e' più di una decina d'anni che ARM domina nel settore dei PDA prima ed ora smartphone e tablet, domina nel settore embedded a 32bit, ecc.
Ed a suo tempo Microsoft era partita con tanto entusiasmo con Windows CE (e la sua variante Mobile) ma poi ha finito con il gestirlo male perdendo terreno contro tutti i concorrenti, specialmente nei settori più in crescita e lucrosi. :doh:

Era una risposta all'obiezione riguardo l'impossibilità di MS di supprotare tutte le architetture, che come avevo già scritto era più una questione di metodo che di mezzi.


E' stata una scelta puramente economica. Non volevano perdere tempo e denaro su una piattaforma poco diffusa (nel loro ambito target, quello desktop).

Linux nasce con tutt'altre prerogative rispetto al SO MS.


Infatti ho parlato di tempo, personale e risorse varie e non dei soldi, che sul lato Linux sono difficili da quantificare.


Io parlo anche di quelli, in generale, è difficile quantificare tutto di Linux e le varie distribuzioni, per questo è anche difficilmente paragonabile.


Perchè ognuno ricompila e rende disponibile in pacchetti sul repository quello che gli serve, non è che uno ricompila libreoffice per schede industriali powerpc giusto per il gusto di farlo.

Ribadisco che ciò non c'entra nulla con l'argomento della news


Sono passati 26 anni e nel frattempo di cose ne sono successe parecchie e di cantonate Microsoft ne ha prese una bella cifra.
Basta ricordare come al lancio di Windows 95 pensavano che il futuro non sarebbe stato internet ma "Microsoft Network". :ciapet:


Vabbè da lì in poi non ci volle poi molto a tirare fuori Internet Explorer.

Le cantonate le prendono tutti quando ci si trova in un settore come quello informatico dove un giorno va di moda una cosa ed il giorno dopo è da buttare.

MS continua comunque ad essere sulla cresta dell'onda nel suo settore principale, quello del software.

Certamente come tutti i colossi, sono grossi e lenti a muoversi, mentre piccole startup hanno idee più che valide e sfondano (salvo poi diventare a loro volta altri colossi inamovibili).


Ma e' più di una decina d'anni che ARM domina nel settore dei PDA prima ed ora smartphone e tablet, domina nel settore embedded a 32bit, ecc.
Ed a suo tempo Microsoft era partita con tanto entusiasmo con Windows CE (e la sua variante Mobile) ma poi ha finito con il gestirlo male perdendo terreno contro tutti i concorrenti, specialmente nei settori più in crescita e lucrosi. :doh:

Non lo metto in dubbio, Windows 8 è la risposta a questo, seppure in netto ritardo rispetto alla concorrenza.

MS s'è svegliata tardi, però devo dire da sviluppatore da essere rimasto favorevolmente colpito da WinRT e dall'idea di fondo che MS ha.

Vabbè da lì in poi non ci volle poi molto a tirare fuori Internet Explorer.
purtroppo si :p

MS continua comunque ad essere sulla cresta dell'onda nel suo settore principale, quello del software.
un po' generico e vago! diciamo nel suo settore "consumer desktop" :) negli ultimi anni anche quello delle consolle grazie alla xbox360!

MS s'è svegliata tardi, però devo dire da sviluppatore da essere rimasto favorevolmente colpito da WinRT e dall'idea di fondo che MS ha.
svegliata tardi non direi, c'è da tantissimi anni nel mondo mobile con windows mobile, è che nn ha mai imboccato la strada buona! forse questa è la volta buona :)

MS s'è svegliata tardi, però devo dire da sviluppatore da essere rimasto favorevolmente colpito da WinRT e dall'idea di fondo che MS ha.

C++ forever ed al rogo il CLR di .Net ? :sofico:
Perché è quello il senso di tale mossa in ultima analisi.

.Net, C# ecc. rimarranno ma mi sa che finiranno con il rivestire il ruolo che aveva Visual Basic (pre-.Net) ed il suo runtime.

C++ forever ed al rogo il CLR di .Net ? :sofico:
Perché è quello il senso di tale mossa in ultima analisi.

.Net, C# ecc. rimarranno ma mi sa che finiranno con il rivestire il ruolo che aveva Visual Basic (pre-.Net) ed il suo runtime.

Beh potrai usare WinRT nel linguaggio che più ti aggrada, con l'aggiunta di C++ nativo (che poi è una versione estesa di C++, fortunatamente direi, visto che C++ classico fa un po' schifo :asd: ).

Il bello è proprio questo, ognuno potrà scegliere il linguaggio che preferisce.

Beh potrai usare WinRT nel linguaggio che più ti aggrada, con l'aggiunta di C++ nativo (che poi è una versione estesa di C++, fortunatamente direi, visto che C++ classico fa un po' schifo :asd: ).

Il bello è proprio questo, ognuno potrà scegliere il linguaggio che preferisce.

Il problema è la quantità di funzionalità presenti in .NET e assenti in WinRT (in primis la classe SerialPort, mi sono informato proprio oggi al riguardo perché mi sarebbe servita per un mio progetto) e la quantità di codice già esistente (ok, su può portare facilmente, ma non è proprio la stessa cosa)

Comunque, pare che sia possibile usare classi .NET all'interno di codice WinRT

Il problema è la quantità di funzionalità presenti in .NET e assenti in WinRT (in primis la classe SerialPort, mi sono informato proprio oggi al riguardo perché mi sarebbe servita per un mio progetto) e la quantità di codice già esistente (ok, su può portare facilmente, ma non è proprio la stessa cosa)

La porta seriale si può gestire come un file (infatti con win32 si usava CreateFile, DeviceIOControl, ecc. ecc.).
Nel caso di WinRT si tratta solo di ricomporre un puzzle, nel senso che le funzioni che in win32 erano accorpate in un unica libreria, in certi casi con WinRT sono "sparpagliate" in più interfacce.

Ad esempio invece della funzione win32 DeviceIOControl di kernel32 bisogna usare l'interfaccia IDeviceIoControl che si trova in DeviceAccess.Lib, ecc. ecc.

In pratica tutte le funzionalità di win32 (su cui si appoggiavano le precedenti implementazioni di .Net) sotto WinRT ci sono ancora tutte, sono state solo riorganizzate ed è stato aggiunto dell'altro.

Beh potrai usare WinRT nel linguaggio che più ti aggrada, con l'aggiunta di C++ nativo (che poi è una versione estesa di C++, fortunatamente direi, visto che C++ classico fa un po' schifo :asd: ).

Il bello è proprio questo, ognuno potrà scegliere il linguaggio che preferisce.
un po' come già succedeva su windows mobile per caso? :stordita: ma questo varrà solo per windows 8 "pc" o anche per la versione smartphone e arm?

Credo ci manchi un "pezzo" per comporre il puzzle, se uso le API WinRT sto usando codice "nativo" o sempre CLR/.NET?

Ovvero avrò n eseguibili per tutte le architetture che M$ vorrà supportare (ora sono X86 e ARM... tra 2-3 anni magari s'aggiunge MIPSEL) o un solo eseguibile CLR/.NET?
Che quindi per sua natura dovrà essere eseguito/interpretato per mezzo di una VM?

Io scommetto che sarà così, mi pare strano che proprio ora che diventerebbe importantissimo avere eseguibili che gira su più architetture senza ricompilazione si butti a mare .NET :rolleyes:

WinRT è solo una API basata su .NET e scritta per la CPU "virtuale" CLR come Win32 era, in fondo, basata su DOS/X86...

La porta seriale si può gestire come un file (infatti con win32 si usava CreateFile, DeviceIOControl, ecc. ecc.).
Nel caso di WinRT si tratta solo di ricomporre un puzzle, nel senso che le funzioni che in win32 erano accorpate in un unica libreria, in certi casi con WinRT sono "sparpagliate" in più interfacce.

Ad esempio invece della funzione win32 DeviceIOControl di kernel32 bisogna usare l'interfaccia IDeviceIoControl che si trova in DeviceAccess.Lib, ecc. ecc.

In pratica tutte le funzionalità di win32 (su cui si appoggiavano le precedenti implementazioni di .Net) sotto WinRT ci sono ancora tutte, sono state solo riorganizzate ed è stato aggiunto dell'altro.

Sicuro però che da WinRT sia possibile andare a leggere scrivere dalla seriale in questo modo? se non sbaglio le applicazioni metro girano in una sandbox e non possono andare a spasso per il sistema come vogliono

un po' come già succedeva su windows mobile per caso? :stordita: ma questo varrà solo per windows 8 "pc" o anche per la versione smartphone e arm?

Su windows mobile avevi C++ per programmarlo con codice nativo e C#, VB e C++ per .NET Compact ;)

Comunque, windows 8 non uscirà su smartphone, avranno solo molto in comune

Credo ci manchi un "pezzo" per comporre il puzzle, se uso le API WinRT sto usando codice "nativo" o sempre CLR/.NET?


Dipende dal linguaggio, l'API è nativa fondamentalmente su tutti i linguaggi, grazie ad un sistema basato sui metadati.

Se scegli di usare C++/CX allora stai programmando in maniera nativa, se scegli C# stai usando .NET.


Ovvero avrò n eseguibili per tutte le architetture che M$ vorrà supportare (ora sono X86 e ARM... tra 2-3 anni magari s'aggiunge MIPSEL) o un solo eseguibile CLR/.NET?
Che quindi per sua natura dovrà essere eseguito/interpretato per mezzo di una VM?


Se programmi in .NET avrai un eseguibile .NET che presumibilmmente girerà su tutte le architetture senza problemi.

Se programmi in C++/CX probabilmente per supportare tutte le piattaforme dovrai ricompilare per la specifica architettura.


WinRT è solo una API basata su .NET e scritta per la CPU "virtuale" CLR come Win32 era, in fondo, basata su DOS/X86...

No, WinRT è una API che può essere programmata in qualsiasi linguaggio supportato da MS, sia nativo che managed.

Su windows mobile avevi C++ per programmarlo con codice nativo e C#, VB e C++ per .NET Compact ;)

Comunque, windows 8 non uscirà su smartphone, avranno solo molto in comune
su windows mobile potevi usare anche le QT:D

Dipende dal linguaggio, l'API è nativa fondamentalmente su tutti i linguaggi, grazie ad un sistema basato sui metadati.

Se scegli di usare C++/CX allora stai programmando in maniera nativa, se scegli C# stai usando .NET.


Non so cosa sia CX (è il "C" liscio? Estensione demoniaca Microsoft? Cosa è?)... comunque anche il C++ può avere target il CLR ovvero essere managed, giusto?

Io, comunque, fossi stato in M$ con Windows 8 la possibilità di avere applicazioni NATIVE l'avrei tolta proprio... solo CLR :sofico:

Dovendo supportare 2 architetture il native sarà un bel problema da gestire :mbe:

No, WinRT è una API che può essere programmata in qualsiasi linguaggio supportato da MS, sia nativo che managed.

Esatto, le implementazioni di .Net fino a Windows 7 erano costruite sopra win32 e DirectX, con Windows 8 invece la "sua" versione di .Net è costruita sopra WinRT e DirectX.

WinRT è basato su COM (Component Object Model, il "vecchio" sistema ad oggetti ed interfacce che .Net in teoria doveva sostituire), usa un modello di gestione della memoria unmanaged e da .Net prende in prestito il formato di descrizione delle API (infatti nei file .winmd si usa una versione modificata del formato di metadati ECMA 335).

In pratica l'infrastruttura "di base" è una versione aggiornata di COM, dove sono state eliminate le parti più ostiche e sostituite con roba più facile da usare e gestire (si spera).

Non so voi, ma certe cose di COM/DCOM sembravano essere state progettate dalla sezione "atti insensati di sadismo" dell' UCAS (Ufficio Complicazione Affari Semplici), speriamo che questo sia migliore altrimenti ci sarà un periodo di transizione di quelli "interessanti", tipo i casini che succedevano certe volte con le dll dei runtime microsoft con numeri di versione "duplicati" (dove in base all'ordine di installazione delle applicazione poteva succedere che alcune non funzionassero più o avessero comportamenti strani) e con gli ActiveX "con problemi di registrazione".

su windows mobile potevi usare anche le QT:D

Su windows mobile si poteva fare qualunque cosa :D

Non so cosa sia CX (è il "C" liscio? Estensione demoniaca Microsoft? Cosa è?)... comunque anche il C++ può avere target il CLR ovvero essere managed, giusto?

Io, comunque, fossi stato in M$ con Windows 8 la possibilità di avere applicazioni NATIVE l'avrei tolta proprio... solo CLR :sofico:

Dovendo supportare 2 architetture il native sarà un bel problema da gestire :mbe:

Fat binary ed il problema è "risolto" :D

Risolto, sì, Apple lo ha dimostrato (ma IMHO solo essa poteva farlo funzionare), ma INELEGANTE, dai :D

Poi scusa avevi la SOLUZIONE in casa... e la butti?

.NET faceva così tanto schifo? Evidente a sto punto... se è vero che WinRt è basato sul vetusto modello COM e genera codice NATIVO... beh che dire ESOTICO :mc:

Ma siete sicuri? Azz... assurdo... ora che fanno il salto ad un nuova architettura tornano al nativo? Che senso ha :confused: ?

Sospetto in errori in dove l'avete letto: non può essere, dai!

Lo so, lo so, .NET è una VM può dare l'idea di esser lenta, ma dipende dalla VM ricordatelo.... chiedete a Google: JIT ;)

Chiedete a Google cosa è davvero un'applicazione/linguaggio "managed", perché vi protegge dai cattivi, ecc...

Chiedete a Google (letteralmente) perché le App Android sono scritte in JAVA (sì lo so gli piace chiamrlo con un nome del pirillo, ma tra di noi possiamo dirlo: l'è IAVA :ciapet: ) e perché è correttamente VIETATO usare il C/C++ o altro...

Pure, semplice, totale follia :doh:

Risolto, sì, Apple lo ha dimostrato (ma IMHO solo essa poteva farlo funzionare), ma INELEGANTE, dai :D

Poi scusa avevi la SOLUZIONE in casa... e la butti?

.NET faceva così tanto schifo? Evidente a sto punto... se è vero che WinRt è basato sul vetusto modello COM e genera codice NATIVO... beh che dire ESOTICO :mc:

Ma siete sicuri? Azz... assurdo... ora che fanno il salto ad un nuova architettura tornano al nativo? Che senso ha :confused: ?

Sospetto in errori in dove l'avete letto: non può essere, dai!

Lo so, lo so, .NET è una VM può dare l'idea di esser lenta, ma dipende dalla VM ricordatelo.... chiedete a Google: JIT ;)

Chiedete a Google cosa è davvero un'applicazione/linguaggio "managed", perché vi protegge dai cattivi, ecc...

Chiedete a Google (letteralmente) perché le App Android sono scritte in JAVA (sì lo so gli piace chiamrlo con un nome del pirillo, ma tra di noi possiamo dirlo: l'è IAVA :ciapet: ) e perché è correttamente VIETATO usare il C/C++ o altro...

Pure, semplice, totale follia :doh:

Non capisco questo astio nei confronti dei linguaggi non-managed, probabilmente si basa su convinzioni errate che hai.

Si è sempre potuto programmare in nativo su Windows, e mi sembra logico per quei programmi che hanno bisogno di una gestione della memoria sofisticata e performance più elevate ne facciano uso.

Tieni presente che il nuovo modello di sviluppo delle applicazioni Metro prevede che il programmatore insieme all'app distribuisca un manifesto in cui verrà dichiarato quali sono le funzionalità del sistema operativo necessarie all'esecuzione.

Sicuramente le stesse verranno mostrate all'utente all'atto dell'installazione/primo utilizzo, così da avere l'esplicto consenso (che poi è il meccanismo che usano alcuni sistemi mobili).

Da qui il sistema operativo garantirà che il manifesto non venga violato.

PS: i compilatori JIT esistono da prima dell'avvento di Google, che non deve certo insegnare a Microsoft (che è nata facendo tools di sviluppo) come fare un sistema operativo o un qualsiasi compilatore. Tra l'altro come ti spieghi il fatto che tutti i browser sono scritti in linguaggi nativi? Chrome ha al suo interno parti di assembler addirittura.

Il problema di C++ (oltre alla sua sintassi orrenda) è che prima dell'avvento di WinRT, non c'era una libreria object oriented nativa per interfacciarsi con il SO (escludo i vari wapper Win32).

Adesso comunque con l'introduzione di alcune estensioni sarà interessante confrontarsi nuovamente con questo linguaggio, in chiave decisamente più moderna.

Comunque volenti o nolenti MS continua ancora a trascinare gli sviluppatori: https://wiki.mozilla.org/Windows8

Risolto, sì, Apple lo ha dimostrato (ma IMHO solo essa poteva farlo funzionare), ma INELEGANTE, dai :D

Poi scusa avevi la SOLUZIONE in casa... e la butti?

.NET faceva così tanto schifo? Evidente a sto punto... se è vero che WinRt è basato sul vetusto modello COM e genera codice NATIVO... beh che dire ESOTICO :mc:

Ma siete sicuri? Azz... assurdo... ora che fanno il salto ad un nuova architettura tornano al nativo? Che senso ha :confused: ?

Sospetto in errori in dove l'avete letto: non può essere, dai!

Lo so, lo so, .NET è una VM può dare l'idea di esser lenta, ma dipende dalla VM ricordatelo.... chiedete a Google: JIT ;)

Chiedete a Google cosa è davvero un'applicazione/linguaggio "managed", perché vi protegge dai cattivi, ecc...

Chiedete a Google (letteralmente) perché le App Android sono scritte in JAVA (sì lo so gli piace chiamrlo con un nome del pirillo, ma tra di noi possiamo dirlo: l'è IAVA :ciapet: ) e perché è correttamente VIETATO usare il C/C++ o altro...

Pure, semplice, totale follia :doh:

Pare che sia soprattutto una questione di politica interna. Certi team interni sono da sempre stati contrari a .NET, infatti l'hanno sempre evitato nei loro prodotti (come Office), e Sinofsky è tra questi... Favorire .NET agevolerebbe la scalata di altri elementi di Microsoft, ostacolando la sua... o almeno questo è quello che si dice online

Non capisco questo astio nei confronti dei linguaggi non-managed, probabilmente si basa su convinzioni errate che hai.


Non sono errate te lo garantisco: parlo del C che conosco meglio, ma C++ non sarà poi così diverso... hai presente la sprintf() o sscanf()... ecco sai un malintenzionato quanti bei giochini può farci? Ti apre come una mela il bel programmetto... e tu NON puoi farci NULLA: è semplicemente l'API che è... bacata by design...

Vogliamo nominare gets()? Pietà :p
... e no fgets() è soli più complessa da usare... serve a nulla! Ci dai la dimensione? E io ti sovrascrivo il II argomento... dai :D

Citando un famoso comico di Zelig (?):

"Cosa fa JAVA quando vede una sprintf()? Se ne batte il ***o :Prrr: "

Vogliamo parlare delle cosacce che un (lo)hacker può ficcare in una DLL/SO?
Ecco queste son cose che un linguaggio MANAGED NON permette... vogliamo parlare della PROTEZIONE DELLA MEMORIA? E' intrinseca in un linguaggio managed... il C mi permette almeno in teoria di scrivere nello spazio di memoria di altri, giusto (e s'ì' in un Amiga lo fai IMHO... o in VxWorks)?
Poi vado in core... ma lo potrei fare!


Si è sempre potuto programmare in nativo su Windows, e mi sembra logico per quei programmi che hanno bisogno di una gestione della memoria sofisticata e performance più elevate ne facciano uso.


Sì OK, ma era consigliato? Almeno da .NET in poi? Direi di no :mc:

Per non parlare poi di cosa fa l'App: vuole leggermi la rubrica? Copiarsela e inviarla via web?
JAVA/.NET lo sanno e possono impedirlo... WinRT come può fare?
C'è una Sandbox? Non riesco a bypassarla con 2 colpi di mouse? Cambiando una chiave nel registro :doh: ?


Tieni presente che il nuovo modello di sviluppo delle applicazioni Metro prevede che il programmatore insieme all'app distribuisca un manifesto in cui verrà dichiarato quali sono le funzionalità del sistema operativo necessarie all'esecuzione.


Se scrivo in un linguaggio non managed nulla l'OS potrà farci se il manifest non è rispettato: lo bypasso l'OS :Prrr:


Sicuramente le stesse verranno mostrate all'utente all'atto dell'installazione/primo utilizzo, così da avere l'esplicto consenso (che poi è il meccanismo che usano alcuni sistemi mobili).


... e l'utente premerà OK, senza leggere al solito :mbe:
*azzi suoi dici? Può essere... ma avevi il MODO di impedirlo by design, no? Quindi?


Da qui il sistema operativo garantirà che il manifesto non venga violato.


Come? Può essere bypassato... è scritto in C WinRt, no? Una bella printf() ben dosata e via dalle scatole :ciapet:
E' scritto in C++ se voglio ci metto pure lì le printyf()... cin non credo sia da meno comunque, ma non lo so quindi taccio :help:

A parte che mi ci gioco quel che vuoi che ci sarà la chiavina nel registro da settare per disabilitarlo totalmente e via: il regno degli hacker... virus sui telefoni che bello :doh:


PS: i compilatori JIT esistono da prima dell'avvento di Google, che non deve certo insegnare a Microsoft (che è nata facendo tools di sviluppo) come fare un sistema operativo o un qualsiasi compilatore. Tra l'altro come ti spieghi il fatto che tutti i browser sono scritti in linguaggi nativi? Chrome ha al suo interno parti di assembler addirittura.


Nessuno vuole insegnargli nulla a M$ tanto più che avevano già il prodotto in casa... tra l'altro ho sempre avuto l'impressione che .NERT in fase d'installazione venisse... compilato... AOT se non erro si dice... quindi? Non avrebbe dovuto essere uguale a un app C/C++? Con in più il vantaggio OVVIO di essere ottimizzato per il PC su cui gira (visto che compilo non per un PC astratto, ma per quello lì che ho sotto le chiappe ;) )


Comunque volenti o nolenti MS continua ancora a trascinare gli sviluppatori: https://wiki.mozilla.org/Windows8

In un baratro :eek: ?

Scherzi a parte sto tornare indietro puzza di brutta, bruttissima mossa, se politica beh follia... proprio ora tra l'altro?

Da programmatore Linux (e NO non me ne vanto, anzi... lamento la totale inesperienza in linguaggi MODERNI e sensati) avendo SOLO letto di .NET cosa penso? E' un vomitoire? A occhio pareva bello... JAVA migliorato cosa aveva di male?

Non si poteva migliorare la VM... JIT ecc? LLVM giura e spergiura che si possono eguagliare e PERSINO, in certi casi, superare le performance di applicazioni NATIVE... e M$ se la fa in mano?
Loro?

Belin :rolleyes:

Non sono errate te lo garantisco: parlo del C che conosco meglio, ma C++ non sarà poi così diverso... hai presente la sprintf() o sscanf()... ecco sai un malintenzionato quanti bei giochini può farci? Ti apre come una mela il bel programmetto... e tu NON puoi farci NULLA: è semplicemente l'API che è... bacata by design...

Vogliamo nominare gets()? Pietà :p
... e no fgets() è soli più complessa da usare... serve a nulla! Ci dai la dimensione? E io ti sovrascrivo il II argomento... dai :D


Ma non a caso esistono le varianti SICURE. Si tratta solo di conoscerlo, cosa che qualsiasi buon programmatore dovrebbe sapere.


Vogliamo parlare delle cosacce che un (lo)hacker può ficcare in una DLL/SO?
Ecco queste son cose che un linguaggio MANAGED NON permette... vogliamo parlare della PROTEZIONE DELLA MEMORIA? E' intrinseca in un linguaggio managed... il C mi permette almeno in teoria di scrivere nello spazio di memoria di altri, giusto (e s'ì' in un Amiga lo fai IMHO... o in VxWorks)?


No, C non ti permette proprio un bel nulla di per se dato che la protezione della memoria del processo è garantita a livello di SO, salvo bug dello stesso chiaramente. Ma quelli ci saranno sempre, anche nelle varie VM, che chissà come mai, sono scritte in un linguaggio non-managed :rolleyes: .


Per non parlare poi di cosa fa l'App: vuole leggermi la rubrica? Copiarsela e inviarla via web?
JAVA/.NET lo sanno e possono impedirlo... WinRT come può fare?
C'è una Sandbox? Non riesco a bypassarla con 2 colpi di mouse? Cambiando una chiave nel registro :doh: ?


Posso fare un programma MANAGED in 15 secondi che prenda la lista dei files nella tua cartella documenti e la invia via web, di che cosa stiamo parlando?

PS: su qualsiasi SO, con qualsiasi linguaggio, managed o no.

WinRT è una API per cui non ha il compito di fare nulla se non mettere a disposizione del programmatore delle funzioni.


Se scrivo in un linguaggio non managed nulla l'OS potrà farci se il manifest non è rispettato: lo bypasso l'OS :Prrr:


Ma anche no, è il SO in fase di esecuzione che impedisce semplicemente le chiamate a funzioni (o le syscall) che non rispettano il manifest.

Guarda caso è lo stesso principio che adotta Android.


... e l'utente premerà OK, senza leggere al solito :mbe:
*azzi suoi dici? Può essere... ma avevi il MODO di impedirlo by design, no? Quindi?


No, by design la politica del manifest è ancora più sicura.


Come? Può essere bypassato... è scritto in C WinRt, no? Una bella printf() ben dosata e via dalle scatole :ciapet:
E' scritto in C++ se voglio ci metto pure lì le printyf()... cin non credo sia da meno comunque, ma non lo so quindi taccio :help:


Eh già :rolleyes:


A parte che mi ci gioco quel che vuoi che ci sarà la chiavina nel registro da settare per disabilitarlo totalmente e via: il regno degli hacker... virus sui telefoni che bello :doh:


Android insegna del resto :rolleyes: .


Nessuno vuole insegnargli nulla a M$ tanto più che avevano già il prodotto in casa... tra l'altro ho sempre avuto l'impressione che .NERT in fase d'installazione venisse... compilato... AOT se non erro si dice... quindi? Non avrebbe dovuto essere uguale a un app C/C++? Con in più il vantaggio OVVIO di essere ottimizzato per il PC su cui gira (visto che compilo non per un PC astratto, ma per quello lì che ho sotto le chiappe ;) )


Tu non sai minimanete di cosa stai parlando, per cui direi di finirla qui.


In un baratro :eek: ?

Scherzi a parte sto tornare indietro puzza di brutta, bruttissima mossa, se politica beh follia... proprio ora tra l'altro?

Da programmatore Linux (e NO non me ne vanto, anzi... lamento la totale inesperienza in linguaggi MODERNI e sensati) avendo SOLO letto di .NET cosa penso? E' un vomitoire? A occhio pareva bello... JAVA migliorato cosa aveva di male?

Non si poteva migliorare la VM... JIT ecc? LLVM giura e spergiura che si possono eguagliare e PERSINO, in certi casi, superare le performance di applicazioni NATIVE... e M$ se la fa in mano?
Loro?

Belin :rolleyes:

Più che programmatore Linux mi sembri uno alle prime armi che non conosce né il funzionamento di un compilatore né tantomeno di un SO, d'altro canto hai solo "letto" di .NET...

Non so cosa sia CX (è il "C" liscio? Estensione demoniaca Microsoft? Cosa è?)... comunque anche il C++ può avere target il CLR ovvero essere managed, giusto?

Io, comunque, fossi stato in M$ con Windows 8 la possibilità di avere applicazioni NATIVE l'avrei tolta proprio... solo CLR :sofico:

Dovendo supportare 2 architetture il native sarà un bel problema da gestire :mbe:
ma senza codice nativo certe cose nn le fai, in campo "multimediale" soprattutto diventa un bel problema! Le QT il programma del crossplatform l'hanno risolto senza problemi, volendo si riesce! Ma la maggior parte delle applicazioni non useranno codice nativo che servirà più che altro per applicazioni multimediali come già succede su android!

Risolto, sì, Apple lo ha dimostrato (ma IMHO solo essa poteva farlo funzionare), ma INELEGANTE, dai :D

Poi scusa avevi la SOLUZIONE in casa... e la butti?

.NET faceva così tanto schifo? Evidente a sto punto... se è vero che WinRt è basato sul vetusto modello COM e genera codice NATIVO... beh che dire ESOTICO :mc:

Ma siete sicuri? Azz... assurdo... ora che fanno il salto ad un nuova architettura tornano al nativo? Che senso ha :confused: ?

Sospetto in errori in dove l'avete letto: non può essere, dai!

Lo so, lo so, .NET è una VM può dare l'idea di esser lenta, ma dipende dalla VM ricordatelo.... chiedete a Google: JIT ;)

Chiedete a Google cosa è davvero un'applicazione/linguaggio "managed", perché vi protegge dai cattivi, ecc...

Chiedete a Google (letteralmente) perché le App Android sono scritte in JAVA (sì lo so gli piace chiamrlo con un nome del pirillo, ma tra di noi possiamo dirlo: l'è IAVA :ciapet: ) e perché è correttamente VIETATO usare il C/C++ o altro...

Pure, semplice, totale follia :doh:
falso, su android puoi usare l'ndk e scrivere codice nativo, cosa diventata fondamentale per i programmi multimediali, tipo i codec di vari lettori video!

Per non parlare poi di cosa fa l'App: vuole leggermi la rubrica? Copiarsela e inviarla via web?
JAVA/.NET lo sanno e possono impedirlo... WinRT come può fare?
C'è una Sandbox? Non riesco a bypassarla con 2 colpi di mouse? Cambiando una chiave nel registro :doh: ?

scusa ma perché dovrebbero esserci problemi? :stordita: anche su android ci sn tante applicazioni realizzate cn l'sdk quindi in java che permettono queste cose, dipende dai permessi! ma i permessi ci sn pure su symbian dove si usa il c++ (per le applicazioni in QT)

... e l'utente premerà OK, senza leggere al solito :mbe:
*azzi suoi dici? Può essere... ma avevi il MODO di impedirlo by design, no? Quindi?

e quindi è così anche su android che usa java :stordita: quindi che cambia??


A parte che mi ci gioco quel che vuoi che ci sarà la chiavina nel registro da settare per disabilitarlo totalmente e via: il regno degli hacker... virus sui telefoni che bello :doh:

e il market place che ci sta a fare? sai come funziona adesso su windows phone? nn puoi installare niente che nn proviene dal market place! prevedo la stessa cosa su tablet cn windows 8 per arm!

Pare che sia soprattutto una questione di politica interna. Certi team interni sono da sempre stati contrari a .NET, infatti l'hanno sempre evitato nei loro prodotti (come Office), e Sinofsky è tra questi... Favorire .NET agevolerebbe la scalata di altri elementi di Microsoft, ostacolando la sua... o almeno questo è quello che si dice online

C'è anche una componente "politica", ma le motivazioni scatenanti di certe scelte tipo WinRT o il non-port di Office sono fondamentalmente tecniche.

Semplicemente .Net è stato sviluppato avendo troppa fretta e trascurando vari aspetti tecnici (in particolare relativi al codice del S.O. e ad altre parti che devono essere unmanaged).

La prova più evidente è che le prime librerie per .Net erano essenziamente "win32 incapsulato ad oggetti per .Net" (ma non tutto, e dalle "mancanze" deriva l'abuso di P/Invoke).

Poi nelle release successive hanno apportato varie correzioni, ma nonostante questo .Net è buono solo per lo sviluppo di applicazioni "che non fanno troppa roba a basso livello con le loro manine" (e questo spiega come mai l'OS Team di Microsoft non sia così entusiasta).

Poi c'è il problema di win32/win64/winCE.
La versione a 64bit di .Net è uscita "con un certo ritardo" perchè la VM stessa non era stata pensata sin dal principio per i 64bit e per poter gestire in modo sufficientemente trasparente il codice unmannaged a 32bit ed a 64bit. :muro:
La versione per Windows CE è "solo" il Compact Framework perchè mancano le funzioni win32 che servirebbero per il framework completo, cosa decisamente pessima, visto che questo implica che il framework .Net è "portatile" solo da un implementazione di win32 all'altra. :muro:
Peggio ancora Windows CE in base alla versione ha modelli di memoria che fanno ca**** Aehm! Che forse sarebbero da migliorare ed anche questo ha creato qualche problema di porting.

Per questo Office per ora non è stato "riscritto per .Net"; aveva poco senso mollare win32 e riscrivere e ritestare una quantità enorme di roba per passare ad un nuovo framework ... che richiede ancora win32. :read:

C'è anche una componente "politica", ma le motivazioni scatenanti di certe scelte tipo WinRT o il non-port di Office sono fondamentalmente tecniche.

Semplicemente .Net è stato sviluppato avendo troppa fretta e trascurando vari aspetti tecnici (in particolare relativi al codice del S.O. e ad altre parti che devono essere unmanaged).

La prova più evidente è che le prime librerie per .Net erano essenziamente "win32 incapsulato ad oggetti per .Net" (ma non tutto, e dalle "mancanze" deriva l'abuso di P/Invoke).


Quali mancanze? P/Invoke serve come bridge per le librerie native già esistenti, scritte magari in linguaggi di più basso livello come C/C++.

Tutti quanti i maggiori linguaggi managed mettono a disposizione strumenti di quel tipo.

La cosa bella di WinRT è che non ci sarà bisogno di P/Invoke, perché la libreria risulterà nativa in qualsiasi linguaggio ;).


Poi nelle release successive hanno apportato varie correzioni, ma nonostante questo .Net è buono solo per lo sviluppo di applicazioni "che non fanno troppa roba a basso livello con le loro manine" (e questo spiega come mai l'OS Team di Microsoft non sia così entusiasta).


Come Java, Python, Ruby e tutti i linguaggi managed, .NET è pensato per gli applicativi ad alto livello (anche web), non per quelli di basso livello, anche se comunque esistono moltissimi bindings che consentono di fare praticamente la qualunque usando librerie native per quelle parti dell'applicazione che richiedono maggiori prestazioni (ammesso che il framework sia il collo di bottiglia).

Comunque Windows Phone con Silverlight ti smentiscono ampiamente sull'utilizzo di .NET in altri ambiti.

Tant'è che prestazionalmente è superiore all'accoppiata Android+Java, per cui di cosa stiamo parlando?


Poi c'è il problema di win32/win64/winCE.
La versione a 64bit di .Net è uscita "con un certo ritardo" perchè la VM stessa non era stata pensata sin dal principio per i 64bit e per poter gestire in modo sufficientemente trasparente il codice unmannaged a 32bit ed a 64bit. :muro:


Premesso che se usi .NET per scrivere codice unmanaged significa che hai sbagliato strumento, tieni comunque presente che la maggior parte degli applicativi non trae alcun vantaggio dai 64bit, ed è questo il motivo per cui nonostante sono anni che la piattaforma 64bit è diffusa, sono poche le applicazioni native 64bit.

Quindi il ritardo è più che giustificato, ed in ogni caso non sminuisce certo .NET, che si è dimostrato essere una piattaforma molto flessibile (vedi DLR, IronPython, IronRuby).


[..]
Per questo Office per ora non è stato "riscritto per .Net"; aveva poco senso mollare win32 e riscrivere e ritestare una quantità enorme di roba per passare ad un nuovo framework ... che richiede ancora win32. :read:

Portare un programma delle dimensioni di office da un linguaggio ad un altro non è cosa da poco se permetti, anche perché se fai tutto questo con l'intento della portabilità (di certo non lo fai con l'intento delle prestazioni, altrimenti esce fuori OpenOffice che ancora oggi non supporta l'accelerazione grafica hardware), allora è sufficiente che il tuo codice sia ben scritto per portarlo su altre architetture ricompilando.

La maggior parte dei problemi di portabilità dipende da problemi con le dimensioni dei tipi e il byte order... ma se scrivi codice a certi livelli, queste cose le cambi con 2 define.

Office è stato portato su ARM, ma lì il problema di Microsoft è come integrarlo con Metro e consentire agli utenti tablet di usarlo proficuamente, per cui non vedo quale sia il problema.

Quindi .NET, da quello che capisco, era un po' un ibrido... a volte si potevano (dovevano a volte mancando funzionalità) chiamare DLL scritte in C/C++ quindi codice non managed... non era diciamo "completo" :confused:

Beh questa spiega molte cose e la difficoltà alla fine di usarlo comunque con ARM... se dipende così tanto da Win32 alla fine non serve a nulla :cry:

@WarDuck

Le versioni "sicure" non sono sicure affatto:

http://tldp.org/HOWTO/Secure-Programs-HOWTO/dangers-c.html

cosa accade se il buffer da copiare è più grande di quello in cui copi? Sei sicuro metta il tappo? Io scommetterei di no ;)

Son d'accordo comunque a finirla qui, non mi sembra un modo corretto e sereno di confrontarsi... sinceramente non ti capisco, manco avessi attaccato i tuoi cari :Prrr:

Comunque Windows Phone con Silverlight ti smentiscono ampiamente sull'utilizzo di .NET in altri ambiti.

Tant'è che prestazionalmente è superiore all'accoppiata Android+Java, per cui di cosa stiamo parlando?
L'argomento è più complesso! si confronta un sistema più "limitato" con uno che invece forse esagera un po' troppo con le funzioni :fagiano: inoltre ad android manca anche l'accelerazione hardware dell'interfaccia cosa arrivata con ICS (anche honeycomb ma nn era granché).
Cmq nn mi pare che silverlight su windows phone smentisca alcunché, roba a basso livello nn ne fa così come del resto nn si fa su android con java e bisogna ricorrere all'NDK! ci vorrebbe qualcosa del genere anche su windows phone e arriverà a quanto pare con Apollo proprio perché silverlight non basta!


Portare un programma delle dimensioni di office da un linguaggio ad un altro non è cosa da poco se permetti, anche perché se fai tutto questo con l'intento della portabilità (di certo non lo fai con l'intento delle prestazioni, altrimenti esce fuori OpenOffice che ancora oggi non supporta l'accelerazione grafica hardware), allora è sufficiente che il tuo codice sia ben scritto per portarlo su altre architetture ricompilando.

Concordo ed è quello che dicevo anch'io nelle pagine precedenti anche relativo a office su arm, nn credo sia bastata una semplice ricompilatina :fagiano:

Quindi .NET, da quello che capisco, era un po' un ibrido... a volte si potevano (dovevano a volte mancando funzionalità) chiamare DLL scritte in C/C++ quindi codice non managed... non era diciamo "completo" :confused:


Ma questa cosa non è vera. La libreria di .NET è più vasta di quella di Java a momenti.


Beh questa spiega molte cose e la difficoltà alla fine di usarlo comunque con ARM... se dipende così tanto da Win32 alla fine non serve a nulla :cry:


Ma chi vi mette in testa certe cose?


@WarDuck

Le versioni "sicure" non sono sicure affatto:

http://tldp.org/HOWTO/Secure-Programs-HOWTO/dangers-c.html

cosa accade se il buffer da copiare è più grande di quello in cui copi? Sei sicuro metta il tappo? Io scommetterei di no ;)


Premesso che quella pagina è del 2003, comunque quello che dici è ancora una volta opinabile.

Il fatto che la libreria standard possa mettere a disposizione funzioni che consentono al programmatore di sbagliare, non significa che è colpa del linguaggio in se.

In C++ per questo motivo si è introdotto il tipo string, e sempre per questo motivo sono nate le eccezioni, per altro ti invito a studiare come sono fatte in Windows le Structured Exception Handling:

http://en.wikipedia.org/wiki/Exception_handling_syntax#C

(vedi la parte relativa a Windows)

Il discorso del bound checking può essere incapsulato in strutture o funzioni nel caso C più sicure (cosa che fanno tutti i programmatori seri).

Ad esempio posso crearmi una struttura o una classe (in C++) per manipolare i buffer in maniera totalmente sicura e a prova di buffer overflow, senza dover ricorrere ad una macchina virtuale.

Quello che dici te non è prerogativa di una macchina virtuale, quanto dell'incapsulamento che c'è dietro, ovvero di funzioni che fanno da wrapper e che ti mascherano la complessità e le varie insidie.


Son d'accordo comunque a finirla qui, non mi sembra un modo corretto e sereno di confrontarsi... sinceramente non ti capisco, manco avessi attaccato i tuoi cari :Prrr:

Perché dimostri di non saper scindere il linguaggio come strumento dalle librerie/applicazioni che vengono scritte.

Ogni linguaggio ha pro e contro.

Quali mancanze? P/Invoke serve come bridge per le librerie native già esistenti, scritte magari in linguaggi di più basso livello come C/C++.

Non a caso ho usato le virgolette ed ho parlato esplicitamente di "abuso di P/Invoke". Significa che avevano sottovalutato quante funzionalità sarebbe stato il caso di fornire pre-incapsulate in classi .Net e come integrarsi in modo "pulito" con il codice nativo.


La cosa bella di WinRT è che non ci sarà bisogno di P/Invoke, perché la libreria risulterà nativa in qualsiasi linguaggio ;).

In altre parole hai parzialmente risposto da te alla domanda che avevi posto prima. ;)


Come Java, Python, Ruby e tutti i linguaggi managed, .NET è pensato per gli applicativi ad alto livello (anche web), non per quelli di basso livello, anche se comunque esistono moltissimi bindings che consentono di fare praticamente la qualunque usando librerie native per quelle parti dell'applicazione che richiedono maggiori prestazioni (ammesso che il framework sia il collo di bottiglia).

Solo che il messaggio iniziale di Microsoft era assai diverso, era più sul tipo "usate .Net per tutto e lasciate perdere il C++ e la roba unmanaged perchè sono roba legacy, il futuro è solo .Net", ecc. ecc. ;)



Comunque Windows Phone con Silverlight ti smentiscono ampiamente sull'utilizzo di .NET in altri ambiti.

Windows Phone ha alla base Windows CE6.0R3 ed il relativo porting di .Net Compact Framework (su cui Silverlight girava già).
Non hanno fatto altro che adattare il runtime già sviluppato aggiungendo librerie per supportare la nuova UI e le funzioni native che tornano utili su uno smartphone.
Ovvero anche su Windows Phone si continua ad usare .Net per applicazioni "che non fanno troppa roba a basso livello con le loro manine". :read:



Tant'è che prestazionalmente è superiore all'accoppiata Android+Java, per cui di cosa stiamo parlando?

E' così superiore che ora pure Microsoft supporterà lo sviluppo di app in C++ per Windows Phone, trai da te le conclusioni del caso.


Premesso che se usi .NET per scrivere codice unmanaged significa che hai sbagliato strumento, tieni comunque presente che la maggior parte degli applicativi non trae alcun vantaggio dai 64bit, ed è questo il motivo per cui nonostante sono anni che la piattaforma 64bit è diffusa, sono poche le applicazioni native 64bit.

Si sbaglia strumento perchè .Net non è stato pensato per poter essere in grado di far coabitare esplicitamente ed in modo agevole codice managed portabile e codice unmanaged portatile.
Se invece di scopiazzare Java avessero preso da subito ispirazione da LLVM (che a quei tempi era già in circolazione e che si basava su R&D preesistente) ora sarebbe tutto un altro paio di maniche.


Portare un programma delle dimensioni di office da un linguaggio ad un altro non è cosa da poco se permetti, anche perché se fai tutto questo con l'intento della portabilità (di certo non lo fai con l'intento delle prestazioni, altrimenti esce fuori OpenOffice che ancora oggi non supporta l'accelerazione grafica hardware), allora è sufficiente che il tuo codice sia ben scritto per portarlo su altre architetture ricompilando.

La maggior parte dei problemi di portabilità dipende da problemi con le dimensioni dei tipi e il byte order... ma se scrivi codice a certi livelli, queste cose le cambi con 2 define.

Office è stato portato su ARM, ma lì il problema di Microsoft è come integrarlo con Metro e consentire agli utenti tablet di usarlo proficuamente, per cui non vedo quale sia il problema.

Ehm! Guarda che hai quasi ripetuto con parole diverse quello che avevo già scritto. ;)
L'unica cosa che hai sottovalutato è che anche se il codice è scritto per essere portabile, non è detto sia così indolore riscrivere la parte che si interfaccia al runtime quando questo ad esempio cambia da un sistema unmanaged (win32) ad uno managed (.Net), specialmente se nei sorgenti molto codice è scritto secondo un modello unmanaged.

Non a caso ho usato le virgolette ed ho parlato esplicitamente di "abuso di P/Invoke". Significa che avevano sottovalutato quante funzionalità sarebbe stato il caso di fornire pre-incapsulate in classi .Net e come integrarsi in modo "pulito" con il codice nativo.


Fammi un esempio.


Solo che il messaggio iniziale di Microsoft era assai diverso, era più sul tipo "usate .Net per tutto e lasciate perdere il C++ e la roba unmanaged perchè sono roba legacy, il futuro è solo .Net", ecc. ecc. ;)

Che Microsoft spinga .NET è fuori discussione (basta vedere gli ultimi visual studio per capirlo), perché consente maggiore libertà alla stessa, e agli sviluppatori che non si devono preoccupare di dettagli di basso livello, né tantomeno pensare ad una particolare architettura.

Quello che molti non riescono a capire che .NET e C++ possono convivere tranquillamente, per cui alcune parti le posso fare in .NET ed altre in C++.


Windows Phone ha alla base Windows CE6.0R3 ed il relativo porting di .Net Compact Framework (su cui Silverlight girava già).
Non hanno fatto altro che adattare il runtime già sviluppato aggiungendo librerie per supportare la nuova UI e le funzioni native che tornano utili su uno smartphone.
Ovvero anche su Windows Phone si continua ad usare .Net per applicazioni "che non fanno troppa roba a basso livello con le loro manine". :read:


Fatto sta che se vuoi scrivere una app per Windows Phone devi per forza farlo usando uno dei linguaggi .NET, e comunque il risultato sono app fluide e responsive.


E' così superiore che ora pure Microsoft supporterà lo sviluppo di app in C++ per Windows Phone, trai da te le conclusioni del caso.

Cosa c'entra con l'affermazione che ho fatto?

Anzi la tua rafforza ulteriormente la mia, dal momento che MS con .NET e Silverlight è riuscita ad essere più performante di Android+NDK.


Si sbaglia strumento perchè .Net non è stato pensato per poter essere in grado di far coabitare esplicitamente ed in modo agevole codice managed portabile e codice unmanaged portatile.
Se invece di scopiazzare Java avessero preso da subito ispirazione da LLVM (che a quei tempi era già in circolazione e che si basava su R&D preesistente) ora sarebbe tutto un altro paio di maniche.


Ancora non mi hai fatto un esempio di cosa costituisce un problema. Il codice nativo è per forza di cose compilato e dipendente dall'architettura.

Stando a Wikipedia la prima versione .NET risale al febbraio 2002, mentre la prima versione di LLVM risale al 2003.


Ehm! Guarda che hai quasi ripetuto con parole diverse quello che avevo già scritto. ;)
L'unica cosa che hai sottovalutato è che anche se il codice è scritto per essere portabile, non è detto sia così indolore riscrivere la parte che si interfaccia al runtime quando questo ad esempio cambia da un sistema unmanaged (win32) ad uno managed (.Net), specialmente se nei sorgenti molto codice è scritto secondo un modello unmanaged.

Si ma di cosa stiamo parlando? Office non è managed, e non credo che MS voglia farlo diventare managed.

Ribadisco, se il codice è scritto bene, non hai bisogno di un linguaggio managed per la portabilità.

Ma questa cosa non è vera. La libreria di .NET è più vasta di quella di Java a momenti.


So 'na sega io... riporto ciò che dicevate prima... se necessitavi di p/invoke per chiamare codice nativo... hai perso, OK?
Se poi chi lo scrisse era in errore OK... come avessi detto: zuccabubu :p


Ma chi vi mette in testa certe cose?


VOI :ciapet:


Premesso che quella pagina è del 2003, comunque quello che dici è ancora una volta opinabile.

Il fatto che la libreria standard possa mettere a disposizione funzioni che consentono al programmatore di sbagliare, non significa che è colpa del linguaggio in se.


Certo che lo è: l'API non deve andare in core di per se... il C lo fa!

Fammi una strlen() su una stringa NULL cosa ottieni? SEGFAULT! Io preferirei 0... perché non fare il test? Cosa c'è di male? (A dire il vero VxWorks mi torna 0 bello paciarotto...) E' lento? ... bravi ora è veloce... e il "Tronco di Milano" è bloccato :muro:


In C++ per questo motivo si è introdotto il tipo string, e sempre per questo motivo sono nate le eccezioni, per altro ti invito a studiare come sono fatte in Windows le Structured Exception Handling:

http://en.wikipedia.org/wiki/Exception_handling_syntax#C

(vedi la parte relativa a Windows)


Poi vado a leggere te lo prometto così imparo qualcosa....

Dico solo che C++ ti da un goccio di controllo in più, ma il C non ti permette di far molto se la stringa non ha il tappo o se esco dai limiti di un array: NULLA... dimostrami il contrario: e no NON esistono eccezioni; va in core o, come dicono loro, da risultati impredicibili :mc:
... e NO, io, non posso farci nulla!

Il C++ bello quanto vuoi, ma in fondo, in fondo semplificando è una serie di librerie (sì lo dico il C+++ è una libreria, non un linguaggio!) che chiamano classi pomposamente: alla fine sempre sprintf() e strlen() chiamano... e POSSONO corare... se gli arriva il satanico NULL :mad:


Il discorso del bound checking può essere incapsulato in strutture o funzioni nel caso C più sicure (cosa che fanno tutti i programmatori seri).


Serii noi non siamo... abbiamo l'usanza, da me detestata, di usare VOLUTAMENTE stringhe senza il tappo... strutture per proteggere dal buon cheching? Come?... Funzioni me le dovrei scrivere (e in parte tento di farlo... combattendo! I colleghi dicono che è overhead inutile :doh: ): di fatto va wrappato l'intero POSIX, giusto? strlen() che torna o in caso di NULL, memcpy() che torna NULL se dest è NULL, ecc...


Ad esempio posso crearmi una struttura o una classe (in C++) per manipolare i buffer in maniera totalmente sicura e a prova di buffer overflow, senza dover ricorrere ad una macchina virtuale.


OK, ma io NON posso usare il C++, lavoro anche con VxWorks ovvero con sistemi realtime (lo so che sembro un cazz/ro, ma non lo sono davvero ;) ) e posso usare solo il C... quindi? Cosa wrappo? Se poi vado lento? Poi me lo dici quando la sbarra non s'alza che accade... perché io wrappo tutto POSIX...

C++ mi sa che nemmeno posso compilarlo per VxWorks (pure vecchio di 10 anni, eh per esser sicuri) :cry:


Quello che dici te non è prerogativa di una macchina virtuale, quanto dell'incapsulamento che c'è dietro, ovvero di funzioni che fanno da wrapper e che ti mascherano la complessità e le varie insidie.


Caratteristiche che però definiscono una macchina virtuale, nei fatti:


L'Hardware è astratto, non è X86 o ARM... è Bytecode/Bitcode/CLR il target (la "CPU")
Le "risorse" sono bloccate e controllate... non posso cancellare il FS sottostante... debbo chiedere il permesso all'utente e pure all'OS probabilmente ;)
Le funzioni devono essere "safe" e generare eccezioni non "corare", eccezioni che se uno ce l'ha grosso posso essere gestite o ignorate (!):
il programma continua l'esecuzione bello sereno e paciorotto: se faccio tornare tutto al main() non gestendo NULLA, il rogramma termina e ho il trace chiaro di cosa accade "Belin <out bound exception>? ... ahh che fesso è un array di 12 NON di 13, banale!" Ma lo sai anche tu se usi .NET cosa vuol dire...
SOLO per questo JAVA/NET sono TOGHISSIMI... WinRT questo non te lo darà MAI... se è C/C++, va in core: passo indietro :doh:
Non si gioca con la memoria in maniera raw non esistono puntatori né matematiche di essi (char *sarcazzo = "puppa", sarcazzo++ // sarcazzo = "uppa")... i valori si passano per valore NON per riferimento... di nuovo scomodo e lento? OK, ma salva le chiappe: il pointer può esser sovrascritto.... il valore NO!
Per sua natura è IMPOSSIBILE accedere alla memoria di altri processi e fare "porcate", massimo se ce la fai ottieni un eccezione... non esegui programmi sul computer HOST... ti sfido a scrivere bratta in un String JAVA di un'applicazione che sta girando e fare "cosacce" :mbe:


WinRT non credo esendo nativo possa garantirmi tutto questo sinceramente... spero di sbagliare, ovvio, ma ne dubito...


Perché dimostri di non saper scindere il linguaggio come strumento dalle librerie/applicazioni che vengono scritte.


Il C senza POSIX cosa serve? Dal punto di vista mio sono inscindibili, OK?
... e POSIX va in core... quindi? Quindi il C è veloce, bello, lo amo, lo odio, lo detesto, ma è unsafe :eek:

C++ senza stdc++ a che serve? Ci faccio le uova... ho string? Bello... se il char* che soggiace per magia diventa NULL (e può accadere... prova a usare pragma(pack) e pragma(pop) e... divertiti!)? Chiamo il metodo len() fichissimo e... lui poveraccio cosa fa? strlen() ovviamente del buffer sottostante... ohh, ma è NULL ... BAM!!!! Core :muro: :muro: :muro:
Certo poteva controllare prima, ma... NOOO! Dai NON è NULL... per costruzione, no?

Quindi? il C++ è semi-veloce, bello, lo amo, lo odio, , lo detesto, ma è unsafe :eek:

P.S. L'exception handling di Windows sembra funzionare anche con il C... ma è OBBLIGATORIO o optional? La div di 0 automaticamente da un'eccezione o lo fa solo se uso __try() ? JAVA mi OBBLIGA a mettere try/catch se il metodo torna un'eccezione... NET essendo copiato immagino pure... con in più finally che, se non erro, JAVA non possiede...

Fammi una strlen() su una stringa NULL cosa ottieni? SEGFAULT! Io preferirei 0... perché non fare il test? Cosa c'è di male? (A dire il vero VxWorks mi torna 0 bello paciarotto...) E' lento? ... bravi ora è veloce... e il "Tronco di Milano" è bloccato :muro:


Quindi? Segfault è forse meno piacevole di una eccezione che ti manda in crash il programma perché non l'hai gestita?

Concettualmente c'è ben poco di diverso eh...


Dico solo che C++ ti da un goccio di controllo in più, ma il C non ti permette di far molto se la stringa non ha il tappo o se esco dai limiti di un array: NULLA... dimostrami il contrario: e no NON esistono eccezioni; va in core o, come dicono loro, da risultati impredicibili :mc:
... e NO, io, non posso farci nulla!


Ancora, confondi il linguaggio, con le librerie.

C ti permette di fare casini semplicemente se non sai quello che stai facendo.

Ma se hai paura di fare casini programmando, cambia mestiere, fai un favore a tutti.

Programmare in C richiede più attenzione, se non lo vuoi fare allora evita, ma prima o poi ti troverai a doverlo fare, e allora non potrai fare le cose alla carlona solo perché "più semplici".

In ogni lavoro andrebbe messa la giusta dose di attenzione, e non la classica superficialità tipica di questi tempi.


Il C++ bello quanto vuoi, ma in fondo, in fondo semplificando è una serie di librerie (sì lo dico il C+++ è una libreria, non un linguaggio!) che chiamano classi pomposamente: alla fine sempre sprintf() e strlen() chiamano... e POSSONO corare... se gli arriva il satanico NULL :mad:


E chi te lo dice che sia necessario usare strlen? La mia libreria protrebbe benissimo non usarla.

Ti dirò di più, quando mi arriva per esempio da socket una nuova stringa, leggo X byte, e li metto in un buffer di X+1 bytes preventivamente inizializzato tutto a 0.
E' facile dimostrare MATEMATICAMENTE che un programma del genere non avrà mai il tipo di problemi di cui parli.


OK, ma io NON posso usare il C++, lavoro anche con VxWorks ovvero con sistemi realtime (lo so che sembro un cazz/ro, ma non lo sono davvero ;) ) e posso usare solo il C... quindi? Cosa wrappo? Se poi vado lento? Poi me lo dici quando la sbarra non s'alza che accade... perché io wrappo tutto POSIX...

C++ mi sa che nemmeno posso compilarlo per VxWorks (pure vecchio di 10 anni, eh per esser sicuri) :cry:


Quindi?


Caratteristiche che però definiscono una macchina virtuale, nei fatti:


L'Hardware è astratto, non è X86 o ARM... è Bytecode/Bitcode/CLR il target (la "CPU")


Non significa niente, perché alla fine della fiera la VM gira sempre su x86/ARM.

Ripeto: la VM spesso è scritta in un linguaggio nativo. Ed è pertanto soggetta a tutti i bug di cui parli.


Le "risorse" sono bloccate e controllate... non posso cancellare il FS sottostante... debbo chiedere il permesso all'utente e pure all'OS probabilmente ;)


Valla a raccontare a qualcun'altro eh...

http://msdn.microsoft.com/it-it/library/system.io.file.delete%28v=vs.80%29.aspx

http://docs.oracle.com/javase/6/docs/api/java/io/File.html#delete%28%29


Le funzioni devono essere "safe" e generare eccezioni non "corare", eccezioni che se uno ce l'ha grosso posso essere gestite o ignorate (!):
il programma continua l'esecuzione bello sereno e paciorotto: se faccio tornare tutto al main() non gestendo NULLA, il rogramma termina e ho il trace chiaro di cosa accade "Belin <out bound exception>? ... ahh che fesso è un array di 12 NON di 13, banale!" Ma lo sai anche tu se usi .NET cosa vuol dire...
SOLO per questo JAVA/NET sono TOGHISSIMI...


Chiamasi bound checking, è solo un controllo in più che puoi fare benissimo con C/C++.

Loro wrappano l'API, quindi sono bravi?


WinRT questo non te lo darà MAI... se è C/C++, va in core: passo indietro :doh:


E chi te l'ha detto? Hai visto l'API? Hai visto il linguaggio?

http://www.google.it/url?sa=t&rct=j&q=winrt%20exception%20class&source=web&cd=2&ved=0CDEQFjAB&url=http%3A%2F%2Fvideo.ch9.ms%2Fbuild%2F2011%2Fslides%2FTOOL-532T_Sutter.pptx&ei=PfE6T_uhIJDp8QO90siOCw&usg=AFQjCNFfdvx-MxalV8LrVNwMDia2nyS2cw&cad=rja

Il C++ non è il C++ classico ma C++/CX che è una estenzione Microsoft (grazie a dio).


Non si gioca con la memoria in maniera raw non esistono puntatori né matematiche di essi (char *sarcazzo = "puppa", sarcazzo++ // sarcazzo = "uppa")... i valori si passano per valore NON per riferimento... di nuovo scomodo e lento? OK, ma salva le chiappe: il pointer può esser sovrascritto.... il valore NO!


In Java e .NET tutti gli oggetti vengono passate per riferimento, in C++ puoi fare lo stesso senza passare alcun puntatore alle funzioni.


Per sua natura è IMPOSSIBILE accedere alla memoria di altri processi e fare "porcate", massimo se ce la fai ottieni un eccezione... non esegui programmi sul computer HOST... ti sfido a scrivere bratta in un String JAVA di un'applicazione che sta girando e fare "cosacce" :mbe:



Chi ti impedisce di scrivere nella memoria di un altro processo è principalmente il sistema operativo, non la macchina virtuale, che in ogni caso è incapsulata in un processo.

Sicuramente la macchina virtuale costituisce una barriera in più, ma non è la panacea di tutti i mali.


WinRT non credo esendo nativo possa garantirmi tutto questo sinceramente... spero di sbagliare, ovvio, ma ne dubito...


Ma non ti sei stancato di fare ipotesi senza informarti neanche un briciolo?


Il C senza POSIX cosa serve? Dal punto di vista mio sono inscindibili, OK?
... e POSIX va in core... quindi? Quindi il C è veloce, bello, lo amo, lo odio, lo detesto, ma è unsafe :eek:

C++ senza stdc++ a che serve? Ci faccio le uova... ho string? Bello... se il char* che soggiace per magia diventa NULL (e può accadere... prova a usare pragma(pack) e pragma(pop) e... divertiti!)? Chiamo il metodo len() fichissimo e... lui poveraccio cosa fa? strlen() ovviamente del buffer sottostante... ohh, ma è NULL ... BAM!!!! Core :muro: :muro: :muro:
Certo poteva controllare prima, ma... NOOO! Dai NON è NULL... per costruzione, no?

Quindi? il C++ è semi-veloce, bello, lo amo, lo odio, , lo detesto, ma è unsafe :eek:

P.S. L'exception handling di Windows sembra funzionare anche con il C... ma è OBBLIGATORIO o optional? La div di 0 automaticamente da un'eccezione o lo fa solo se uso __try() ? JAVA mi OBBLIGA a mettere try/catch se il metodo torna un'eccezione... NET essendo copiato immagino pure... con in più finally che, se non erro, JAVA non possiede...

Ma infatti le librerie standard C e C++ sono una oscenità e sicuramente non possono essere all'altezza del 2012 né tantomeno competere con altre librerie più moderne e pensate meglio (vedi Qt).

Con questo concludo, e ti invito a non sparare più castronerie, perché altrimenti mi costringi a risponderti e non voglio più farlo.

Mi intrometto solo per dire che .NET supporta l'aritmetica dei puntatori e permette di scrivere codice non sicuro (con la keyword unsafe in c#)

Permette anche di allocare esplicitamente la memoria

Ma infatti le librerie standard C e C++ sono una oscenità e sicuramente non possono essere all'altezza del 2012 né tantomeno competere con altre librerie più moderne e pensate meglio (vedi Qt).


Quindi, in sostanza, sei d'accordo con me, vero? Escludendo il resto in cui non sei d'accordo, ovviamente :mbe:

Per il C ahimè non credo ci sia di meglio, purtroppo (intendo per OS non M$) se hai qualcosa che sostituisca POSIX e c. ben pensate e safe ti prego vivamente di suggerirmela... ne sarei lieto... altrimenti mi tocca farla: son stufo di aver core per futili motivi!

D'accordo invece su Qt: bel framework e lo uso con certa soddisfazione :D


Con questo concludo, e ti invito a non sparare più castronerie, perché altrimenti mi costringi a risponderti e non voglio più farlo.

Dai concludiamola qui tanto non ha senso che ci accapigliamo noialtri... bisognerebbe parlarne con i coder M$ probabilmente avranno i loro buoni motivi, anche se mi sfuggono ;)

Ciao e... buon lavoro... torno al mio amato/odiato C :Prrr:

Fammi un esempio.

Stai scherzando, vero ? :asd:
Secondo te l'OS Team se ne è uscito con WinRT solo perchè avevano tempo da perdere ?
Se .Net avesse già pre-incapsulato in classi tutto il necessario ed avesse un sistema di interfacciamento con il codice nativo sufficientemente completo, non avrebbero dovuto reinventare la ruota per l'ennesima volta.

Quello che molti non riescono a capire che .NET e C++ possono convivere tranquillamente, per cui alcune parti le posso fare in .NET ed altre in C++.

E chi dice il contrario ?
Solo che in certi casi è più semplice evitare di usare .Net. ;)

Fatto sta che se vuoi scrivere una app per Windows Phone devi per forza farlo usando uno dei linguaggi .NET, e comunque il risultato sono app fluide e responsive.

Ed il tuo punto sarebbe ?
Ripeto, io ho scritto che .Net va bene solo se fai cose che si appoggiano alle sue librerie per la roba pesante e non devi fare troppa roba con le tue manine a basso livello.


Cosa c'entra con l'affermazione che ho fatto?

Anzi la tua rafforza ulteriormente la mia, dal momento che MS con .NET e Silverlight è riuscita ad essere più performante di Android+NDK.

Non ho parlato di fluidita rispetto ad Android, ecc. ecc.
Mi sembra di aver scritto abbastanza chiaramente che anche su Windows Phone per certe cose hai bisogno del C++ e che per questo Microsoft ha dovuto rinunciare alla sua strategia iniziale "solo Silverlight".
Questo iultimo fatto prova quanto affermavo, non ti sembra ?



Stando a Wikipedia la prima versione .NET risale al febbraio 2002, mentre la prima versione di LLVM risale al 2003.
La versione 1.0 di LLVM è stata rilasciata nel 2003, ma il progetto LLVM iniziò nel 2000 ed era basato su un fottio di R&D precedente.
Tutta roba che in Microsoft apparentemente ignorarono, probabilmente perchè erano più focalizzati su un "anti-Java migliorato" dopo che non erano riusciti a fare il solito "embrace,extend, extinguish" usando la loro MSJVM (Sun li bloccò a colpi di cause legali perchè non implementavano la JVM completa).


Si ma di cosa stiamo parlando? Office non è managed, e non credo che MS voglia farlo diventare managed.

Ribadisco, se il codice è scritto bene, non hai bisogno di un linguaggio managed per la portabilità.

Sigh! Infatti io avevo fatto notare che Office non è stato portato su .Net perchè era inutile farlo, visto che si appoggiava sulle stesse API native che servivano pure a .Net e quindi non sarebbe stato più portabile di prima. ;)