Egli è un tipo schivo, che solitamente se ne sta in disparte, senza dare confidenza a nessuno. Non è un amante dell'avventura e, nonostante l'incredibile somiglianza con Link, disdegna perfino i videogiochi... Piuttosto che perdere del tempo prezioso standosene con un inutile "joystick" tra le mani, il piccolo Linker preferisce meditare sui libri e studiare il "BASIC" ed il "Linguaggio Macchina", per poi trascorrere ore ed ore a sperimentare codici e programmi sul suo fido "Commodore 64", che del "Nintendo Enterteinment System" non sa che cosa farsene, lui!
Ma questa è la fine di un racconto circolare che il vostro narratore preferito vuole incominciare dal principio... :)
Qualche giorno fa, il vostro buon Marte ha fatto una scoperta che l'ha illuminato su uno dei più inquietanti misteri della sua infanzia. Quando era giovane, infatti, il vostro verdastro anfitrione era solito dilettarsi con il suo "C64". Prevalentemente utilizzava la macchina alla stregua di una "console" per i videogiochi, ma qualche volta la usava anche per scrivere dei semplicissimi programmini in "BASIC"... In tal senso, non essendo proprio digiuno di programmazione, il Marte s'era sempre domandato come mai i listati dei videogames, indipendentemente dal tempo di caricamento del gioco (un indicatore, quest'ultimo, che faceva vagamente intuire al giovane il concetto di «"file" più o meno grosso»... ;) ), erano sempre ed invariabilmente composti da righe tipo: "1986 SYS 7475"...
«Boh!!! Ma come fanno questi a far funzionare un intero videogioco con una sola linea di codice, che se mi ci metto io devo scriverne dieci solo per impostare l'abbozzo di un programma? E perché per fare il "LOAD" una misera linea di "BASIC" ci sta così tanto tempo, mentre un programma di cinquanta o cento linee scritto da me si carica in una manciata di secondi??? Proprio non capisco...».
Il Marte crebbe con questi amletici dubbi (più o meno... ;) ) finché una brillante intuizione nata dalla piena comprensione della sintassi del comando "LOAD" del "BASIC V2" non lo indirizzò sulla strada giusta...
Nella fattispecie, il suddetto comando funzionava così:
LOAD ["<filename>"] [,<device number>] [,<secondary number>]
Inutile dirlo, il bistrattato "SECONDARY NUMBER" era la chiave di volta dell'intera faccenda.
Fondamentalmente, questo parametro gestiva i caricamenti all'interno delle aree di memoria più appropriate. Della serie: dovevi caricare un programma scritto in "BASIC" dal drive "8"? «LOAD "NOMEPROGRAMMA",8,0» (con il ",0" finale eventualmente anche trascurabile in quanto, se non presente, era comunque utilizzato di "default"...). Avevi assemblato e compilato del "Linguaggio Macchina" e volevi provarlo? «LOAD "NOMEPROGRAMMA",8,1». In quest'ultimo caso, il "file" (grazie al suo "header") veniva caricato ed "alloccato" precisamente nelle aree di memoria adibite a contenerlo, e non altrove...
Morale, la "Commodore Business Machine Ltd." aveva originariamente concepito il comando "LOAD" del "BASIC V 2" in maniera "ignorante", per dire... :D Della serie: io sono un computer stupido e non ho idea di cosa mi vuoi fare caricare. Specificamelo tu, così non mi sbaglio... :P
In tal senso, se per esempio utilizziamo la sintassi «LOAD "NOMEPROGRAMMA",8,1» per aprire un programma in "BASIC", durante il suo caricamento accade questo...
Lo schermo si riempie progressivamente di pattume...
Il programma solitamente non risulta eseguibile e la cosa più sensata da fare è resettare tutto e ricaricare.
Esempio opposto: utilizziamo il banalissimo «LOAD "NOMEPROGRAMMA",8» per caricare un "file" scritto in puro "assembler"... La procedura di "loading" sembrerà procedere senza intoppi; tuttavia, a caricamento ultimato, il comando "LIST" produrrà sullo schermo un papocchio simile a questo...
Ah! Però!!!
Ovviamente, con un listato del genere in memoria, il "RUN" genererà solamente un errore... Del resto, anche conoscendo il "SYS" corretto per avviare il programma, questo comunque non funzionerà perché il suo codice è stato si caricato, ma ora si trova erroneamente "alloccato" in una porzione di memoria sbagliata... ;)
Morale: con le impostazioni standard previste da mamma "Commodore", i caricamenti tecnicamente potevano rivelarsi dei veri e propri incubi... In primo luogo, l'utente doveva sapere che cosa stava per caricare PRIMA di usare il comando "LOAD" (per utilizzare la sintassi giusta, a seconda della circostanza...). Secondariamente, ogni programma in "assembler" (praticamente tutti i giochi...) doveva essere accuratamente documentato perché, una volta terminata la fase di caricamento di un "software" scritto in "Linguaggio Macchina" puro, sia il comando "LIST" sia il "RUN" non avevano alcun esito! (Entrambe le istruzioni valevano solo ed esclusivamente per il "BASIC"!!! :) ).
Mannaggia! E mo questo come lo avvio?!
Ve li immaginate tutti i dischi dei vari giochi corredati da riferimenti trascritti su fogli volanti? Oppure pile e pile di manuali da ravanare... "Raccogli Le Mele" parte con "SYS 1234". "Attenti Bombe"? "SYS 5678"... E così via, vino alla pazzia o all'esaurimento psicofisico più totale... :D
Ma le "software house", i pirati, gli "hackers" ed i programmatori indipendenti fortunatamente decisero fin da subito che tutte queste complicazioni andavano decisamente ridimensionate...
E qui rientrano in scena quei misteriosi programmini "BASIC" di una riga che tanto avevano turbato il Marte in gioventù, spalleggiati dal prode Linker!!!
In tal senso, com'è facilmente intuibile, i "packers/linkers" erano una vasta categoria di "tools" che si occupavano di compattare assieme uno o più programmi allo scopo di creare un unico "file" eseguibile ibrido assolutamente insensibile alle stringenti regole di caricamento imposte dal "LOAD" di casa "Commodore". Gli eseguibili così creati, una volta avviati (il "linker" si preoccupava anche di dotarli dell'ormai famosa «singola linea di "BASIC"» che faceva funzionare il "RUN"... ;) ), si occupavano di spacchettare accuratamente il loro contenuto nella memoria del sistema. I vari pezzi finivano nelle giuste posizioni e tutto funzionava in maniera corretta senza alcun intervento da parte dell'utente che, nella stragrande maggioranza dei casi, nemmeno si accorgeva di quello che stava succedendo... Il Marte insegna!!! :D
Esemplificando il discorso, immaginate che io abbia scritto, assemblato e salvato su disco il seguente programmino in "Linguaggio Macchina". ("Immaginate" un par de ciufoli! L'ho fatto!!! :D )...
Il mio primo programma in "assembler", tra l'altro!
Un programma che, una volta mandato in esecuzione ("SYS 4096"), produce il seguente, fantasmagorico effetto... :P
"Psichedelia. Ti fai gli acidi e poi sei in acido!".
Ora, lasciare il programma così, non mi pareva il caso (e, soprattutto, non mi tornava utile ai fini della mia narrazione... ;) ). In tal senso, per dare maggiore significato al tutto, ho creato un altrettanto piccolo programmino in "BASIC" che funge da "front end" per l'assemblato e si occupa di pulire lo schermo, disponendosi poi in attesa della pressione di un tasto allo scopo di avviare il codice "macchina" solamente in seguito ad un'azione volontaria dell'utente (e non "ex abrupto"... ;) ).
Bello, eh?
...Un "front end wannabe" che, chiaramente, nella sua versione "stand alone" non fa proprio niente, in quanto l'istruzione "SYS 4096" (linea 100) fa riferimento ad un'area di memoria che è vuota e vuota rimarrà fino a quando non troverò un modo per mettere fisicamente assieme questo listato "BASIC" e l'eseguibile in linguaggio macchina precedentemente illustrato...
Detto! Fatto!!!
Dando quindi in pasto i miei due "files" (il programma in "BASIC" e l'assemblato in "Linguaggio Macchina"...) ad un "Packer/Linker" come "Masters' Design Group Packer/Linker V1.2", ho ottenuto un unico programma eseguibile che si carica indipendentemente dall'istruzione "LOAD" utilizzata e che, a caricamento ultimato, presenta all'utente il seguente (e familiare... ;) ) listato...
Toh!? Qual buon vento!!!
Il "RUN" del tutto produce un effetto combinato altrettanto familiare... ;)
Ah! Che soddisfazione!!!
E non è tutto! Premendo "RUN STOP + RESTORE", l'esecuzione del programma si arresta come di consueto ed un "LIST" ci restituisce intatto il listato "BASIC" originale del succitato "front end"!!!
Ma è giunta l'ora di lasciarci...
Tuttavia, non siate tristi... Ora anche voi, come me, conoscete il prode Linker e le sue indiscutibili qualità. Linker. L'eroico discendente di una feconda stirpe di programmi concepiti per facilitare l'esistenza dell'utente medio del "Commodore 64". Amici! Siategli riconoscenti!!! Dimostrategli tutta la vostra infinita gratitudine e ricordatevi che ogni volta che caricate un programma sul vostro computer del cuore, molto probabilmente un parente dell'eroe del quale vi abbiamo narrato le gesta ha vinto una guerra per voi!!! :)