| : Licence Professionnelle ADMISYS | ||
|---|---|---|
| Précédent | ||
Les systèmes d'exploitation vendus (loués ???) par Microsoft™ comportent, depuis les premières versions de Microsoft Windows™ une certaine compatibilité ascendante avec la génération précédente, à savoir PC|MS|DR/DOS™ laquelle permettait de créer des traitements batchs (scripts). Au fur et à mesure de l'évolution de ses systèmes d'exploitation, Microsoft™ semble vouloir permettre aux administrateurs gérant ses systèmes d'exercer leurs tâches de plus en plus via des scripts : pour preuve tous les outils permettant l'accès ou la configuration d'Active Directory™ existent en version "ligne de commande"...
Un indice supplémentaire est l'effort de développement fourni pour l'interpréteur de commande des systèmes récents, à savoir cmd.exe, qui intègre l'historisation activée par défaut, et (à compter de Microsoft Windows XP™ la possibilité de complétion des commandes.
L'originel PC-DOS™ commandé par IBM™ à Microsoft™, provenait en fait du développement de Q-DOS™ racheté à Tim Paterson, lui-même grandement inspiré de CPM™, et disposait pour toute interface utilisateur de l'ineffable shell dénommé command.com. A l'instar des shells Unix, il comportait des commandes internes et permettait de chainer des commandes externes (dans son propre espace mémoire, évidemment).
Ce command.com permettait également d'interpréter des fichiers de scripts (nommés fichiers batch) portant l'extension .BAT afin de réaliser des tâches d'administration du système, ou de préparer l'environnement de travail et lancer des applications. Ce shell permettait également la redirection vers des fichiers.
D'un point de vue programmation, les fichiers .BAT permettaient de re-router le flux d'instruction via des aiguillages GOTO etiquette et des tests sur le code de retour de commandes ERRORLEVEL via la commande interne IF [NOT]. La boucle FOR IN ... DO était également disponible pour procéder à des intérations sur des noms de fichiers.
Avec l'avênement de Windows NT4™, le shell command.com connait une évolution majeure, et devient cmd.exe qui ouvre un "terminal en mode texte" dans l'interface graphique. Du point de vue intrinsèque de sa programmation, il ne connait guère d'évolutions par par rapport à la génération précédente, mais il est adapté au contexte multi-processus, et à l'environnement graphique.
Par contre, Microsoft™ fournit d'autres interpréteurs, plus riches en fonctionnalités, puisque directement issus de leurs outils de développement phares : VBScript™ et surtout l'infrastructure Window Script Host™ qui se veut plus une plateforme de script qu'un simple langage car, en effet, différents langages frontaux lui sont disponibles (Wscript pour le mode fenêtré, Cscript pour le mode console texte, ou encore VBScript™, Javascript ou Active Perl™).
Enfin, les dernières briques apportées par Microsoft™ à son système de scripting est l'infracstructure Windows Management Instrumentation ou WMI qui permet un accès à la quasi-totalité des objets du système et Active Directory Service Interface ou ADSI plus spécialisé pour la gestion d'Active Directory (bien que permettant également l'accès aux données des bases SAM de NT4 ou 2000, ou encore aux annuaires d'Exchange™) sont représentés dans le système de scripts comme de nouveaux objets.
L'évolution vers la ligne de commande se poursuit encore avec le dernier des systèmes d'exploitation Microsoft™ : Windows 2008 Server™, qu'il est possible de déployer en "Mode Core" (c'est à dire sans interface graphique), et dans lequel le shell Cmd.exe, s'il existe toujours pour les raisons de compatibilité, se voit mis en concurrence avec un nouvel environnement de ligne de commande : Windows Power Shell™ qui, si l'on en croit les fichiers de déploiement fourni, ne travaille plus sur des données textuelles mais sur des objets de la platforme et dont les commandes externes sont appelées applet de commande.NET™.