Un navigateur de 1999 peut être parfaitement conservé sur un disque et rester pratiquement impossible à lancer.
Biyubi a été écrit par Oscar Toledo G. pour un ordinateur maison équipé d’un processeur AMD Am29000. Le programme dépendait d’un système d’exploitation maison, d’une pile TCP/IP, d’un environnement graphique, de fontes bitmap et d’un compilateur C construit spécifiquement pour cette machine.1
Vingt-sept ans plus tard, retrouver l’exécutable ne suffisait donc pas. Il fallait refaire le monde dans lequel cet exécutable avait un sens.
C’est ce qui rend le projet plus intéressant qu’un simple « vieux navigateur fonctionne à nouveau ». La préservation logicielle ne concerne pas seulement le programme final. Elle concerne les outils qui ont permis de l’écrire, les services qu’il attend et le matériel auquel il parle.
Au début, même écrire le logiciel était devenu le problème
La première version de l’ordinateur G11 repose sur un Am29000, une architecture RISC lancée par AMD à la fin des années 1980. Toledo y construit un système fenêtré directement en code machine entre 1996 et 1998.2
Ce choix finit par devenir un piège. Modifier une fonction oblige à prévoir sa place en mémoire, agrandir une routine peut déplacer les suivantes, puis il faut corriger les sauts qui les visent. Ça devient vite pénible. Toledo raconte avoir laissé des séries de NOP dans certains endroits simplement pour réserver de l’espace à de futures modifications.1
Ça fonctionne tant que le logiciel reste petit. Puis le système grandit.
Le problème suivant n’est donc pas « quel programme écrire ? ». Il devient « comment retrouver un langage de haut niveau sur cette machine ? ».
Un GCC avec support Am29k existe alors, mais Toledo estime qu’il exige davantage de mémoire et d’infrastructure que les 512 Ko disponibles sur sa machine : système d’exploitation plus riche, assembleur, linker, Flex, Bison.1
Plutôt que porter toute cette chaîne, il repart d’un compilateur C qu’il avait déjà écrit pour son ordinateur à transputer.14
Changer de processeur oblige à changer la manière de penser le compilateur
Le transputer et l’Am29000 ne posent pas le même problème au générateur de code.
Sur le transputer, beaucoup d’opérations passent par une pile et l’architecture prend en charge une partie du mouvement des valeurs. L’Am29000 expose au contraire de nombreux registres. Le compilateur doit décider où placer variables, arguments et valeurs temporaires.1
Toledo finit par modifier son architecture de compilation : plutôt que produire immédiatement le code au fil de l’analyse, il conserve une fonction complète dans une représentation intermédiaire en arbres et listes chaînées. Il peut alors regarder quelles variables ont besoin d’une adresse en mémoire, lesquelles peuvent rester dans des registres et combien de registres locaux la fonction exige.1
Ce détail raconte une chose utile sur le portage d’un compilateur.
Un compilateur n’est pas seulement un traducteur entre « C » et « assembleur ». Son architecture interne finit par refléter les propriétés de la machine cible. Quand le processeur change suffisamment, certaines décisions prises pour l’ancien matériel cessent d’être pratiques.
En mai 1998, Toledo commence le générateur Am29000. Début juin, il parvient à compiler le compilateur, assembler sa sortie et reproduire le même binaire à chaque construction.1
Le langage vient de récupérer un outil capable de se reconstruire lui-même sur son propre environnement.
Le self-hosting transforme l’ordinateur en atelier
Le compilateur seul ne suffit toujours pas. Il faut encore un assembleur pour transformer sa sortie en instructions machine, puis un éditeur pour écrire confortablement les nouveaux programmes. Toledo porte d’abord son assembleur à la main vers le code machine, puis compile finalement sa version C avec le compilateur qu’il vient de rendre opérationnel. Il construit ensuite un éditeur de texte, lui aussi initialement écrit en code machine.1
Environ deux mois de travail aboutissent ainsi à un environnement complet : éditeur, compilateur C et assembleur.1
Cette séquence ressemble à la fabrication d’une machine-outil avant la pièce qu’on voulait produire.
Dans un environnement contemporain, cc, un linker, un éditeur et une bibliothèque standard semblent faire partie du paysage. Sur une architecture maison abandonnée par les outils courants, ils redeviennent des objets à construire.
C’est un peu le vrai rôle du compilateur ici : il ne produit pas encore le navigateur, mais il rend un projet de cette taille possible pour une seule personne.
Biyubi est une conséquence du compilateur
Toledo commence son navigateur le 22 mars 1999. Le 9 avril, une première version HTML fonctionne localement. En parallèle, il développe sa pile TCP/IP, PPP, PAP et les commandes nécessaires au modem.1
Le 24 juin 1999, le navigateur accède à Internet pour la première fois depuis l’ordinateur Am29000, en utilisant un compte Prodigy emprunté à un ami.1
Le contexte matériel est difficile à imaginer aujourd’hui. La machine tourne autour d’un processeur à 12 MHz dans sa version évoquée pour le navigateur, avec seulement quelques centaines de kilo-octets de RAM disponibles. L’exécutable Biyubi atteint 362 Ko.1
Il ne pouvait donc pas simplement occuper cette RAM comme une application moderne.
Toledo retrouve en 2026 que le navigateur avait été placé dans l’EPROM, à côté de sa pile réseau. Une partie de l’environnement vit ainsi directement dans la mémoire non volatile de la machine.1
Cette contrainte explique aussi pourquoi retrouver un seul binaire ne suffit pas. Au premier redémarrage de 2026, Biyubi cherche un cache de fontes qui manque à l’appel. Toledo doit retourner dans ses sauvegardes sur mini-CD pour retrouver le fichier daté d’août 1999.1
Un logiciel ancien est rarement un fichier solitaire. Tout autour, on retrouve des petits morceaux qui semblaient insignifiants tant que la machine complète existait encore.
En 2026, le premier outil à reconstruire est l’émulateur
La machine originale n’est plus disponible sous une forme facilement utilisable. Toledo possède toutefois des images de disquettes, des dumps mémoire, des ROM et des sauvegardes.
Pour les faire vivre, il écrit un émulateur Am29000 moderne.23
Le travail n’est pas une émulation parfaite de chaque composant historique. Toledo choisit régulièrement une frontière pragmatique.
Le contrôleur de disquette peut être court-circuité vers les services de l’émulateur. Le contrôleur graphique Cirrus Logic est implémenté pour les comportements réellement utilisés. Certaines fonctions de stockage ou de clavier sont interceptées plutôt que reproduites transistor par transistor.2
C’est une distinction importante pour la préservation.
Le but n’est pas toujours de construire un musée électrique parfait de la machine. Le bon niveau d’émulation dépend de ce qu’on cherche à conserver. Ici, Toledo veut exécuter son système et ses applications, comprendre leurs dépendances et fournir une expérience reproductible sur Windows ou macOS.23
La fidélité se négocie donc fonction par fonction. En pratique, il faut décider ce qu’on cherche réellement à préserver.
Reconnecter le navigateur signifie aussi traduire le réseau de 1999
Même avec Biyubi affiché à l’écran, le Web moderne pose un nouveau problème.
Le navigateur de 1999 s’attend à sa propre pile TCP/IP, elle-même construite autour d’un modem et de protocoles comme PPP. Reconstituer exactement ce chemin n’apporterait pas grand-chose à la démonstration de 2026.1
Toledo choisit donc un pont.
Dans l’émulateur, certains services réseau du vieux système sont redirigés vers des fonctions contemporaines pour résoudre un nom DNS et ouvrir une connexion TCP. Biyubi croit toujours parler à ses services de 1999 ; l’émulateur traduit ces appels vers les sockets du système hôte.1
Le navigateur reste très limité face au Web actuel. HTTPS, JavaScript moderne, CSS et vingt-cinq ans d’évolution des protocoles ont évidemment déplacé la cible. Mais des sites simples en HTTP peuvent encore lui répondre.1
Cette solution est presque l’inverse d’un port moderne.
On ne transforme pas Biyubi pour en faire une application macOS. On transforme son environnement pour que Biyubi puisse rester Biyubi.
Le compilateur redevient une preuve de conservation, pas seulement un outil historique
Le dépôt restauré ne se contente pas d’exécuter quelques binaires.
Toledo fournit de nouveau les sources du compilateur C et de l’assembleur dans l’environnement de développement. Il montre même le compilateur reprendre ses quelque 10 000 lignes de source et produire à nouveau le même binaire, sous contrainte de mémoire.1
C’est un test beaucoup plus intéressant que « l’écran de démarrage apparaît ».
Un système ancien peut booter tout en étant pratiquement mort pour le développement. Si son compilateur, son assembleur, son éditeur et ses bibliothèques fonctionnent encore, l’environnement récupère une capacité de transformation.
On peut corriger un programme. On peut en compiler un autre. On découvre les limites de la machine en les rencontrant dans son propre atelier.
Le logiciel préservé redevient productif. Et là, l’archive change de nature.
Une architecture morte n’est pas seulement un jeu d’instructions sans processeur
L’Am29000 n’est plus une plateforme informatique générale vivante. Pourtant, son jeu d’instructions n’est que la première couche de ce qui a disparu autour de l’ordinateur G11.
Il faut retrouver ou reconstruire le compilateur, l’assembleur, les conventions d’appel, le stockage, les pilotes graphiques, les images de disque, les fontes, les outils de build et les services réseau attendus.
C’est pour cette raison que la préservation par « garder le binaire » atteint vite sa limite.
Le binaire conserve un état final. Il ne conserve pas automatiquement la capacité de produire le prochain état.
Pour un jeu commercial, l’émulation de la console peut suffire à préserver une expérience très importante. Pour un environnement de développement personnel comme Fénix, conserver seulement les exécutables perd une autre moitié de l’histoire : comment ce logiciel pouvait encore être écrit depuis cette machine.
Le compilateur C de Toledo est donc presque plus révélateur que son navigateur.
Biyubi montre ce que l’ordinateur pouvait faire en 1999. Fénix C montre ce que l’ordinateur pouvait encore devenir.
La meilleure archive est parfois un système capable de se reconstruire
Les disquettes, ROM et mini-CD de Toledo ont survécu de manière très imparfaite. Certaines sauvegardes ne sont plus lisibles. Des fichiers sont absents. Des adresses doivent être retrouvées dans les binaires. Des pilotes réapparaissent seulement lorsqu’un accès matériel fait planter l’émulateur.12
Ce n’est pas une restauration propre depuis une image disque parfaite.
C’est une reconstruction à partir de fragments.
Pourtant, l’arrivée du compilateur self-hosting change la nature de ce qui est restauré. L’environnement ne sert plus seulement à contempler 1999. Il peut reprendre ses propres sources et fabriquer du logiciel selon ses règles.
On retrouve alors une propriété familière aux systèmes vivants : une partie de la mécanique nécessaire à leur propre évolution se trouve déjà à l’intérieur.
Un navigateur qui charge à nouveau une page après vingt-sept ans est une belle image.
Le fait qu’on puisse de nouveau compiler ce qui tourne derrière est peut-être la vraie résurrection.