Ancora Newton: il bug del 2010

Come accennavo nella prima parte della mini-serie sulla storia del Newton, il problema più grosso che affligge oggi la comunità di utenti Newton è il cosiddetto ‘bug del 2010’. Questo problema si riteneva pressoché risolto, dato che tempo addietro Avi Drissman (programmatore noto alla comunità Newton soprattutto per l’ottimo Avi’s Backdrop, un’elegante applicazione per la ‘scrivania’ del Newton che consuma pochissime risorse) aveva rilasciato un programma chiamato Fix2010 (vedere la pagina del sito di Drissman dedicata al software per il Newton). Il programma, però, è tuttora in alpha, e dopo che alcuni membri di NewtonTalk si sono presi la briga di installarlo e collaudarlo si è constatato che non è risolutivo e, almeno sui MessagePad con l’ultima versione del NewtonOS (2.1), i problemi rimangono.

Eckhart Köppen, uno degli sviluppatori Newton rimasti ancora molto attivi (è autore, fra le altre cose, di un browser, di un lettore di RSS, e di una serie di plug-in per il Newton che ne espandono le possibilità — senza di lui non avremmo il Bluetooth sul Newton), ha deciso di investigare il problema e ne parla in questa pagina del suo sito. Eccone una traduzione:

Il problema dell’anno 2010 nel Newton

Il NewtonOS presenta un bug nella gestione degli anni a partire dal 2010. Il bug si trova nell’interfaccia NewtonScript inerente a determinate funzioni temporali, ed è provocato da un overflow di un valore intero di NewtonScript. Tale bug sembra manifestarsi soltanto in dispositivi con NewtonOS 2.1.

L’orologio del Newton

Nei dispositivi 2.1, il Newton prevede un orologio in tempo reale ad alta risoluzione (RTC — Real Time Clock). L’interfaccia verso il RTC è la classe TURealTimeAlarm in LongTime.h. I valori temporali vengono registrati in oggetti della classe TTime. Il RTC può gestire intervalli di tempo molto lunghi, ma la maggior parte delle funzioni utilizzano numeri interi non firmati a 32 bit come secondi a partire dall’1 gennaio 1904.

Classi e Funzioni

C++

Le funzioni C++ più comuni sono le funzioni RealClock e RealClockSeconds per leggere il RTC, e le funzioni SetRealClock e SetRealClockSeconds per impostare il RTC. La base per tutte queste funzioni è sempre l’1 gennaio 1904, e la risoluzione è in minuti o secondi. L’uso di un numero intero non firmato a 32 bit crea un problema di overflow nell’anno 2040. In generale, si possono considerare tutte le funzioni C++ sicure e senza problemi fino al 2040.

NewtonScript

Le funzioni NewtonScript sono tutte basate sul RTC — non esiste un orologio mantenuto separatamente per il livello del NewtonScript. Tali funzioni si basano sulle funzioni RealClock descritte sopra, e funzionano con risoluzione in minuti o secondi.

La funzione Time funziona con una base temporale incentrata sull’1 gennaio 1904. La funzione TimeInSeconds, e tutte le funzioni che utilizzano i secondi come risoluzione si servono di una base temporale che parte dall’1 gennaio 1993.

Il bug

L’overflow avviene in tutte le funzioni NewtonScript che utilizzano i secondi come risoluzione. A differenza del numero intero non firmato a 32 bit impiegato dalle funzioni C++, gli interi in NewtonScript sono soltanto a 30 bit. Mentre le funzioni C++ possono gestire l’intervallo fra il 1904 e il 2040 senza un overflow, le funzioni NewtonScript devono essere ideate con un intervallo minore a causa della loro limitata precisione.

Le funzioni basate sui secondi vengono implementate prendendo il valore dell’orologio in tempo reale (RTC), sottraendo lo spostamento all’1 gennaio 1993, e convertendo il risultato in un numero intero NewtonScript. Questo intervallo più ristretto e limitato provoca un overflow nel 2010.

I possibili fix

Riformulare una base per le funzioni temporali basate sui minuti

Il problema di un overflow nelle funzioni basate sui secondi è provocato dall’orologio di sistema che raggiunge e supera la data dell’overflow. Assicurandosi che l’orologio di sistema rimanga all’interno dell’intervallo ‘sicuro’, è possibile evitare l’overflow. Questo tipo di soluzione è stato implementato da Avi Drissman nel pacchetto Fix2010. Fix2010 impiega il concetto della ‘hexade’ (ossia 16 anni) e regola tutte quelle funzioni che si servono dei minuti come base temporale in modo che rientrino sempre nell’intervallo di tempo ‘sicuro’, tenendo conto della differenza di intervallo del gruppo di sedici anni.

Riformulare una base per le funzioni temporali basate sui secondi

Un approccio più a basso livello è quello di cambiare la compensazione impiegata dalle funzioni basate sui secondi in modo che l’intervallo di tempo ‘sicuro’ inizi e finisca più tardi.

Considerazioni

Per ognuna delle soluzioni, occorre tenere in considerazione alcune insidie. Le parti del NewtonOS non sistemate potrebbero attivarsi prima che la patch entri in funzione (per esempio al riavvio o dopo un cold boot), e certi dati potrebbero presentare dei valori errati. Per ora rimangono aperte le seguenti problematiche:

  • Lo stato dell’orologio dopo la perdita del tempo: l’orologio in tal caso si resetta e torna al 1996, e questo valore può entrare in conflitto con le funzioni a cui è stata applicata la patch.
  • Gli allarmi: gli orari in cui è stato impostato un allarme potrebbero essere alterati se l’allarme è stato inserito senza la patch.
  • Certe assunzioni precodificate inerenti alle basi temporali: quei programmi che presumono che le funzioni basate sui secondi inizino sempre nel 1993 potrebbero smettere di funzionare.

È interessante inquadrare tutta la questione alla luce delle osservazioni dell’ex ingegnere Newton che ho pubblicato nelle quattro parti sulla storia del Newton. È chiaro che per applicare una simile patch occorre effettuare un reverse-engineering dell’ultima patch di sistema, che è quel che ha fatto Köppen qualche giorno fa, scrivendo in lista NewtonTalk: Pare che creare delle patch proprie sia meno complicato di quel che si pensava. […] Sono stato in grado di ricreare la patch originale [717260] dai sorgenti e fare qualche esperimento con piccole modifiche. Esistono ancora dei problemi da risolvere, ma in generale è di certo meno magia nera di quanto anticipato. In bocca al lupo, Eckhart. Documenterò eventuali risoluzioni.

Category Mele e appunti Tags ,

About Riccardo Mori

Writer. Translator. Mac consultant. Enthusiast photographer. • If you like what I write, please consider supporting my writing by purchasing my short stories, Minigrooves or by making a donation. Thank you!