
Envoyé par
Emmanuel Delahaye

Envoyé par
rigobert
la fonction system() permet de lancer exclusivement une commande de type EXE, COM, CMD ou BAT.
Eh, on est plus en Win16... Windows 3.1, c'est fini...
Quel rapport avec Win16 ?
Les EXE, COM, CMD et BAT sont toujours d’actualité sous Win32 ; les CMD sont même une spécificité de la plateforme NT (W2K, XP). J'avais juste oublié d'ajouter que les commandes DOS internes (dir, type, del ...) étaient elles aussi utilisables de cette façon.
Pour ceux qui lisent l’Anglais, la doc de l’implémentation de la fonction system() sous Windows se trouve ici
En résumé, il est dit que la fonction system() permet de lancer une commande depuis un programme C, de la même façon qu’on saisirait une commande manuellement dans la console.
Ce qui signifie que :
1/ la chaîne passée à system() est de la forme <commande> [arg 1] [arg 2] … [arg n]
donc passer par exemple "image.img" à system() revient à taper la même chose dans la console, ce qui n’a à priori pas de sens.
2/ il est possible que dans un contexte très particulier une utilisation non documentée de system() donne miraculeusement le résultat escompté … sur un poste donné ; mais il y a de fortes chances pour que ça ne fonctionne pas sur la majorité des autres (cf discussions sans fin « je ne comprends pas : ça marche chez moi mais pas chez toi… »). Exploiter des fonctionnalités non documentées d’une API c’est se mettre à coup sûr en position de devoir faire face tôt ou tard à des problèmes de compatibilité (qui souvent vont se révéler insolubles).
3/ la fonction system() ne convient pas pour « exécuter » un fichier document (non exécutable intrinsèquement) sans connaître (et donc sans pouvoir explicitement spécifier sur la ligne de commande) la commande ou l’application prenant en charge le type du document en question.
Par exemple :
system("c:\\tools\\view.exe image.img");
a un sens et fonctionnera si "view.exe" se trouve bien à l'endroit spécifié (c:\tools) et si "image.img" se trouve dans le dossier courant, contrairement à
qui n'en a aucun (à moins que "image.img" soit un exécutable renommé
), et qui ne devrait jamais fonctionner.
Mais même en connaissant la commande à utiliser pour exécuter le document, produire un code 100% compatible restera très compliqué parce qu’il faudra d’une part être sûr que la commande en question est bien installée et d’autre part être capable de la localiser sur le disque dur.
De plus, le fait que la commande recherchée ne soit pas installée ne signifie pas pour autant que le document ne peut être exécuté : il est tout à fait possible qu’une autre commande remplissant le même rôle soit elle bien installée, mais malheureusement … on ne la connaît pas !
Enfin, c’est parfois l’utilisateur qui a choisi d’associer telle application à tel type de fichier, et en pareille situation, le développeur a le devoir de respecter le choix de l’utilisateur ; à défaut c’est son environnement de travail (ou de loisirs
) qui risque de devenir incohérent.
4/ il existe (sous Windows je le reprécise) une base de données centrale des associations documents/commandes. En se servant de cette base de données, il est très facile d’exécuter un document au travers d’une commande open dans le shell, ce sans avoir à se poser la question de la commande physique à utiliser et encore moins d’où elle se trouve.
Pour info, ceci est réalisable en une seule ligne de code avec la fonction Win32 ShellExecute() dont la doc se trouve ici .
Je n’en dirai pas plus ici, la solution apportée étant spécifique à la plateforme Windows, elle sort un peu du cadre de ce forum.
Ceci dit, je pense que l'implémentation dans d'autres systèmes doit être assez proche, dans l'esprit, de ce que j'ai décrit ici.
Partager