Quand j’étais petit, j’étais un jedi de la ligne de commande. Parce qu’il n’y avait pas le choix pour gérer son ordinateur et parce que j’aimais bien bidouiller.
J’ai donc démarré ma vie informatique avec l’installation et l’utilisation de MS-DOS, un temps que les moins de 20 30 ans ne peuvent (heureusement) pas connaître.
À l’époque, il fallait se farcir un gros manuel en papier ressemblant à ça :
J’en ai chié, franchement, car en ligne de commande, la moindre faute de frappe et c’est raté.
Vous avez saisi le contexte ? Génial.
Hé bien figurez-vous qu’il s’agit de ma madeleine de Proust informatique.
J’adore tripoter de la ligne de commande. Ce n’est pas sale, peut-être un peu déviant mais en tout cas, je retourne faire mumuse assez souvent.
J’ai déjà écrit sur le presque parfait émulateur de MS-DOS qu’est DOSBox, je vous laisse vous y replonger, c’était en 2018 et la dernière version stable officielle datait de fort longtemps auparavant, alors que les sources étaient toujours en cours de développement.
Le constat n’a pas changé : la dernière version stable est la 0.74-3 et date de 2019, avec une version française à jour.
Côté Ubuntu, elle est bien sûr disponible dans les dépôts.
Le problème pour moi réside dans le fait que même si l’équipe continue le développement, les binaires (fichiers exécutables) ne sont pas compilés officiellement.
De plus, de nombreux patchs existent sur le forum officiel, mais rares sont ceux intégrés dans le code source.
Enfin, le développement s’appuie sur la bibliothèque SDL 1.x, dont la dernière version date de 2012, la version 2.x ayant pris le relai.
Tout ceci donne un programme qui boîte un peu et manque surtout d’options permettant de pousser l’émulation dans des fonds inaccessibles et surtout, il reste pas mal de bugs non résolus.
Je rajouterai que les développeurs semblent mystérieusement coincés dans un monde où les retours communautaires et les outils plus modernes sont inexistants (les sources restent sur SourceForge malgré les possibilités plus avancées de Git/GitHub, les patchs restent ignorés, etc.)…
Mais que faire dans un monde Libre et Ouvert (DOSBox est sous licence GPL) ?
Dériver le projet bien sûr 🙂 !
Pour résumer la situation : plusieurs développeurs hors du projet ont dérivé les sources pour permettre, tout en suivant le développement principal, d’intégrer des patchs en les testant auparavant et de corriger divers bugs tout en proposant des options de configuration en plus.
Parmi ces dérivés, j’ai noté DOSBox-x (disponible en snap), DOSBox-ECE et celui que je préfère DOSBox-Staging.
Sous Ubuntu, même si un snap est disponible, DOSBox-Staging est disponible en PPA (version stable ou développement).
Une fois installé, si le fichier de configuration n’est pas présent au premier lancement, il sera créé d’office et vous le trouverez dans ~/.config/dosbos/dosbox-staging.conf
(ou dosbox-staging-git.conf
).
Les options disponibles sont plutôt explicites (et expliquées).
Pour ce qui est de la langue de Molière, j’ai décidé de mettre la main à la pâte :
- création du fichier de langue anglaise (dans DOSBox :
config -writelang nomfichier.ext
) - traduction des clefs déjà existantes dans la version officielle 0.74-3 en reprenant la traduction française disponible
- traduction de zéro pour toutes les autres clefs liées à DOSBox-Staging
Cela a permit de discuter avec les développeurs pour voir comment moderniser le système de langue (qui n’est pas en UTF-8, bonjour les conversions pour passer du fichier DOSBox à l’UTF-8 puis la reconversion une fois traduit pour tester le résultat) à l’avenir.
Le résultat, qui sera, je pense distribué avec une prochaine version stable, est disponible sur GitHub (dossier contrib/translations/fr) et il suffit, une fois téléchargé le fichier fr_FR.lng dans le dossier de configuration de DOSBox-Staging, de renseigner son nom dans le fichier .conf adéquat sous la valeur language=fr_FR.lng
et en voiture Simone !
Pour l’utilisation de base, je vous conseille de vous créer un répertoire équivalent au disque dur C de DOSBox, que vous monterez avec la commande mount C chemin
et de passer en clavier français avec keyb fr
, les deux instructions pouvant se mettre à la fin du fichier de configuration (remplaçant AUTOEXEC.BAT pour les connaisseurs).
Je n’ai pas oublié les fichiers .ini (j’ai dû faire un clavier.ini il y a peu d’années) mais autoexec.bat m’était sorti de la tête ; ton rappel me fait sourire.
Dire que autoexec.bat a été très important pour moi à une époque…
Comme pour le Covid-19, c’est la faute de Bill Gates !
#oupas
Je détestais, je déteste toujours parce que j’en ai tapé des lignes avant le me dos et qu’un jour de 84, il y a eu le mac! …depuis je me soigne à coup de terminal. Mais ca reste contre nature pour un progressiste de l’informatique.
Le problème de dos box c’est la gestion de l’horloge sur d’anciens programmes aussi.
Là je prends ça comme un hobby, pas une contrainte.
Ceci dit, avant le PC, j’avais un Amstrad donc les lignes de commandes contraignantes, j’ai connu… et l’Amstrad entre pas dans la ligne de compte de la nostalgie chez moi…
bonjour ,il y avait aussi en plus du autoexec.bat le config.sys les deux fichiers à savoir dompter sous dos pour un bon demarrage , une époque !! etant depuis plus de 15 ans sous linux on continue avec les lignes de commandes , mais cette fois dans le terminal c’est par amour de mettre les mains dans le cambouis !!
Oui,aussi. Ceci dit on finissait, à partir de MS-DOS 6.x (de tête) en menu de démarrage avec des fichiers différents…