Alcune aziende, come Blizzard, creano software che continua a funzionare bene nelle versioni future di Windows e con versioni più recenti delle loro altre dipendenze software. Altre aziende (per lo più non sono aziende software hardcore) a volte scrivono software che si interrompe con il rilascio di un nuovo sistema operativo o altra dipendenza software. Cosa sanno le aziende del software hardcore che gli altri no? Quali sono le cause principali dei problemi di compatibilità diretta?
Blizzard ha scritto un software che funziona bene con le versioni future di Windows (Starcraft suona ancora su 7 per esempio) ...
o Microsoft ha scritto "versioni future" del software che sta guardando all'indietro?
Qualcosa come WoW non è esattamente "lungimirante" poiché è ancora in fase di sviluppo. Altri software, come Starcraft / Warcraft / Diablo, sono stati scritti per il momento e funzionano ancora perché MS fa il possibile per abilitare il vecchio software sui nuovi sistemi.
Blizzard ha anche l'abilità e la ragione di aggiornare i suoi vecchi giochi. Titoli molto popolari che guidano il suo attuale software.
Alcuni software utilizzano parti di hackish / non standard che non funzionano bene. Configurazioni uniche, dipendenti da bug "vecchi", driver non portati su nuovi sistemi, ecc.
Diversi motivi:
Ecco la mia esperienza: molti anni fa, un prodotto su cui ho lavorato iniziò a supportare plugin di terze parti. Avremmo inviato una richiesta al plug-in, a cui avrebbe dovuto rispondere. Il primo parametro nel plugin era un numero che identificava la richiesta che stavamo facendo. A quel punto c'era solo una una richiesta. Tuttavia abbiamo documentato che dovresti controllare questo numero e se si tratta di un numero che non hai capito, non fare altro che restituire un codice di errore con il significato "Non capisco questa richiesta". Abbastanza semplice La prima versione al nostro fianco è stata gestita correttamente. Anche quando inviamo la prima richiesta (l'unica che potremmo mai inviare) abbiamo controllato se il plugin ha risposto "non capisco" e l'abbiamo gestito.
Quindi abbiamo aggiunto la seconda richiesta. Testato con vecchi plugin in attesa che rispondessero "Non capisco questa richiesta". Tutti i plugin hanno eseguito l'azione per la prima richiesta. Questo non è compatibile con le versioni precedenti :-( Questi plugin erano stati spediti ai clienti e si sarebbero bloccati in modo anomalo con una nuova versione dell'app.
Cosa abbiamo fatto: collocare il software in un contesto in cui la prima richiesta potrebbe essere eseguita senza danni. Inviata una richiesta completamente diversa. Se la risposta non era "non capisco", allora sapevamo che il plugin era stato scritto da idioti e non sono state fatte richieste diverse da quella che abbiamo sviluppato per prime.
Non è possibile garantire la "compatibilità diretta", spetta ai produttori di SO e HW. La cosa migliore che puoi fare quando scrivi software è assicurarti che non stia usando funzioni deprecate o trucchi non standard.
Penso che sia proprio il software compatibile con la scrittura in avanti ad avere più impegno. Se lo sforzo (= costo) vale la compatibilità deve essere valutato dalla società di rilascio.
Ad esempio, gli schemi di database possono cambiare. Potrebbero essere migrati automaticamente (per la migliore esperienza utente) o ignorati (per minori sforzi di sviluppo).
Alcuni programmatori leggono la documentazione e scrivono il codice che usa il sistema operativo nel modo in cui la documentazione glielo dice. Altri programmatori scrivono codice più veloce ed eseguono il debug di qualsiasi codice che non funzioni.
Un buon esempio sarà un codice che non può far fronte a finestre con un numero di versione a due cifre; non fallirà il testing su Windows 8, ma se usato su Windows 10 ... ..
Poi hai i giochi che sono scritti per essere il più veloce possibile, ignorando il sistema operativo senza preoccuparti se funzioneranno tra qualche anno ... ..
Prendi un programmatore che si prenda a programmare il lavoro sul software Unix nei giorni in cui ogni venditore ha una sua versione di unità, che il programmatore sarà molto abituato a leggere gli standard e SOLO a seconda di cosa dicono gli standard. Dato che dover spedire il tuo software su 6 diverse versioni di Unix ti insegna velocemente a fare attenzione. Confrontalo con un programmatore che ha imparato su VB, dove è normale cambiare semplicemente il codice fino a quando non funziona ... Ma metti il "programmatore di tipo Unix" sullo stesso compito del "programmatore di tipo VB" e spesso la persona che ha imparato su VB produrrà un risultato che può essere venduto molto più rapidamente.
Quando intervistiamo lo staff, le persone tendono a scegliere persone affini, quindi una volta che un'azienda ha i primi membri dello staff, il nuovo personale tende a pensare allo stesso modo.
Penserei che la ragione principale della mancanza di compatibilità diretta sarebbe la mancanza di programmatori che lavorano anche per chiaroveggente.
Leggi altre domande sui tag forward-compatibility