Nota bene: l'articolo proposto in questa pagina è proprietà degli autori e non può essere distribuito o riutilizzato in alcun modo o forma senza il loro consenso scritto.
Le informazioni qui riportate risalgono alla data di pubblicazione dell'articolo e non è detto che siano ancora valide o che rispecchino lo stato attuale dei programmi, le posizioni delle persone interpellate o degli autori stessi.

Introduzione

Jacek Rzeuski è un nome che forse non risulterà familiare a molti, se si eccettuano i fan dell'overclocking estremo, ramo nel quale è considerato la bibbia vivente. Eppure questo personaggio gode di una popolarità crescente da quando ha preso in mano e sta aggiornando con successo i sorgenti di Directory Opus 4, forse il più celebre programma Amiga, recentemente rilasciati come GPL.

Intervista

D: Ciao, Jacek Fino a poco tempo fa il tuo nome non era fra i più conosciuti nella comunità Amiga. Cosa hai fatto prima di approdare a Directory Opus? Come hai iniziato e da quando usi Amiga?

R: Innanzitutto tengo a precisare che Directory Opus 4 non è un mio progetto. Ne ho solo aggiornato i sorgenti, rilasciati sotto licenza GPL da GP Software. Ho realizzato anche altri programmi, a scopo personale o di studio. Tra quelli rilasciati su Aminet posso segnalarvi: Win2Front, una semplice commodity per "esplorare" le finestre aperte sul WB, MUI_Frecell, un solitario basato su MUI, ispirato alla controparte per Win95, e WOSPrefs, un programma di peferenze per WarpOS, Warp3D e StorMESA.
Ma non è tutto. Dovrei terminare un editor di livelli per il noto gioco strategico HistoryLine 1914-1918. Attualmente sto partecipando allo sviluppo di Myzar, una GUI per il client RC5. Nello specifico mi occupo dell'implementazione di un grafico della velocità che, in un prossimo futuro, diverrà una classe MUI con supporto esteso a più CPU (PowerPC incluso). Ho anche scritto un programma di preferenze per "Heretic Fortress", un modulo aggiuntivo di Heretic 2. Il progetto è completo ma ancora non rilasciato pubblicamente.



Immagine Il buon vecchio Directory Opus 4 con un tocco di modernità.

D: Navigando nella Rete abbiamo scovato tuoi interventi dai quali si desume una certa familiarità non solo con il software ma anche con l'hardware, in particolare le schede BVision. Hai dei suggerimenti da dare ai lettori di Amiga Life riguardo a moltiplicatori, quarzi e alimentazione?

R: Sì, mi interesso anche di hardware. Mio padre è specializzato in elettronica e, a volte, l'ho aiutato nel suo lavoro. Ho iniziato ad usare il saldatore a sette anni, ero molto attratto dall'elettronica dei computer e spesso "giocherellavo" con i miei Amiga sotto lo sguardo vigile di mio padre (che allora lavorava presso un centro Commodore). Così, non potendo resistere alla tentazione di mettere le mani anche sulle BlizzardPPC, ho prelevato dai siti di Motorola e Cypress (il produttore dei chip dei controller SCSI, NdR) tutta la documentazione di CPU e chip.
Cercando di risolvere i problemi legati ad alimentazione e surriscaldamento, sono riuscito anche ad approfondire le metodiche di overclock delle BlizzardPPC, ricavandone informazioni che che sono poi state pubblicate su mailing list e web. Ciò che ho dedotto dalle molte discussioni sull'argomento è che le schede con maggiori problemi sono quelle con '040/25: il voltaggio del connettore di alimentazione della ventolina non deve essere inferiore a 4.85V. Un voltaggio più basso, probabilmente non gradito dai chip della RAM, potrebbe provocare dei blocchi accidentali di sistema. Tutto ciò si manifesta generalmente con l'aggiunta della BVision, che prende l'alimentazione proprio dalla BlizzardPPC causando cali di tensione. Ma quello dell'alimentazione, in realtà, non è il solo problema. Infatti, dopo l'inserimento della BVision, ho iniziato a riscontrare dei blocchi di sistema provocati dall'eccessivo surriscaldamento del chip che gestisce la logica posto sotto la ventolina del PPC. Così, dopo aver sostituito la ventolina originale con una per Celeron, ho deciso di progettare un mio sistema di raffreddamento e di inserire tutto in un PowerTower (non Mikronik). Questi suggerimenti sono stati utili ad altre persone anche se, in teoria, basterebbe collocare una lamiera tra il chip incriminato e la ventolina originale. C'è anche da dire che il Permedia2, per un uso prolungato, ha bisogno di un'ulteriore ventilazione. DCE, a conoscenza della questione, munirà le nuove BVision di dissipatore.

D: Parliamo di Directory Opus 4. Quando hai deciso di occupartene e perché?

R: Ho preso questa decisione subito dopo il rilascio dei sorgenti. Uso Directory Opus 4 abitualmente, ma era necessario apportare alcune modifiche alla versione attuale, che contiene molte parti di codice anteriori all'OS2.0. Il supporto a sistemi RTG, ad esempio, è quasi nullo.
Molti dicono che stia perdendo il mio tempo e mi consigliano di passare a Directory Opus 5: è una questione di gusti. Sono abituato al tipico "filemanager" suddiviso in due finestre. Ho provato più volte, ma senza esito, a passare a Directory Opus 5.
Il riscontro inaspettato che ho ottenuto con il rilascio della prima versione mi ha fatto molto piacere e mi ha realmente stupito in quanto non pensavo che Directory Opus 4 avesse ancora tanti seguaci! Insomma, tutto ciò è uno sprone a proseguire il mio lavoro.

D: Si sa, interpretare codice scritto da altri è quasi più difficile che crearne di proprio. Che approccio hai usato per comprendere i sorgenti di Directory Opus?

R: Sì, è difficile, specialmente se i sorgenti non sono commentati, come nel caso di Directory Opus 4. Le difficoltà, poi, aumentano a causa del pesante utilizzo di variabili globali, che vengono definite in un sorgente e referenziate e modificate in un altro. E' veramente arduo tenerne traccia e capirne il significato. I sorgenti, inoltre, sono molto grandi: solo quello relativo al programma principale occupa 1 MB. Introdurre delle modifiche significa dover rintracciare il codice inerente e cercare di comprenderlo a fondo. Senza farlo, non è possibile prevedere come quel particolare cambiamento influenzerà il funzionamento del resto del programma. Ad esempio, tornando alle variabili globali, è necessario individuare tutte le chiamate al codice modificato e analizzarle. Alcuni, lamentandosi della lentezza con cui lo sviluppo procede, mi dicono: "ehi, cambia solo questa linea di codice e funzionerà". Probabilmente sarà pure così, ma qualcosa potrebbe non andare o smettere di funzionare correttamente. In questo modo, come risultato, otterrei un solo utente soddisfatto e dieci (o più) persone che si lamentano. Per questo, prima del rilascio pubblico, tutti i cambiamenti apportati vengono discussi sulla mailing list e testati a dovere.

D: Hai incontrato difficoltà impreviste durante questi primi mesi di sviluppo?

R: Sicuramente. Ho deciso di compilare i sorgenti usando il GCC perché ho cancellato la mia copia illegale del SAS/C molto tempo fa. Il GCC è migliore del SAS e, cosa importante, è ancora sviluppato. Purtroppo, però, i sorgenti preparati con quest'ultimo vanno ritoccati prima di poter essere compilati con il GCC (alcune direttive degli include non sono compatibili, così come non lo sono tutte le chiamate a funzioni che usano specifiche per l'indiririzzamento diretto dei registri, ad esempio gli hook) e, inoltre, ho dovuto rendere compatibili gli include del GCC per via della dopus.library e di altre librerie usate.
Le parti scritte in assembly hanno costituito un'ulteriore difficoltà: il GCC non riconosce tali porzioni di codice e ho dovuto cercare un assemblatore esterno. La scelta è caduta su PhxAss in quanto è freeware, ancora supportato e non aveva problemi nella compilazione dei sorgenti. Quantunque non abbia mai usato un assemblatore, devo ammettere di aver imparato molte cose leggendo la documentazione di PhxAss.
Il problema finale è stato quello di effettuare il link di tutti i sorgenti e generare l'eseguibile vero e proprio. A questo punto si è presentata un'ulteriore magagna: una parte di dati destinata alla CHIP veniva posta nella memoria pubblica (Fast, ndr), causando errori nella visualizzazione di alcuni gadget su sistemi privi di scheda grafica o del patch FBlit. Senza poi dimenticare la prima versione che aveva problemi di stack se lanciata da CLI. Devo comunque dire che tutte queste difficoltà erano semplicemente causate dalla mia iniziale inesperienza nell'utilizzo del linker.



Immagine La sezione di EGroup (successivamente diventato Yahoo Groups, NdA) in cui è ospitata la mailing list di Jacek Rzeuski.

D: Sappiamo che ci leggono molti programmatori, persone che magari vorrebbero seguire le tue orme e prendere in mano altri programmi di cui sono disponibili i sorgenti. Che consigli daresti loro?

R: Non aspettatevi che sia una cosa facile. La legge di Murphy sostiene che ciò che sembra facile è difficile e ciò che sembra duro è impossibile. Ma non fateci troppo affidamento, molto dipende dal codice. Ad ogni modo il mio suggerimento è quello di non effettuare conversioni per Amiga da altre piattaforme se non si ha una grande conoscenza di ambedue i sistemi. Riprendere lo sviluppo di applicazioni Amiga già esistenti è più facile, ma bisogna essere preparati al fatto che la comprensione del codice altrui non lo è. Molti imparano la programmazione scrivendo applicazioni e capita che utilizzino soluzioni assai bizzarre. Quando riguardo le mie prime creazioni mi è difficile credere che sia stato proprio io a scriverle. Senza contare che molto spesso capita che programmatori esperti scrivano un codice di difficile comprensione. Ma mai lasciare nulla di intentato! Anche se l'esperimento non dovesse andare a buon fine c'è sempre qualcosa da imparare.

D: Quali progetti hai per Directory Opus al momento? Magari l'implementazione di un client FTP simile a "OpusFTP" di Magellan o qualche altra funzionalità analoga? E, oltre a Directory Opus, pensi di prendere in mano altri progetti simili?

R: Attualmente Directory Opus ha un ottimo supporto ARexx, che credo sia possibile sfruttare per l'implementazione di funzioni FTP. Purtroppo non ho mai imparato la programmazione ARexx, sebbene ci abbia provato.
Alcune persone mi chiedono di rendere Diretory Opus 4 simile a Magellan. Beh, non credo che lo farò. A chi ricerca in Directory Opus 4 le stesse funzionalità di Magellan, come la possibilità di usarlo in alternativa al WB, suggerisco di acquistare Magellan stesso. Modifiche tali richiederebbero una totale riscrittura, come ha fatto anche GP Software abbandonando lo sviluppo di Directory Opus 4.
Riguardo quest'esperienza posso dire di aver acquisito conoscenze di cui farò tesoro in futuro. Sfortunatamente, per quanto concerne l'eventualità di dedicarmi ad altri progetti simili, la cronica mancanza di tempo che mi affligge mi costringe a lavorare su questi programmi (e sulla continuazione di Directory Opus) nei soli momenti liberi. Nonostante ciò sono sempre disponibile ad offrire il mio aiuto ad altri programmatori che ne avessero bisogno.

Indirizzi utili

Gli indirizzi pubblicati sono stati verificati ed aggiornati a maggio 2019.