di Carlo Nithaiah Del Mar Pirazzini
C’è un certo tipo di storia retro‑informatica che rassicura tutti: si ritrova il sorgente di un vecchio programma, qualcuno lo compila, lo mette online, e il caso viene archiviato sotto la voce “preservazione”. Tutti annuiscono compiaciuti… un pezzetto di storia del software è stato salvato.
Quello che sta succedendo con Directory Opus 5 è più interessante di così. Un progetto su GitHub si presenta come un fork moderno e attivamente mantenuto di Directory Opus 5 Magellan II, aggiornato per AmigaOS 3, AmigaOS 4, MorphOS e AROS, e continua esplicitamente il ramo open source rilasciato con licenza APL nel 2012.
In altre parole: non è un cimelio lucidato per le foto. È software vivo, che deve ancora fare i conti con bug veri, utenti veri e piattaforme reali.
Non è una storia degli anni ’80
Tecnicamente, Directory Opus non è una storia “Amiga anni ’80”. È un fenomeno anni ’90, arrivato proprio quando la piattaforma stava entrando nella sua età matura.
Le cronologie pubbliche collocano:
- Directory Opus 1 a gennaio 1990
- Opus 2 a febbraio 1991
- Opus 3 a fine 1991
- Opus 4 a dicembre 1992
- Il primo Opus 5 nel 1995
- Magellan II entro il 1998
Questa puntualizzazione temporale non è un dettaglio nerd, spiega che cosa fosse davvero DOpus. Non nasce nel momento pionieristico della scena Amiga, quando tutto era esperimento e scoperta. Arriva quando gli utenti sono diventati più esigenti, più tecnici e molto meno disposti a perdere tempo con interfacce scomode.
Nel periodo di Opus, possedere un Amiga significava sempre più personalizzarlo fino a farlo coincidere con le proprie abitudini, non con le scelte preconfezionate di un team di sviluppo. La stessa comunicazione di quegli anni lo sottolinea: un articolo del 1993 su Directory Opus 4.0 lo definiva “il più potente, user‑friendly e configurabile utility di directory disponibile” e lo vendeva sull’idea che l’interfaccia dovesse adattarsi a te, non al programmatore.
File manager, sì. Ma soprattutto identità
Sulla carta, Directory Opus era “solo” un file manager. In pratica, era uno di quei programmi che insegnavano all’utente a comportarsi come un operatore di sistema, più che come un semplice “utilizzatore finale”. È un aspetto facile da sottovalutare oggi, in un mondo dove file system, percorsi e gerarchie sono sempre più nascosti dietro ricerche full‑text e interfacce minimal.
L’Amiga, al contrario, premiava chi capiva davvero com’era fatta la macchina. Directory Opus si inseriva perfettamente in questo scenario. Non è un caso che, nella descrizione del progetto open source moderno, DOpus 5 venga definito anche come un “clone di Workbench” con funzioni di gestione file.
Quando DOpus 5 ha raggiunto la sua piena maturità, non era più soltanto il tool che aprivi per copiare file da un disco all’altro. Per molti utenti era diventato uno dei modi principali attraverso cui “pensare” al proprio Amiga: una lente fissa sul sistema, non un accessorio.
Questa centralità emerge anche dalla cultura che gli gira attorno. Il manuale ufficiale di Directory Opus 4 segnala, ad esempio, che l’edizione AmigaGuide era distribuita insieme alle versioni coverdisk di DirOpus 4.12, e gli archivi delle riviste confermano che CU Amiga (febbraio 1995, coverdisk 100) includeva “Directory Opus v4” sul disco di copertina.
Non significa “monopolio assoluto”, ma è un indicatore forte: finisci sui coverdisk quando la redazione ti considera parte del “sangue” della piattaforma.
L’eredità vera: ambizione, non nostalgia
L’importanza di Directory Opus nel lungo periodo non sta nel fatto che fosse amato. Di utility amate l’Amiga ne ha avute molte. Il punto è che DOpus ha contribuito a normalizzare l’idea che un “vero” utente Amiga potesse pretendere molto di più da un file manager: più controllo, più scripting, più integrazione, più personalizzazione, più leva operativa.
È anche per questo che l’evoluzione in direzione Magellan è così significativa: la linea di prodotto si sposta da “potente utility di directory” a qualcosa di molto più simile a un ambiente desktop configurabile e a un sostituto di Workbench. Da lì puoi tracciare una linea quasi retta verso il tipo di utente che, nel 2026, continua a interessarsi agli ecosistemi “Amiga‑like”: gente che non cerca la comodità a ogni costo, ma la possibilità di stabilire un rapporto quasi intimo con il software.
Un mondo in cui:
- L’interfaccia non è sacra.
- Il workflow non è fisso.
- I “default” sono un inizio, non un dogma.
Directory Opus è stato uno dei programmi che hanno insegnato a tutta una generazione a pretendere questo tipo di libertà.
Il fork attuale è interessante proprio perché non si comporta come un progetto da museo. Non è una repository messa lì a prendere polvere, ma un codice su cui si lavora attivamente.
Le nuove versioni
La 5.95 risolve un blocco in fase di avvio su MorphOS e modernizza la gestione dell’IPC per avvicinarla alle build OS4 e AROS. La 5.96 importa un set di fix su risorse, memory leak e alcune modifiche di UI/UX derivate da Galileo. La 5.97 chiude una perdita di risorse legata allo zoom gadget di sistema e ripristina le tooltip che sparivano dopo i clic sui gadget.
Questo è il tipo di lavoro che spesso nessuno cita quando si parla di “preservazione”. Preservare software non significa solo archiviare il sorgente su un server.
Vuol dire:
- combattere con freeze in fase di startup;
- smontare assunzioni obsolete sulle ABI;
- sistemare ownership di memoria;
- inseguire regressioni sui widget;
- adattare vecchio codice a toolchain moderne.
Leggendo il changelog, sembra più un’officina che un santuario. Ed è esattamente quello che si vorrebbe vedere da un revival serio.
5.97: un micro‑update che racconta molto
La release 5.97 di Directory Opus 5 per “All Amigas” non introduce nuove funzioni visibili all’utente, ma sistema due bug molto specifici nella gestione delle finestre dei lister, abbastanza sottili da passare inosservati e abbastanza fastidiosi da valere una versione dedicata.
Cosa cambia nella 5.97
Il primo bug corretto in 5.97 riguarda una perdita di memoria ogni volta che si apriva e chiudeva un lister, legata al gadget di zoom di sistema della finestra. Durante l’apertura del lister, la funzione lister_open_window modificava il gadget di zoom am azzerando i bit GTYP_SYSGADGET | GTYP_SYSTYPEMASK e impostando GadgetID = GAD_ZOOM, così l’handler di DOpus poteva intercettare l’evento.
Il problema è che Intuition libera automaticamente la memoria solo per i gadget che riconosce ancora come “system gadgets”: dopo la modifica, quel gadget non veniva più trattato come tale e la memoria associata non veniva rilasciata alla chiusura della finestra.
La soluzione adottata in 5.97 è pulita: all’apertura della finestra, DOpus salva i valori originali di GadgetType e GadgetID del gadget di zoom, li sostituisce con quelli necessari al proprio handler, e poco prima di chiamare CloseWindow ripristina i valori originali. In questo modo Intuition, al momento della chiusura, vede di nuovo un vero gadget di sistema e ne libera correttamente la memoria, eliminando il leak.
Il secondo bug riguarda le tooltip della toolbar dei lister. All’apertura del lister, le tooltip funzionavano regolarmente, ma dopo il primo clic su qualsiasi gadget (anche cambiando modalità da Icon a Name tramite menu) le tooltip smettevano di apparire per tutta la vita di quella finestra. Il motivo era nella gestione di IDCMP_GADGETUP: ogni rilascio di gadget rimuoveva IDCMP_INTUITICKS dalla maschera degli eventi della finestra, disattivando proprio il meccanismo temporizzato che alimenta le tooltip.
In 5.97 questa gestione viene corretta: la routine di GADGETUP lascia attivo INTUITICKS, allineandosi all’intento già documentato nel percorso di IDCMP_MOUSEBUTTONS. Risultato: le tooltip continuano a funzionare correttamente anche dopo aver interagito con la toolbar, senza effetti collaterali sugli altri eventi di input.
Nel complesso, la 5.97 è un aggiornamento chirurgico che non tocca formati, API o IPC, ma aumenta stabilità e qualità d’uso intervenendo su due dettagli che colpiscono proprio il cuore dell’esperienza quotidiana: l’apertura e la gestione delle finestre dei lister. Il repository documenta chiaramente le piattaforme supportate; punta l’utente verso release precompilate; spiega come compilare il tutto tramite toolchain cross‑compile per ogni sistema di destinazione, inclusa un’immagine Docker che integra i quattro toolchain.
Sul fronte legale, il progetto è esplicito: il codice Amiga è distribuito sotto AROS Public License 1.1; il marchio “Directory Opus” resta limitato alle piattaforme Amiga‑like e non interferisce con il prodotto commerciale per Windows sviluppato da GPSoftware. Questa chiarezza tecnica e legale dà al fork una credibilità che manca a molti revival retro “solo a vibe”. Qui l’obiettivo è essere leggibili come vero progetto di ingegneria del software, non solo come oggetto di culto.
Quello che sopravvive è una filosofia, la versione più facile di questa storia dice: “una classica applicazione Amiga è stata riportata in vita”. La versione più accurata dice che, in realtà, Directory Opus non ha mai smesso del tutto di vivere, ha conservato abbastanza peso pratico ed emotivo da spingere persone, negli anni, a portarlo su nuove piattaforme, aprirne il codice, impacchettarlo e ridistribuirlo, digitalizzare manuali, preservare coverdisk e documentazione e oggi, lavorare attivamente sul suo codice per adattarlo a più sistemi derivati dall’Amiga.
Questa persistenza racconta qualcosa di preciso sul mondo Amiga ovvero che il software migliore, spesso, non era “solo software”. Era un modo di intendere il personal computing: diretto, flessibile, modellato sull’utente, un po’ ossessivo, a tratti indisciplinato, e difficilissimo da sostituire una volta che ci avevi fatto la mano.
È per questo che vale la pena guardare con attenzione a Directory Opus 5.97 e ai suoi successori. Non tanto perché “torna un nome storico”, ma perché quel nome continua a essere portatore di un certo ideale di macchina personale, ancora vivo, ancora discutibile, ma soprattutto ancora utilizzabile oggi.
Github: https://github.com/midwan/dopus5allamigas/releases/tag/5.97
