Un UNIX-like qui tourne sous MS-DOS

C'est en l'an 2 avant Linus Torvalds (pas son année de naissance, mais l'année de publication du noyau UNIX-like pour PC qui l'a rendu célèbre) que j'ai acheté mon premier PC.
Ses possibilités sous MS-DOS 3.3 étaient bien plus limitées que celles des machines UNIX de mon lieu de travail. J'ai donc choisi de réécrire en C la plupart des outils que j'utilisais au boulot.

Vous trouverez plus d'une centaine d'utilitaires UNIX-LIKE avec les sources que j'ai utilisés et perfectionnés pendant plus de 10 ans.

Les outils réalisés

Près de 150 utilitaires ont été écrits. La plupart correspondent à la commande UNIX System V équivalente.

Pour connaitre la liste détaillée cliquer ici.

Il ne manque que quelques outils pour couvrir la quasi totalité des besoins :

il n'y a pas d'interpréteur de commande sh, on utilise donc command.com
néanmoins, certains outils palient en partie à ce manque :
- execfich utilise les données en entrée comme argument d'une commande (comme le permettent les ` ` sous UNIX)
- redirect permet de redirriger les entrées / sorties, notamment la sortie erreur (ce que ne fait pas MS-DOS)
- rawbloc est une surcouche de l'interpréteur de commandes qui permet :
  - de remonter sur une ligne déjà écrite et d'utiliser les caractères qu'elle contient pour taper la commande suivante
  - d'accéder à l'historique des commandes précédentes
  - de mémoriser cet historique, ainsi que le répertoire courant et le prompt dans un fichier, pour utilisation au prochain redémarrage du calculateur.

il n'y a pas de commande sed, ni de commande tr, bien que pour cette dernière carspe fasse une partie du travail.

il n'y a pas de commande troff, nroff pour les textes mis en page, mais un système de commandes mnémoniques (issu de mon ancien lieu de travail) le remplace.
Il est compatible avec la commande d'impression lp et en partie (pour ce qui peut être affiché) avec les commandes de visualisation de fichiers pg et gpg.

l'écriture d'outils très évolués comme awk, lex, yacc/bison n'a jamais été prévue.

il n'y a pas non plus de compilateur C, linker etc. On utilise Turbo C 2.0 de Borland.

il n'y a pas de système de compression / décompression de fichiers (bien que des essais aient été réalisés.

la commande d'aide, équivalente de man s'appelle docunix.

Sinon, il existe pour les copies de répertoires et les sauvegardes des commandes toutes prêtes copie, copnew, sauveg, sauvroot, restor qui, sous UNIX correspondraient plutôt à des shells.

Les options des commandes

Pour chaque commande développée, seulement un petit nombre d'options (celles jugées utiles) de la commande UNIX System V des années 80 ont été implantées.
Là encore, il y a des particularités en fonction des outils :

Pour l'affichage du contenu des répertoires, à la place d'une commande ls avec options, il y a plusieurs commandes : ls, lf, lr, ll, lt et ltt qui fonctionnent chacune avec un mode d'affichage différent.

Alors la commande find d'UNIX System V permettait de chercher des fichiers à partir de leur date de dernière modification comptée uniquement en jours, ma version de la commande find permet d'exprimer aussi cette ancienneté en heures, minutes et secondes.
La commande find développée depuis pour GNU/Linux offre elle aussi cette possibilité, mais avec une syntaxe d'utilisation différente.

Les éditeurs et visualiseurs de textes vi, pg et dérivés peuvent disposer d'options spécifiques comme -n pour l'affichage des numéros de lignes.

Des programmes simples qui font peu mais bien

C'est la philosophie d'UNIX à ses origines. Je l'ai reprise en la poussant quelquefois un peu plus loin.

la commande paste d'UNIX permet de faire 2 choses assez différentes. J'ai donc réalisé 2 commandes distinctes paste et groupe.

pour les recherche de chaines de caractères ou d'expressions régulières dans les fichiers, UNIX a prévu 3 commandes plus ou moins riches en possibilités, mais aussi, plus ou moins complexes et plus ou moins lentes : fgrep, grep et egrep. J'ai fait de même mais pas toujours avec la même progression au niveau des possibilités. Une 4ème commande dgrep (la plus riche en possibilités) était prévue mais n'a jamais été écrite.

lorsqu'un outil est complexe, comme le comparateur de fichiers diff, j'ai écrit également des commandes plus simples fonctionnant bien dans certains cas particuliers : diffl, diffs, plus, moins.

de même, pour le visualiseur de fichiers pg et l'éditeur de texte vi, la première version réalisée était limitée aux fichiers de 64 Koctets. J'ai ensuite rajouté des versions pour les fichier plus gros mais pouvant être chargé en RAM : gpg et gvi, et pour les fichiers encore plus gros : mxpg et mxvi, cette dernière n'ayant jamais été terminée.

Caractéristiques des sources et compilation

Les sources ont été écrits en langage C. La plupart des applications se limitent à un fichier sources.

La plupart des sources sont peu commentés. Je n'avais pas prévu de les diffuser un jour.

Lorsque plusieurs fichiers sources sont nécessaires, un fichier projet .PRJ est fourni. Il contient la liste des fichiers source de l'application à compiler séparément.

Ces fichiers sont prévus pour être compilés avec Turbo C 2.0 de Borland.
Le modèle mémoire optimal est "tiny" pour la plupart des applications, et "compact" pour les applications conversationnelles (l'emploi du modèle compact est précisé dans le fichier source).

Si vous utilisez un compilateur plus moderne, il est bon de connaitre les points suivants :

La déclaration des paramètres des fonctions se fait souvent selon la norme des années 80

Les prototypes de fonctions n'ont été mis que lorsqu'ils étaient indispensables. La convention employée est qu'une fonction sans type de retour spécifié ne retourne pas de valeur. Elle est donc de type void et non de type int .

Dans le cas particulier des éditeurs, une astuce peu orthodoxe par le biais de fichiers d'inclusion permet de compiler un source de plus de 64 Koctets. Avec un compilateur plus moderne, rien n'empêche d'avoir recour à une compilation séparée des morceaux. Mais il faudra dans ce cas définir une constante :
#define vi , #define gvi ou #define mxvi selon le modèle d'éditeur de textes à compiler, et mettre les #define des source bufvi.c , bufgvi.c et bufmxvi.c (s'il est terminé un jour) dans des fichiers d'inclusion pour qu'ils puissent être connus des autres sources.

Environnement d'exécution

Toutes ces commandes s'exécutent sous MS-DOS (à partir de la version 3.3) ou dans les fenêtres MS-DOS de Windows 95 à 98. Les outils permettant de se déplacer dans un texte supposent l'utilisation du pilote ANSI.SYS .
La commande rawbloc est capable de détecter l'absence de ce pilote et, la plupart du temps, de lancer son installation.

Par contre depuis Windows XP, si l'exécution de rawbloc permet d'avoir une fenêtre MS-DOS, le pilote ANSI.SYS n'a pu être trouvé, ce qui limite les possibilités des outils conversationnels rawbloc, pg et ses dérivés, et exclue carrément les éditeurs de textes vi et gvi.

Téléchargement des fichiers

fichiers source et fichiers projet

fichiers exécutables correspondants

fichiers d'aide en ligne

Les fichiers d'aide en ligne doivent être recopiés dans le répertoire qui contiendra les exécutables correspondants.

Il existe aussi des applications non documentées. En général, ce sont des applications sans équivalent sous UNIX.
Examiner les sources pour deviner ce qu'elles font.

Certaines activep, masquep, majtypep et majtailep permettent de modifier la table des partitions primaires. L'utilisation de majtailep peut poser des problèmes avec Windows XP.

fichiers source d'applications non documentées

fichiers exécutables correspondants

Cliquer ici pour revenir au sommaire du site