Notch: non passate a Windows 8

Riguardo a questo punto ho già risposto ad hexaae, per il resto ...



Infatti è quello che sto facendo attualmente, ma dalle mie parti si chiama avere come target principale Windows 7 ed ignorare Windows 8 per quanto sia possibile.
Nel senso che se ci sono problemi li si risolve, ma non si usano funzionalità che costringerebbero a dover avere due versioni distinte per Windows 7 e Windows 8, in altre parole ignorare WinRT.



Se non fosse che la retrocompatibilità è uno dei punti di forza di Windows.



Solo che secondo le loro dichiarazioni, Metro e WinRT sono "il futuro"
e l'intero ambiente desktop lo hanno classificato "legacy"; è li che sta il vero problema.
Allo stato attuale per moltissime applicazioni Metro e WinRT non valgono un porting, per quel che miriguarda preferisco attendere e vedere se si rendono conto del problema invece di investire tempo e risorse ora e poi (dopo essermi svenato ecc. ecc.) sentire Microsoft che annuncia funzionalità che mi avrebbero semplificato enormemente il lavoro.



La differenza è che nelle specifiche dell'ELF è inclusa l'ABI (Application Binary Interface) ed è bella solida rispetto a quello che ha fatto Microsoft.
Mentre nel caso di PE l'ABI è "ballerina"



Per questo nel post avevo scritto "quelli che si sono fermati a win32"
Il passagio da win16 a win32 era decisamente vantaggioso, da li in avanti ...



Legacy, purtroppo. Notare che alla sua base c'è un pattern PIMPL che avrebbe permesso di renderla sicura ed object oriented in passi successivi mantenendo la retrocompatibilità in modo molto più semplice che con l'approccio seguito invece da Microsoft (basato sul seguire la mdoa del momento a modo loro).


Infatti WinRT in un certo senso è una loro evoluzione.



"Prodotti vincolati a Microsoft" sarebbe la definizione più corretta.
Per quel che mi riguarda sono rimasto con win32 e più avanti quando verrà il tempo e non ci saranno rogne probabilmente farò la transizione a WinRT tramite il porting di Qt.



Per questo ho evitato .Net, nel senso che non è significativamente multipiattaforma e sotto vari aspetti è "il nuovo VisualBasic"; quello fino a VB6 per intendersi, con un runtime tutto suo che Microsoft cercava di infilare per partito preso ovunque, lo aveva infilato persino dentro Internet Explorer come linguaggio di scripting in competizione con Javascript ed è ancora presente dentro Office.
Quando poi Microsoft decise di rottarne la versione standalone a vantaggio di .Net fu poi un casino fare il porting verso la "nuova terra promessa" di Microsoft (specialmente per le particolarità e le idiosincrasie che Microsoft stessa ci aveva infilato dentro), infatti VB.Net era quasi totalmente incompatibile con VisualBasic (sintassi simile, ma varie differenze e sopratutto librerie e sistema ad oggetti troppo differente).
Pensa che ho ancora una applicazioni scritta in VB6 che prima o poi dovrò portare in C++ e Qt (il porting per ora non vale la pena, ma quando verrà il momento sarà più facile farlo verso C++ e Qt che verso .Net).



Per ora non lo causa, ma il messaggio inviato da Microsoft è stato sin troppo esplicito.

Comunque è così da sempre... si scrive codice per una determinata piattaforma, si cerca di campare finché dura, poi si prende il codice, si butta quello che non si può portare, e col resto si parte per fare una versione adatta al sistema in voga al momento. Vedi chiunque sviluppi giochi per console, che ad ogni giro spesso deve reinventarsi la ruota, perché chiaramente sviluppa solo con l'idea di finire il lavoro con le minori spese possibili.

Se il codice è scritto bene, quindi a oggetti e in layer modulari, il più possibile indipendenti dall'hardware e data driven, il porting da e verso qualunque piattaforma/linguaggio/API è relativamente semplice. Se poi il linguaggio è lo stesso (che so C++), l'hardware pure (che so, un PC), cambiano solo le API (che so WinRT)... non è che richieda chissa quale lavoro. C'è da rifare tutto il layer UI, ok... ma la logica è quella e quella rimane.

Chiaro che se invece uno a scritto codice che funzionasse, magari anche robusto, quello che vuoi, ma con buona parte dei dati hardcodati, non modulare, ma tutto mischiato, sia il codice vero e proprio, che le API, ecc... bè... lì la vedo bigia, ma non è colpa di Microsofr a questo punto.

Ma pure io intendevo in tal senso, solo che non mi sembra di vedere stadi pieni di sviluppatori che fanno la ola per l'arrivo di VS2012.

Se non altro perchè la parte più significativa della nuove funzionalità di VS2012 riguarda il supporto per Metro e WinRT (ed una IDE più gradevole più piccole aggiunte alle funzionalità già presenti, ma non qualcosa di così eccezionale).

Perché ti risulta per caso che non puoi compilare e far eseguire una applicazione pensata per XP sotto Vista e/o 7? Salvo casi particolari (citati più sotto) la quasi totalità di applicazioni per XP gira tranquillamente.

Dopodiché parli di Linux dove ogni settimana esce una nuova versione delle varie librerie? Nota bene, le API di Windows mettono a disposizione tutta una serie di funzionalità che sotto Linux sono implementate tipicamente da librerie di terze parti, che vengono costantemente e freneticamente aggiornate, quindi non direi proprio che Linux sia un campione di stabilità in tal senso, anzi è tutto l'opposto considerata la frammentazione e appunto il fatto che ogni 3x2 cambiano il kernel.

Tant'è che tanti moduli custom per il kernel è difficile trovarli per l'ultima versione, quasi sempre per 2.6.32 o 37, raramente 3.0... e siamo al 3.5.

Una applicazione alla quale stiamo lavorando non compila più se passiamo dal gcc 4.6 al 4.7, tanto per la cronaca. E giù a sistemare la codebase.

Lasciamo stare.



Win16 è stata deprecata (finalmente direi) con i sistemi a 64 bit, Win32 è stata forse l'API più longeva in assoluto, chiaramente sono state aggiunte diverse funzioni, ma non mi pare che ci siano stati grossi problemi.

Per 10 anni si è stati con Windows XP, e programmi che girano su Windows 2000 girano ancora oggi su Windows 7, quindi di cosa stiamo parlando?

ActiveX andrebbe deprecato da una vita, ma ancora non si decidono a farlo e non vedo cosa c'entri comunque con il tuo discorso, se non tanto per allungare una lista che a conti fatti è corta.

La maggior parte delle incompatibilità con Vista erano fondamentalmente dovute a 2 fattori:

1) gestione di privilegi diversa
2) major number di Windows passato da 5 a 6 (tant'è che ti faccio notare per questo motivo sia Windows 7 che Windows 8 continuano a tenere il 6 come major number).

Windows è forse il sistema operativo con la maggiore retrocompatibilità in assoluto, direi che qualche aggiustino alla code base ogni tanto si può fare o no?

Sarà forse che gli sviluppatori si sono abituati così tanto ad XP per 10 anni che non hanno più voglia di fare il loro lavoro...

Dopodiché ricordo a tutti che sono le app a dover essere pensate per il SO e non il contrario.

WinRT non sarà niente di che, ma intanto è la prima API nativa ad oggetti a poter essere programmata con svariati linguaggi di programmazione e che non ha bisogno di binding particolari o wrapper per esportare le funzionalità negli altri linguaggi.

Dopo anni di Win32 direi che era il minimo che potessero fare. Considerato anche che ormai il paradigma ad oggetti ha svariati anni sulle spalle, sarebbe ora di fornire una API OO nativa come cristo comanda.

Devo ringraziare chi ha postato il link ai requisiti per la certificazione:
http://msdn.microsoft.com/it-it/lib...s/hh694083.aspx
al massimo vengono accettate applicazioni fino a PEGI 16.
Un gioco PEGI 18:
http://www.mobygames.com/attribute/...buteId,426/p,3/
sarà escluso oppure censurato.
Chissà come sarà Dead Space censurato, magari al posto dei necromorfi metteranno i teletubbies ;-)

Appunto e proprio per questo al momento per interi settori applicativi non è il momento di fare il porting verso WinRT, ma attendere, vedere come butta e solo al momento giusto fare il porting (ne prima, ne dopo, in entrambi i casi ci si rimetterebbe).
Sul lato Windows io ho ignorato totalmente .Net (interi anni-uomo risparmiati e salute mentale che ci guadagna) e probabilmente farò il passaggio da win32 a WinRT, ma non è ancora il tempo, se Microsoft prende una batosta di quelle serie su fronti "caldi" come quello dei tablet, potrebbe riconsiderare in modo drastico la sua strategia con modifiche massicce a WinRT ed all'ecosistema che gli vuole costruire attorno.

premesso il fatto che questo commento e' degno di capitan ovvio -non te la prendere, non lo dico per flammare- dato che mi sembra scontato che faccia i suoi interessi altrimenti lavorerebbe alla caritas o giu' di li -e avrebbero grossi problemi a tenerlo vicino a tutto quel cibo gratis xD- ma il punto mi sembra un altro, ovvero le possibilita' per il futuro e relative liberta'...se il primo passo e' lo store su win 8 e altre amenita' non posso far finta di nulla e non farci un pensiero, poi ovvio che essendo software o aziende private debbano anche guardare al profitto ci mancherebbe, ma direi che IL MODO in cui lo fanno e' cio' che fa la reale differenza...

utilizzo w8 da un po' ..... messo anche a dominio e funziona correttamente, utilizzando il software gratuito " classic shell " mi da il menu start uguale a w7 o xp a seconda della personalizzazione.

inoltre sul tablet iconia w500 che ha w7 fatto upgrade a w8 si è velocizzato notevolmente..... nn capisco tutto questo terrorismo mah....

Bé, ho scritto Visual Studio 2012 per dire Visual Studio in se... solo la versione express, che è gratuita e permette di sviluppare anche app dekstop alla vecchia maniera, ha un IDE che è avanti anni luce rispetto agli altri.

Infatti dovrebbero additare il vero problema non Windows 8 che non c'entra nulla... e dire che se Microsoft dovesse un giorno chiudere il supporto ad applicazioni no WinRT, loro scomparirebbere.

Dire "Windows 8 è una cagata" non ha senso e non fa che alimentare flame, e uno come Notch lo sa e ci marcia sopra per avere più gente che poi dice "Grande Notch, non pensavo. Mi è sempre sembrato un giochetto da nulla, ma quasi quasi Minecraft lo provo, uno così non può che aver fatto un gran gioco".