Pourquoi les variables d’environnement TMP et TEMP existent-elles toutes les deux ? (2015)

• Sous Windows, TMP et TEMP existent toujours tous deux pour indiquer l’emplacement des fichiers temporaires, et lorsqu’ils diffèrent, celui qui sera utilisé dépend de l’implémentation du programme
• CP/M ne disposait pas de variables d’environnement, il fallait donc configurer l’emplacement des fichiers temporaires programme par programme ; des logiciels comme WordStar modifiaient leur comportement en patchant certains octets du fichier exécutable
• MS-DOS a ajouté les variables d’environnement tout en gardant fortement à l’esprit la compatibilité avec CP/M, mais les premiers programmes MS-DOS utilisaient très peu TEMP ou TMP en raison de l’inertie héritée de CP/M
• Lorsque les programmes MS-DOS ont commencé à utiliser les variables d’environnement comme moyen de stocker des paramètres, TEMP et TMP se sont retrouvés en concurrence ; certains programmes comme DISKCOPY et EDIT cherchaient TEMP avant TMP
• L’implémentation des tubes dans MS-DOS 2.0 a choisi TEMP pour l’emplacement des fichiers temporaires, mais sous Windows, GetTempFileName vérifie d’abord TMP, ce qui a permis aux deux variables de continuer à coexister

---

Origine de la coexistence de TMP et TEMP

• Dans les variables d’environnement Windows, TMP et TEMP existent toutes les deux pour désigner l’emplacement des fichiers temporaires, et si elles diffèrent, le bon choix varie selon les programmes
• L’endroit où un programme crée ses fichiers temporaires dépend de son implémentation ; un programme Windows a de fortes chances d’utiliser la fonction GetTempFileName, auquel cas TMP est prioritaire
• Si la boîte de dialogue de configuration des variables d’environnement affiche TMP et TEMP ensemble, c’est parce qu’aucune des deux n’a jamais été complètement imposée comme standard, et que deux choix historiques ont coexisté

CP/M n’avait pas de variables d’environnement

• Vers 1973, le système d’exploitation courant sur les micro-ordinateurs était CP/M, et CP/M ne possédait pas de variables d’environnement
• Comme il n’y avait pas de variables d’environnement, il n’existait pas non plus de variable TMP ou TEMP
• Pour indiquer à un programme où stocker ses fichiers temporaires, il fallait une configuration spécifique à chaque programme, par exemple en patchant certains octets du fichier exécutable pour désigner la lettre du lecteur où placer ces fichiers
• Des programmes comme WordStar indiquaient dans leur manuel quels octets patcher pour modifier tel ou tel comportement, et réservaient même un espace de patch permettant d’ajouter des sous-routines personnalisées, par exemple pour la prise en charge d’imprimantes

L’arrivée de MS-DOS et des variables d’environnement

• En 1981 sont apparus le processeur 8086 et MS-DOS, tous deux fortement influencés par CP/M
• L’un des objectifs initiaux de conception de MS-DOS était de permettre la traduction mécanique de programmes CP/M pour processeur 8080 en programmes MS-DOS pour processeur 8086
• Ce traducteur partait du principe que le programme n’utilisait pas de pratiques atypiques comme le code auto-modifiant, les sauts vers le milieu d’une instruction ou l’utilisation du code comme données
• Les registres H et L du 8080 correspondaient aux registres BH et BL du 8086, et le fait que seul HL pouvait servir à l’accès adressé en mémoire sur 8080 explique pourquoi, sur 8086, parmi AX, BX, CX et DX, seul BX pouvait être utilisé pour l’accès mémoire
• En plus de la compatibilité avec CP/M, MS-DOS a introduit des variables d’environnement, mais comme les anciens programmes CP/M n’en utilisaient pas, les premiers programmes MS-DOS n’y avaient pas recours non plus
• Les utilisateurs pouvaient définir TEMP ou TMP, mais les premiers programmes n’en tenaient pas compte

TEMP et TMP entrent en concurrence sur le marché

• Avec le temps, des programmes conçus d’abord pour MS-DOS ont commencé à apparaître, et ils ont commencé à utiliser les variables d’environnement comme mécanisme de stockage de configuration
• TEMP et TMP ont alors commencé à être utilisés chacun comme variable d’environnement pour définir l’emplacement des fichiers temporaires, devenant les deux principaux candidats
• Le choix de la variable vérifiée en premier dépendait de l’implémentation du programme
• De nombreux programmes vérifiaient les deux, TEMP et TMP, pour satisfaire tous les cas, mais l’ordre de vérification variait selon les implémentations
• Les anciens programmes DISKCOPY et EDIT cherchaient TEMP avant TMP

Les tubes de MS-DOS 2.0 et TEMP

• MS-DOS 2.0 a introduit la fonctionnalité de tube permettant de transmettre la sortie d’un programme à l’entrée d’un autre
• Comme MS-DOS était un système d’exploitation mono-tâche, les tubes étaient simulés en redirigeant la sortie du premier programme vers un fichier temporaire, en l’exécutant jusqu’au bout, puis en lançant le second programme pour qu’il lise ce fichier temporaire comme entrée
• Cette fonctionnalité obligeait donc MS-DOS lui-même à disposer d’un emplacement où créer des fichiers temporaires
• C’est TEMP qui a été choisi pour contrôler cet emplacement
• Même si COMMAND.COM avait choisi TEMP, la question de savoir si les autres programmes utiliseraient TEMP ou TMP restait à la discrétion de chaque programme

Sous Windows, une voie a favorisé TMP

• Windows a suivi une évolution comparable, mais l’implémentation initiale de GetTempFileName a été conçue pour vérifier TMP avant TEMP
• Lorsqu’un programme Windows utilise GetTempFileName pour créer un fichier temporaire, il a donc tendance à préférer TMP
• Il n’existe donc pas de réponse unique à la question « quelle variable est la bonne ? » : tout dépend de l’API ou de la logique interne utilisée par le programme
• Encore aujourd’hui, la boîte de dialogue de configuration des variables d’environnement affiche à la fois TMP et TEMP, et les deux continuent de coexister pour indiquer l’emplacement des fichiers temporaires

[GN⁺]

Commentaires sur Hacker News

• Intéressant. C’est antérieur à mon époque, donc je n’avais jamais entendu parler de la configuration de programmes CP/M par patch

  • Oui, ça existait vraiment, et le code de patch devait être en langage machine Z80/8080
    J’ai moi-même écrit comme ça des routines plus rapides de clavier et d’affichage pour mon WordStar
  • Oui, ça a bien existé, et certains programmes initialement prévus pour CP/M ont perduré longtemps, jusqu’à WordStar 7.0 pour DOS
    Il me semble que la documentation de WordStar 7 indiquait les offsets de patch permettant de modifier le comportement du programme avec debug.exe de DOS
  • Ça existe encore dans une certaine mesure. Les projets de suckless se configurent généralement en modifiant config.h puis en recompilant
    https://suckless.org/
    Cela dit, je viens seulement de voir que c’était déjà mentionné dans un autre sous-fil de cette page
  • Cette approche était nécessaire parce que la RAM et l’espace disque étaient extrêmement limités, et que presque tous les ordinateurs étaient livrés avec un assembleur
    Beaucoup de programmes CP/M devaient tourner avec 32 Kio de RAM et des disquettes lentes de 130 Kio, voire sur cassette. Avoir 64 Kio de RAM et des disques de 360 Kio, c’était déjà assez exceptionnel
    À l’époque, contrairement à aujourd’hui, on optimisait les logiciels pour le bas du marché plutôt que pour le haut. Plus un programme tournait sur de systèmes, plus il se vendait, et on ne renvoyait pas simplement les clients vers une mise à niveau matérielle
    Il n’y avait tout simplement pas la place pour des fichiers de configuration externes, ni pour un programme chargé de les créer, et même le traitement des arguments en ligne de commande consommait de précieux octets
    Aujourd’hui, on se plaint qu’un MacBook Neo n’ait « que » 8 000 000 000 octets de RAM, mais en 1978 on pouvait déjà construire un IDE de base en 2 048 octets

• J’aime bien le blog de Raymond, mais dire que CP/M était courant sur les micro-ordinateurs en 1973, c’est étrange
  En 1973, les micro-ordinateurs relevaient plutôt du prototype ou du système de développement, comme l’Intel Intellec, et n’avaient pas de système d’exploitation. Kildall a bien commencé à développer CP/M en 1973, mais à ce moment-là il ne tournait que sur un simulateur de mainframe PDP-10
  En 1979, d’accord, mais 1973 est beaucoup trop tôt

  • Wikipedia indique que CP/M a été créé en 1974, donc la chronologie ici semble clairement décalée
  • C’est amusant de se dire que l’écart entre 1979 et 1973 correspond à celui entre 2020 et aujourd’hui
    Du coup, on se rappelle qu’en 2020, ChatGPT n’existait pas encore

• Très bon exemple d’une décision prise presque sans réflexion par des développeurs des débuts et qui reste pendant des décennies

  • Une table centrale d’un produit S&P500 sur lequel j’ai travaillé brièvement s’appellera probablement attornies pour toujours, simplement parce que personne n’a repéré la faute au départ
  • Rien n’est aussi permanent qu’une décision TMPoraire

• Si les programmes ont choisi TMP, c’est probablement parce que les extensions de fichiers sous MS-DOS étaient limitées à 3 caractères, et qu’il était courant d’utiliser l’extension .TMP pour les fichiers temporaires

• C’est un peu comme l’incohérence des programmes Unix entre http_proxy et HTTP_PROXY
  De nos jours, beaucoup de programmes regardent les deux, mais l’ordre de vérification n’est pas forcément le même

• La mention de CP/M prête à confusion. L’auteur semble dire d’abord que cela deviendra important plus tard, puis finit par expliquer que cela n’avait en fait rien à voir avec CP/M ni avec le CPU 8080

  • D’accord. Cette histoire n’a pas grand-chose à voir ni avec CP/M, ni avec la digression vers le 8080/8086
    L’essentiel, c’est simplement que Microsoft l’utilisait en interne sans chercher à le standardiser
  • Si CP/M avait utilisé des variables d’environnement pour la configuration, il y aurait déjà eu un standard sur TMP ou TEMP, et DOS l’aurait probablement suivi
    Mais le vrai obstacle, c’est que CP/M n’avait pas de répertoires, et DOS 1.0 non plus
  • Tu pourrais citer la phrase à laquelle tu fais référence ?

• Vers 1995, Telstra, c’est-à-dire Australia Telecom, avait environ 50 000 postes de travail dans toute l’organisation
  Un jour, un petit fichier nommé null est apparu dans le répertoire home réseau de tout le monde, probablement parce qu’un utilisateur Unix avait essayé d’écrire un fichier .bat
  Pourquoi suivre un standard déjà existant, après tout. J’ai voulu demander « pourquoi standardiser ? », mais je me suis dit que ça risquait de troubler les Nord-Américains

  • Il a probablement essayé /dev/null au début, puis, comme ça n’a pas marché, il l’a remplacé par null
    Sinon, l’idée que ça vienne d’un programmeur Unix n’aurait pas beaucoup de sens. Ce serait plutôt un programmeur DOS qui aurait écrit null au lieu de NUL
  • Je me demande quel était le texte qu’on cherchait à jeter
  • Un programme d’installation de pilote Logitech faisait quelque chose de similaire
    Il cherchait un fichier nommé NULL sur le disque dur, et évidemment il y avait une instruction du genre > NULL dans le fichier .BAT

• Honnêtement, pour beaucoup de programmes, la configuration par patch à la CP/M aurait sans doute été préférable à cette habitude de parsemer le répertoire home de dotfiles

  • Si les gens respectaient simplement la XDG Base Directory Specification, la prolifération des fichiers de configuration ne serait pas un problème
    De plus en plus de projets l’adoptent, y compris des projets longtemps réticents comme Firefox
  • L’un des principes un peu particuliers de l’écosystème suckless, c’est qu’on configure en général les projets en modifiant le code source puis en recompilant
    Vu sous l’angle de l’open source moderne, on peut y voir une approche similaire. Mais avec leur ascétisme général, ces projets ne conviendront sans doute pas à tous les goûts
  • À l’origine, tout devrait être dans .config
    Le problème, c’est que beaucoup de développeurs d’applications pensent que leur application est spéciale et mérite son propre répertoire
  • Je préfère des dotfiles qu’on peut grep et gérer avec un éditeur de texte à des paramètres disséminés partout dans un registre binaire centralisé
    C’est peut-être simplement une question d’habitude
  • J’aimerais que ça soit standardisé. Une distribution qui arriverait d’une manière ou d’une autre à imposer le dossier .config serait gagnante pour moi
    Cela dit, j’ai bien peur qu’il ne soit déjà trop tard

• Je ne savais pas que c’était à ce point confus
  La leçon est probablement : faites toujours pointer les deux vers le même chemin, sinon ça finira mal

• Cela fait des décennies que je relève ce genre de choses agaçantes chez Microsoft
  Avant, il y avait toujours un « développeur senior » qui prétendait tout savoir et avait une réponse à tout. Du genre : « temp, c’est temporary, et tmp, c’est troubleshoot my pc, pour les logs de débogage. C’est pour ça que je suis senior et pas toi. »
  Puis en devenant moi-même plus senior, j’ai compris que j’avais eu raison de poser la question, et maintenant, quand on parle avec d’anciens développeurs Microsoft, ils expliquent que c’était une erreur, mais qu’ils l’ont conservée pour la compatibilité ascendante
  Mais on en vient alors à se demander pourquoi cette excuse serait valable. Ils invoquent la compatibilité ascendante, tout en imposant quand même des changements qui cassent souvent des compatibilités essentielles et des workflows réels, comme avec New Outlook. Ensuite ils se défaussent en disant : « Je ne suis pas un mauvais développeur, demandez donc aux nouveaux. »
  Sauf qu’on ne peut pas demander aux nouveaux, et qu’ils sont cachés derrière la barrière de sélection LeetCode. Du coup, ce n’est pas étonnant que ce genre de vrais problèmes ne soit jamais corrigé et qu’on se retrouve avec des choses comme New Outlook. L’ancien « senior » travaille maintenant là-bas, et les vrais développeurs sont partis à la retraite
  Même quand Microsoft donne une réponse apparemment cohérente sur le fait que des programmes tiers utilisent de manière inappropriée le dossier Documents de l’utilisateur, ou qu’OneDrive le supprime de force par erreur, six mois plus tard Microsoft pousse un changement aléatoire qui modifie le comportement dans le mauvais sens et détruit toute la logique de départ
  C’est pareil pour Notepad. Dans des entretiens avec les développeurs, ils expliquaient qu’il devait rester extrêmement simple parce que le risque devait être nul, puis plus tard on lui a ajouté la connexion au compte Microsoft et Copilot
  À mes yeux, la mentalité des développeurs façon LeetCode et la culture Microsoft ont abîmé toute l’industrie. Il n’y a plus de discussion calme possible, on en arrive vite à : « Tu ne travailles pas chez Microsoft, donc ton avis ne vaut rien »
  Je me souviens très bien de l’époque où Google Chrome s’installait dans AppData pour contourner les droits administrateur. Il était pourtant évident que la fonctionnalité n’avait pas été conçue à l’origine pour permettre à des tiers d’installer des logiciels sans privilèges admin
  Mais Chrome était très bon à l’époque, et comme il fallait gérer le chaos de la distribution d’exceptions tierces sur des millions de PC d’entreprise verrouillés, les développeurs présentent maintenant cela comme une fonctionnalité intentionnelle