Wine
La documentation sur Wine que vous trouverez sur cette page est tirée des annexes (pages 98 à 101) du Guide IDA de migration vers l'Open Source (pdf).
Wine est l'acronyme récursif de « Wine Is Not an Emulator » (ou l'acronyme de WINdows Emulator...) et tous les détails
Histoire
Le développement de Wine a commencé autour de 1993 par
Bob Amstadt qui utilisait GNU/Linux et MS-Windows sur la même machine.
Les logiciels GNU/Linux étaient arrivés à un point
permettant de satisfaire de nombreux besoins mais il avait certains jeux
dont il était fou qui n'étaient disponibles que sous MS-Windows.
Fatigué de redémarrer uniquement pour jouer, il commença
à travailler sur le moyen d'intercepter les appels système
des jeux utilisés pour les faire correspondre à ceux de
l'environnement X sous GNU/Linux.
D'autres entendirent parler de ce travail et vinrent à la rescousse,
jusqu'à ce que Wine soit capable d'exécuter les jeux auxquels
ils souhaitaient jouer.
Autour de 1995, certains tentèrent d'exécuter d'autres programmes,
dont Quicken et la suite MSOffice et ceux-ci devinrent le centre d'intérêt
principal. Un groupe distinct fit sécession, continuant le support
des techniques graphiques complexes utilisées dans les jeux mais
rarement nécessaires dans les applications bureautique. Le projet
prit alors une approche plus formalisée, avec une équipe
de développeurs et un chef de projet. Depuis 2000; le projet a
été repris de manière plus systématique avec
un chef de projet et une équipe support basés aux États-Unis,
deux petites équipes de développement au Canada et des développeurs
dans la plupart des pays européens. Des éditeurs majeurs
contribuent aussi, IBM par exemple.
Des techniques d'identification des appels systèmes par les programmes
furent créées. Dans de nombreux cas, le développement
d'une petite quantité de code permettait le fonctionnement d'une
application. Il fut trouvé que les programmes préparent
souvent l'appel à une interface particulière sans réaliser
l'appel lui-même. Le code fut alors écrit pour permettre
aux programmes de continuer à faire ces appels préparatoires
sans déclencher d'erreur intermédiaire, ainsi que le code
des appels eux-mêmes.
La première utilisation commerciale de Wine fut réalisée
par Corel qui réalisa un gros travail de support de Wine et l'utilisa
pour produire une version native GNU/Linux de WordPerfect 8. D'autres
entreprises on depuis utilisé Wine pour produire une version GNU/Linux
de leurs produits avec le minimum d'efforts et de modifications, l'une
des dernières étant Xilinx qui réalise des paquetages
de CAO spécialisée en électronique. Le projet Ximian
Mono prévoit d'utiliser Wine pour permettre aux applications .NET
écrites pour MS-Windows de fonctionner sans réécriture
(voir http://appde.winehq.com/
pour le détail du niveau de support de diverses applications).
Récemment, une équipe de développeurs MS-Windows
expérimentés a commencé la réalisation d'une
suite de programmes de test systématique des plus de 12 000 appels
système actuellement présents dans l'ensemble des bibliothèques
MS-Windows.
Actuellement, Wine se compose d'environ 750 000 lignes de code «
C » implantant autour de 90% des appels des spécifications
courantes de MS-Windows telles que ECMA-234 et Open32. Les appels non
publiquement documentés sont plus difficiles à implanter
mais des progrès sont en cours.
Certaines entreprises qui travaillent sur Wine développent du code
pour des fonctions particulières initialement propriétaires.
Elles font cela pour se fondre elles-mêmes ainsi que leur travail
dans le flux principal du projet. Elles insèrent leur code dans
ce flux lorsqu'elles disposent d'une source de revenus alternative suffisante.
Les supports d'OLE et de ActiveX entrent dans cette catégorie.
Ce que Wine fait
Wine intercepte tous les appels système MS-Windows
et MS-DOS ainsi que les interruptions BIOS 4 pour tenter de les
faire correspondre dans l'environnement X GNU/Linux. Les instructions
natives du processeur sont exécutées comme elles l'auraient
été dans l'environnement MS-Windows et c'est pourquoi
MS-Wine n'est pas un émulateur intégral.
Wine n'est pas lié à l'architecture Intel x86 - il existe
par exemple une version pour Alpha de
DEC/Compaq, mais le besoin et l'utilisation sérieuse n'existent
que sur x86. Il ne permet pas aux programmes MS-Windows x86 de
s'exécuter sur une autre architecture telle que PowerPC ni SPARC,
quoique Wine puisse se compiler et s'exécuter sur les deux.
Toutes les interfaces de l'environnement MS-Windows ne peuvent
avoir de correspondance dans l'environnement X GNU/Linux. Certaines
n'ont simplement pas d'équivalent. Cela veut dire que dans certains
cas une quantité significative de code doive être écrite
pour permettre la correspondance. Par exemple, il y a des problèmes
avec les curseurs les plus complexes utilisés par certains programmes
MSWindows.
Le système X-Window ne peut pas gérer plus de deux couleurs
dans un curseur, ce qui oblige Wine à faire des hypothèses
sur les couleurs à utiliser, parfois avec un résultat inutilisable.
Wine est en réalité composé de deux produits ; Wine
lui-même qui permet l'exécution de programmes MS-Windows
et Winelib une bibliothèque de compilation destinée
à la production de programmes natifs GNU/Linux (c'est celle-ci
que Corel a utilisé pour la version GNU/Linux de WordPerfect).
Winelib peut être utilisée pour exécuter sur un matériel
non-x86 des programmes dont le code source est disponible, quoique des
problèmes spécifiques existent encore pour d'autres architectures
(notamment concernant l'ordre des octets).
Où Wine est bon
Le support des programmes MS-Windows 3.x/95/98/Me/NT est disponible (moins
complet pour MSWindows NT). De nombreux programmes pour MS-Windows 2000
fonctionneront, sauf s'ils utilisent de nouvelles interfaces spécialisées
introduites par ce dernier. Peu de travail a été fait pour
le support des programmes spécifiques MS-Windows XP mais il en
existe très peu.
Wine supporte l'essentiel des interfaces documentées de MS-Windows,
cependant pas toujours de manière aussi complète que l'on
pourrait le souhaiter. Voir http://www.winehq.com/?page=status pour connaître
l'état actuel du support dans Wine.
Les programmes qui s'exécutent en isolation ou utilisent uniquement
des interfaces de communication externes doivent fonctionner. Chaque programme
doit être testé individuellement car l'interaction des interfaces
et paramètres utilisés peut poser problème.
Il a été rapporté l'utilisation avec succès
de certains compilateurs et environnements de développements.
Où Wine n'est pas bon
Certaines zones spécifiques sont incomplètes, l'échange
dynamique de données (DDE) par exemple ; cependant, de nombreux
programmes font des appels DDE sans utiliser ceux-ci en réalité
et ainsi fonctionnent très bien. OpenGL et autres logiciels graphiques
à hautes performances ont aussi des problèmes. L'implantation
des listes de contrôle d'accès (ACL - comme dans MS-Windows
NT) existe en partie mais n'est pas encore intégrée
avec les ACL du système d'exploitation sous-jacent.
La technologie des pilotes VxD, introduite par MS-Windows 98,
est une zone difficile. Elle nécessite l'accès au matériel
et à l'intérieur du noyau d'une manière qu'aucun
système multi-utilisateur sérieux ne peut permettre. Des
techniques existent pour produire des résultats équivalents
mais elles impliquent une quantité de travail et leur fonctionnement
n'est pas garanti. Dans certains cas, les éditeurs peuvent être
convaincus de produire une version GNU/Linux utilisant les interfaces
normales. Ce type d'accès étant abandonné par Microsoft
(les architectures de type MS-Windows NT ne le permettent pas),
cela cessera progressivement d'être un problème.
Certains programmes MS-Windows tentent de manipuler directement
les périphériques (notamment les ports série). Cela
n'est pas autorisé sous GNU/Linux ni sous Unix. Cela ne s'applique
en principe qu'aux paquetages de communication tels que Procomm ainsi
qu'aux programmes issus du monde MS-DOS pour lequel il était nécessaire
de procéder ainsi.
Le rendu de certaines images graphiques n'est pas encore satisfaisant
(en particulier celui des polices TrueType) mais ce but est activement
poursuivi.
L'autre zone de difficulté est le logiciel produit par Microsoft
lui-même, car celui-ci tend à utiliser des interfaces non
documentées. Quoiqu'il soit possible de découvrir ce qui
se passe, les développeurs doivent être prudents car les
lois sur la rétro-ingénierie sont très strictes dans
certains pays. Les Etats-Unis par exemple interdisent celle-ci dans tous
les cas et de nombreux pays occidentaux ne l'autorisent que pour établir
une compatibilité. Ainsi, le travail sur cette partie restera toujours
assez lent.
L'exécution de logiciels d'installation, en particulier, a été
problématique mais de récents travaux ont résolu
l'essentiel des difficultés et le travail continue. Certaines de
celles-ci sont causées par les développeurs de paquetages
qui n'appliquent pas les techniques recommandées. L'accès
à la base de registre en est un exemple. Wine maintient sa base
de registre dans un format différent de celui de MSWindows
pour en faciliter la récupération. Tant que les interfaces
documentées sont utilisées, cela n'a pas d'importance, mais
parfois, les développeurs tentent d'y accéder directement,
au risque de corrompre une base de registre réelle sous MS-Windows,
avec pour résultat un fonctionnement impossible sous Wine.
Wine est parfois critiqué pour ses faibles performances mais cela
est souvent dû à la quantité de code de déverminage.
Il est possible de compiler Wine sans celui-ci mais cela doit être
réalisé avec prudence car alors les éventuels problèmes
ne pourront être diagnostiqués sans une nouvelle recompilation.
Wine - alternatives commerciales
Comme mentionné plus haut, des versions étendues de Wine sont disponibles comme produits commerciaux afin d'aider au développement du tronc principal de celui-ci. Les deux entreprises qui font cela sont Transgaming et CodeWeavers. Transgaming travaille essentiellement sur l'amélioration des interfaces graphiques et sonores et son produit est destiné au marché du jeu. CodeWeavers travaille sur les applications bureautiques principales et édite un produit, CrossOver Office qui supporte MS-Office et Lotus Notes.
Wine et Visual Basic
Il a été rapporté un fonctionnement de Visual
Basic 3 mais aucun détail n'est disponible. Visual Basic 6
ne s'installe actuellement pas. Le travail est en cours pour régler
cela, mais il est trop tôt pour dire si le résultat sera
un succès complet ou non.
Aucune autre version n'a été testée.
Migration d'application vers Wine
Voici une liste des lignes directrices de gestion du processus de migration d'applications sous GNU/Linux avec Wine :
- Contrôler les conditions de licence : certaines entreprises ont réalisé des licences qui interdisent l'exécution de leur application hors du système d'exploitation cible. Oracle par exemple faisait cela et Microsoft commence à le faire pour les composants qui peuvent être téléchargés gratuitement ; faire une liste à part des programmes qui entrent dans cette catégorie ;
- Obtenir une copie de chaque application à migrer ; les licences site peuvent ne pas permettre les copies pour tests ;
- Configurer une machine avec la dernière version de Wine ;
- Tester chaque programme de la liste de test, noter tous les problèmes rencontrés ainsi que la phase de survenance (installation, initialisation ou exécution) et valider leur impact sur une sélection représentative d'utilisateurs finals ; noter aussi les problèmes de performances ;
- Pour chaque programme de la liste de problèmes, contrôler tout d'abord l'existence éventuelle d'une version GNU/Linux et tester alors celle-ci aussitôt que possible ; dans le cas contraire, contacter l'éditeur pour lui suggérer d'en réaliser une, par exemple avec Winlib (il faudra négocier séparément avec chaque éditeur) ;
- Si l'éditeur refuse de coopérer, il faudra trouver une application alternative ou abandonner le projet ;
- Utiliser la liste des DLL et appels système manquants nécessaires pour en déterminer un coût d'implantation ; tester à nouveau chaque programme avec les dernières versions de Wine/Winelib jusqu'à disparition de tous les problèmes (parfois, les correctifs posent des problèmes à des programmes qui fonctionnaient correctement) ;
- Wine est normalement compilé avec la trace de déverminage, ce qui impacte négativement les performances (en particulier pour l'interaction écran) ; tester à nouveau tous les programmes qui fonctionnent avec des problèmes de performances sur une version de Wine compilée sans la trace de déverminage ; si les performances restent insuffisantes, un travail de développement sera nécessaire.