Dennis Ritchie : comment C a rendu Unix portable

Le 9 septembre 2026 marque le 85e anniversaire de la naissance de Dennis Ritchie. Ses travaux sur C et Unix ont changé la manière de transférer les logiciels. Mais un code portable n’a jamais garanti qu’un même fichier fonctionnerait sur chaque ordinateur.

Imaginez que vous donniez à un ami une disquette contenant votre programme. Son ordinateur possède un autre processeur, un autre système d’exploitation et d’autres habitudes pour les fichiers. Que lui avez-vous transmis : un logiciel exécutable, une base à recompiler ou un travail à recommencer ? Cette question éclaire mieux l’apport de Dennis Ritchie qu’une longue liste d’appareils célèbres rattachés à son héritage.

Le Heidelberg Laureate Forum indique sa naissance le 9 septembre 1941. Nous en célébrons aujourd’hui le 85e anniversaire, également signalé dans notre calendrier geek. L’occasion invite à se demander ce qui reste du travail quand l’ordinateur d’origine disparaît.

C et Unix remplissent des rôles différents

C est un langage de programmation : il permet de décrire des opérations qu’un compilateur peut traduire. Unix est un système d’exploitation : il gère des ressources et fournit des services aux programmes. Les confondre empêche de comprendre leur complémentarité. Un calcul n’a pas besoin de connaître le modèle du disque. Le système peut donner accès à un fichier tout en masquant une grande partie du fonctionnement du matériel.

Le Computer History Museum présente Ritchie comme le créateur de C et le cocréateur d’Unix avec Ken Thompson. Il situe ces travaux à Bell Labs au début des années 1970. Il s’agit d’une construction collective, pas d’un inventeur solitaire ayant conçu toutes les couches de l’informatique.

Un programme relie au moins trois décisions : que faut-il calculer, comment demander des services et quelles instructions machine effectueront le travail ? On peut les mêler si étroitement que le moindre changement touche l’ensemble. On peut aussi les séparer assez pour remplacer une partie sans jeter les deux autres. La portabilité commence lorsque cette séparation devient réellement utile.

La réécriture de 1973 n’était pas un bouton magique

Dans leur article sur Unix, Ritchie et Thompson situent la réécriture en C à l’été 1973. Le texte conservé est la révision de 1978 de l’article de 1974. Il décrit un système plus facile à comprendre et à modifier, malgré une taille accrue.

Réécrire un noyau dans un langage de plus haut niveau déplace le travail du programmeur. L’assembleur suit de près les instructions d’un processeur. C permet de décrire des fonctions, des données et le déroulement des opérations ; le compilateur prend en charge de nombreux choix d’instructions. La machine compte toujours. Ses détails ordinaires occupent simplement moins de place dans le texte principal du programme.

La portabilité n’était d’ailleurs pas le grand dessein initial. Dans son histoire de C, Ritchie explique que cet intérêt est venu plus tard. C a évolué à partir de B ; sa période la plus créative se situe en 1972. L’amélioration d’un environnement de travail a ouvert de nouvelles possibilités.

Un code source portable n’est pas un exécutable universel

Revenons à la disquette. Elle peut contenir du code source, un texte lisible écrit en C. Ou un exécutable, déjà traduit pour une cible précise. Ce ne sont pas les mêmes cadeaux. Un compilateur adapté peut produire d’autres instructions machine à partir d’un code source approprié. Copier l’ancien exécutable n’accomplit pas cette traduction.

Prenons un petit programme qui lit des températures et recherche la plus basse. Sa logique de comparaison n’a pas besoin de connaître la carte graphique. Si ses entrées et sorties utilisent des fonctions disponibles dans les deux environnements, le même source pourra peut-être être recompilé pour chacun. Ajouter une fenêtre au moyen d’une bibliothèque propre à une plateforme crée une dépendance supplémentaire.

Une compilation réussie n’est aussi qu’une étape. Il faut disposer des bibliothèques attendues et respecter les conventions d’entrée ainsi que le comportement prévu. Un fichier peut s’ouvrir correctement tout en présentant ses nombres dans un format inadapté. Deux programmes peuvent démarrer et pourtant interpréter différemment les données. La portabilité exige donc de vérifier les résultats.

Où l’ancienne machine se cache-t-elle ?

Pour lire un programme sous cet angle, cherchons ses hypothèses sur l’environnement. Trois endroits méritent une attention particulière :

• La représentation des données. Le code suppose-t-il une taille précise pour les entiers ? Enregistre-t-il une structure en copiant directement sa mémoire ? Un format d’échange défini ne se confond pas avec une disposition en mémoire.
• Les services du système. Comment obtient-il des fichiers, l’heure, des entrées et d’autres ressources ? Une interface limitée s’adapte plus facilement que des appels propres à une plateforme dispersés dans toutes les fonctions.
• L’accès au matériel. Le code qui dialogue directement avec un périphérique doit le connaître. Une frontière explicite concentre les adaptations ; elle ne supprime pas le travail.

Ces questions constituent notre grille de lecture pratique, pas une description de tous les programmes C historiques. Un langage offre des possibilités de séparation. Encore faut-il les employer. Un programme remarquablement court peut accumuler les hypothèses implicites. Un autre, un peu plus long, peut exprimer clairement ses attentes et permettre à quelqu’un d’autre de les examiner.

Le vrai bénéfice : préserver le travail humain

Stephen C. Johnson et Ritchie documentent le passage à l’Interdata 8/32 dans leur étude de 1978 sur la portabilité. Leur critère pratique est l’effort économisé par rapport à une réécriture. Une grande partie du source restait commune aux environnements ; les adaptations techniques demeuraient nécessaires.

C’est cette mesure qui rend l’enjeu tangible. Le but n’est pas de faire disparaître toute modification. Il est de conserver ce qui contient déjà de la réflexion : les algorithmes, les décisions et la compréhension accumulée d’un problème. Changer de machine ne devrait pas automatiquement imposer de résoudre la même question depuis le début.

Notre article sur les ordinateurs personnels de Steve Wozniak propose un regard complémentaire. On peut lire ces histoires comme deux questions de conception : comment rendre une machine accessible, et comment éviter qu’un logiciel utile reste enfermé dans une seule machine ?

Lire cet article dans une autre langue: anglais · allemand · espagnol.

Un petit exercice pour cet anniversaire

Inutile de porter un système d’exploitation entier pour essayer cette idée. Choisissez un petit programme que vous comprenez. Notez ses entrées et sorties attendues, puis repérez une hypothèse sur son environnement. Il peut s’agir d’un chemin de dossier, d’un encodage de caractères ou d’une bibliothèque d’affichage particulière.

Rassemblez cette hypothèse à un endroit clairement nommé. Si vous disposez d’un second environnement, recompilez le programme et comparez les résultats sur les mêmes exemples. Sinon, indiquez ce qu’il faudrait vérifier lors du transfert. Cela ne prouve pas encore une portabilité universelle. Mais une ambition floue devient une question précise, qu’une autre personne pourra explorer.

Pour le 85e anniversaire de la naissance de Ritchie, voilà un hommage à sa mesure : rendre un peu de savoir plus facile à transmettre. C et Unix n’ont pas effacé les différences entre ordinateurs. Leur histoire montre combien il peut être précieux d’en réduire le coût.