 |
|
| |
 |
Alexandre Julliard
Directeur Technique
CodeWeavers |
|
Alexandre Julliard (Wine)
"Wine n'amène aucune perte de performance par rapport à Windows"
Le mainteneur du plus important projet d'implémentation Windows libre, dont la version 1.0 est attendue pour cette année, lève le voile sur les coulisses de son activité, et les obstacles qu'il rencontre.
24/04/2006 |
| |
 |
|
JDN
Développeurs. Wine certifie ne pas être un émulateur, jusque dans son nom (Wine Is Not an Emulator) - ce qui peut ne pas sembler évident à tous. Quelle différence faites-vous entre un émulateur Windows, et la couche de compatibilité que met en place Wine ?
Alexandre Julliard Le nom du projet est à prendre dans un sens ironique, parce que Wine est bien sûr aussi un émulateur. L'aspect important est que dans le cas de Wine il n'y a pas de couche supplémentaire par rapport à Windows, c'est simplement une implémentation différente de la même API. En particulier, il n'y a aucune perte de performance par rapport à Windows, contrairement par exemple à un système de machine virtuelle qui fait tourner une copie complète de Windows au-dessus d'un autre OS, ce qui multiplie le nombre de couches.
La version 1.0 de Wine est attendue depuis 6 ans déjà, et sa version béta (0.9) date d'octobre 2005. Peut-on s'attendre à une version stable pour 2006, voire avant l'été ?
Pour 2006 probablement, avant l'été je ne pense pas. Il va falloir attendre que le rythme des corrections diminue pour stabiliser la version 1.0. Nous aurons notre conférence annuelle des développeurs Wine au mois de septembre, et je pense que c'est à cette occasion que nous allons finaliser les plans pour 1.0.
Maintenant que Wine est dans une période de consolidation, quelles sont les fonctionnalités qui vous posent problème ?
Le principal problème aujourd'hui réside dans les systèmes de protection contre la copie, qu'utilisent la plupart des jeux. Ces systèmes font toutes sortes d'opérations bizarres pour détecter les débogueurs, vérifier que le CD est authentique, etc. et ça pose pas mal de problèmes puisque l'architecture de bas niveau de Wine est nécessairement différente de celle de Windows. En plus, ces programmes font tout ce qui est possible pour dissimuler leurs opérations, ce qui complique les investigations.
Comment en êtes-vous arrivé à diriger un projet Open Source créé par d'autres ? Comment avez-vous intégré le projet ?
En fait, j'ai fait partie du projet dès le début, j'étais un des membres fondateurs, donc je n'ai pas vraiment eu à intégrer un projet existant. Comme j'étais probablement celui qui consacrait le plus de temps à Wine - étant étudiant à l'époque, ce qui aide bien -, je dirais que j'étais le candidat naturel pour reprendre le flambeau quand le mainteneur précédent a dû renoncer par manque de temps.
|
|
 Le modèle du dictateur simplifie le processus de décision." |
|
Qu'implique votre statut de "dictateur bénévole" ?
Je pense que le modèle du dictateur est un bon modèle, surtout pour un projet comme Wine où il est très facile de casser quelque chose sans s'en rendre compte, simplement parce que personne ne peut tester toutes les applications Windows existantes ; il est donc nécessaire d'exercer un contrôle strict en amont. L'autre avantage du modèle est qu'il permet d'éviter en grande partie les problèmes politiques puisque le processus de décision est simple et clair pour tout le monde. Ça permet de se concentrer plutôt sur les problèmes techniques...
Quel profil de développeur pourrait aider le projet à avancer plus vite ?
Le profil de développeur Wine est quelqu'un qui connaît bien à la fois la structure interne de Linux et celle de Windows, donc c'est forcément difficile à trouver. En plus, il faut des gens suffisamment masochistes pour aimer passer tout leur temps à déboguer des applications pour lesquelles ils n'ont pas accès au code source. Forcément, tout ça fait qu'il est plus difficile d'attirer des développeurs pour Wine que pour d'autres projets plus sexy...
Quels sont les plus gros défis auxquels le projet Wine a fait face dans ces 12 ans d'existence ?
Le défi principal a été la transition de 16 à 32 bits - qui a d'ailleurs été un gros problème aussi pour Microsoft... Au début, Wine implémentait l'architecture Windows 3.1, et le passage à une architecture de type Windows NT a pris de nombreuses années, puisqu'il fallait faire ça progressivement, sans casser tout ce qui fonctionnait déjà. Rétrospectivement il aurait été nettement plus facile de partir sur une architecture NT dès le début; mais bien sûr à l'époque toutes les applications intéressantes étaient des applications Windows 3.1.
Wine consiste plus ou moins à reproduire l'API Windows pour systèmes Unix. Pensez-vous pouvoir réaliser ce travail de conversion dans son intégralité ?
Le but n'est pas nécessairement de reproduire l'intégralité de l'API, mais seulement ce qui est utilisé par des applications existantes. Il y a une grande quantité de fonctionnalités obscures dans l'API que personne n'utilise, et dont nous n'avons pas à nous soucier. Et du moment qu'une application utilise une fonction, simplement l'observation du comportement de l'application nous permet d'avoir une bonne idée de ce que la fonction est censée faire, même s'il n'y a pas d'autre documentation.
Il faut aussi noter que grâce à la pression judiciaire, Microsoft a fait de grands progrès dans la documentation, et il y a aujourd'hui beaucoup moins de fonctions non documentées qu'il y a quelques années.
|
|
Wine suivra les prochaines évolutions de Windows, comme WinFX." |
|
Wine a évolué, proposant aujourd'hui une compatibilité Win32 au lieu de la Win16 d'origine. Suivrez-vous les prochaines évolutions de l'API, à commencer par WinFX ?
Certainement, mais comme mentionné ci-dessus nous suivons les évolutions uniquement dans la mesure où elles sont effectivement utilisées par des applications réelles, donc il y a toujours un décalage entre le moment où une nouvelle API est annoncée et le moment où il devient important pour Wine de la supporter.
Pour tout ce qui est du support .Net et C# il est clair qu'une grande partie du travail a déjà été faite par le projet Mono, et nous n'allons pas dupliquer tout ça dans Wine, mais tirer parti de Mono d'une manière ou d'une autre.
Votre employeur, CodeWeavers, vous paie en partie pour travailler sur Wine. Quels droits avez-vous sur le code source créé durant votre travail, et celui créé pendant votre temps libre ?
En règle générale le code source créé durant mon travail appartient à Codeweavers, mais une partie de mon temps de travail est réservée à mes tâches de mainteneur, et Codeweavers n'a pas d'influence sur ce que je fais pendant ce temps-là. Donc le code source que je développe pendant ce temps m'appartient, de même que le code créé pendant mon temps libre. Il faut admettre que la distinction n'est pas toujours très claire puisque je travaille sur le même code dans les trois cas... mais comme tout le code est sous LGPL de toute façon, la distinction n'est pas très importante.
Les développeurs Unix peuvent-ils, ou pourront-ils, développer des applications Windows en n'utilisant que Wine ?
Tout à fait, et c'est déjà en grande partie le cas. La seule chose que Wine ne fait pas, c'est de générer des exécutables Windows, donc il reste nécessaire d'utiliser un compilateur Win32 comme MinGW pour cette dernière étape. Nous avons fait un gros effort pour être le plus compatible possible avec MinGW, donc il est possible d'utiliser exactement le même environnement de développement, même Makefiles, etc. et de changer simplement le nom du compilateur pour générer soit un programme Windows soit un programme Linux. |
| |
Propos recueillis par Xavier Borderie, JDN Développeurs |
|
|
PARCOURS
|
|
 |
| |
Alexandre Julliard, 35 ans, est le mainteneur du projet Wine depuis 1994.
1999 CodeWeavers, Chief Technology Officer
1996 Lightning Instrumentation, chef de projets
1994 Elca Informatique, ingénieur de développement
|
|
|
|
|
|
|
Dossier 
