It may be reproduced and modified under the same terms as Wine itself.
2. General Questions about Wine
2.1. What is Wine and what is it supposed to do?
Wine is a program which allows the operation of DOS and MS
Windows programs (Windows 3.x and Win32 executables) on UNIX operating systems such as Linux.
It consists of a program loader, which loads and executes a Windows
binary, and a set of libraries that implements Windows API calls
using their UNIX or X11 equivalents. The libraries may also be used
for porting Win32 code into native UNIX executables, often
without many changes in the source. Wine is free software,
and its license (contained in the file LICENSE
in each distribution) is the LGPL.
2.2. Does Wine emulate a full computer?
No, as the name says, Wine Is Not a (CPU) Emulator. Wine just
provides the Windows API. This means that you will need an
x86-compatible processor to run an x86 Windows application, for instance from Intel or AMD. The
advantage is that, unlike solutions that rely on CPU emulation, Wine
runs applications at full speed. Sometimes a program run under
Wine will be slower than when run on a copy of Microsoft Windows, but
this is more due to the fact that Microsoft has heavily optimized parts of their
code, whereas mostly Wine is not well optimized (yet). Occasionally, an app
may run faster under Wine than on Windows. Most apps run at roughly the same speed.
2.3. Are there any alternatives to Wine?
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.
Note that, like Wine, they can only use the hardware platform that
the target programs were originally compiled for (see below).
2.4. What is the difference between Wine and x86 hardware emulators?
There are two free x86 hardware emulators:
Bochs, and
Plex86.
Plex86 is the open-source free-software alternative for VMWare,
VirtualPC, and other IA-32 on IA-32 "Virtual PC products." It
can only run on the IA-32 architecture.
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.
Both are licensed under the GPL. Bochs is older than Plex86, seems to be
easier to install, but Plex86 will run faster because Plex86 uses a just in
time binary compiler.
The drawback of all emulators is that you need a version
of Windows in order to run Windows, and that they all have an
impact on performance. Wine also gives much better desktop integration - for
instance, programs use your standard window manager, system tray icons will
appear in your tray area (if you have one), and you can run programs direct from the
command line as well as menus. The clipboard also works seamlessly at this time.
2.5. When will Wine integrate an x86 CPU emulator so we can
run Windows applications on non-x86 machines?
The short answer is 'probably never'. Remember, Wine Is Not a
(CPU) Emulator. The long answer is that we probably don't want or
need to integrate one in the traditional sense.
Integrating a CPU emulator in Wine would be extremely hard,
due to the large number of Windows APIs and the complex
data types they exchange. It is not uncommon for a Windows API to
take three or more pointers to structures composed of many fields,
including pointers to other complex structures. For each of these
we would need a conversion routine to deal with the byte order and
alignment issues. Furthermore, Windows also contains many callback
mechanisms that constitute as many extra places where we would have
to handle these conversion issues. Wine already has to deal with
16 vs. 32 bit APIs and Ansi vs. Unicode APIs which both
introduce significant complexity. Adding support for a CPU emulator
inside Wine would introduce at least double that complexity and
only serve to slow down the development of Wine.
Fortunately another solution exists to run Windows applications
on non-x86 platforms: run both Wine and the application inside the
CPU emulator. As long as the emulator provides a standard Unix
environment, Wine should only need minimal modifications. What
performance you lose due to Wine running inside the emulator
rather than natively, you gain in complexity inside of Wine.
Furthermore, if the emulator is fast enough to run Windows
applications, Photoshop for instance, then it should be fast enough
to run that same Windows application plus Wine.
Two projects have started along those lines: QEMU, an
open-source project, and Dynamite,
a commercial CPU emulator environment from
Transitives Technologies.
2.6. Why would anyone want Wine? Doesn't Windows suck?
First Wine is not about running Windows but about running Windows
applications.
So if all your computing needs are fulfilled by native Unix
applications, then you do not need Wine and should not be using
it. However, if you depend on one or more of the tens of
thousands of Windows applications, then Wine is the best way to
use it without giving up on Unix. Let's look at the alternatives
to see why:
The most obvious alternative is to dual-boot. This is the solution
that provides the best compatibility. However it requires that you
acquire a Windows license and then dedicate a good chunk of your
hard-drive to Windows. But the worst is yet to come. Each time you
will want to use that application you will have to reboot to
Windows. This is especially significant if external factors dictate
when you must use this application (e.g. credit card to process,
email to retrieve from a Lotus Notes server). Then you will find
yourself forced to close all your Linux applications just to run
that one Windows application. You may quickly get tired of this, or
will find that such a situation is impossible to justify in a
business environment.
The next solution is to install virtual machine emulation software
such as VMWare, Win4Lin or Plex86. Then you can use windows
applications without suffering such a big disruption. But it still
requires that you acquire a Windows license and dedicate as much
disk space to Windows. Furthermore you will pay for the added
convenience: if using VMWare or Win4Lin you have to buy another
license, and more importantly you now have to dedicate a good chunk
of your computer's memory to the virtual machine. Performance will
take a significant hit too.
Using Wine lets you avoid all of that overhead: Windows license,
hard-drive space required by Windows, memory and performance hit
taken by emulated virtual machines. Now you can start your Windows
application straight from your regular desktop environment, place
that application's window side by side with native applications,
copy/paste from one to the other, and run it all at full speed.
It is also a pretty vital part of migrating a large organization,
you can't change a 5000 desktop setup overnight without a lot of risk.
2.7. Can I use Wine to make the Windows driver for my network card /
graphics card / scanner / etc. work on Unix?
The goal of Wine is to make it possible to run Windows applications
on Unix, not Windows drivers or VxDs.
Drivers and Windows applications belong to different worlds.
Applications run in user mode and use the APIs provided by
the kernel and the other user mode dlls. In contrast, drivers
are loaded in the Windows kernel, i.e. in ring 0 instead of ring
3, drivers have to deal with specific memory management issues, and use
instructions not available to regular applications. This means
they would not be able to run in Wine since Wine runs entirely
in user mode. Rather you would have to modify the Linux kernel.
But in addition, drivers use a completely different API from
regular Windows applications. So the work performed on Wine would
not even be of any use for such a project. In other words, making
it possible to use Windows drivers or VxDs on Unix would be a
completely separate project.
However, if you want to reuse Windows drivers on a non-Microsoft
operating system we recommend that you have a look at
ReactOS.
2.8. Which one of the different Wine packages out there is good for me?
Currently there is a broad selection of different Wine packages/versions:
This is the "standard" distribution of Wine. Its license is
the LGPL, it can be downloaded for free. Both source code and binaries
are available in the download section of the site.
Wine version with special packaging to make sure almost all
important Office type programs work pretty well. Costs $74.95
for the Pro version and $39.95 for the Standard version.
Seems to be well worth it so far according to some comments.
(note: you're supporting a company actively contributing to Wine
if you decide to buy CrossOver.)
Allows you to run your favorite Windows productivity applications in
a distributed thin-client environment under Linux. Server Edition is
also a great addition to Solaris environments, since there built-in
support for Solaris desktops makes running Windows applications a
possibility on Sun workstations as well. For pricing just follow this link:
CrossOver Office Server Edition Pricing
2.9. What's the history of Wine?
The Wine project started in 1993 as a way to support running Windows 3.1
programs on Linux. Bob Amstadt was the original coordinator, but turned
it over fairly early on to Alexandre Julliard, who has run it ever
since. A newsgroup
was created in July 1994. Over the years, ports for
other Unixes have been added, along with support for Win32 as Win32
applications became popular.
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 13, 2004
was called Wine-20040813.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.
2.11. What is the current Status of Wine?
As of mid 2004, Wine consists of about 1.6 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 100K people. Wine
implements more than 90% of the calls in popular Windows
specifications such as ECMA-234 and Open32.
You may also want to look at the
Status page for a global view on Wine's implementation progress.
2.12. When will Wine be finished?
Large software projects are never finished, only released. In any
case Wine is chasing a moving target since every new release of
Windows contains new API calls or variations on the existing ones.
Because Wine is being developed by volunteers, it is difficult to
predict when it will be ready for general release. But due to the
much increased interest by 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 Real Soon Now(tm).
2.13. Who is responsible for Wine?
Wine is available thanks to the work of many people. Please see the
AUTHORS
file in the distribution for the complete list. Some companies that
are or have been involved with Wine development are CodeWeavers,
TransGaming, Corel, and Macadamian.
2.14. What undocumented APIs / interfaces are not understood? Would
seeing Microsoft source help?
The best would be if the Windows API was 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 10 times
more people working simply on one release than have ever
worked on Wine, in the history of the project.
2.15. Will there be a Windows version of Wine?
Some people are working on getting Wine code to compile on Windows
using one of the following projects as a basis:
There's some progress, so a Wine version that's usable on Windows
might be available at some time in the future.
Part of the rationale for these projects is to find out areas where
Wine portability is lacking. This is especially true of the
ReactOS project which is a reimplementation of the Windows kernel
and should thus be able to reuse most of Wine dlls.
Another reason for pursuing these projects is to be able to
replace a single Windows dll with its Wine counterpart. Besides
being a good test for the Wine dll, this lets us detect cases where
we made incorrect assumptions about how the dlls interact.
2.16. Can I use Windows printer drivers in Wine?
Native printer drivers are not supported. At one time Wine supported 16bit
native drivers but that was long ago. Wine uses the printers (and other
devices) installed in your operating system. For the most part if you don't
have the device installed on your OS then wine can't use it.
3. What do I need in order to use Wine?
3.1. Under what hardware platform(s) and operating system(s) will
Wine(Lib) run?
Wine is being developed specifically to run on the Intel
x86 class of CPUs under certain UNIXes that run on this
platform. Winelib however is capable of porting the Windows
applications source code to other platforms
also, not only x86.
Thus running Windows binaries on other platforms (e.g. Mac OS X on
PowerPC) using just Wine is not possible. You
would have to either run Wine in an emulated x86 environment or
take the Windows application source code and recompile it using
Winelib.
These are the platforms supported by Wine.
Winelib support for other platforms keeps evolving,
so it's not specifically listed here.
NetBSD, OpenBSD, UnixWare, and SCO OpenServer 5 worked at one time,
but Wine now requires kernel-level threads which are not currently
available (or understood by the Wine team) on those platforms.
The Wine development team hopes to attract the interest of other
commercial UNIX and UNIX clone vendors as well.
BeOS: porting efforts (BeWine) used to be pretty strong, but BeOS
has severe limitations in Unix call support. The demise of Be
further hampered the project though it might come back one day on
one of the open BeOS projects. In any case a functional port seems
unlikely to ever happen at this stage.
Mac OS X / Darwin: The Darwine 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: This port is well maintained and should work with
limitations in specific areas (mainly missing device/hardware
support).
Linux/x86: Works, and as the most popular platform for both
developers and users, it is the best supported platform of all.
3.2. What minimum CPU must I have in my computer to be able to run Wine
and MS Windows applications smoothly?
We need to differentiate between Wine and Winelib here.
Wine won't run on any x86 CPU less than an 80386 due to address
management limitations.
It is known to also work in the 80486 and upwards compatible CPUs.
The basic test is, if you can run X11 now, you should be able to run
Wine and MS Windows applications under it.
As always, the faster your CPU, the better. Having a math coprocessor
is unimportant. However, having a graphics accelerated video card
supported by X will help greatly.
Depending on your application you may find that faster speeds are
required for sensible use. We can't give specific advice on that due
to the vast range of applications out there. However the rule of
thumb is that if your application runs fine on Windows, it should
run fine on the same platform in Wine.
3.3. How much disk space will the Wine source code and binaries take on my
hard drive?
You need approximately 250 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 20MB range.
3.4. How much RAM do I need to have on my UNIX system to be able to run
Wine and MS Windows applications smoothly?
If you can run X smoothly on your UNIX system now, you should be
able to run Wine and MS Windows applications just fine too, depending
on how memory hungry the application is.
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.
3.5. How long does Wine take to build
Wine is getting to be quite large, and building from scratch takes a
lot of processing. As of May 2004, compile times were around 10
minutes on a Athlon 2000 with 512 MB of RAM and 20 minutes on a Athlon
1200 with 640 MB of RAM. If you have a CVS copy of wine, you may not need
to rebuild every thing each update.
3.6. I have a Drivespaced, Doublespaced or Stackered DOS partition. Can
Wine run MS Windows binaries located in such a partition?
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/
3.7. Do I need to have a DOS partition on my system to use Wine?
You do not need a licensed and installed copy of DOS or MS Windows to
install, configure and run Wine. However, Wine has to be able to
'see' an MS Windows binary (i.e. application) if it is to run it.
3.8. If Wine completely replaces MS Windows, will it duplicate all of the
functions of MS Windows?
Wine's goal is to make it possible to run Windows applications on
Unix. To this end it will provide replacements for just those
DLLs and APIs that are needed by these Windows applications.
This means that Wine will not provide replacements for DLLs that
are not shipped with Windows or are always shipped with Windows
application (e.g. the Visual Basic run time). This also
means that implementing an API that no application ever uses is not
a priority. Similarly, until there are applications out there that
use the Win64 API, it will not be a priority. That being said,
we will certainly try to keep our options open and to improve our API
coverage as we can.
Also Wine is not an operating system, so that writing device
drivers is not part of Wine's goals. However if you are interested
in device drivers, the Linux,
FreeBSD and
ReactOS kernel developers
would certainly appreciate your contribution.
Similarly Wine does not try to be a desktop environment so
providing applets such as a calculator, a file manager or even
window manager that look like Windows, are low priority or would
even best be done as a separate project. Such projects would also
to a large extant be redundant with other open-source projects.
Again, there are projects that would certainly appreciate your
contributions in this areas, such as the
Gnome or
KDE desktop environments. You
will get the added benefit that your contribution will then be
usable by everyone, not just by Wine users.
3.9.
Will I be able to install MS Windows applications in any flavor of a
UNIX file system?
Wine is written to be file system independent, so MS Windows
applications will install and run under virtually any file system
supported by your brand of UNIX.
3.10. Will Wine run only under X, or can it run in character mode?
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.
Wine's infrastructure is already somewhat prepared for supporting
other graphics drivers than x11drv, but no real "alternative"
graphics driver has been developed yet.
3.11. Will Wine run under any X window manager? Does it require a window manager at all?
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 as described
in man wine.conf.
3.12. Will 32-bit Windows 95/98/ME/NT/2000/XP applications run under Wine?
Yes, 32-bit programs are now well supported.
4. Getting Wine
4.1. Where can I get Wine?
Because of lags created by using a mirror, word of the latest release
may reach you before the release is actually available at the ftp
sites listed here. The sources are available from the following
locations:
It should also be available from any other site that mirrors
ibiblio.org, see http://www.ibiblio.org/pub/Linux/MIRRORS.html.
Some of these sites may archive previous versions of Wine as well as the
current one. To determine which is the latest one, look at the
distribution file name, which will take the form
Wine-YYYYMMDD.tar.gz. Simply replace YYYYMMDD in the distribution
file name with the numbers for year, month and date, respectively.
The latest one is the one to get.
Wine binary packages are available for several OS'es and
distributions. See
the download page for the most recent list.
4.2. Is there a CVS tree?
Current Wine sources are also available via anonymous client/server
CVS. You will need CVS 1.9 or above. If you are coming from behind a
firewall, you will either need a hole in the firewall for the CVS
port (2401) or use SOCKS.
Use "cvs" as the password (without the quotes). Note that
/home/wine is a path on the server, not on your
machine. To check out the entire Wine source tree (which may be
slow), use
cvs -z 3 checkout wine
or if you just want a subtree, or individual file, you can do that
too with
cvs -z 3 checkout wine/ANNOUNCE
Be aware, though, that getting the entire Wine source tree via CVS
is pretty slow, especially compared to getting Wine from an FTP
mirror near you. For a CVS mirror list, see
http://www.winehq.org/site/cvs#cvsservers
Patch files are also available, so that you don't have to download,
install, and configure the entire distribution each month if you are
current to the previous release. Patch file release names follow the
same numbering convention as do the general releases, and take the
form
Wine-YYYYMMDD.diff.gz
Patch files are available from the same sites that distribute the
full release. To upgrade to a new release by using a patch file,
first cd to the top-level directory of the release (the one
containing the README file), then do a "make clean", and patch the
release with
gunzip -c patch-file | patch -p1
where patch-file is the name of the patch file something like
Wine-YYYYMMDD.diff.gz. You can then re-run ./configure, and then run
make depend && make
If you are mirroring the Wine distribution from the tsx-11 site and
wish to be listed here in this FAQ, please add it to the
"things to go into the documentation" area.
4.3. Can I get Wine using cvsup?
The CVS mirrors don't offer cvsup support yet, but the main server
does. Use a wine.sup file of:
*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
5. Installing and Configuring Wine
5.1. How do I compile the Wine distribution source code?
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).
5.2. How do I install Windows in Wine under Linux?
Simple answer: you CAN'T. Windows demands direct access to the
hardware and cannot get it with Wine and UNIX in the way
Wine is supposed to be primarily used WITHOUT Windows. If you want
to use a Windows installation, then use an existing installation
alongside the UNIX installation (see the dual-boot HOWTO for your OS
for more details). Or alternatively use the cabextract utility to
extract Windows install archives to a directory that you want to use
as Wine's Windows tree.
5.3. How do I configure Wine to run on my system?
Wine requires that you have a config file as
~/.wine/config. The format of this file is
explained in the wine.conf man page. The file
documentation/samples/config
( http://source.winehq.org/source/documentation/samples/config)
contains a config file example. More explicit directions can be
found in the README file
( http://source.winehq.org/source/README) that will be located in
the base Wine directory after you gunzip and untar the distribution
file.
5.4. How do I upgrade Wine without losing my working configuration?
Upgrading the wine installation does not affect the existing wine
configuration. So after upgrading wine you still have the old (working )
wine configuration.
5.5. If I want to use a Windows install, which versions are OK?
Either use a classic no-windows install (Wine is getting better all
the time) or use a Win9x install (Win95, 98, 98SE, ME). DON'T
configure Wine to use an NT-based Windows install (NT, Win2K, WinXP, Win2K3).
In general, most Windows installations contain vast quantities of garbage
that can confuse Wine and make it less reliable. If you can, it's best to
install the programs you want into Wine's fake windows drive.
5.6. If I use a Windows install with Wine, which one works best?
As of 02/2002:
I'd say Win98SE is the best version to use with Wine, as it's fairly
widespread amongst developers and relatively old. Using Win2K files
is definitely worse than a plain no-windows
Wine install, and Win ME is said to be problematic, too (as probably
no developer uses it). In short: all Win9x <= W98SE are good.
5.7. Installing applications generated by Visual Basic won't run. What
should I do?
Make sure you have all the VB run time libraries installed. You can
get the latest version from the Microsoft web site.
5.8. When I click on *.exe file in my file Manager, nothing happens.
The normal Wine releases don't have .exe extensions registered for
Wine in KDE/Gnome yet. You have to open a terminal window instead
(often an icon showing a "black screen") and type something like:
cd /my/windows/program/directory
wine myprogram.exe
5.9. bash says "wine: Command not found" What can I do?
Try to logout and login again into bash. That might fix it.
If it doesn't, then make sure the wine binary is in your
PATH.
Run as root:
find / -name "wine" -type f -perm +111
to find the path where the wine binary is in. Then check whether
PATH includes it:
echo $PATH
If not, add that e.g. to /etc/profile by doing:
export PATH=$PATH:/path/to/wine/binary
That should help.
If you used a package manager (rpm or
apt) - Verify your packages. The package
winesetuptk.rpm is only a front-end for
making a meaningful config file, it DOES NOT install the wine
package...
It depends on how you installed. If you used an RPM, the right command is this:
rpm -e wine (as root)
If you installed from source (the .tar.gz file), the right
way to do it is to change to the root of the source tree (the directory with the configure script,
readme etc) then run as root:
make uninstall
6. About running Wine
6.1. How do I run an MS Windows program under Wine?
When invoking Wine, you must specify the entire path to the
executable, or by file name only. For example to run Windows'
solitaire, type any of the following:
wine sol or wine sol.exe
(using the search path to locate the file).
wine c:\\windows\\sol.exe
(using a DOS file name).
wine /usr/windows/sol.exe
(using a UNIX file name).
wine "c:\windows\sol.exe"
(using quoted DOS file name).
The path of the file will also be added to the path when a full name
is supplied on the command line.
6.2. I have installed and configured Wine, but Wine cannot find MS
Windows on my drive. Where did I go wrong?
If you have a DOS partition, first make sure that you have mounted
it, either by putting the entry into /etc/fstab,
or by manually mounting it.
Remember too that unless your version of UNIX can see through it, or
you are running a utility that can see through it, your DOS
partition must not be located on a Drivespaced, Doublespaced or
Stackered partition, as neither Linux, FreeBSD, NetBSD or Wine can
natively 'see' files located in these compressed DOS partitions.
Check your path statements in the wine.conf
file. No capital letters may be used in paths, as they are
automatically converted to lowercase.
6.3. I was able to get various MS Windows programs to run, but parts of
them do not work. What is wrong?
Wine is not complete at this time, so some of each programs'
features may not work. They will in time as more of the MS
Windows API calls are included in Wine.
6.4. I have run various MS Windows programs, but since the program menus
do not work, how can I exit these programs?
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.
6.5. My program doesn't work, what can I do?
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).
You can submit your application to the Wine Application DB and gather tips on ways to get your app to work its best.
You can also submit your application to the CodeWeavers CrossOver
Compatibility Center.
Where you can pledge/vote toward future support of your favorite application.
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 in the config file). 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.
6.6. Can I use Wine with SUSE, RedHat or other Linux Distro's?
You can use Wine on any sufficiently recent Linux installation. The
amount of work getting Wine up and running depends on whether you
install a binary packages or do a source install.
6.7. Does Wine work with AMD Processors?
Yes, it does. Wine should work on any processor compatible with
the Pentium or greater.
6.8. Can I launch a Unix program from a Windows program?
Sure, Wine supports that. Just enter the unix program name wherever
a program has something that it's supposed to execute, and it
should just work.
6.9. I get "Error installing iKernel.exe: (0x1400)"
when running an InstallShield 6 installer.
If you get the error "Error installing iKernel.exe: (0x1400)" at any
point, it's probably because there are leftover processes from a
previous try. You can verify this with the command
$ ps augxw | grep wine
If that command shows old copies of wine running your setup,
you need to kill them before you can run the setup program.
If there are no other Wine programs running, you can kill them
all with the command
$ killall wine
If you're also running Wine programs you care about, you'll
have to kill off the old Setup instances one by one using
kill and the individual PIDs (or perhaps Wine's spiffy Task Manager,
which doesn't exist yet).
You should repeat the ps to make sure all of the old
Wine processes are gone.
7.2. I couldn't find the answer to my question in the documentation, but
I've written a document explaining how to solve it. What should I do?
Updates and additions to the Wine documentation directory should be
sent to the wine-patches mailing list at
http://www.winehq.org/site/forums. Website and FAQ
additions should be added to the appropriate Wine Knowledge base directory.
7.3. Is there a Usenet newsgroup for Wine?
Yes, and it's called
comp.emulators.ms-windows.wine. The newsgroup serves as a
place for users and developers to discuss Wine, and for minor
announcements for the general public. Major announcements will be
cross posted to other appropriate newsgroups, such as the following:
Sure. It's channel #WineHQ on
irc.freenode.net see
(http://freenode.net).
Usually several Wine developers hang out there just to help YOU ;-)
7.6. I think I've found a bug. How do I report this bug to the Wine
programming team?
Bug reports should be submitted to our online Bugzilla system
(http://bugs.winehq.org/).
You should include at least the following:
The Wine version tested
The Windows application name, including the version, and, if
applicable, a URL the application can be downloaded from
A brief description of the bug
The relevant part(s) of the output of the Wine debugger
A screenshot of the visual problem, if applicable
For more information about reporting bugs please see the
How to report a bug section of the Wine Users Guide.
8. Helping Wine or becoming a Wine developer
8.1. How do I become a Wine developer? What do I need to know?
If you can program C, that's a good start. Download the sources via
(CVS,)
subscribe to the mailing lists, look around the source, and
pay attention to the comp.emulators.ms-windows.wine newsgroup
and the mailing lists (http://www.winehq.org/site/forums).
See if there's anything that you think you can fix or work
on. You won't have much trouble finding areas that need work
in Wine (grep for FIXMEs in the source).
8.2. How can I help contribute to the Wine project, and in what way(s)?
You can contribute programming or documentation skills, or monetary
or equipment donations, to aid the Wine developers in reaching their
goals.
For a list of ideas of how you can help, please consult the
Wine contrib page.
8.3. I want to help beta test Wine. How can I do this?
Wine still consists of some Alpha code at this time. However, anyone
is welcome to download the latest version, and try it out at any
time.
8.4. I have written some code that I would like to submit to the Wine
project. How do I go about doing this?
Submitting a patch for inclusion in Wine is pretty simple.
Basically all you have to do is send the patch to the
wine-patches mailing list
(http://www.winehq.org/mailman/listinfo/wine-patches).
Still there are a couple of recommendations about the patch format
and all so it's best to read our page describing how to submit
patches. This will also give you more details about the whole
process and in particular to what will happen to your patch once
submitted.
9. Developing programs using Wine/WineLib
9.1. Can I use Wine to port my Win32 sources to Unix?
That is the idea of Winelib. Right now you may still have some
difficulties, but this is changing all the time. Read the
Winelib User's Guide for info.
9.2. Will MFC work with Wine? What do I need to do?
Wine is not implementing an MFC replacement nor does it intend to.
However it is possible (with a lot of work) to compile the MFC from
source and thus produce an mfc42.dll.so library.
9.3. Are there any commercial applications which have been ported
using Wine?
Here are few examples of applications ported using Wine or Winelib:
Corel's WordPerfect Office Suite 2000 was ported to Linux using
Wine.
Kylix, the Linux version of Delphi, was ported to Linux using
Winelib. The IDE actually uses a combination of QT and Winelib
which would not have been possible to achieve using only Wine.
The generated applications however do not depend on Wine in
any way.
MusicMatch Jukebox 5 has also been
ported
to Linux using Winelib. However more recent versions have not, and
version 5 is no longer available.
Many other important applications have already been ported. (we are
speaking of several top 500 applications here)
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.
9.5. How can I detect Wine?
You really shouldn't want to do this. If there's a quirk in Wine
you need to work around, it's much better to fix it in Wine.
10. Wine HQ issues
10.1. Why are the mailing lists set to reply to author, not to mailing list?
