Wine FAQ

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-devel@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.

Yes, there are. You can use VMWare to run a Windows installation inside a virtual machine, or use Win4Lin to run a specially adapted Windows version on Linux. Both solutions cost money for both the software itself and a Windows license.

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/2000.

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.

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.

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.

Actuellement il existe un large choix de différentes versions/packages de Wine:

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

A new version of Wine is distributed about every month. You will be able to keep up on all the latest releases by reading the newsgroup comp.emulators.ms-windows.wine, or by visiting the Wine HQ homepage. When downloading Wine from your FTP site of choice (see the Download page for some of these choices), you can make sure that you are getting the latest version by watching the version numbers in the distribution file name. For instance, the distribution released on August 30, 2005 was called Wine-20050830.tar.gz. Patch files are also available. If you are current to the previous version, you can download and apply just the current patch file rather than the entire new distribution. The patch file names follow the same conventions as the monthly distribution. Read-only CVS access is also available.

As of mid 2005, Wine consists of about 1.4 million lines of code, written by more than 600 developers from dozens of countries around the world. Wine is in active use by an estimated 200K people. Wine implements more than 90% of the calls in popular Windows specifications such as ECMA-234 and 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.

Because Wine is being developed mainly by a single company (CodeWeavers) and volunteers, it is difficult to predict when it will be ready for general release. But due to the much increased interest by other companies in porting apps via Wine, Wine development is constantly getting more and more active. Right now we are working on releasing Wine 0.9 our schedule has this release around September 30th 2005.

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.

The best solution would be if the Windows API were fully documented, so Wine could be a perfect "clean-room" implementation. Seeing the source code might make it harder to prove that no copyright violations have taken place. That said, the documentation is often bad, nonexistent, and even misleading where it exists, so a fair amount of reverse engineering has been necessary, particularly in the shell (Explorer) interface. The biggest problem facing Wine though is simply lack of manpower. At one point, over 5000 people were working on Windows 2000. While Wine doesn't need to replicate all of Windows (we only cover the parts needed to make Windows programs work), that's still nearly 8 times more people working simply on one release than have ever worked on Wine, in the history of the project.

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: The Darwine project is currently working on porting Wine to the Darwin/x86 platform. Their goal is to eventually make it possible to run x86 Windows applications on Darwin/PPC and then Mac OS X by using 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.

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.

You need approximately 750 megabytes of free hard drive space to store and compile the source code. Wine also needs about 18 megs in your /tmp directory. And about 50 MB are needed to do a make install.

Binary packages, especially those not containing debug information, have much lower disk space requirements, usually in the 30MB range.

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.

Wine's memory requirements will depend on the application or game that you choose to run. You will need to meet the minimum requirements for the application as well as the overhead of your underlying OS. You may want to check with the vendor of the application for its suggested memory requirements.

Wine is getting to be quite large, and building from scratch takes a lot of processing. As of September 2005, compile times were around 15 minutes on a Intel 3.8GHz Laptop with 1 GB of RAM. If you have a CVS copy of wine, you may not need to rebuild every thing each update.

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/

You do not need a licensed and installed copy of DOS or MS Windows to install, configure or run Wine. However, Wine has to be able to 'see' an MS Windows binary (i.e. application) if it is to run it.

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é.

Wine is window manager independent, so the X window manager you choose to run has (almost) no bearing on your ability to run MS Windows programs under Wine. Wine uses standard X libraries, so no additional ones are needed. Wine has its own window management, which acts like MS Windows. It can be turned off to use the native window manager by modifying Managed or Desktop settings in winecfg.

Oui, les programmes 32-bit sont bien supportés.

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

• http://www.ibiblio.org/pub/Linux/ALPHA/wine/development/

• 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/

• ftp://orcus.progsoc.uts.edu.au/pub/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 
              

See the README (http://source.winehq.org/source/README) for instructions. Additionally, you may want to set the TMPDIR environment variable TMPDIR=~/tmp or TMPDIR=/tmp (if you are 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.

As of Wine release 20050725 the config file has been disabled and the values are now stored instead in registry files in your .wine directory. The preferred method to configure Wine is with winecfg, winefcg is a tool to make it easy for new users to edit some of the contents of there registry files.

Upgrading the wine installation does not affect the existing wine registry settings. So after upgrading wine you still have the old (working ) wine registry configuration.

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.

As of 09/2005:

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.

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.

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.

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.

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.

Menus should be working correctly, if for some reason your applications menus stops responding. You can kill the xterm shell window that you called up to run your MS Windows program, and the X window that appeared with the program will be killed too. If you started the application from a shortcut you can open a terminal and start xkill and just click on the application to kill it.

If you are a programmer and know C, then start debugging Wine and help us make it better! If you can't, then you will have to either convince a Wine developer to try and make your program work (there must be a downloadable version or demo for that).

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.

We recommend that you try builtin dlls first and report any errors that you may run across to wine-devel or to our Bugzilla. If you report problems they can be verified and fixed by the development team and this helps everyone over the long run by not covering up bugs with the use of native dlls.

Alternatively, you may be able to get the app working by taking native DLLs from a Microsoft Windows install, and using them (set the dlls to native with winecgf). Not all DLLs can be replaced that way - in particular DirectX cannot be, nor can some core system DLLs like 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.

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.

Oui, voir http://www.winehq.org/site/documentation.

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:

• comp.os.linux.announce

• comp.windows.x.announce

• comp.emulators.announce

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.

Sure. It's channel #WineHQ on irc.freenode.net see (http://freenode.net). Usually several knowledgeable Wine users hang out there.

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.

One area where every Wine user user can contribute to this project is by sending high quality bug reports to our Bugzilla and helping the developers with any follow up questions that they may have about a bug that you have come across. It is not only impossible but also impractical for a developers to have a copy of every program on the market. This is why we need your help even after you have sent in the initial bug report. If a developer has a good idea what might be causing the bug he or she may ask if you can try a patch and see if it fixes the problem. After this patch makes its way into our main development tree the bug report will be closed and your help will be appreciated by everyone.

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.

• Vividas Streaming Video (http://www.vividas.com/support/)

• Ability Office (http://www.ability.com/linux/abilitylinux.php)

• IBM's Websphere (http://www7b.boulder.ibm.com/dl/swws/swwsgddb-p)

• BricsCad® (BricsCad® V6 for Linux)

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.

Franchement, vous n'avez pas trop intérêt à faire cela. Si il y a un truc bizarre à corriger dans Wine, il est vraiment préférable de le réparer dans Wine.

Il y a de bonnes raisons pour procéder de la sorte.

Voir: http://www.winehq.org/site/forums And select [(Un-)Subscribe]