General Wine Information
This is for small tips, tricks and general troubleshooting for Wine Users. Often these arise from discussions in the Wine Mailing Lists. Interesting details that don't require a seperate entry in the Wine-wiki, or have yet to be assigned a permanent page in the wiki can be listed here. Wine is now essential to some business as One wrote: We use Wine at work to run a Windows console binary from a dead company (so no prospect of porting or updates). It runs on a Linux box with a zillion other things, rather than a Windows box, where it would have to be pretty much the only thing running and cost us a Windows licence and the PC to run it on - so for us it's not reliability, it's sort-of-virtualisation. It's run flawlessly for years. It's the example I bring up whenever anyone claims Wine will never be ready for real-world use ;-)
What is Wine - Is Wine Legal
A user queried: As I will be using Linux/Ubuntu (along with wine) for business purposes, is Wine and what it does 100% legal?
A. English: Of course! The code is implemented in a clean room reverse engineering way. [He then cautioned] The use of native DLLs, however, may violate Windows EULA (but that depends on the DLL, and if your country allows that restriction or not).
The user continued: Can I open and use both a Linux based program and a windows based program (using wine obviously) at the same time?
A. English: Yes. Wine [runs] windows programs try very hard to integrate into your native Linux desktop. Try running 'wine notepad' for an example.
The the user asked: One program that I specifically have to use, which will require Wine, is not a complicated program [..] but at the same time is not a very well known or popular one. �Does anyone forsee any issues in Wine being able to run a program like this?
A. English: You can check http://appdb.winehq.org to see if it's listed.
General Wine Tips
- The Wine FAQ at http://winehq.org/site/docs/wine-faq/index
- The Wine User Guide at http://winehq.org/site/docs/wine-user/index
- WWN: Wine Documentation This will soon need updating as the Config File was removed for the June Release 2005.
- The Wine Developers Guide at http://winehq.org/site/docs/wine-devel/index
- [May 05] WWN: Wine Documentation :Recently updated. 'In great shape'.
- How to help get applications working in Wine at http://winehq.org/site/helping-applications
- Getting Started with Wine Development at http://winehq.org/site/developer-cheatsheet
Dimi Paun mentioned a change in the documentation arrangements for Wine [May 05]: the SGML docs have moved over to the CVS SourceForge: http://sourceforge.net/cvs/?group_id=6241
I'll be managing that tree for now (unless Alexandre wants to do it :)). Please send your patches as you usually do to [email protected], but make sure to prefix the subject with '[WINEDOCS]' so I can more easily spot them. Discussions should take place on [email protected] as per normal. The new repository is set up with translations in mind [...]
Has wine previously been installed on my computer?
You can confirm whether Wine is installed by opening a terminal window and typing
Unless the Wine Application Database instructs otherwise, use the latest release. Wine is constantly improving at an impressive rate.
H. Bostick [May 05][Wine Archive link]: [Most distributions of Linux] have some [old] version of Wine in their repositories. So the user just installs it from there. We have to send them to the [www.winehq.org [official wine hq]] site to get a current download. [...] Wine installs silently as H. Bostick points out: 'There is no popup on firstrun' but then said 'if you need more help, or want to help, head over to http://www.winehq.org.' With your version of Wine help is provided with the standard linux man pages though she added a caution: [...] man pages are not the default first search point of this so-called "average (Windows) user"
M. Hearn described the reasoning behind this: The basic idea is you don't need any instructions. We currently associate EXE files with Wine, so you can just click on the EXE file [as you would do with Windows]. [..] We [do] need [...]somebody [...]to draw us some nice win32 file icons and get them merged into the default icon themes (or our CVS). I. Leo Puoti: I just use the wine icon for Mandrake RPMs.
When Wine is run for the first time, it installs in the users home directory under ~/.wine but a user queried this [July 05]: the C drive [is installed] under ~/.wine [and is] 'hidden' [...] a lot of graphical file browsing tools won't show dot files / directories without reconfiguration.
S. Richie: It's sort of a [Linux] standard to have an application store all of stuff in its own hidden folder. Now, Wine may be a bit of an exception to this, since it's not really one application or even suite of applications - the user has to install everything. However, keeping everything in .wine allows an easy, clean, nuke and reinstall of Wine, or transference of it to another system - one of the reasons this standard came about. Wine Archive
M. Hearn [Jun 06]: [after musing whether this should change asked] How often does [the average user] need to go poking around C:\Program Files in real Windows? wine archive
P. Beutner: system.reg, user.reg and dosdevices/, [...] are "generally uninteresting". And if you [access and edit...] them you want to use regedit/winecfg, than editing them by hand. wine archive
A user asked [aug 08 wine user] Is there any way [...] to change that and make it a normal directory called simply "wine"?
D. Kasak pointed to an easy solution: How about [create a visable link to this from your home folder]:
ln -s .wine wine
One user asked: is it possible to point the wine c drive to my xp drive named system which i am mounting automatically each time the system starts as this has my xp program files in in
Another poster said: Doing that will kill your windows install. if you do that the only way to fix it. is to reinstall windows. Read the FAQ! [Ed This is true! Occasionally people post saying they have to reinstall Windows because they did not heed this warning]
The Wine Version
What version of Wine do I have Installed?
If you already have wine installed, identify the version by typing in a terminal window
A. Mohr explained why there are two dashes: Unix *always* (well, almost;) uses double-dash for long options Wine Archive
Identifying the Latest Version of Wine
There is a small catch that may trip you up with the version numbers when you are looking to download the very latest version. A. Talbot [Feb 07 Wine devel] The problem arises when version control programs sort the release "tags" alphanumerically, [...]. as one long time wine user noted: [The] actual system is [...] a numbering one - so [...] the difference between 0.9.3. and 0.9.30 is the difference between 3 and 30. [...] so [..] 0.9.3. < 0.9.30. ; 03.9.3.1 < 0.9.30.1 ...etc .
Ed. Perhaps another example will suffice. After version x.x.99, the next version would likely be increased by 1 which gives you x.x.100. However your software tools may list the older version first.
Which Version of Wine should I use
A. English Jan 09:[..] as an experienced Wine user and developer, I can tell you that you should be using the development release. It has support for more programs/functions. Stable is good for you if you don't ever want things to change, and your program works great in 1.0.1.
J. Drescher: To me it's a question of what is better an incomplete "stable" version wine that was created months ago that is known to have bugs or a version of wine that has fixed some of the bugs in the "stable" version and made it more complete but may have a few more unknown bugs added?
[Ed one advantage of stable is that software developers can recommend a version to use]
64Wine and Wine on 64
Wine currently can run on many 64 bit systems with the compatibility libraries for 32bit. Now for wine running the 64bit Windows software, that is another matter all together. Work has been on going and it can apparently run some things but this will need on going work.
A discussion about the long term ideas was raised by one userfeb 09]: I realise that the Win64 stuff is experimental [in2009] but I'm [curious], in the longer term is it expected that one executable will be able to run both Win32 and Win64 executables?
A. Juliard: Not really, you'll of course still need to build a full 32-bit version of Wine, the 64-bit Wine will never be able to run 32-bit apps. What needs to be improved is that the 64-bit loader should be able to forward automatically to the 32-bit one when encountering a 32-bit app.
V. Povirk [2011 feb] You'll want to make sure you have a recent gcc; see http://wiki.winehq.org/Wine64
As a general rule, taking programs shipped with Windows and trying to run them in Wine is not a good test of anything. They are not like normal programs. Maybe notepad and calc used to be simple, but I'm not so sure that's the case in Windows 7. [..] I think the fact that 7zip and Putty work is an indication that the simplest of 64-bit programs do run, and the basic architecture is working.
Vitamin: [ The meaning of WoW64 mode is] To be able to start 32-bit windows apps under 32-bit Wine that will use the same registry. Both Windows and Wine uses separate set of 32-bit libraries to run 32-bit applications on 64-bit system. There is no way around this. With Wine, you need to properly install both 32-bit and 64-bit Wine versions so they can cooperate (that's what Wine calls wow64, more-less).
Wine development since version 1.2
A. Julliard gave a few notes on future development post 1.0 [Jun 08 wine devel]:
- [...] Development will continue as usual in the git "master" branch. The 1.1.x development releases will be made from that branch every other Friday.
- There is now a git "stable" branch, where only important bug fixes will be committed. The 1.0.x maintenance releases will be made from that branch whenever enough changes have accumulated to justify a release. The process I suggest for the 1.0.1 release is as follows:
- all bugs should be fixed in the master branch first - once a bug fix has been committed to master, the corresponding bug report should be marked fixed, with the sha1 of the commit fixing it
- the bug report should then be put into the 1.0.1 milestone.
This will allow me to periodically query for 1.0.1 bugs that are fixed in master and cherry-pick the corresponding commits into the stable branch.[...]It's easy enough to extract a list of translation patches if we decide to merge them, so I don't think there's a need to maintain a list in bugzilla. [...]If a patch can't be made to apply then I'll ask the author to merge it, but for 1.0.1 that shouldn't happen, we won't be diverging that fast. And once backporting starts to become too painful then it will be time to make a new stable release. [... For the 1.0.1 branch] If a bug fix comes with a test then the test can be merged too, but otherwise I don't think it's necessary to add tests.
J. Hawkins [Jun 07]: There will never be a point where all Windows apps work in Wine. As it stands, we have a bigger compatibility goal than current versions of Windows, as we support apps all the way back to Win 3.1. Unfortunately, it's just not possible to support all known apps.
Ed: while tests for win98 are apparently no longer being added, the existing tests are still available for developers. With limited developers, this is not that win98 is being abandoned, but new tests for windows 2000 and later are easier and quicker to write and test without being forced to workaround the many many win98 issues.
anon: repeat after me... Wine, more compatible with Windows than er, Windows!
Wine has continued its stunning pace of development. If you are running version 1 you might want to upgrade. [Mar 09] vitamin wrote to a user running version1.0: Upgrade. You need wine_gecko and it's not available for such old Wine version anymore.
Previous Preparations for Wine 1.2
A. Julliard said: 64-bit support isn't too far away
Update Jan 2011. Wine now supports 64bit but improvements are still ongoing. G. van den Berg: It is supposed to be usable in 1.2 and newer (working 64-bit support was the release criteria for 1.2), but it is likely to be significantly less reliable than 32-bit... (And a much larger percentage of apps will have problems)
Developing Software for Windows and Wine
One developer reported: I did several changes to my application to be compatible with wine, but if every time a new snapshot is released something is broken I can't support wine.
M. Stefanuic: That's the wrong approach. You shouldn't need to make your application compatible to Wine. If your up runs into Wine bugs please fix Wine itself or at least open bug reports. Wine will make the efforts to be bug compatible to Windows _if_ real life applications depend on that behavior. But Wine won't be compatible to its own bugs.
Wine and Windows Partitions
A user queried about mixing wine and Windows. While this appears to be a common misconception about wine, J. Chapman explained it this way [Aug 07 wine user]: Wine Is Not (an) Emulator.
This means that it cannot run windows - it 'is' windows as far as your end-user applications are concerned.[...] This means that you should [...] install applications properly [under wine] and use them. It does not require, nor does it work with, an existing windows installation.
NEVER, EVER run wine as root!
V. Margolen wine developer Warned : don't run programs directly from your [real] windows drive. [as a general rule] Never point your c: drive to the real windows drive - that won't help wine at all but it might break your windows beyond repair. [because]. Wine, [can] (and will) create/write/change/delete files under C:\Windows. This is dangerous on a working windows drive. wine archive [Oct 07 wine devel he added] : It's the same as [attempting] to run an application on windows via the network from another [windows] PC [No, dont try this at home, this is a bad idea. Doing this even in Windows will likely cause you grief].
Running Wine with user privileges
T. Cavin: Yes, this is a "security precaution", but [...] It isn't just Wine that you shouldn't run as root or superuser, it's any program. On any Unix or Linux computer system, a process running with root (uid=0), (or in MS-Windows a process running with administrator privileges) has unquestioned authority to change the system. Execution privileges directly affect program functionality, and giving a program too many privileges means you may be giving it more than it was designed for.
The operating system doesn't care if the command to format the system disk came from a command line of a logged in sys-admin who is wiping the disk before disposal, or from an email virus automatically executed by Outlook Express. If the process issuing the format command has sufficient privileges to wipe the disk ... it's history.
That's an extreme example, but there are many lesser issues that can cause more subtle damage. Programs that are designed to be run by non-privileged users may normally probe parts of the file system in order to find a place to store temporary files. This probe can be as simple as checking for read permissions, and a failed check causes the program to look elsewhere for temporary file space. A user program may try to store information in the current directory, and if it can't write there it will switch to a user's home directory. If you run such a program as superuser, the permissions check always succeeds, so you may end up writing files anywhere on your system. in the case of Wine, this is a particularly serious issue. Wine is designed to run programs that were written for a different OS. Regardless of anyone's opinion of the innate reliability of such code, running _any_program in Wine is running it in a foreign environment that has different rules than the program expects.
[...] If you do this on your own machine you are only likely to hurt yourself. It might be interesting to see what happens, and it could even be a good learning experience. But please don't do this on any system you (or anyone else) depends on. Wine Archive
It is true there are a few programs where wine needs to run as root, wine will tell you if it needs root permissions. Unless wine tells you, do not run as root. J. Lang Oct 07 wine devel: we strongly recommend against running Wine as root. But you sometimes need to run Wine as root in order to do certain things on Linux, e.g. open raw sockets. The solution: don't run applications that want to do those things, or take it up with the Linux kernel developers.
Setting up the very real but fake Windows environment
You can obtain installation files and the source code from the Official Wine website. Users have added to The Wine-Wiki instructions to install Wine for most distributions, and the Official Wine Application Database has important information on how to install and run an extensive list of programs with Wine.
You can then run Windows software under wine by either clicking on a Windows executable, from the command line, or you can make a shortcut. If you run a installation program that puts installs a shortcut on the desktop, Wine can often create a shortcut on your linux desktop for you.
Since the June 2005 release of Wine, type in a terminal window Winecfg. This will create a fake Windows Drive and all the directories in your home user directory, and is where Wine's configuration settings can be altered. (Previous versions of Wine made use of the (now obsolete) Wine Config File) With winecfg, you can set overrides for each application, sound, and many other aspects of wine. If you are new to Wine, or have not used Wine for a long period, the need to first read the documentation with Wine probably cannot be understated.
A. Browaeys: See windows programs as plugins for wine . They are installed in the home directory of the user used to install them[...](c: is a directory in your user home, so your are already "root" in the windows meaning in your wine environment). Security wise using wine as root is giving your windows program the capabilities to break your system [...].
W. Olgburn: the general recommendation is to install applications separately under wine.
If you have a windows executable, say "setup.exe," you could:
- open up a terminal window, cd to the right directory, and type
- wine setup.exe
- open a file browser like Konqueror, click on setup.exe, and in the "Open with..." dialog type "wine."
At this stage in Wine's development, sometimes dll overrides are required, which means that a Native Microsft Dll is needed to make it run. Several methods are available. See winecfg,Using the Command Line#WINEDLLOVERRIDES and see Man Page:WINEDLLOVERRIDES for running Wine InstallShield or Wine MSI installers and also while running some programs. Because of the rapid pace of Wine development, check the Wine application database for the latest tips to installing and using your favourite software (if your software is not listed, please make sure you submit it to be added). Sometimes the tips are out of date, and it can be best to try on a clean wineprefix without any workarounds - it might just work!
W. Ogburn: As you install programs under Wine, you should automatically get a "Wine" entry in your applications menu. This works like the MS Windows Start menu, if you're used to that. Wine Archives.
N. Law [Nov 2006]: for those that rely upon wine to run their favorite application, then install your stable version of wine that runs your application somewhere other than the default installation directory and use that while still downloading and testing the latest release. Then when the latest wine breaks you application it doesn't stop you using your favorite [application ]
Windows File Locations
V. Margolen: [Wine is a] "Windows replacement". So all the cases [where] someone has an access to a partition with functioning windows means nothing to Wine. "~/.wine/dosdevices/c: points to what windows programs will see as a "c:" drive." [but] don't run programs directly from your [real] windows drive. [as a general rule] Never point your c: drive to the real windows drive - that won't help wine at all but it might break your windows beyond repair. [because]. Wine, [can] (and will) create/write/change/delete files under C:\Windows. This is dangerous on a working windows drive. While at any time you can remove ~/.wine dir [created by wine] and [restart] with a clean [fake] "windows" environment, you [will] have to reinstall Microsoft Windows if [you] break [your real windows installation]. [whttp://www.winehq.org/pipermail/wine-devel/2005-November/042319.html wine archive]
J.Hawkins:In [the folder] .wine/dosdevices there are symbolic links that point to virtual "devices" for wine. Z:\ usually maps to the root directory.., so if you want to access anything outside of C:\ you can use Z:\. Generally you should use .wine/drive_c with windows programs though so you don't have to look through the unix file system for a file.
Does wine need to set virtual memory in like windows?
J. vonThaddon: 'No. Wine is not Windows. Everything on the OS-Level like memory management, network access and so on, is done by Linux'
Setting the Version of Windows
Some programs need to run on a specific version of Windows. The version of Windows can be set using winecfg (Older Wine versions use the Wine Config File). Setting the version on the command line and through the obsolete config file, has been deprecated and will no longer work. Dimi Paun maintains a list of where you can now set advanced options for Wine, and the scope they have here http://winehq.org/site/status_options .
Since June 05 P. Oberndorfer: wine now defaults to behave like Win 2000 [though if this does give trouble,] you could try to set windows version to 98 with winecfg. Wine Archives.
Wine and Fake Windows Dlls
Wine refers to dlls as builtin and native. You may recognize the name because if you look in Windows there are quite a few files that end in the letters .dll. What you need to know is that builtin means that this file has already been implemented with wine whereas a native dll is a dll that is copied over from Windows installation. With wine you can sometimes use a native dll, but check in the official application database to see what will work with your software.
Wine has even got fake dlls. Winehq Bugzilla entry 19276 [the] rundll32.exe in system32 is a fake. rundll32.exe.so is [..the] real one. This was noticed by one programmer [Oct 07 wine devel] ddhelp.exe is on the list of fake dlls [...] I've found that dsound.vxd also isn't [..] built in Wine. These two files are on the list by mistake?
A. Julliard: No, they are here because an app needs them. It's not always necessary to have a corresponding builtin, if the app doesn't try to actually load the dll a fake is enough.
These dlls may be more than an empty file Vitamin sept 08:[They are] Stubs or what we call them "fake dlls". They contain only resources but not the actual code.
Keep in mind that in the rare case when you want to override a dll or use a Windows dll Vitamin:you should copy it to the program's directory and override it for that only program in winecfg. Unless you force Wine to use [a] native dll, Wine will always prefer to use it's own [builtin] dlls [separate files, but somewhere in /usr/lib/wine ...] (except when [the] Wine dll is a complete stub (has no code at all) and [wine is] configured to prefer native, if [it] exists). [Ed. so dont replace those fake dlls with a windows one - wine might just ignore it]
Wine outputs many debugging messages, but if you are not trying to debug or add to Wine's functionality, you can redirect these messages. Often this will make programs (such as games) run faster. J von Thadden:
$@ all command line parameters &>/dev/null all output into hell & go to background
Put together, this works as:
wine program_name.exe ($@ &>/dev/null &)
[ed ] Your favorite program may run well, but you can hide some of the terminal messages so Grandma doesnt worry...
D. Clark and TimeFX:
WINEDEBUG=fixme-all wine program.exe
D. Clark [May 05] highlighted another somewhat more advanced trick to consider: try setting msvcrt to native. Often with programs that are processor intensive [...] using a native msvcrt can have a dramatic impact on performance. [ed] to try this, you would need to copy msvcrt into your wine's system directroy and then run your application with the following:
WINEDLLOVERRIDE="msvcrt=native" wine foo.exe
However for those trying this, U. Bonnes asked: If you have downloadable applications that work fine with native MSVCRT and not with builtin msvcrt, please let wine-devel know.Wine Archives
Running Command Line Applications
C.Curley: you can run some. I've already found out you cannot run programs that access the video hardware directly. Use wineconsole. Winehq Bugzilla entry 19437 V Margolen 2009-07-25 If you [use] wineconsole, Wine [has] control over ^C.
D.Clark: If it is a purely command line application, that is, it only outputs plain text, then plain old Wine is fine. I have been running Xilinx command line tools under Wine for years that way.
J.Vinod suggested: Use the full path. You may pass arguments to the program being executed by adding them to the end of the command line invoking wine eg:
wine notepad C:\\TEMP\\README.TXT
Note that you need to '\' escape special characters (and spaces) when invoking Wine via a shell. If wine should run the program myapp.exe with the arguments --(2 gyphons)display 3d somefile, then you could use the following command line to invoke wine:
wine --dll riched32=n -- myapp.exe --display 3d somefile
Check the man pages for more details.....
C.Curley: Here is how to set up a shell script running on Linux invoke the console/command line application
$ cat $(which rf) #!/bin/sh # Time-stamp: <2005-01-24 07:57:01 ccurley rf> # Shell script to launch real-Forth from wine. # set the geometry once and for all. wineconsole seems to prefer 80x25 geo=3D80x25-15+20 xterm -fn 10x20 -geometry $geo -e 'cd ~/.wine/drive_c/crc/rf ; /usr/bin/wineconsole c:\\crc\\rf\\rff.com 3 load'
However S.Petreolle pointed out: You can use wcmd Wine Archive Link
M. Stefaniuc: If you want wcmd [...] both [of of these] methods work:
wineconsole --backend=user wcmd
The later one runs a console which is fully compatible to that on Windows and some programs rely on that. Wineconsole is only the "terminal emulation window". [..] It also has the advantage that the wine debugging output (FIXME/ERR) don't clutter the output.Wine Archive Link
Stopping a program
M. Hearn: You can't interrupt all Windows programs using ctrl-c. It is preferable to use "kill" instead. Pressing Ctrl-C on the console of a Wine process will cause it to deadlock or crash, and you may see a lot of "Expect deadlock!" statements.
Wine Archive Link If you want to kill Wine, [dont use] Ctrl-C. [type in a terminal window]:
killall -9 wine-preloader
There has been a fair bit of work to make wine work with windows based installers that create shortcuts on the desktop or menu. If it works in windows, it should work in wine.
Dec 2011 With gnome3, this has changed a bit. There are no desktop shortcuts by default. While it is possible to set up a desktop run by nautilus, gnome tweak tool is needed to make this change. For those using the default settings, software installed using Wine is there in the menu, apparently listed under "Applications", "other" after you log out and log back in again. The shortcut settings are found under
To change settings, you will find a line there in the format:
Exec=env WINEPREFIX="/home/[yourname]/.wine" wine C:\\\\windows\\\\command\\\\start.exe /Unix /home/bj/.wine/dosdevices/c:/users/Public/Start\\ Menu/Programs/[softwaredirectory[/[softwarename.lnk]
- WINEPREFIX is the folder that contains the fake windows installation. There are ways to change this, and if programs are installed in separate folders they do not affect or interfere with each other.
- If running wine from git you will need to edit this file to locate wine. Change "wine" to "/home/[yourname]/wine-git/wine"
- You will need swap [yourname] to the folder name for your login. There are two ways to do this. The long way is.. use the command pwd which tells you what directory you are in. Open a terminal to type [code] pwd
- If you make a mistake, relax. It should not break anything serious, the shortcut will simply not work. Considering that if you need to edit this file because it does not work, relax a bit. If you like, make a copy or print a copy out. If stuck, you can get help in the wine use forum http://forum.winehq.org/viewforum.php?f=2
Creating a Shortcut
Is it possible to create a shorcut of our program on our desktop [i.e gnome 2] so that a end user will just click the icon on the desktop to run the program.exe without needing to type the text command "wine program.exe".
M.Hearn: Yes it's possible, just create a link that runs
Odds and Ends
You can list information that is of interest but were not sure where to put it here... Another wiki user may know where it goes.
Alt + Tab
Feb 2011 a user asked: [is] there anything like alt + tab which lets you switch between applications in wine?
Vitamin: [If you run programs in the virtual desktop [Ed, setup via winecfg] ] No, Wine doesn't have a key shortcut to switch between applications. If you are not using virtual desktop - that's up to Window Manager, not Wine.
How do programmers develop Wine
Simply by testing the behavior of Windows. R. Dunn explained [Aug 07 wine devel]: [An analogy] would be that you have a light switch and a light bulb. The light switch is your input and the light bulb is the output. Everything else is unknown (a black box). You don't know how it works.
You could open the box up and look inside (the equivalent of looking at the Windows source), but Wine can't do that. Also, if you modify the Wine code to improve it, you may break something. This would be like making a short circuit in your example above: the light no longer works in your replica (i.e. Wine), so any tests will fail on that.
What you can do instead is say that when the light switch is on the 'up' position, the light bulb is on and when the switch is on the 'down' position, the light bulb is off. Now say you have two rows of 4 switches and a row of 4 lights, aligned with each other. What is the behavior of this system? The only way to find out (without looking inside) is to devise a set of tests. This way, you can find out what logic the system is using. For example, if the system is behaving like a binary adder, you can deduce that from the tests. The tests in Wine are designed to pass on Windows (and should, in theory, pass cleanly on that platform). The implementation of Wine is then written to pass those tests, therefore matching the behavior of Windows. [emphasis added]
Ed. Anyone who looks at the source code to Windows is banned from working on Wine.
Wine vs Codeweavers
A user asked [Sept 06]: Is your group affiliated with "CodeWeavers"? They claim to have a "wine" product called Crossover Mac that will have a final release soon.
T. Schmidt: CodeWeavers is a company that sells a proprietary version of Wine called CrossOver Office, for running Windows applications on Linux. The company was founded in 1996 as a consultancy, eventually moving entirely over to Wine support. Crossover is regularly rebased to new Wine snapshots, and patches that the company's employees write are sent back to the project almost immediately
- http://en.wikipedia.org/wiki/Wine_(software) has more information as well.
And this page:
- http://www.codeweavers.com/products/cxmac/truth_in_advertising/the_real_dirt/ pretty much defines the differences between Wine and Crossover.
D. Kegel: It should also be said that Wine is the "clean" tree (Alexandre doesn't let any [poor] code in), while Crossover uses an "expedient" tree (with a fair amount of code that really isn't right, but happens to make a few key apps like MS Office work). It's a good division, actually, with lots of cross-pollination. The two trees are kept well in sync. wine archive
Wine vs TransGaming
J. Green [Aug 07 wine devel] All of the LGPL Cedega/Cider source code is available on TransGaming's public CVS server at http://www.cedega.com/cvs/. Any substantial patches to LGPL'd components are typically submitted back to WineHQ. There haven't been many recently since most of those components aren't heavily used by games. One of my roles at TransGaming is to make sure that patches to our LGPL'd folders make their way back here [to wine].
Wine doesnt assist working around game protection
A user asked wouldn't WINE [...] make a great cracking tool for [exeCypter]? [...] It supposedly detects and resists attempts to debug encrypted applications to break the code, but can it do so with WINE's virtualized environment?
M. Hearn [May 05]: They generally work pretty well (assuming they run correctly). It's quite hard to figure out what they're doing even when run within Wine.Wine Archive
May 07. Progress has continued apace. When Wine 0.9.37 was released it noted an improvement: Support for a few more exe protection schemes.
Can Wine Run Windows64 Applications
Ed. Work is ongoing. The wine1.2 release officially mentioned windows64bit, but as of 2010 it is still a work in progress.
Ge van Geldorp [Jun 06]: With the Win64 patches I just submitted to wine-patches, I'm able to successfully build Win64-enabled Wine and execute the following 64-bit winelib (winelib64? wine64lib?) application.
K. Ober: I'm currently hacking on gcc for an embedded target (Z8 Encore), but I wouldn't mind giving it a try while I'm digging in the gcc tree.
A. Julliard described the problem: Wine can't use a global option since we have to call Unix functions. The only way is to have an explicit attribute on Windows APIs.
F. Navara: I've had GCC patched to use the MSVC x64 calling convention (without a switch though) for about a year now, but it doesn't solve the problem. There is much more ABI differences including the exception handling (and yes, I mean exception handling in C, not only C++) where MSVC generates special unwinding information for the functions.
F. Navara: the documentation I can recommend
- http://blogs.msdn.com/freik/archive/category/12430.aspx - MSDN
- the PE-COFF v8 document recently updated by MS (http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx) * the ABI document that comes with some MSVC versions
Can Wine Run on a Mac
With Apple moving to intel processors, normal windows applications can run using Wine. Codeweavers now offer a version of wine for the Apple with intel processors. But with the PowerPC processors it is not so clear.
Jurgen: Short answer[with powerpc processors]: nope. Wine doesn't emulate the Intel processor, [...] Since Macs use PowerPC CPUs, not Intel or AMD CPUs, it won't work for you. [..]
M. Mebane: As I understand it, the long-term goal of the Darwine project is to integrate Wine and QEMU to get x86 binaries running on PPCs. http://darwine.opendarwin.org/ [Ed unfortunately Darwine project appears to have ended. But, you may be able to fix this another way...]
E. Charpentier: You might be interested by one of a few emulators projects running under MacOSX : the older is bochs, but I have to say I have been very impressed by QEMU. Even in "full emulation" mode, it is able to run a complete installation of Windows NT quite decently (feels like a PIII/1G while running on a monoprocessor PIV/3.2G). According to the mailing lists, a MacOS version is good enough to do the same. Wine Archives
What about Windows Viruses
As long as you are running wine as a normal user and NOT as root, there is some protection. It is still a concern, but considering that you will most likely be using native Linux software for transferring software, perhaps it is unlikely you will be easily infected.
W. Ogburn [Nov 05] : I think there are two different answers:In principle, an executable that you run as a user under Wine can do anything that a malicious Linux executable could do. So it could potentially mess up your user's account. There's no special protection from malicious programs that comes from running under Wine. However, a Windows virus or other malicious program that doesn't know anything about Wine or Linux isn't very likely to do that. Any harmful effects will probably be limited to your fake Windows directory, and a lot of things that a virus might try to do won't work at all.
S. Petreolle: [read acces] Files are still at risk since the virus has _read_ access on them. As an example viruses replicate by reading mail adresses into files.
J. LaBarre pointed to another concern. I have a data partition formatted as FAT32 to be shared between Linux and Windows 2000. This partition is mounted under a "windisk" group which has R/W permissions (umask 0007)
M. Knecht: If he executed some exe file that had a virus in it, and the virus found some data file to infect, then the virus is there. It may not matter on his system, but should he send that file on to someone else then he would be transmitting a virus to others.
J. Ernst provided a voice of reason: If you are worried you can have your own wine user that you'll use for running wine.[and lock that down]
B. Klein [feb 09]: Check out clamav and other *nix-native virus scanners. They're much more suited for this task than adding a full-blown virus scanner to Wine as standard. K. BLin: If you're really interested, look into resurrecting http://wiki.winehq.org/ClamAntiVirusIntegration It has probably bitrottet in the last two years, but it'd at least get you an idea how something like this could be done.
Viewing Windows Help Files
Truiken [ Apr 06] suggested using the command: wine hh filename.chm H. Arnesen pointed out there are native linux help file views: chm-viewer - xchm. kchmviewer, probably others.
Following The Wine Mailing Lists
A comment on the winedevel list noted a handy tip for sorting mail from the mailing lists: One Developer reported: Due to the rather large amount of spam sent to the *winehq.com email addresses (as opposed to *winehq.org), I would like to phase them out. I will state up front that this proposal benefits only me or any future moderator. Since I have been doing that for about 6 years now, hopefully I'll get a bit of sympathy
S. Dossinger: OK with me. The dual address thing is also confusing for everyone who sets up his own filters in the mailer, mostly to sort out mails into different folders.
R. Shearman: You should sort on the List-Id header instead.
The Wine License
T Wickline wrote [Jul 07 wine devel]: I was wondering if there are any plans in place for Wine to move to the newly revised LGPL 3 licence before the release of 1.0? http://www.gnu.org/licenses/lgpl.html
D. Jovanovic: LGPL3 = GPL3 + additional permissions: "This version of the GNU Lesser General Public License incorporates the terms and conditions of version 3 of the GNU General Public License, supplemented by the additional permissions listed below." The GPL3 has no track record so far,[...] Let's wait a while before making the decision.
K. Blin: This means that, as the GPLv3, the LGPLv3 is more compatible with international laws, as opposed to being US-centric like the (L)GPLv2 was. Also, all the other reasons to move to the GPLv3 apply. [...] At Samba, we have decided to switch to GPLv3 for the coming releases, releasing the libraries that were under the LGPLv2 under the LGPLv3. As for other projects, see http://gpl3.palamida.com:8080/index.jsp. [He then referred to the previous comment about waiting..] What specifically are we waiting for? [...]
T. Kuliavas :[...] there is no difference between GPLv2 and GPLv3 for BSD people. [...] Last time I've checked programmers could use code licensed under BSD license in GPL software, but they couldn't use code licensed under GPL in BSD licensed software. BSD is compatible with GPL, but GPL is not compatible with BSD. [...] The only people worried about GPLv3 and not worried about GPLv2, are the ones that use GPL software and restrict end user rights with hardware or patents.
Victor noted: Wine isn't just a library. (LGPL) though T. Schmidt said: Nor is the LGPL a license exclusively for libraries.
I. MacFarlane: [...] The version 3 of the (L)GPL license has numerous benefits:
- It's much more legally sound in the rest of the world (IMO one of the most important factors about the new license) - numerous reasons for this e.g. referencing WIPO rather than US laws.
- It has an explicit patent agreement (really an extension of the above -(L)GPLv2 has an implicit patent agreement, but this is only valid in the US) - this means that people who contribute to and/or distribute WINE cannot sue WINE (or WINE users) for patent infringement.
- It is compatible with the Apache 2.0 license, meaning that there is an even bigger pool of source code to draw from.
- It helps ensure that companies cannot prevent people from modifying the source code by providing them explicit legal rights to change the code in these circumstances, and requiring information to allow users to change it.
- For LGPL only, It makes 100% sure that GPL+linking exception and LGPL can be combined legally in all jurisdictions by merging them (which is essentially the only real difference, barring slightly different wording in the v2.1 of LGPL vs v2. of GPL)
- It prevents patent agreements where only some people are protected.
- It provides a mechanism for first-time accidental violations to be 'cured' more easily
- ... and lots of other minor changes to improve the validity of the legal status of the license.
- Solaris may go GPLv3, another potentially useful repository of code to
draw from that would not be possible under GPLv2. So as you can see, (L)GPL version 3 has a lot of benefits. It also has broad support (excluding Linus of course, who I must point out objects only to a single clause in the license that can be resolved by adding an extra permission, as GPLv3 permits), including strong corporate backing (e.g. IBM, Red Hat, MySQL, Sun, even Novell). As one of the projects that Microsoft would most like to destroy, the added protections in this updated version of the license would seem even more valuable.
ps: As a last note to Damjan - all GPL versions have been considered both radical and political when they were released. In retrospect, the protections that they provided have been considered invaluable.
S. Edwards liked (l)GLPv3): The termination clause is clarified and a grace period added for compliance. As it stands right now, if someone was to inadvertently not adhere to the terms of a (L)GPLv2 program an over zealous major contributor could revoke distribution rights downstream to the offender even if the offender was in the process of trying to remedy the situation. It may only be a technicality but this bothers me. When corporate powers, with their own motives of profit outweigh commitment to FreeSoftware, are major contributors all the loopholes have to be closed. Imagine a world where SCO had contributed a lot of (L)GPL code and then they had gotten lucky to find a technicality in the license to revoke it for everyone.
M. Stefanuic pointed out that other projects using GPLv3 still automatically can not share code with wine: Samba is GPL and Wine is LGPL. I don't see v3 having changed something in regard to that. If Wine wants to use Samba code it has to ask the people that own the copyright to relicense their work.
Alexandre Julliard was silent on the matter, so we will have to wait and see.
The Software Freedom Conservancy and Wine
J. White Nov 08 [with formatting added]: several years ago, we decided to work with the Software Freedom Conservancy to ask them to manage aspects of Wine that merited the shield of a formal organization. They have been great, and a great improvement over our former process. [...]
What they do for [Wine], and how [it] is governed
First, there are essentially 2 major assets they manage for us.
- They manage all funds donated to Wine - the donate button goes into a bank account they manage.
- They also hold trademarks to the Wine logo that they filed on our behalf.
For decisions on how to spend funds, we've adopted a loose set of guidelines. That is, Dan Kegel, Alexandre, and myself are in contact with them. The goal is that all 3 of us agree on every decision, but 2 of the 3 of us must concur with any decision before it is effective. We three can appoint anyone else we choose to replace or augment the decision group. All decisions are CC'd to the WWN author (currently Zach Goldberg) for monitoring.
The SFC will recognize a 'revolt' by the Wine project. That is, Dan, Alexandre and I can be overthrown, once you figure out our evil plans, if the SFC is persuaded that the majority of Wine contributors agree on that point. Patch count in the Wine tree will be the primary mechanism to recognize a contributor.
Finally, all spending by the SFC on Wine's behalf for the last few years has been related to Wineconf. That has either been to pay for conference expenses directly (as in Reading, 2 years ago), or to help defray travel costs for Wine contributors to come to Wineconf (as happened this year).
General Wine Troubleshooting
For General Troubleshooting see another page called General Wine Troubleshooting