Filter
Vue

Emulation et virtualisation: tour d'horizon

par Arthur - 19/04/2006
Mieux comprendre les émulateurs et la virtualisation avec ce tour d'horizon.
Tutoriel pour Sheepshaver par dexter_
Les solutions de virtualisation ?
Ça y ressemble, mais ce ne sont pas des émulateurs à proprement parler. Il s'agit du même principe que les émulateurs, sauf qu'elles reposent sur les composants eux-mêmes de l'ordinateur, et n'émulent pas le fonctionnement d'un processeur différent. Les utilisateurs de PC sous Windows ou Linux connaissent probablement le fameux VMware. Celui-ci propose de simuler un PC virtuel sur un PC ! Ici, nul besoin d'émuler un processeur x86, le logiciel se sert simplement du processeur de l'ordinateur. L'intérêt est également de lancer un ou plusieurs autres systèmes d'exploitation dans des fenêtres distinctes, mais la solution de virtualisation se limite aux systèmes pouvant fonctionner sur votre machine. Par exemple, il sera impossible de démarrer Windows avec un logiciel de virtualisation sur un Mac PowerPC, alors qu'un émulateur PC en serait capable.
L'intérêt d'une solution de virtualisation est qu'elle est bien plus rapide que la solution d'émulation, puisque le gros du travail d'un émulateur, traduire les instructions du processeur à émuler en instructions pour le processeur de l'ordinateur n'est pas fait dans le cas de la virtualisation.
Sur Mac, il existe Mac-On-Mac, qui propose de lancer Mac OS X dans Mac OS X, notamment.


Mac-On-Mac

La version PowerPC de SheepShaver est une solution de virtualisation, car elle permet de lancer Mac OS 8 ou 9 sans besoin d'émulation, alors que les versions Windows, Linux x86 ou Macintel de SheepShaver sont des émulateurs.
De la même façon, alors que j'ai classé Virtual PC pour Mac parmi les émulateurs, il est à noter que la version Windows de Virtual PC est une simple solution de virtualisation.
Au niveau de la compréhension pour l'utilisateur, les notions d'émulation et de virtualisation sont assez voisines, puisque dans les deux cas, il faut configurer le logiciel en sachant qu'il se comportera comme une machine à part entière, indépendante du Mac.
Et les autres ?
Les abus de langage nous poussent à appeler émulateurs des logiciels qui n'en sont pas. Classic par exemple, sur Macs PowerPC, n'est ni un émulateur, ni une solution de virtualisation. Pourquoi ?


Classic

Classic fonctionne au sein de l'interface de Mac OS X.
Car Classic n'émule pas de processeur, pas de disque dur virtuel, d'affichage ou de son. Classic ne fait qu'offrir une passerelle entre les pilotes de carte graphique, de son Mac OS X pour Mac OS 9, et utilise directement le ou les disques durs du Mac. Cela explique, encore une fois, la grande rapidité de Classic, son absence de configuration (excepté l'emplacement du Dossier Système Mac OS 9), et son fonctionnement transparent, intégré dans le bureau de Mac OS X.
Le fameux Wine, bien connu des utilisateurs Linux x86, récemment adapté pour devenir Darwine sous Mac OS X, fait également partie de ce groupe, qu'on pourrait baptiser "environnements de compatibilité". Le nom Wine nous rappelle d'ailleurs sa particularité, puisque les lettres Wine signifient Wine Is Not an Emulator.
Darwine, bien que toujours en version inutilisable pour le grand public, montre son potentiel : faire fonctionner sous Mac OS X des applications Windows, sans Windows, en double-cliquant simplement sur l'application concernée !. Contrairement à Wine dont il est issu, différence de microprocesseur pour les Macs PowerPC oblige, il doit s'embarrasser d'une émulation processeur, alors que les utilisateurs de Mac OS X sur Macintel pourront bientôt bénéficier d'une compatibilité (pas parfaite, certes) avec les applications Windows, à vitesse native, sous Mac OS X. La version PPC de Darwine n'est pas encore utilisable, car l'émulateur x86 n'est pas encore implanté, mais la version Intel fonctionne très bien et permet d'exécuter la plupart des applications Windows pour peu qu'elles ne demandent pas de composants de type ActiveX ou Internet Explorer.


Darwine

Ces solutions d'environnement de compatibilité ont pour avantage d'avoir une configuration à faire limitée, puisqu'il n'y a normalement aucun composant à simuler, mais cependant, leur compatibilité est loin d'être parfaite.
Pourquoi ? Parce que le "secret" pour pouvoir faire tourner les applications sans les enfermer dans une machine virtuelle, est de modifier la relation entre l'application et les différents composants système logiciels auxquels elle fait appel normalement : le son, l'affichage, les api utilisées pour les éléments d'interface (fenêtres, boutons, etc). Ainsi, il arrive que certaines applications refusent de fonctionner, car certaines contiennent des instructions mal interprétées par l'environnement de compatibilité, ce qui renvoie une erreur.
Exemple : une application Windows qu'on essayerait de lancer grâce à Wine sous Mac OS X : l'application Windows s'attend à trouver une Base de Registre, des APIs Windows, etc. Le but de Wine est la réécriture des APIs Windows, pour être utilisées sous Unix. Il faut donc rediriger les appels effectués par l'application vers les APIs réécrites, vers une base des registres qui est un simple fichier texte, ou vers un faux dossier Windows qui ne contiendra en fait que les fichiers que les applications y installeront elles-mêmes.
De plus, les applications n'évoluent pas dans un environnement fermé et donc relativement sécurisé d'une machine virtuelle, donc le risque de virus ou autre existe.
News
Articles
Blog
Tous les mots-clés
Du
Au
Vue complète
Vue par jour
Vue liste
Suivant
Précédent
Imprimer la page
Recommander à un ami
Partager la page