‘Bienvenu dans la matrice’. C’est ce que j’aurais dit si j’accueillais un programme dans un environnement virtuel. Mais d’abord, je n’ai pas d’affect pour les programmes que j’écris. Ensuite il s’agit d’une création. Pourquoi devrais-je alors lui donner des explications sur son environnement ?
En effet, au départ, les programmes s’exécutaient au plus proche du microprocesseur (µp). Sans intermédiaire, seul le système d’exploitation était garant que le programme ne risquait pas de provoquer des anomalies. Mais rapidement, les débordements de certains programmes ont entraîné la mise en place d’autres gardes fous.
Vous avez peut-être entendu parlé du mode ‘réel’ et du mode ‘protégé’. Dans le premier cas, les instructions du programme sont exécutées directement par le µp. Le programme peut accéder à toutes les entrées et sorties câblées à l’ordinateur. En contrepartie, il ne peut accéder à plus de 1 Mo de mémoire vive. Largement suffisant d’après un grand visionnaire.
Ce mode empêche le fait que plusieurs programmes s’exécutent sur un même ordinateur. Mono-tâche uniquement. C’est pour cela qu’au démarrage d’un système d’exploitation (OS) multi-tâche, le processeur est basculé en mode ‘protégé’. Ainsi, un cadre d’exécution se dessine afin d’assurer une résilience du système.
En plus des règles mises en place par l’OS, le processeur s’assure que le programme en cours d’exécution ne bloque pas les autres et que s’il est arrêté, à son redémarrage, il retrouvera son contexte avant d’être relancé. Multi-tâche ne veut pas dire ‘temps réel’, mais comme le µp va très vite, on en a l’impression.
Mais ce mode ‘protégé’ n’est pas une caverne. Le programme est libre de disposer des ressources présentes sur l’ordinateur, et dans faire un bon ou un mauvais usage, dans le cadre défini par l’OS. Mais si à cause d’une faille présente, le programme dégrade un autre programme important pour le chef d’orchestre, alors ce dernier se retrouve incapable de jouer sa partition.
Alors, plutôt que d’exécuter le programme en direct, il peut être intéressant de le placer dans un environnement qui simule son environnement natif. ‘Sois le bienvenu dans la matrice’. Il y a deux situations.
Le programme est exécuté dans un cadre défini par son programme parent. On parle alors de bac à sable. Ce mécanisme est connu par les anti-virus. Votre navigateur aussi l’utilise afin de ne pas cracher les autres onglets lorsqu’il arrive sur une page Internet mal codée.
Le programme est exécuté dans un programme qui simule le système d’exploitation. On parle alors de virtualisation. Le programme a l’impression de s’exécuter sur un vrai ordinateur. En réalité, tout est factice et s’il commet une erreur, il suffira de restaurer l’image sans bloquer son ordinateur.
Le mode virtuel est utilisé sur les téléphones intelligents depuis longtemps. Même si vous réussissez à obtenir le mot de passe administrateur (root), vous ne pourrez pas purger toutes les traces pour rendre votre téléphone inutilisable. Il suffira à quelqu’un qui connaît les accès (ADB pour Android) pour récupérer votre contexte, restaurer une image propre et remettre le téléphone dans un état d’origine.
Si ces mécanismes avaient existé à l’époque de Windows 95, cela m’aurait évité pas mal de réinstallation. Sur XP, ce n’était pas non plus de la virtualisation.
Mais pourquoi s’arrêter en si bon chemin. Lorsqu’on développe, il peut être intéressant de simuler son environnement cible. Sur ma machine virtuelle qui s’exécute sur une machine réelle, je crée donc une machine virtuelle et j’installe les applications qui m’intéressent, puis je peux commencer à coder.
Mais tout cela, l’application qui s’exécute ne le sait pas … ni son utilisateur d’ailleurs. Le monde à l’air si réel.