Dave Gardner l'a maintenu de 1995 à 1998.
Douglas Ridgway a pris le relais en 1999.
Andreas Mohr l'a converti en FAQ-O-Matic en 2000.
Dimitrie O. Paun, Keith Matthews et Tom Wickline (par ordre alphabétique) l'ont réorganisée en 2002.
Pour toute suggestion, ajout ou remarque concernant cette FAQ, n'hésitez pas à nous écrire à wine-faq@winehq.org
La FAQ originale de Wine, sur laquelle est basée la présente FAQ, a pour copyright © 1995-1998 David Gardner.
Elle peut être reproduite et modifiée selon les même termes que Wine lui-même.
This FAQ lives in the CVS repository on SourceForge. In order to update this document you'll need to checkout the the docs from CVS, edit it, and then send a patch. In order to get the docs, run the following CVS command:
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/wine co -P docs
When prompted for a password, just press the enter key.
A subdirectory named docs will be created. If you navigate through there you'll find the FAQ in docs/en/wine-faq.sgml. The file is written in SGML, which is simply a superset of HTML. You can use your favorite text editor to make changes to it but be sure to make sure each opening tag has a corresponding closing tag. You may find the tidy or xmllint utilities useful for editing the document.
After editing the file, generate a patch against CVS and email it to wine-patches@winehq.org.
Wine est un programme qui permet d'exécuter les opérations DOS et les programmes MS Windows (Windows 3.x et exécutables Win32 ) sur les systèmes d'exploitation UNIX comme Linux. il comprend un programme de chargement, qui charge et exécute un binaire Windows, et un ensemble de bibliothèques qui implémentent les appels aux API Windows en utilisant leurs équivalents UNIX ou X11. Les bibliothèques peuvent être également utilisées pour porter du code Win32 en exécutables UNIX, souvent sans beaucoup de changement au niveau du code source. Wine est un logiciel libre, et sa license (qui se trouve dans le fichier LICENSE de chaque distribution) est la LGPL (GNU Lesser General Public License).
Non, comme son nom l'indique, Wine n'est pas un émulateur [Wine Is Not a (CPU) Emulator]. Wine fournit simplement les API Windows. Cela signifie que vous aurez besoin d'un processeur compatible x86 pour exécuter une application Windows x86, par exemple un Intel ou un AMD. L'avantage est que, à la différence des solutions qui s'appuient sur une émulation CPU, Wine exécute des applications à pleine vitesse. Parfois un programme exécuté sous Wine sera plus lent que s'il était exécuté sur une copie de Microsoft Windows, mais cela est principalement dû au fait que Microsoft a énormément optimisé des parties de son code, alors qu'essentiellement Wine n'est pas (pour le moment) bien optimisé. Occasionellement, il arrive qu'une application tourne plus vite sous Wine que sous Windows. La plupart des applications tourne approximativement à la même vitesse.
Oui. Vous pouvez utiliser VMWare (http://www.vmware.com) pour exécuter une installation Windows au sein d'une machine virtuelle, ou utiliser Win4Lin (http://www.win4lin.com) pour exécuter une version spécialement adaptée de Windows sous Linux. Les deux solutions coûtent de l'argent pour à la fois le logiciel lui-même et la license Windows.
Notez que, comme Wine, ils peuvent seulement utiliser la plate-forme matérielle pour laquelle le programme cible a été compilé (voir ci-dessus).
Il existe deux émulateurs x86 libres: Bochs, and Plex86.
Plex86 est un logiciel libre open-source offrant une solution de rechange pour VMWare, VirtualPC, et autre IA-32 sur IA-32 "Virtual PC products." Il peut uniquement fonctionner sur l'architecture IA-32.
Bochs is a highly portable open source IA-32 (x86) PC emulator written in C++, that runs on most popular platforms. It includes emulation of the Intel x86 CPU, common I/O devices, and a custom BIOS. Currently, Bochs can be compiled to emulate a 386, 486 or Pentium CPU. Bochs is capable of running most Operating Systems inside the emulation including Linux, Windows® 95, DOS, and recently Windows® NT 4.
Les deux logiciels sont sous license GPL. Bochs est plus ancien que Plex86, semble être plus facile à installer, mais Plex86 se révélera plus rapide car il utilise un compilateur binaire en juste à temps.
L'inconvénient de tous les émulateurs est que vous avez besoin d'une version de Windows pour exécuter Windows, et qu'ils ont tous un impact sur la performance. Wine offre également une meilleure intégration du bureau- par exemple, les programmes utilisent votre gestionnaire de fenêtre standard, les icônes de la barre de lancement rapide [system tray] apparaîtront dans votre barre des tâches (si vous en avez une), et vous pouvez exécuter les programmes directement depuis la ligne de commande comme depuis les menus. La tablette électronique fonctionne aussi d'une façon homogène actuellement.
2.5. Quand Wine intégrera-t-il un émulateur CPU x86 de façon à faire tourner des applications Windows sur des mahines non-x86 ?
Pour être bref, probablement jamais. Souvenez-vous, Wine n'est pas un émulateur (de CPU). Pour être plus précis disons que nous ne voulons probablement pas ou ne ressentons pas le besoin d'en intégrer un au sens traditionnel du terme.
Intégrer un émulateur CPU à Wine serait extrémement difficile, à cause du grand nombre d'API Windows et de la compléxité des types de données qu'elles échangent. Il n'est pas rare de voir dans une API Windows trois pointeurs ou plus vers des structures composées de nombreux champs, y compris des pointeurs vers d'autres structures complexes. Pour chacun d'entre eux, nous aurions besoin d'un mécanisme automatique de conversion qui puisse traiter les problèmes d'ordre des octets et d'alignement. De plus, Windows contient aussi de nombreux méchanisme de rappel automatique [callback] qui constituent autant d'occasions où nous aurions à essuyer ces problèmes de conversion. Wine doit déjà faire avec les API 16 bits face aux API 32 bits et les API Ansi face aux API Unicode, des différences qui apportent leur lot de compléxité. Ajouter un support pour les émulateurs CPU à l'intérieur de Wine compliquerait deux fois plus les choses et ne servirait qu'à ralentir le développement de Wine.
Heureusement, une autre solution existe pour faire fonctionner des applications Windows sous des plateformes non x86 : exécuter à la fois Wine et l'application au sein de l'émulateur CPU. Tant que l'émulateur offre un environnement UNIX standard, Wine devrait seulement avoir besoin de modifications minimes. La performance que vous perdez en faisant tourner Wine dans l'émulateur plutôt que nativement, vous la gagnez en compléxité dans Wine. De plus, si l'émulateur est assez rapide pour faire tourner des applications Windows, Photoshop par exemple, alors il devrait être suffisament rapide pour exécuter cette même application et Wine.
Deux nouveaux projets s'inscrivent dans cette optique : QEMU, projet open-source, et Dynamite Dynamite, environment commercial émulant un CPU de chez Transitives Technologies.
Tout d'abord Wine n'est pas là pour faire tourner Windows mais pour faire tourner des applications Windows.
Par conséquent si tous vos besoins informatiques sont satisfaits par des applications natives UNIX, alors vous n'avez pas besoin de Wine et vous ne devriez pas l'utiliser. Cependant, si vous avez vraiment besoin d'une ou plusieurs des dizaines de milliers d'applications Windows , alors Wine et le meilleur moyen de les utiliser sans abandonner Unix. Jetons un oeil sur toutes les autres solutions possibles pour voir pourquoi:
Parmi celles-ci, la plus évidente, est d'utiliser le double démarrage. C'est la solution qui offre la meilleure compatibilité. Cependant cela implique d'acquérir une license Windows et de dédier une bon morceau de votre disque dur à Windows. Mais le pire est encore à venir. Chaque fois que vous voudrez utiliser cette application vous devrez redémarrer sur Windows. C'est particulièrement désagréable si cette obligation vient de l'extérieur et vous obligent à utiliser cette application (e.g le traitement du carte de crédit, email a récupérer depuis un serveur Lotus Notes). Vous serez alors obligé de fermer toutes vos applications Linux juste pour ouvrir cette application Windows. Vous serez sans doute vite exaspéré de cette situation, ou vous trouverez qu'une telle situation n'est pas acceptable dans le cadre du travail.
L'autre solution est d'installer un logiciel d'émulation de machine virtuelle tel que VMWare, Win4Lin ou Plex86. Vous pouvez alors utiliser des applications Windows sans déplorer une telle interruption. Mais cela implique également d'acquérir une license Windows et autant d'espace disque pour Windows. De plus vous devrez payer pour cet inconvénient supplémentaire : si puisque vous utilisez VMWare ou Win4Lin vous devez acheter une nouvelle license, et plus important vous devez dédiez maintenant une bonne partie de votre mémoire vive à la machine virtuelle. Les performances vont en prendre un sérieux coup également.
L'utilisation de Wine vous permet d'éviter toutes ces charges : la license Windows, l'espace disque-dur pris par Windows, les conséquences sur la mémoire et les performances dûes à l'émulation de la machine virtuelle. Vous pouvez maintenant démarrer votre application Windows depuis votre environnement bureau habituel, placer la fenêtre de cette application côte à côte avec d'autres applications natives, faire des copier/coller de l'une vers l'autre, et l'exécuter à pleine vitesse.
C'est aussi un élément assez important pour la migration d'un organisme de grande taille, on ne change pas en une nuit changez la configuration de 5000 bureaux sans risque.
2.7. Puis-je utiliser Wine pour que les pilotes Windows de ma carte réseau / carte graphique / scanner / etc. marchent sous Unix ?
Le but de Wine est de rendre possible l'exécution d'applications Windows sous Unix, mais pas les pilotes Windows ou les VxD.
Les pilotes et les applications Windows appartiennent à des mondes différents. Les applications tournent en mode utilisateur et utilisent les API fournies par le noyau et les autres dll mode utilisateur. A l'inverse, les pilotes sont chargés dans le noyau Windows, c.à.d. au niveau 0 au lieu du niveau 3, ils doivent faire face à des problèmes spécifiques de gestion de mémoire, et utilisent des instructions qui ne sont pas disponibles pour les applications classiques. Cela signifie qu'ils ne pourraient tourner dans Wine puisque ce dernier s'exécute en mode utilisateur. Il vous faudrait alors modifier le noyau Linux. Mais par ailleurs, les pilotes utilisent une API complétement différente des applications Windows classiques. Le travail réalisé sur Wine ne serait donc d'aucune utilité pour un tel projet. En d'autres termes, rendre possible l'utilisation de pilotes Windows ou VxDs sous Unix serait un tout autre projet.
Cependant, si vous voulez réutiliser des pilotes Windows sous un système d'exploitation non-Microsoft nous vous recommandons la lecture de ReactOS.
If you trace Wine's roots back, you'll find quite a few different projects have emerged. For complete details, look at the Wine history page to learn how these diverged.
In the beginning, the only version of Wine that existed was managed by Alexandre. This eventually became to be known as the WineHQ tree. From there, all other branches diverged. One of the first ones to be developed outside of WineHQ was done by Corel in 1998 in support of their Wine efforts. Even though Wine was developed under the X11 (BSD-like) license, Corel resubmitted most of their changes back to WineHQ. Corel eventually moved on as well as their development team. Many changes from Corel made their way back into the WineHQ tree.
In 2002 the main WineHQ tree changed licenses to LGPL and caused Wine to fork. The original X11 code is available on SourceForge as the ReWind project. For all intents and purposes, this is a dead project. The code has diverged drastically from WineHQ's and any updates that do appear are infrequent. Anyone wishing to utilize the old Wine code under the old X11 license should strongly consider otherwise.
As Corel was ending their efforts, two new companies emerged with their own versions of Wine. CodeWeavers' developed their CrossOver line of products and TransGaming developed WineX (now called Cedega.) CodeWeavers continues to develop their products based on Wine and actively supports the community. Their development model consists of contributing directly to the WineHQ tree and branching periodically for releases. TransGaming's WineX/Cedega product followed the X11 split. Much of their code has been relicensed under the Aladdin Free Public License limiting the distribution. TransGaming has since adopted some of the libraries from the WineHQ tree and they remain under the LGPL license. TransGaming maintains informal contact with the Wine community but has not contributed anything to Wine in a number of years.
If your primary concern is to use a free version of Wine (as in beer as well as right-to-use), then you're probably most interested in utilizing the WineHQ tree. If you want a commercial product (including all the features like support) developed by a company that actively contributes to Wine, then you should check out the CodeWeavers' products described below. If you simply want to run games, TransGaming's Cedega might be a solution.
Actuellement il existe un large choix de différentes versions/packages de Wine:
C'est la distribution "standard" de Wine. Sa license est la LGPL, il peut être téléchargé gratuitement. Le code source et les binaires sont disponibles dans la section "download" du site.
C'est la version Wine avec un assortiment spécial pour s'assurer que la plupart des programmes de la suite Office fonctionne correctement. Elle coûte 74.95$ pour la version Pro et 39.95$ pour la version Standard. Elle semble véritablement valoir le coup, jusqu'à maintenant, si l'on s'en référe à certains commentaires. (note: vous apporterez votre soutien à une entreprise contribuant activement à Wine si vous décidez d'acheter CrossOver.)
Elle vous permet d'exécuter vos applications de productivité Windows favorites dans un environnement client léger distribué sous Linux. La Server Edition est aussi un bon ajout aux environnements Solaris, puisque le support intégré pour les bureaux Solaris permet de faire tourner les applications sur les stations de travail Sun. Pour les tarifs veuillez vous référez au lien suivant: CrossOver Office Server Edition Pricing
Le projet Wine a commencé en 1993 dans le but de supporter des programmes tournant sous Windows 3.1 pour Linux. Bob Amstadt a été le coordinateur original, mais a cédé assez rapidement la place à Alexandre Julliard, qui est toujours en place. Un groupe d'actualités (news:comp.emulators.ms-windows.wine) a été créé en Juillet 1994. Au fil des ans, des ports pour d'autres Unix ont été ajoutés, avec le support pour Win32 quand les applications Win32 sont devenues très répandues.
Pour plus d'informations, voyez http://www.winehq.com/site/history
Une nouvelle version de Wine sort a peu près chaque mois. Vous pourrez vous tenir au courant de toutes les dernières versions en lisant la newsgroup comp.emulators.ms-windows.wine, ou en visitant la page d'accueil de WineHQ. Quand vous téléchargez Wine depuis le site FTP de votre choix (voir la page de téléchargement pour certains de ces choix), vous pouvez vérifier que vous récupérez bien la dernière version en regardant le numéro de version dans le nom du fichier. Par exemple, la distribution réalisée le 13 août 2004 s'appelle Wine-20040813.tar.gz. Les fichiers correctifs [patch] sont aussi disponibles. Si vous avez la précédente version, vous pouvez télécharger et appliquer le correctif actuel plutôt que de réinstaller entièrement la dernière distribution. Le nom du correctif suit les mêmes conventions que la distribution mensuelle. Un accès en lecture du Read-only CVS est également disponible.
A mi 2004, Wine c'est 1,6 million de lignes de code, écrites par plus de 600 développeurs de douzaines de pays à travers le monde. On estime que Wine est utilisé par 100 000 personnes. Wine implémente plus de 90% des appels dans les spécifications Windows répandues telles que ECMA-234 et Open32.
Vous pouvez également vous référer à la page du statut pour avoir une vision globale de l'avancement des implémentations de Wine.
Les grands projets informatiques ne sont jamais finis, ils n'existent que sous forme de versions. En tout cas, Wine court après une cible mouvante car chaque nouvelle révision de Windows contient de nouveaux appels aux API ou des variations sur celles existantes.
Puisque Wine est développé par des bénévoles, il est difficile de prédire quand il sera prêt pour une une version générale. Mais l'intérêt croissant des entreprises pour porter des applications via Wine fait que, le développement de ce dernier est de plus en plus actif. A l'heure actuelle, nous sommes en train de travailler sur le lancement de Wine 0.9 Real Soon Now(tm).
Wine existe grâce au travail de nombreuses personnes. Voyez le fichier AUTHORS dans la distribution pour la liste compléte. Parmi les entreprises qui sont ou qui ont été impliquées dans le développement de Wine on trouve CodeWeavers, TransGaming, Corel, et Macadamian.
2.15. Parmi les API/interfaces non documentées, lesquelles ne le sont pas parce qu'elles sont difficiles à comprendre? Est-ce que regarder les sources de Microsoft pourrait aider ?
L'déal serait que les API Windows soient complétement documentées; Wine serait alors une implémentation parfaite et nickel chrome. Avec un accès au code source, il pourrait être plus difficile de prouver qu'aucun copyright n'a été violé. Ceci dit, la documentation est souvent mal faite, inexistante, et même erronée quand elle existe, ce qui fait qu'un taux important de retro-engineering a été nécessaire, particulièrement dans l'interface shell. Le problème majeur concernant Wine est cependant le manque de ressources humaines. A un moment donné, plus de 5000 personnes travaillaient sur Windows 2000. Alors que Wine n'a pas besoin de répliquer Windows entiérement (nous reprenons simplement les parties nécessaires pour faire tourner les programmes Windows), ce chiffre, qui représente le nombre de personnes mobilisé pour une seule version, est 10 fois supérieur au nombre de personnes ayant travaillé sur Wine jusqu'alors, depuis le début du projet.
Certaines personnes sont en train de travailler sur la portabilité de Wine pour qu'il puisse être compilé sous Windows en utilisant l'un des projets suivants comme base :
Cygwin (http://www.cygwin.com)
MinGW (http://www.mingw.org)
ReactOS (http://www.reactos.com)
Il y a des progrès, une version de Wine utilisable sous Wine devrait donc être disponible dans un futur proche.
La logique pour ces projets est en partie de trouver des zones où la portabilité de Wine est absente. C'est particulièrement vrai pour le porjet ReactOS qui est une réimplémentation du noyau Windows et qui devrait ainsi être capable de réutiliser la plupart des dll de Wine.
Une autre raison de mener ces projets est la possibilité de remplacer une simple dll Windows par son alter ego Wine. Outre que c'est un bon test pour la dll Wine, cela nous laisse la possibilité de détecter les cas où nous nous trompons au sujet de l'interaction des dll entre elles.
Les pilotes d'impressions natifs ne sont pas supportés. Il fût un temps où Wine supportait les pilotes natifs 16bit mais cela remonte à longtemps. Wine utilise les imprimantes (et autres matériels) installées sur votre système d'exploitation. La plupart du temps, si vous n'avez le matériel installé sur votre SE alors Wine ne peut pas l'utiliser.
Wine est développé pour tourner spécifiquement sur une classe de CPU Intel x86 sous certains UNIX qui tournent sous cette plate-forme. Winelib est cependant capable de porter le code source des applications Windows également vers d'autres plate-formes, et pas seulement vers les x86.
Ainsi faire tourner des binaires Windows sous d'autres plate-formes (par exemple: Mac OS X sous PowerPC) en utilisant seulement Wine est impossible. Il vous faudrait soit faire tourner Wine dans un environnement émulé x86 ou récupérer le code source de l'application Windows et le recompiler en utilisant Winelib.
Voici les plate-formes supportées par Wine. La compatibilité Winelib avec d'autres plate-formes est sans cesse en évolution, donc il n'en est pas fait spécialement mention dans cette liste.
NetBSD, OpenBSD, UnixWare, et SCO OpenServer 5 marchaient à une époque, mais Wine nécessite maintenant des unités d'éxécution au niveau du programme résident [kernel-level threads] qui ne sont pas actuellement disponibles (ou pas bien maîtrisés par l'équipe Wine) sur ces plate-formes.
L'équipe développement Wine espère également attirer l'intérêt d'autres vendeurs d'UNIX commercial et clone d'UNIX.
BeOS: efforts de portage asssez sérieux autrefois (BeWine), mais BeOS connaît de sévères limitations dans le support d'appel Unix. La disparition de Be a géné le projet bien qu'il puisse revenir un jour parmi un des projets ouverts BeOS. En tout cas, il apparaît peu probable qu'un port fonctionnel voit le jour en l'état actuel.
Mac OS X / Darwin: Le projet Darwine Darwine s'occupe actuellement du portage de Wine sur la plate-forme Darwin/x86. Leur but est de rendre finalement possible l'exécution d'applications x86 Windows sur Darwin/PPC puis ensuite sur Mac OS X en utilisant Bochs.
FreeBSD: Le suivi de ce portage est bien assuré malgré quelques limites dans certaines situations précises(principalement en l'absence de support périphérique/matériel).
Linux/x86: Pas de problème, et en tant que plate-forme préférée des développeurs et utilisateurs, c'est la plate-forme la mieux supportée de toutes.
3.2. Quelle puissance CPU minimale doit avoir mon ordinateur pour que Wine et les applications MS Windows tournent bien?
Nous devons différencier ici Wine et Winelib.
Wine ne tournera sur aucun CPU x86 inférieur au 80386 à cause des limitations de gestion d'adresse.
Il fonctionnerait également sur les 80486 et supérieur. Le test simple est, si vous pouvez faire tourner X11 actuellement, vous devriez alors pouvoir faire tourner Wine et des applications MS Windows.
Comme toujours, plus votre CPU est puissant, mieux c'est. Avoir un coprocesseur math n'est pas important. Cependant, avoir une carte graphique avec accélération 3D supportée par le X sera un plus.
En fonction de votre application vous trouverez probablement que des vitesses plus grandes sont requises pour une utilisation avancée. On ne peut pas donner de conseils spécifiques sur ce sujet à cause du vaste choix des applications disponibles. Cependant la règle de base est que si votre application tourne correctement sous Windows, elle devrait tourner correctement sous la même pate-forme avec Wine.
Il vous faut a peu près 250 megaoctets d'espace libre sur le disque dur pour stocker et compiler le code source. Wine requiert également 18 Mo dans votre dossier /tmp. Et environ 50 Mo sont requis pour faire un "make install".
Les paquets binaires, en particulier ceux ne contenant pas d'information de deboggage, ont un besoin moindre d'espace disque disponible, habituellement aux alentours de 20Mo.
3.4. De combien de RAM ai-je besoin sur mon système UNIX pour que Wine et les applications MS Windows tournent bien?
Si vous arrivez à faire tourner le X de manière fluide sur votre système UNIX actuellement, vous devriez pouvoir faire tourner Wine et des applications MS Windows tout aussi bien, en fonction de la gourmandise en RAM de l'application.
Les besoins mémoire de Wine dépendront de l'application ou du jeu que vous avez choisi d'exécuter. Il vous faudra répondre au besoin minimal de l'application ainsi que la surcharge de votre système d'exploitation sous-jacent. Vous pourrez voir avec le revendeur pour les besoins en mémoire indiqués pour cette application.
Wine tend à devenir assez important, et pour le compiler intégralement il faut un grand nombre de processus. Depuis mai 2004, les temps de compilation étaient d'environ 10 minutes sur un Athlon 2000 avec 512 Mo de RAM et 20 minutes sur un Athlon 1200 avec 640 Mo de RAM. Si vous avez une copie CVS de Wine, vous n'aurez sans doute pas besoin de tout reconstruire à chaque mise à jour.
3.6. J'ai une partition Drivespaced, Doublespaced ou Stackered. Est-ce que Wine peut exécuter des binaires MS Windows situés dans une de ces partitions?
Yes, but only if the operating system supports mounting those types of drives. There is a Linux file system driver called dmsdos that will allow read/write access to Doublespaced and Drivespace 1.0 drives. More specifically, it supports mounting DOS 6.0 and 6.2 Doublespaced, DOS 6.22 Drivespaced, and Windows 95 Doublespaced compressed partitions (read and write access works fine, but write access is slow). It can be found at ftp://metalab.unc.edu/pub/Linux/system/filesystems/dosfs/
Vous n'avez pas besoin d'une copie installée et sous license de DOS ou de MS Windows pour installer, configurer et utiliser Wine. Cependant, Wine doit pouvoir 'voir' un binaire MS Windows (c.à.d. l'application) si elle doit être exécutée.
3.8. Si Wine remplace complétement MS Windows, est-ce qu'il dupliquera toutes les fonctions de MS Windows?
L'objectif de Wine est de rendre possible l'exécution d'applications Windows sous Unix. Dans cette perspective, il fournira des remplacements juste pour les DLL et API qui sont requises pour ces applications Windows. Cela signifie que Wine ne fournira aucun remplacement pour les DLL qui ne sont pas fournies avec Windows ou qui sont toujours fournies avec une application Windows (par exemple l'exécutable de Visual Basic). Cela signifie également que l'implémentation d'une API qu'aucune application n'utilise jamais n'est pas une priorité. De la même manière, tant que des applications utilisant l'API Win64 ne sont pas disponibles, cela ne sera pas une priorité. Ceci dit, on essayera certainement de garder des portes ouvertes et d'améliorer notre couverture d'API autant que possible.
Comme Wine n'est pas non plus une SE, écrire des pilotes de matériel ne fait pas partie des objectifs de Wine. Cependant, si vous êtes intéressé par les pilotes de matériel, les développeurs de noyau sur Linux, FreeBSD (http://www.freebsd.org/) et ReactOS apprécieront certainement votre contribution.
De la même manière, Wine n'essaie pas d'être un environnement de bureau donc fournir des applets telle qu'une calculatrice, un gestionnaire de fichier ou même un gestionnaire de fenêtre qui ressemble à Windows n'est pas prioritaire ou serait même mieux fait dans un projet à part. De tels projets feraient également pour une grande double emploi avec d'autres projets open-source. Là encore, ils existent des projets où votre aide dans ce domaine seraient certainement appréciée, tels que les environnements de bureau Gnome ou KDE. Vous aurez en plus la satisfaction de voir que votre contribution est utile à tous et pas seulement aux utilisateurs de Wine.
Wine est écrit pour être indépendant du système de fichiers, donc les applications MS Windows s'installeront et s'exécuteront virtuellement sous n'importe quel système de fichiers supporté par votre marque d'UNIX.
Most of Wine's development effort is geared towards MS Windows' GUI,
but some limited support for character mode has appeared, by setting
GraphicsDriver=ttydrv
in ~/.wine/config's
[wine]
section.
L'infrastructure de Wine est déjà quelquechose préparé pour supporter d'autres pilotes graphiques que x11drv, mais aucun pilote graphique "alternatif" n'a encore été développé.
3.11. Est-ce que Wine tournera sur n'importe quel gestionnaire de fenêtres X? Est-ce qu'il nécessite un gestionnaire de fenêtre particulier?
Wine est indépendant du gestionnaire de fenêtre, donc le gestionnaire de fenêtres X que vous choisissez de lancer n'a presque aucune incidence sur votre capacité à exécuter des programmes MS Windows sous Wine. Wine utilise des bibliothèques X standard, aucun ajout n'est donc requis. Wine a son propre gestionnaire de fenêtres, qui agit comme MS Windows. Il peut être arrêté pour utiliser le gestionnaire de fenêtres natif en modifiant la configuration de Managed ou Desktop comme décrit dans man wine.conf.
A cause de décalages dus à l'utilisation d'un site mirroir, vosu pourriez avoir vent de la dernière révision avant même que la révision ne soit disponible sur les sites ftp dans la liste ci-dessous. Les sources sont disponibles depuis les sites suivants:
http://sourceforge.net/project/showfiles.php?group_id=6241&package_id=77449
ftp://ftp.infomagic.com/pub/mirrors/linux/sunsite/ALPHA/wine/development/
ftp://ftp.fu-berlin.de/unix/linux/mirrors/sunsite.unc.edu/ALPHA/wine/development/
Il devrait être également disponible sur tout autre site mirroir de ibiblio.org, voyez http://www.ibiblio.org/pub/Linux/MIRRORS.html. Certains de ces sites archivent parfois des versions antérieures de Wine ainsi que la version courante. Pour savoir quelle est la dernière version, jetez un oeil sur le nom du fichier, qui aura la forme Wine-AAAAMMJJ.tar.gz. Remplacez simplement AAAAMMJJ dans le nom de la distribution par le numéro respectivement de l'année, du mois et du jour. Le plus récent est celui à récupérer.
Les packages binaires de Wine sont disponibles pour différents SE et distributions. Voyez la page de téléchargement pour une liste récente.
Les sources actuelles de Wine sont aussi disponibles via un accès anonyme client/serveur sur le CVS. Il vous faudra la version 1.9 du CVS ou tout autre version supérieure. Si vous êtes derrière un firewall, vous aurez également besoin d'ouvrir le port 2401 de votre firewall ou d'utiliser le protocole SOCKS.
Pour vous connecter au serveur CVS, faites
export CVSROOT=:pserver:cvs@cvs.winehq.org/home/wine cvs login
Utilisez "cvs" comme mot de passe (sans les guillemets). Notez que /home/wine est un chemin sur le serveur, pas sur votre machine. Pour vérifier entièrement l'arbre source de Wine (ce qui peut être très lent), utilisez
cvs -z 3 checkout wine
ou si vous voulez juste un sous-arbre, ou un fichier particulier, vous pouvez faire
cvs -z 3 checkout wine/ANNOUNCE
Il faut savoir, cependant, que récupérer entièrement l'arbre source de Wine via CVS est assez lent, spécialement si l'on compare par rapport à la récupération depuis un mirroir FTP situé près de chez vous. Pour une liste de site mirroir CVS, voyez http://www.winehq.org/site/cvs#cvsservers
Des fichiers correctifs sont aussi disponibles, pour que vous n'ayez pas à télécharger, installer et configurer la distribution entière chaque mois si vous voulez la dernière version. Le nom des versions des fichiers patch suit la même règle que les révisions générales, et prend donc la forme
Wine-YYYYMMDD.diff.gz
Les correctifs sont disponibles sur les mêmes sites qui distribuent la version compléte. Pour se mettre à jour avec une nouvelle révision avec un correctif, changez d'abord de dossier jusqu'au répertoire racine de la révision (celui contenant le fichier README), faites ensuite un "make clean", et mettez à jour la révision avec
gunzip -c patch-file | patch -p1
où patch-file est le nom du fichier correctif sous la forme Wine-AAAAMMJJ.diff.gz. Vous pouvez ensuite relancer ./configure, et ensuite exécuter make depend && make
Si vous voulez créer un site mirroir de la distribution Wine depuis le site tsx-11 et que vous voulez faire partie de la liste de cette FAQ, ajoutez vous s'il vous plaît dans la partie "things to go into the documentation".
Les mirroirs CVS n'offrent pas encore le support cvsup, mais le serveur principal oui. Utilisez le fichier wine.sup avec:
*default host=cvs.winehq.org *default base=/cvs *default prefix=/cvs/wine *default release=wine *default delete # If your network link is a T1 or faster, comment out the following line. #*default compress *default use-rel-suffix wine
La marche à suivre se trouve dans le fichier README (http://source.winehq.org/source/README) pour toutes les instructions. Par ailleurs, vous pouvez positionner la variable d'environnement TMPDIR
a TMPDIR=~/tmp ou TMPDIR=/tmp (si vous êtes root).
Réponse simple: C'EST IMPOSSIBLE. Windows a besoin d'un accès direct au matériel, ce qui n'est pas possible si Wine et UNIX se trouvent en travers de la route.
Wine est supposé être utilisé à la base SANS Windows. Si vous voulez utiliser une installation Windows, utilisez alors une installation existante en parallèle de l'installation UNIX (voyez le comment faire le double démarrage [dual-boot HOWTO] pour votre SE pour plus de détails). Or alternatively use the cabextract utility to extract Windows install archives to a directory that you want to use as Wine's Windows tree.
Wine vous oblige à avoir un fichier de configuration comme ~/.wine/config. Le format de ce fichier est expliqué dans la page d'aide [man page] wine.conf. Le fichier ~/.wine/config. Le format de ce fichier est expliqué dans la page d'aide [man page] wine.conf. Le fichier documentation/samples/config ( http://source.winehq.org/source/documentation/samples/config) contient un exemple de fichier de configuration. Des conseils plus explicites se trouvent dans le fichier README ( http://source.winehq.org/source/README) qui se trouvera dans le dossier de base de Wine une fois que vous aurez décompréssé le fichier de distribution avec l'une des deux commandes suivantes gunzip ou untar.
La mise à jour de Wine n'affecte pas pas la configuration de Wine existante. Par conséquent après l'amélioration de Wine vous avez encore votre ancienne configuration (de travail).
Utilisez soit une installation classique non-Windows (Wine s'améliore de jour en jour) soit une installation Win9x (Win95, 98, 98SE, ME). NE configurez PAS Wine pour utiliser une installation Windows basée sur la technologie NT (NT, Win2K, WinXP, Win2K3). En général, la plupart des installations Windows contiennent une quantité monstrueuse de saloperies qui peut perturber Wine et le rendre moins fiable.
En général, la plupart des installations Windows contiennent une grande quantité de garbage that can confuse Wine and make it less reliable. Si vous le pouvez, il est préférable d'installer les programmes que vous voulez dans le lecteur Windows factice.
Au 02/2002:
Je dirais que Win98SE est la meilleure version à utiliser avec Wine, puisqu'elle est pas mal répandue chez les développeurs et qu'elle est relativement mature. L'utilisation de fichiers Win2K est assurément pire qu'une installation de Wine sans fenêtre, et Win ME est connu pour être problématique, également (vu qu'aucun développeur ne l'utilise). Pour faire bref: tout Win9x <= W98SE est bon.
5.7. Impossible de faire tourner/d'éxécuter l'installation d'applcations générées par Visual Basic. Que faire?
Assurez vous que vous avez bien toutes les bibliothéques d'exécution VB d'installées. Vous pouvez obtenir la dernière version depuis le site de Microsoft.
Les versions normales de Wine n'ont pas encore d'extensions .exe enregistrées pour Wine dans KDE/Gnome. Vous devez à la place ouvrir une fenêtre de terminal (souvent une icône représentant un "écran noir") et taper quelque chose ressemblant à ça:
cd /my/windows/program/directory wine myprogram.exe
Essayez de vous délogguer puis de vous relogguer sous bash. Cela peut résoudre le problème.
Si ce n'est pas le cas, alors assurez-vous que le binaire wine est
dans votre PATH
.
Lancez en tant que root:
find / -name "wine" -type f -perm +111
pour trouver le chemin où le binaire Wine se trouve. Vérifiez ensuite
que PATH
l'inclut:
echo $PATH
Sinon, ajoutez le par exemple dans /etc/profile en faisant:
export PATH=$PATH:/path/to/wine/binary
Cela devrait vous dépanner.
Si vous avez utilisé un gestionnaire de paquets (rpm ou apt) - Vérifiez vos paquets. Le paquet winesetuptk.rpm est seulement une interface [front-end] pour créer un fichier de configuration qui tienne la route, il N'INSTALLE PAS le paquetage Wine...
Pour les paquets complets, utilisez http://rpmseek.com/ ou la section Download.
Cela dépend de la façon dont vous l'avez installé. Si vous avez utilisé un RPM, la commande à faire est celle-ci: rpm -e wine (en tant que root)
Si vous l'avez installé depuis la source (le fichier .tar.gz), la bonne façon de faire est d'aller à la racine de l'arbre source (le répertoire avec le script de configuration, le fichier readme etc) et de lancer ensuite (en root): make uninstall
En invoquant Wine, vous devez spécifier le chemin entier de l'exécutable, ou le nom de fichier seulement. Pour exemple pour lancer le solitaire de Windows tapez l'une des commandes suivantes:
wine sol ou wine sol.exe (en utilisant le chemin de recherche pour localiser le fichier).
wine c:\\windows\\sol.exe (en utilisant le nom de fichier DOS).
wine /usr/windows/sol.exe (en utilisant le nom de fichier UNIX).
wine "c:\windows\sol.exe" (en utilisant le nom de fichier DOS entre guillemets).
Le chemin du fichier sera aussi ajouté au chemin [path] quand un nom complet est utilisé en ligne de commande.
6.2. J'ai installé et configuré Wine, mais Wine ne trouve pas MS Windows sur mon disque. Où est l'erreur?
Si vous avez une partition DOS, assurez vous d'abord que vous l'avez montée, soit en rajoutant l'entrée dans le fichier /etc/fstab, ou en la montant à la main.
Rappelez vous également qu'à moins que votre version d'UNIX puisse voir à travers, ou que vous utilisiez un utilitaire qui puisse voir à travers, votre partition DOS ne doit pas se situer sur une partition Drivespaced, Doublespaced ou Stackered, car par nature ni Linux, ni FreeBSD, ni NetBSD ou Wine ne peuvent 'voir' les fichiers situés sur ces partitions DOS compressées.
Vérifiez la syntaxe de votre chemin dans le fichier wine.conf. Les lettres capitales ne doivent pas être utilisées dans les chemins, car elles sont automatiquement converties en minuscules.
6.3. J'ai réussi à éxécuter différents programmes MS Windows, mais tout ne marche pas dans ces programmes. Qu'est ce qui cloche?
Wine n'est pour le moment pas complet, par conséquent dans chaque programme certaines caractéristiques peuvent ne pas fonctionner. Cela finira par se régler car de plus en plus d'appels API MS Windows inclus dans Wine.
6.4. J'ai lancé différents programmes MS Windows, mais comme les menus de ces programmes ne fonctionnent pas, comment quitter ces programmes?
Arrêtez la fenêtre xterm shell que vous avez utilisé pour lancer le programme MS Windows, et la fenêtre X qui est apparue avec le programme s'arrêtera également.
Si vous êtes un développeur et que vous avez des connaissances en C, alors vous pouvez commencer à débogguer Wine et nous aider à l'améliorer! Si ce n'est pas le cas, vous devrez alors soit convaincre un développeur Wine d'essayer de faire marcher votre programme (il doit y avoir une version ou une démonstration téléchargeable pour cela).
Vous pouvez soumettre votre application à la base de données Wine Application DB et récupérer des tuyaux sur la façon d'améliorer le fonctionnement de votre application.
Vous pouvez également soumettre votre application au CodeWeavers CrossOver Compatibility Center. Où vous pouvez votez pour soutenir votre application favorite.
Egalement, il se peut que vous puissiez faire marcher l'application en prenant les DLL natives depuis une installation Microsoft Windows, et en les utilisant (régler les DLL à natif dans le fichier de configuration). Toutes les DLL ne peuvent pas être remplacées de la sorte - en particulier DirectX pas plus que certaines DLL du système central [core system] comme gdi32, user, ntdll, kernel32 etc.
Vous pouvez utiliser Wine sur n'importe quelle installation Linux suffisamment récente. La quantité de travail pour mettre Wine en service et l'utiliser varie selon que vous l'installez avec les paquets binaires ou que vous faites une installation depuis la source.
Oui. Wine devrait marcher avec n'importe quel processeur compatible Pentium ou plus.
Bien sûr, Wine supporte cela. Entrez juste le nom du programme Unix là où le programme propose l'exécution de quelque chose, et cela devrait marcher.
6.9. J'obtiens "Error installing iKernel.exe: (0x1400)" quand je lance un installeur InstallShield 6.
Si vous obtenez l'erreur "Error installing iKernel.exe: (0x1400)" à chaque fois, c'est probablement parcequ'ils restent certaines processus d'une précédente tentative. Vous pouvez le vérifier avec la commande
$ ps augxw | grep wine
Si cette commande affiche d'anciennes copies de Wine lançant votre installation, vous devez les arrêter [kill] avant de pouvoir lancer le programme d'installation. S'il n'y a pas d'autres programmes Wine en cours d'éxécution, vous pouvez tous les arrêter [kill] avec la commande
$ killall wine
Si vous être en train de faire tourner des programmes Wine auquel vous tenez, vous devrez arrêter les anciennes instances d'installation une à une en utilisant la commande kill et les PID de cahque processus PID (ou peut-être le très chic Gestionnaire de tâches de Wine qui n'existe pas encore).
Répétez la commande ps pour vous assurer que tous les anciens processus Wine sont clos.
7.2. Je n'ai pas trouvé la réponse à ma question dans la documentation, mais j'ai écrit une documenation expliquant comment résoudre ce problème. Que dois-je faire?
Des mises à jour et des ajouts concernant la documentation de Wine doivent être envoyés à la liste de diffusion "wine-patches" à http://www.winehq.org/site/forums. Les ajouts sur la FAQ ou le site Web doivent être déposés dans le répertoire de base "Wine knowledge" approprié.
Oui, elle s'appelle comp.emulators.ms-windows.wine. La newsgroup est un espace ouvert aux utilisateurs et aux développeurs qui veulent discuter de Wine, et pour certaines informations non importante grand public. Les annonces importantes seront postées en parallèle sur d'autres newsgroup appropriées, telles que les suivantes:
Si votre site Usenet ne dispose pas de ces newsgroups, demandez expressément à votre admin FAI de les ajouter et/ou de mettre les liens pour s'y connecter.
Wine HQ (http://www.winehq.org) est le site officiel.
Bien sûr. C'est le canal #WineHQ sur irc.freenode.nett voir (http://freenode.net). Habituellement plusieurs développeurs Wine sont présents juste pour VOUS aider, vous! ;-)
7.6. Je crois que j'ai trouvé un bogue. Comment puis-je prévenir l'équipe de programmeurs de Wine de celui-ci?
Les rapports de bogue doivent être soumis à notre système en ligne Bugzilla (http://bugs.winehq.org/). Vous devrez au minimum préciser les choses suivantes:
La version Wine testée
Le nom de l'application Windows, y compris la version, et, si possible, une URL où l'application peut être téléchargée
Une brève description du bogue
Les parties importantes de la sortie du déboggueur de Wine
Une capture d'écran du problème, si possible
Pour plus d'informations sur la manière de rapporter les bogues voir la section How to report a bug du guide de l'utilisateur Wine [the Wine Users Guide].
Si vous pouvez programmer en C, c'est déjà ça. Téléchargez les sources via (CVS,) inscrivez-vous aux listes de diffusion, jetez un oeil au code source, et intéressez-vous au groupe de nouvelles comp.emulators.ms-windows.wine et aux listes de diffusion (http://www.winehq.org/site/forums). Regardez si vous voyez quelque chose que vous pensez pouvoir réparer ou dont vous pouvez vous occuper. Vous n'aurez pas de problèmes pour trouver des domaines où il y a du travail à faire dans Wine (filtrer [grep] les FIXME dans le source).
Vous pouvez apporter vos (connaissances en programmation et en documentation, ou faire des dons en argent ou matériel, pour aider les développeurs de Wine à atteindre leurs buts.
Pour trouver des idées sur la manière dont vous pouvez aider, consultez la page de contribution de Wine.
Wine est encore fait de code Alpha en ce moment. Cependant, n'importe qui est le bienvenu pour télécharger la dernière version, et l'essayer à tout moment.
Soumettre un correctif pour un ajout dans Wine est très simple. En gros tout ce que vous avez à faire est d'envoyer le correctif à la liste diffusion wine-patches (http://www.winehq.org/mailman/listinfo/wine-patches). Il y a cependant des recommendations sur le format du correctif et par conséquent il est conseillé de lire la page où nous décrivons comment soumettre les correctifs (how to submit patches). Cela vous donnera également plus de détails sur l'ensemble du processus et en particulier sur ce que va devenir votre correctif une fois soumis.
C'est justement ça, Winelib. Pour le moment c'est peut-être encore un peu difficile, mais cela évolue tout le temps. Lisez le Guide d'utilisateur de Winelib [Winelib User's Guide] pour information.
Wine n'implémente pas de remplacements MFC et ne prévoit pas d'en faire. Cependant il est possible (avec beaucoup de travail) de compiler MFC depuis les sources et de créer ainsi une bibliothèque mfc42.dll.so.
Reportez-vous au Winelib User's Guide pour savoir comment faire.
Voici quelques exemples d'applications portées en utilisant Wine ou Winelib:
Corel's WordPerfect Office Suite 2000 a été porté sous Linux en utilisant Wine.
Kylix, la version Linux de Delphi, a été portée sous Linux en utilisant Winelib. L'IDE utilise en fait une combinaison de QT et Winelib alors qu'il n'aurait pas été possible d'y arriver en utilisant uniquement Wine. Cependant, les applications générées ne dépendent absolument pas de Wine.
MusicMatch Jukebox 5 a également été porté (http://www.itworld.com/nl/lnx_desktop/01042001/) sous Linux en utilisant Winelib. Cependant des versions plus récentes ne le sont pas, et la version 5 n'est plus disponible.
Ability Office (http://www.ability.com/linux/abilitylinux.php)
IBM's Websphere (http://www7b.boulder.ibm.com/dl/swws/swwsgddb-p)
Beaucoups d'autres applications ont déjà été portées. (on parle de plusieurs applications dans le top 500 ici)
9.4. Is there a way to bind the Wine code, a Windows .exe, associated DLLs, and any necessary accompanying files into a single Linux executable which can execute as if it were a native linux binary (ie without also having Wine pre-installed)?
No. However, if you don't want Wine as a dependency, you can bundle your private version of Wine into your package (.rpm/.deb). Wine has good support for such a setup via the WINEPREFIX environment variable.
Il y a de bonnes raisons pour procéder de la sorte.
Voir: http://www.winehq.org/site/forums And select [(Un-)Subscribe]