ReceiveTempSMS
/
Sweden-Number
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

- new, much more detailed and easier "step-by-step" layout 

- better intro
- add Glossary (glossary.sgml)
- much better Getting Wine chapter
- much better Wine configuration chapter
- better Wine drive layer configuration section
- explain wineserver cmdline options
- rearranged tons of things into a less messy state
- tons of janitorial fixes
This commit is contained in:
Andreas Mohr 2003-04-01 03:26:13 +00:00 committed by Alexandre Julliard
parent 06a8c1203f
commit 56e6cd0eb8
30 changed files with 4636 additions and 3016 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
documentation/Makefile.in
View File

@ -12,9 +12,11 @@ EXTRASUBDIRS = samples status
WINE_USER_SRCS = \
bugs.sgml \
compiling.sgml \
configuring.sgml \
fonts.sgml \
getting.sgml \
glossary.sgml \
installing.sgml \
introduction.sgml \
printing.sgml \
@ -24,9 +26,9 @@ WINE_USER_SRCS = \
WINE_DEVEL_SRCS = \
architecture.sgml \
build.sgml \
compiling.sgml \
consoles.sgml \
cvs-regression.sgml \
cvs.sgml \
debugger.sgml \
debugging.sgml \
dlls.sgml \

8
documentation/architecture.sgml
View File

@ -948,7 +948,7 @@ child1->popup->child2->child3->wnd1->child4->wnd2->desktop.
<para>
(See also <filename>./DEVELOPER-HINTS</filename> or the
<filename>dlls/</filename> subdirectory to see which DLLs
are currently being rewritten for wine)
are currently being rewritten for Wine)
</para>
<!-- FIXME: Should convert this table into a VariableList element -->
@ -959,7 +959,7 @@ AVIFILE.DLL: 32-bit application programming interfaces for the
Audio Video Interleave (AVI) Windows-specific
Microsoft audio-video standard
COMMCTRL.DLL: 16-bit common controls
COMCTL32.DLL: 32-bit common controls
COMCTL32.DLL: 32-bit common controls
COMDLG32.DLL: 32-bit common dialogs
COMMDLG.DLL: 16-bit common dialogs
COMPOBJ.DLL: OLE 16- and 32-bit compatibility libraries
@ -980,8 +980,8 @@ IMM32.DLL: 32-bit IMM API
IMGUTIL.DLL:
KERNEL32.DLL 32-bit kernel DLL
KEYBOARD.DLL: Keyboard drivers
LZ32.DLL: 32-bit Lempel-Ziv or LZ file compression
used by the installshields (???).
LZ32.DLL: 32-bit Lempel-Ziv or LZ file compression
used by the installshield installers (???).
LZEXPAND.DLL: LZ file expansion; needed for Windows Setup
MMSYSTEM.DLL: Core of the Windows multimedia system
MOUSE.DLL: Mouse drivers

26
documentation/bugs.sgml
View File

@ -2,7 +2,7 @@
<title>Troubleshooting / Reporting bugs</title>
<sect1 id="troubleshooting">
<title>What to do if some program still doesn't work ?</title>
<title>What to do if some program still doesn't work?</title>
<para>
There are times when you've been trying everything, you even killed a cat
@ -17,21 +17,9 @@
<title>Run "winecheck" to check your configuration</title>
<para>
Run a Perl script called <command>winecheck</command>, to be
found in Wine's tools/ directory.
The latest version can always be found at
<ulink
url="http://home.arcor.de/andi.mohr/download/winecheck">http://home.arcor.de/andi.mohr/download/winecheck</ulink>.
Make sure to run <command>chmod +x winecheck</command> first before
trying to execute it...
(or alternatively run it via <command>perl ./winecheck</command>)
The winecheck output will be a percentage score indicating Wine
configuration correctness.
Note that winecheck is only alpha, so it's not very complete or
100% accurate.
Run a Perl script called <command>winecheck</command>.
For details, please refer to the <link
linkend="config-verify">Configuration section</link>.
</para>
</sect2>
@ -39,7 +27,7 @@
<title>Use different windows version settings</title>
<para>
In several cases using <link linkend="windows-versions">different windows version settings</link> can help.
In several cases using <link linkend="config-windows-versions">different windows version settings</link> can help.
</para>
</sect2>
@ -62,7 +50,7 @@
<para>
Run with --debugmsg +loaddll to figure out which DLLs are
being used, and whether they're being loaded as native or
builtin.
built-in.
Then make sure you have proper native DLL files in your
configured C:\windows\system directory and fiddle with DLL
load order settings at command line or in config file.
@ -224,7 +212,7 @@
<listitem>
<para>
The name of the Operating system you're using, what distribution (if
any), and what version. (i.e., Linux RedHat 7.2)
any), and what version. (i.e., Linux Red Hat 7.2)
</para>
</listitem>
<listitem>

2
documentation/build.sgml
View File

@ -1,6 +1,6 @@
<chapter id="build">
<title>The Wine Build System</title>
<para>How the Wine build system works, and how to tweak it...</para>
<para>FIXME: How the Wine build system works, and how to tweak it...</para>
</chapter>
<!-- Keep this comment at the end of the file

371
documentation/compiling.sgml
View File

@ -1,292 +1,34 @@
<chapter id="compiling">
<title>Getting and Compiling the Wine Source</title>
<para>How to obtain and compile Wine, and problems that may arise...</para>
<title>Compiling the Wine Source</title>
<sect1 id="getting-source">
<title>Getting Wine Source</title>
<para>
If you are going to compile Wine, either to use the most recent
code possible or to improve it, then the first thing to do is to
obtain a copy of the source code. We'll cover how to retrieve and
compile the official source releases from the <link
linkend="getting-source-ftp">FTP archives</link>, and also how
to get the cutting edge up-to-the-minute fresh Wine source
code from <link linkend="getting-source-cvs">CVS (Concurrent
Versions System)</link>. Both processes of source code
installation are similar, and once you master one, you should
have no trouble dealing with the other one.
</para>
<para>
You may also need to know how to apply a source code patch to
your version of Wine. Perhaps you've uncovered
a bug in Wine, reported it to the <ulink
url="mailto:wine-devel@winehq.com">Wine mailing list</ulink>,
and received a patch from a developer to hopefully fix the
bug. We will show you how to
<link linkend="getting-upgrading">safely apply the
patch</link> and revert it if it doesn't work.
</para>
<para>How to compile wine, and problems that may arise...</para>
<sect2 id="getting-source-ftp">
<title>Getting Wine Source Code from the FTP Archive</title>
<para>
The safest way to grab the source is from one of the official
FTP archives. An up to date listing is in the <ulink
url="http://www.winehq.com/source/ANNOUNCE">ANNOUNCE</ulink>
file in the Wine distribution (which you would have if you
already downloaded it). Here is a list
of FTP servers carrying Wine:
</para>
<itemizedlist>
<listitem>
<para>
<ulink url="ftp://ftp.ibiblio.org/pub/Linux/ALPHA/wine/development/">
ftp://ftp.ibiblio.org/pub/Linux/ALPHA/wine/development/
</ulink>
</para>
</listitem>
<listitem>
<para>
<ulink url="ftp://ftp.infomagic.com/pub/mirrors/linux/sunsite/ALPHA/wine/development/">
ftp://ftp.infomagic.com/pub/mirrors/linux/sunsite/ALPHA/wine/development/
</ulink>
</para>
</listitem>
<listitem>
<para>
<ulink url="ftp://ftp.fu-berlin.de/unix/linux/mirrors/sunsite.unc.edu/ALPHA/wine/development/">
ftp://ftp.fu-berlin.de/unix/linux/mirrors/sunsite.unc.edu/ALPHA/wine/development/
</ulink>
</para>
</listitem>
<listitem>
<para>
<ulink url="ftp://orcus.progsoc.uts.edu.au/pub/Wine/development/">
ftp://orcus.progsoc.uts.edu.au/pub/Wine/development/
</ulink>
</para>
</listitem>
</itemizedlist>
<para>
The official releases are tagged by date with the format
"Wine-<replaceable>YYYYMMDD</>.tar.gz". Your best bet is to grab
the latest one.
</para>
<para>
Once you have downloaded this, you must first compile Wine, and then
install it. This is not very hard to do. First switch to the
directory containing the file you just downloaded. Then extract the
source with (e.g.):
<screen>
<prompt>$ </><userinput>tar xzvf wine-<replaceable>20021031</>.tar.gz</>
</screen>
</para>
<para>
Then, switch to the directory that was created and compile it by typing (e.g.):
<screen>
<prompt>$ </><userinput>./tools/wineinstall</>
</screen>
</para>
<para>
NOTE: You must make sure that you are not the superuser (root) when doing this,
and that you have write permission to the directory that was created by the tar
command as well as all of its subdirectories and files.
</para>
</sect2>
<sect2 id="getting-source-cvs">
<title>Getting Wine Source Code from CVS</title>
<para>
The official web page for Wine CVS is
<ulink url="http://www.winehq.com/development/">
http://www.winehq.com/development/</>.
</para>
<para>
First, you need to get a copy of the latest Wine sources
using CVS. You can tell it where to find the source tree by
setting the <envar>CVSROOT</envar> environment variable. You
also have to log in anonymously to the Wine CVS server. In
<command>bash</>, it might look something like this:
<screen>
<prompt>$ </><userinput>export CVSROOT=:pserver:cvs@cvs.winehq.com:/home/wine</>
<prompt>$ </><userinput>cvs login</>
Password:
<prompt>$ </><userinput>cvs checkout wine</>
</screen>
</para>
<para>
That'll pull down the entire Wine source tree from
winehq.com and place it in the current directory (actually
in the 'wine' subdirectory). CVS has a million command line
parameters, so there are many ways to pull down files, from
anywhere in the revision history. Later, you can grab just
the updates:
<screen>
<prompt>$ </><userinput>cvs update -PAd</>
</screen>
</para>
<para>
<command>cvs update</> works from inside the source tree.
You don't need the <envar>CVSROOT</> environment variable
to run it either. You just have to be inside the source tree.
The <parameter>-P</>, <parameter>-A</> and <parameter>-d</>
options make sure your local Wine tree directory structure stays
in sync with the remote repository.
</para>
<para>
After you've made changes, you can create a patch with
<command>cvs diff -u</>, which sends output to stdout
(the <parameter>-u</> controls the format of the
patch). So, to create a <filename>my_patch.diff</>
file, you would do this:
<screen>
<prompt>$ </><userinput>cvs diff -u &gt;<replaceable>my_patch.diff</></>
</screen>
</para>
<para>
You can call <command>cvs diff</command> from anywhere in the
tree (just like <command>cvs update</command>), and it will
diff recursively from that point. You can also specify
single files or subdirectories:
<screen>
<prompt>$ </><userinput>cvs diff -u dlls/winaspi &gt;<replaceable>my_aspi_patch.diff</></>
</screen>
</para>
<para>
Experiment around a little. It's fairly intuitive.
</para>
</sect2>
<sect2 id="getting-upgrading">
<title>Upgrading Wine with a Patch</title>
<para>
If you have the Wine source code, as opposed to a binary
distribution, you have the option of applying patches to the
source tree to fix bugs and add experimental features.
Perhaps you've found a bug, reported it to the <ulink
url="mailto:wine-devel@winehq.com">Wine mailing list</>,
and received a patch file to fix the bug. You can apply the
patch with the <command>patch</> command, which takes a
streamed patch from <filename>stdin</>:
<screen>
<prompt>$ </><userinput>cd wine</>
<prompt>$ </><userinput>patch -p0 &lt;<replaceable>../patch_to_apply.diff</></>
</screen>
</para>
<para>
To remove the patch, use the <parameter>-R</> option:
<screen>
<prompt>$ </><userinput>patch -p0 -R &lt;<replaceable>../patch_to_apply.diff</></>
</screen>
</para>
<para>
If you want to do a test run to see if the patch will apply
successfully (e.g., if the patch was created from an older or
newer version of the tree), you can use the
<parameter>--dry-run</> parameter to run the patch
without writing to any files:
<screen>
<prompt>$ </><userinput>patch -p0 --dry-run &lt;<replaceable>../patch_to_apply.diff</></>
</screen>
</para>
<para>
<command>patch</> is pretty smart about extracting
patches from the middle of a file, so if you save an email with
an inlined patch to a file on your hard drive, you can invoke
patch on it without stripping out the email headers and other
text. <command>patch</> ignores everything that doesn't
look like a patch.
</para>
<para>
The <parameter>-p0</> option to <command>patch</>
tells it to keep the full file name from the patch file. For example,
if the file name in the patch file was
<filename>wine/programs/clock/main.c</>.
Setting the <parameter>-p0</> option would apply the patch
to the file of the same name i.e.
<filename>wine/programs/clock/main.c </>.
Setting the <parameter>-p1</> option would strip off the
first part of the file name and apply
the patch to <filename>programs/clock/main.c </>.
The <parameter>-p1</> option would be useful if you named
your top level Wine directory differently than the person who sent
you the patch. For the <parameter>-p1</> option
<command>patch</> should be run from the top level Wine directory.
</para>
</sect2>
</sect1>
<para>
In case you downloaded Wine source code files, this chapter will
tell you how to compile it into binary files before installing them.
Otherwise, please proceed directly to the <link
linkend="installing">Installation chapter</link> to install the
binary Wine files.
</para>
<sect1 id="compiling-wine">
<title>Compiling Wine</title>
<sect2>
<title>Tools required</title>
<title>Requirements</title>
<para>
<itemizedlist>
<listitem>
<para>
gcc >= 2.7.x required (Wine uses the stdcall attribute).
Versions earlier than 2.7.2.3 barf on shellord.c
-- compile without optimizing for that file.
In addition EGCS 1.1.x and GCC 2.95.x are reported
to work fine.
</para>
</listitem>
<listitem>
<para>
flex >= 2.5.1 (required for the debugger and wrc,
and lex won't do)
</para>
</listitem>
<listitem>
<para>
bison (also required for debugger. Don't know whether BSD yacc
would work.)
</para>
</listitem>
<listitem>
<para>
X11 libs and include files
</para>
</listitem>
<listitem>
<para>
texinfo >= 3.11 (optional, to compile the documentation.)
</para>
</listitem>
<listitem>
<para>
autoconf (if you want to remake configure, which is
not normally required)
</para>
</listitem>
<listitem>
<para>
XF86DGA extension (optional, detected by configure,
needed for DirectX support)
</para>
</listitem>
<listitem>
<para>
Open Sound System (optional, detected by configure,
for sound support)
</para>
</listitem>
</itemizedlist>
</para>
<para>
The Red Hat RPMs are gcc-<replaceable>XXX</>,
flex-<replaceable>XXX</>, and XFree86-devel-<replaceable>XXX</>,
where XXX is the version number.
For an up-to-date list of software requirements for compiling
Wine and instructions how to actually do it, please see the <ulink
url="http://www.winehq.org/source/README">README</ulink> file,
which is also available in the main directory of a Wine source
code tree.
</para>
</sect2>
<sect2>
<title>Space required</title>
<para>
You also need about 230 MB of available disk space for compilation.
You also need about 400 MB of available disk space for compilation.
The compiled libwine.so binary takes around 5 MB of disk space,
which can be reduced to about 1 MB by stripping ('strip wine').
Stripping is not recommended, however, as you can't submit
@ -298,86 +40,11 @@ Password:
<title>Common problems</title>
<para>
If you get a repeatable sig11 compiling shellord.c, thunk.c
or other files, try compiling just that file without optimization.
Then you should be able to finish the build.
or other files, try compiling just that file without optimization
(removing the -Ox option from the GCC command in the
corresponding Makefile).
</para>
</sect2>
<sect2>
<title>OS specific issues</title>
<para>
<itemizedlist>
<listitem>
<para>
FreeBSD -- In order to run Wine, the FreeBSD kernel
needs to be compiled with
<informaltable frame="all">
<tgroup cols="2">
<tbody>
<row>
<entry>options</entry>
<entry>USER_LDT</entry>
</row>
<row>
<entry>options</entry>
<entry>SYSVSHM</entry>
</row>
<row>
<entry>options</entry>
<entry>SYSVSEM</entry>
</row>
<row>
<entry>options</entry>
<entry>SYSVMSG</entry>
</row>
</tbody>
</tgroup>
</informaltable>
If you need help, read the chapter "<ulink url="http://www.freebsd.org/handbook/kernelconfig-building.html">Building and Installing a Custom Kernel</ulink>" in the "<ulink url="http://www.freebsd.org/handbook/">FreeBSD handbook</ulink>. You'll need to be running FreeBSD 3.x or later.
</para>
</listitem>
<listitem>
<para>
SCO Unixware, Openserver -- UW port is supported by SCO.
</para>
</listitem>
<listitem>
<para>
Solaris x86 2.x -- Needs the GNU toolchain (gcc, gas, flex as above, yacc may work) to compile, seems functional (980215).
</para>
</listitem>
<listitem>
<para>
DGUX, HP, Irix, or other Unixes; non-x86 Linux.
No ports have been seriously attempted.
For non-x86 Unixes, only a Winelib port is relevant.
Alignment may be a problem.
</para>
</listitem>
<listitem>
<para>
OS/2 -- not a complete port. See <ulink
url="http://odin.netlabs.org/">Odin</>. Note that this
project uses some Wine code but is not based on Wine.
</para>
</listitem>
<listitem>
<para>
BeOS -- not a complete port. See <ulink
url="http://bewine.beunited.org/">BeWine</>.
</para>
</listitem>
<listitem>
<para>
Macintosh/Rhapsody -- no ports have been attempted.
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
</sect1>
</chapter>

4053
documentation/configuring.sgml
View File

File diff suppressed because it is too large Load Diff

2
documentation/cvs-regression.sgml
View File

@ -58,7 +58,7 @@ cvs -d $CVSROOT checkout wine
<para>
Note also that it is possible to do all this with a direct
CVS connection, of course. The full CVS file method is less
painful for the winehq CVS server and probably a bit faster
painful for the Winehq CVS server and probably a bit faster
if you don't have a very good net connection.
</para>
<note>

331
documentation/cvs.sgml Normal file
View File

@ -0,0 +1,331 @@
<chapter id="cvs">
<title>Using CVS</title>
<!-- this part is sort of duplicated in the Wine User Guide's
getting.sgml file (as a short intro to CVS). Please don't forget
to update both!
-->
<sect1>
<title>What is CVS?</title>
<para>
<ulink url="http://www.cvshome.org/">CVS</ulink> (Concurrent
Versions System) is the leading source code control system in
the freeware community. It manages source code of projects,
keeps a history of changes to the source files and improves
conflict management when two or more developers work on the same
code part. Another major benefit of CVS is that it's very easy
to update a project to the latest version. CVS features
flexible branching, intelligent merging, high quality <ulink
url="http://www.loria.fr/~molli/cvs/doc/cvs_toc.html">documentation</ulink>
and client/server access with a wide choice of <ulink
url="http://www.loria.fr/cgi-bin/molli/wilma.cgi/rel">clients</ulink>.
</para>
<para>
Current Wine sources are 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 <ulink
url="http://www.cyclic.com/cvs/d ev-net.html">SOCKS</ulink>.
</para>
</sect1>
<sect1>
<title>CVS installation check</title>
<para>
First you need to make sure that you have <command>cvs</command>
installed.
To check whether this is the case, please run:
</para>
<screen>
<prompt>$ </><userinput>cvs</>
</screen>
<para>
If this was successful, then you should have gotten a nice CVS
"Usage" help output. Otherwise (e.g. an error "cvs: command not
found") you still need to install a CVS package for your
particular operating system, similar to the instructions given
in the Wine User Guide chapters for getting and installing a
Wine package on various systems.
</para>
</sect1>
<sect1>
<title>Configuring Wine-specific CVS settings</title>
<para>
First, you should do a
</para>
<screen>
<prompt>$ </><userinput>touch ~/.cvspass</>
</screen>
<para>
to create or update the file <filename>.cvspass</filename> in
your home directory, since CVS needs this file (for password
and login management) and will complain loudly if it doesn't exist.
</para>
<para>
Second, we need to create the file
<filename>.cvsrc</filename> in your home directory
containing the CVS configuration settings needed for a valid
Wine CVS setup (use CVS compression, properly update file and
directory information, ...).
The content of this file should look like the following:
<programlisting>
cvs -z 3
update -PAd
diff -u
checkout -P
</programlisting>
Create the file with an editor of your choice, either by running
<screen>
<prompt>$ </><userinput>&lt;editor&gt; ~/.cvsrc</>
</screen>
, where &lt;editor&gt; is the editor you want to use (e.g.
<command>joe</command>, <command>ae</command>,
<command>vi</command>),
or by creating the file <filename>.cvsrc</filename> in your
home directory with your favourite graphical editor like nedit, kedit,
gedit or others.
</para>
<para>
<command>-z</command> sets the compression level (Levels higher
than 3 will probably not result in faster downloading unless you
have a fast machine and a slow network connection).
<command>-Pd</command> will delete empty directories and create
newly added ones. <command>-A</command> will reset any previous
tag in order to get the latest version in the tree.
<command>-u</command> will create the easiest to read
patches. Please do not submit patches with <command>diff -w</command>.
</para>
</sect1>
<sect1>
<title>Downloading the Wine CVS tree</title>
<para>
Once CVS is installed and the Wine specific CVS
configuration is done, you can now do a login on our CVS
server and checkout (download) the Wine source code.
First, let's do the server login:
</para>
<screen>
<prompt>$ </><userinput>cvs -d :pserver:cvs@cvs.winehq.com:/home/wine login</>
</screen>
<para>
If <command>cvs</command> successfully connects to the CVS server,
then you will get a "CVS password:" prompt.
Simply enter "cvs" as the password (the password is
<emphasis>case sensitive</emphasis>: no capital letters!).
If you want to use one of the mirror servers for Wine CVS
download, please refer to the section <link
linkend="cvs-mirrors">Wine CVS mirror servers</link>.
</para>
<para>
After login, we are able to download the Wine source code tree.
Please make sure that you are in the directory that you want
to have the Wine source code in (the Wine source code will
use the subdirectory <filename>wine/</filename> in this
directory, since the subdirectory is named after the CVS module
that we want to check out). We assume that your current directory
might be your user's home directory.
To download the Wine tree into the subdirectory <filename>wine/</filename>, run:
</para>
<screen>
<prompt>$ </><userinput>cvs -d :pserver:cvs@cvs.winehq.com:/home/wine checkout wine</>
</screen>
<para>
Downloading the CVS tree might take a while (some minutes
to few hours), depending on your connection speed.
Once the download is finished, you should keep a note of
which directory the newly downloaded
<filename>wine/</filename> directory is in, by running
<command>pwd</command> (Print Working Directory):
</para>
<screen>
<prompt>$ </><userinput>pwd</>
</screen>
<para>
Later, you will be able to change to this directory by
running:
</para>
<screen>
<prompt>$ </><userinput>cd <replaceable>&lt;some_dir&gt;</></>
</screen>
<para>
, where &lt;some_dir&gt; is the directory that
<command>pwd</command> gave you.
By running
</para>
<screen>
<prompt>$ </><userinput>cd wine</>
</screen>
<para>
, you can now change to the directory of the Wine CVS tree
you just downloaded.
</para>
</sect1>
<sect1 id="cvs-mirrors">
<title>Wine CVS mirror servers</title>
<para>
Wine's CVS tree is mirrored at several places arround the world
to make sure that the source is easily accessible. Note that not
all servers have all repositories available, but all have at
least the Wine source.
</para>
<para>
CVS access is granted through CVS' "pserver"
authentication. You should set
your <command>CVSROOT</command> environment variable to point to one of
the servers using this format:
</para>
<screen>
CVSROOT=:pserver:&lt;Username&gt;@&lt;CVS Server&gt;:&lt;Server root&gt;
</screen>
<para>
Alternatively, you can use the -d parameter of
<command>cvs</command> instead.
Substitude the applicable fields from the table below.
</para>
<para>
Just do a traceroute and a ping on all servers below to find out
which are
closest to you.
</para>
<para>
<table><title>Wine CVS servers</title>
<tgroup cols=3 align="center">
<thead>
<row>
<entry>CVS Server</entry>
<entry>Username</entry>
<entry>Password</entry>
</row>
</thead>
<tbody>
<row>
<entry>cvs.winehq.com; Minnesota, USA (CodeWeavers)</entry>
<entry>cvs</entry>
<entry>cvs</entry>
</row>
</tbody>
</tgroup>
</table>
</para>
</sect1>
<sect1>
<title>Other modules available via CVS from WineHQ</title>
<para>
The WineHQ CVS server makes a couple of other things available as well.
To get these, log in anonymously as above and do:
</para>
<screen>
<prompt>$ </><userinput>cvs co <replaceable>&lt;modulename&gt;</></>
</screen>
<para>
where &lt;modulename&gt; is one of:
</para>
<itemizedlist>
<listitem>
<para>
<emphasis>Winehq_com</emphasis> -- source for the WineHQ web site
</para>
</listitem>
<listitem>
<para>
<emphasis>c2man</emphasis> -- automatic documentation system, specially modified for Wine
</para>
</listitem>
</itemizedlist>
</sect1>
<sect1>
<title>Converting a Wine FTP download to a CVS tree</title>
<para>
Getting the entire Wine source tree via
CVS is pretty slow, especially compared to getting Wine from an
FTP mirror near you. It's possible to convert a Wine tarball to a CVS
sandbox, just like you would get by checking out the entire source
via CVS. Here's how to do it:
</para>
<itemizedlist>
<listitem>
<para>
Get the latest Wine snapshot: Wine-<replaceable>YYMMDD</replaceable>.tar.gz
</para>
</listitem>
<listitem>
<para>
Get wine-cvsdirs-<replaceable>YYMMDD</replaceable>.tar.gz from <ulink url="ftp://ftp.winehq.com/pub/wine/">ftp://ftp.winehq.com/pub/wine</ulink>
</para>
<para>
Use an FTP client rather than a web browser, and be sure to turn off passive mode, otherwise the fetch will hang.
</para>
<para>
e.g.:
</para>
<screen>
ftp ftp.winehq.com
cd pub/wine
passive off
ls
</screen>
</listitem>
<listitem>
<para>
Untar them on top of each other:
</para>
<screen>
tar xzf Wine-<replaceable>YYYYMMDD</replaceable>.tar.gz
mv wine-<replaceable>YYYYMMDD</replaceable> wine
tar xzf wine-cvsdirs-<replaceable>YYYYMMDD</replaceable>.tar.gz
</screen>
</listitem>
<listitem>
<para>
Update from main tree: login as above, then do
</para>
<screen>
cd wine
cvs update -PAd
</screen>
</listitem>
</itemizedlist>
<para>
You will now be completely up to date.
</para>
</sect1>
<sect1>
<title>WineHQ cvsweb access</title>
<para>
Direct access to the complete CVS tree is also possible, using Bill Fenner's
<ulink url="http://www.freebsd.org/~fenner/cvsweb/">cvsweb</ulink> package:
<itemizedlist>
<listitem>
<para>
<ulink url="http://cvs.winehq.com/cvsweb">cvs.winehq.com/cvsweb</ulink>, on the primary CVS repository
</para>
</listitem>
</itemizedlist>
</para>
</sect1>
</chapter>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-parent-document:("wine-doc.sgml" "set" "book" "part" "chapter" "")
End:
-->

5
documentation/debugger.sgml
View File

@ -900,7 +900,8 @@ wine -debug myprog.exe
<para>
These are the "normal" Win16 addresses, called SEGPTR.
They have a segment:offset notation, e.g. 0x01d7:0x0012.
The segment part usually is a "selector", which *always*
The segment part usually is a "selector", which
<emphasis>always</emphasis>
has the lowest 3 bits set. Some sample selectors are
0x1f7, 0x16f, 0x8f. If these bits are set except for
the lowest bit, as e.g. with 0x1f6,xi then it might be a
@ -1587,7 +1588,7 @@ monitor mem displays memory mapping of debugged process
Even if latest <command>gdb</command> implements the
notion of threads, it won't work with Wine because the
thread abstraction used for implementing Windows' thread
is not 100% mapped onto the linux posix threads
is not 100% mapped onto the Linux POSIX threads
implementation. It means that you'll have to spawn a
different <command>gdb</command> session for each Windows'
thread you wish to debug.

6
documentation/dlls.sgml
View File

@ -1,6 +1,6 @@
<chapter id="dlls">
<title>Wine Builtin DLLs Overview</title>
<para>A more detailed look at Wine's builtin DLLs...</para>
<para>A more detailed look at Wine's built-in DLLs...</para>
<sect1 id="common-controls">
<title>Common Controls</title>
@ -22,7 +22,7 @@
<title>1. Introduction</title>
<para>
The information provided herein is based on the dll version
The information provided herein is based on the DLL version
4.72 which is included in MS Internet Explorer 4.01.
</para>
<para>
@ -681,7 +681,7 @@
<listitem>
<para>
Development in progress. Basic functionality is
almost done. (dll version 4.0)
almost done. (DLL version 4.0)
</para>
</listitem>
</varlistentry>

49
documentation/documentation.sgml
View File

@ -622,10 +622,10 @@ BOOL WINAPI PathRelativePathToA(
<title>Writing Documentation with DocBook</title>
<para>
DocBook is a flavor of <acronym>SGML</acronym>
DocBook is a flavour of <acronym>SGML</acronym>
(<firstterm>Standard Generalized Markup
Language</firstterm>), a syntax for marking up the contents
of documents. HTML is another very common flavor of SGML;
of documents. HTML is another very common flavour of SGML;
DocBook markup looks very similar to HTML markup, although
the names of the markup tags differ.
</para>
@ -636,16 +636,16 @@ BOOL WINAPI PathRelativePathToA(
<para>
The simple answer to that is that SGML allows you
to create multiple formats of a given document from a single
source. Currently it is used to create html, pdf and PS (PostScript)
versions of the Wine books.
source. Currently it is used to create HTML, PDF and PS
(PostScript) versions of the Wine books.
</para>
</note>
<note>
<title>What do I need?</title>
<para>
You need the sgml tools. There are various places where you
can get them. The most generic way of geting them is from their
You need the SGML tools. There are various places where you
can get them. The most generic way of getting them is from their
source as discussed below.
</para>
</note>
@ -653,7 +653,7 @@ BOOL WINAPI PathRelativePathToA(
<note>
<title>Quick instructions</title>
<para>
These are the basic steps to create the Wine books from the sgml source.
These are the basic steps to create the Wine books from the SGML source.
</para>
</note>
@ -693,7 +693,7 @@ BOOL WINAPI PathRelativePathToA(
</orderedlist>
</sect3>
</sect3>
<sect3>
<title>Getting SGML for various distributions</title>
@ -706,11 +706,11 @@ BOOL WINAPI PathRelativePathToA(
</para>
<sect4>
<title>SGML on Redhat</title>
<title>SGML on Red Hat</title>
<para>
The following packages seems to be sufficient for RedHat 7.1. You
The following packages seem to be sufficient for Red Hat 7.1. You
will want to be careful about the order in which you install the
rpms.
RPMs.
<itemizedlist>
<listitem><para>sgml-common-*.rpm</para></listitem>
<listitem><para>openjade-*.rpm</para></listitem>
@ -728,12 +728,23 @@ BOOL WINAPI PathRelativePathToA(
<sect4>
<title>SGML on Debian</title>
<note>
<title>Fix me</title>
<para>
List package names and install locations...
This is not a definitive listing yet, but it seems
you might need the following packages:
<itemizedlist>
<listitem><para>docbook</para></listitem>
<listitem><para>docbook-dsssl</para></listitem>
<listitem><para>docbook-utils</para></listitem>
<listitem><para>docbook-xml</para></listitem>
<listitem><para>docbook-xsl</para></listitem>
<listitem><para>sgml-base</para></listitem>
<listitem><para>sgml-data</para></listitem>
<listitem><para>tetex-base</para></listitem>
<listitem><para>tetex-bin</para></listitem>
<listitem><para>jade</para></listitem>
<listitem><para>jadetex</para></listitem>
</itemizedlist>
</para>
</note>
</sect4>
<sect4>
@ -856,7 +867,7 @@ BOOL WINAPI PathRelativePathToA(
The final term you'll need to know when writing simple
DocBook documents is the <acronym>DTD</acronym>
(<firstterm>Document Type Declaration</firstterm>). The
DTD defines the flavor of SGML a given document is written
DTD defines the flavour of SGML a given document is written
in. It lists all the legal tag names, like <sgmltag
class="starttag">book</sgmltag>, <sgmltag
class="starttag">para</sgmltag>, and so on, and declares
@ -1700,7 +1711,7 @@ BOOL WINAPI PathRelativePathToA(
<sect3 id="docbook-infrastructure">
<title>Basic Infrastructure</title>
<para>
How the build/make system works (makefiles, db2html,
FIXME: How the build/make system works (makefiles, db2html,
db2html-winehq, jade, stylesheets).
</para>
</sect3>
@ -1708,7 +1719,7 @@ BOOL WINAPI PathRelativePathToA(
<sect3 id="docbook-tweaking">
<title>Tweaking the DSSSL stylesheets</title>
<para>
Things you can tweak, and how to do it (examples from
FIXME: Things you can tweak, and how to do it (examples from
default.dsl and winehq.dsl).
</para>
</sect3>
@ -1716,7 +1727,7 @@ BOOL WINAPI PathRelativePathToA(
<sect3 id="docbook-generating">
<title>Generating docs for Wine web sites</title>
<para>
Explain make_winehq, rsync, etc.
FIXME: Explain make_winehq, rsync, etc.
</para>
</sect3>
</sect2>

2
documentation/faq.sgml
View File

@ -1124,7 +1124,7 @@ wine
<answer>
<para>
Make sure you have all the VB runtime libraries installed. You may
need to use the native dll vbrun60.dll
need to use the native DLL vbrun60.dll
</para>
</answer>
</qandaentry>

6
documentation/fonts.sgml
View File

@ -1,7 +1,7 @@
<sect1 id="fonts">
<sect1 id="config-fonts-main">
<title>Dealing with Fonts</title>
<sect2 id="windows-fonts">
<sect2 id="config-windows-fonts">
<title>Fonts</title>
<para>
@ -64,7 +64,7 @@
of the new fonts. You may also or instead have to restart
the font server (using e.g.
<command>/etc/init.d/xfs restart</command>
under RedHat 7.1)
under Red Hat 7.1)
</para>
</listitem>
<listitem>

806
documentation/getting.sgml
View File

@ -1,156 +1,700 @@
<chapter id="getting-wine">
<title>Getting Wine</title>
<para>
If you decided that you can use and want to use Wine (e.g. after
having read the <link linkend="introduction">introductory
chapter</link>), then as a first step you need to find a good
compatible Wine version that you like and that works on your
system, and after you found one, the next step is to transfer its
files to your system somehow.
This chapter is here to tell you what you need to take care of
in order to successfully accomplish these two steps.
</para>
<sect1>
<title>The Many Forms of Wine</title>
<sect1 id="getting-download">
<title>How to download Wine?</title>
<para>
The standard Wine distribution includes quite a few different
executables, libraries, and configuration files. All of these
must be set up properly for Wine to work well. This chapter
will guide you through the necessary steps to get Wine
installed on your system.
</para>
<para>
If you are running a distribution of Linux that uses packages
to keep track of installed software, you should be in luck: A
prepackaged version of Wine should already exist for your system.
The following sections will tell you how to find the latest
Wine packages and get them installed. You should be careful,
though, about mixing packages between different distributions,
and even from different versions of the same distribution.
Often a package will only work on the distribution it's
compiled for. We'll cover
<link linkend="getting-dist-debian">Debian</link>,
<link linkend="getting-dist-redhat">Red Hat</link>, and
<link linkend="getting-dist-other">other</link> distributions.
</para>
<para>
If you're not lucky enough to have a package available for
your operating system, or if you'd prefer a newer version of
Wine than already exists as a package, you will have to
download the Wine source code and compile it yourself on your
own machine. Don't worry, it's not too hard to do this,
especially with the many helpful tools that come with Wine.
You don't need any programming experience to compile and
install Wine, although it might be nice to have some minor
UNIX administrative skills. Working from the source is
covered in the Wine Developer's Guide.
There are three different methods of how the files
belonging to Wine may be brought (downloaded) to your system:
<itemizedlist>
<listitem>
<para>Getting a single Wine <glossterm>package</glossterm> file
(specifically adapted to your particular system), which
contains various <glossterm>binary</glossterm> files of Wine</para>
</listitem>
<listitem>
<para>Getting a single compressed archive file (usually .tar.gz), which contains
all <glossterm>source code</glossterm> files of a standard Wine
release version</para>
</listitem>
<listitem>
<para>Downloading from a <glossterm>CVS</glossterm> server,
which contains the very latest development source code files
of Wine</para>
</listitem>
</itemizedlist>
</para>
<sect2 id="getting-which-wine">
<title>Which Wine form should I pick?</title>
<para>
Now that we told you about the different Wine distribution
methods available, let's discuss the advantages and
disadvantages of the various methods.
</para>
<variablelist>
<title>Wine distribution methods</title>
<varlistentry>
<term><emphasis>Wine package file</emphasis></term>
<listitem>
<para>
Intended user level: Beginner to Advanced
</para>
<para>
Using Wine package files is easy for three
reasons:
They install everything else that's needed for their
operation, they usually preconfigure a lot, and you
don't need to worry about compiling anything or so.
However, the Wine Team doesn't have "official" packages.
All Wine packages are being offered by external groups,
with often slightly inaccurate or quite inaccurate Wine
environment setup.
Also, a package you downloaded might turn out to be
partially incompatible with your particular system
configuration.
Thus it might actually be <emphasis>better</emphasis>
to compile Wine from source and completely install it
on your own, by following the instructions in this
Guide.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis>Wine source code via archive file</emphasis></term>
<listitem>
<para>
Intended user level: Advanced to Expert
</para>
<para>
A Wine source code archive file can be used
if you want to compile your own standard Wine release.
By using differential patch files to newer Wine versions,
you can easily upgrade your outdated Wine directory.
However, as you need to manually download patch files
and you're only able to download the most current
standard Wine release, this is not necessarily the
best method to use.
The only advantage a Wine source archive has is that it
is a standard Wine release with less development
"quirks" than current CVS code. Except for that, CVS
source code is much preferred and almost as easy.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis>Wine source code via CVS checkout</emphasis></term>
<listitem>
<para>
Intended user level: Advanced to Expert/Developer
</para>
<para>
The Wine CVS checkout offers the best way to take
part in bleeding edge Wine capabilities and
development, since you'll be able to download every
single CVS commit even <emphasis>beyond</emphasis> the
last official Wine release.
As upgrading a Wine CVS checkout tree to the latest
version is very easy, this is a recommended method
of installing Wine.
Plus, by carefully following the instructions in this
Guide, you'll be able to gain the very best Wine
environment compatibility (instead of falling victim
to package maintainers who fail to follow some
instructions in the Wine Packagers Guide).
</para>
</listitem>
</varlistentry>
</variablelist>
<para>
To summarize, the "best" way to install Wine is to download
Wine source code via CVS to get the newest code (which might
be unstable!). Then you could easily compile and install the
Wine files manually. The final configuration part (writing the
configuration file and setting up the drive environment) could then
be handled by WineSetupTk. All in all the best way to go,
except for the about 500MB of disk space that you'll need.
</para>
<para>
With source code archive files, you have the advantage that you're
running standard release versions, plus you can update to
newer versions via patch files that we release.
You won't have the newest code and the flexibility offered by CVS,
though.
<para>
<para>
About binary package files: not sure. There's about a zillion
reasons to not like them as much as you'd think: they may be
outdated, they may not include "everything", they are
<emphasis>not</emphasis> optimized for your particular
environment (as opposed to a source compile, which would guess
and set everything based on your system), they frequently fail
to provide a completely configured Wine environment.
On the plus side: they're pretty easy to install and they
don't take as much space as a full-blown source code compile.
But that's about it when it comes to their advantages.
So I'd say they are OK if you want to have a
<emphasis>quick</emphasis> way to have a test run of Wine, but
for prolonged Wine use, configuring the environment on your
own is probably better.
Eventually this will change (we'll probably do some packaging
efforts on our own at some time), but at the current explosive
rate of Wine development, staying as close as possible to the
actual Wine development that's going on is the way to go.
</para>
<para>
If you are running a distribution of Linux or some other
system that uses packages to keep track of installed software,
you should be in luck: A prepackaged version of Wine
should already exist for your system.
The following sections will tell you how to find the latest
Wine packages and get them installed. You should be careful,
though, about mixing system packages between different distributions,
and even from different versions of the same distribution.
Often a package will only work on the distribution which it
has been compiled for. We'll cover
<link linkend="getting-dist-debian">Debian Linux</link>,
<link linkend="getting-dist-redhat">Red Hat Linux</link>,
<link linkend="getting-freebsd">FreeBSD</link>, and
<link linkend="getting-other">other</link> distributions.
</para>
<para>
If you're not lucky enough to have a package available for
your operating system, or if you'd prefer a newer version of
Wine than already exists as a package, you will need to
download the Wine source code and compile it yourself on your
own machine. Don't worry, it's not too hard to do this,
especially with the many helpful tools that come with Wine.
You don't need any programming experience to compile and
install Wine, although it might be nice to have some minor
UNIX administrative skills. Working from the source is
covered in the Wine Developer's Guide.
The main problem with externally maintained package files is
that they lack a standard configuration method, and in fact
they often fail to configure Wine's Windows environment
properly (which is outlined in the Wine Packagers Guide).
</para>
</sect2>
</sect1>
<sect1 id="getting-dist-debian">
<title>Getting Wine for a Debian System</title>
<sect1 id="getting-wine-package">
<title>Getting a Wine package</title>
<sect2 id="getting-dist-debian">
<title>Debian Linux</title>
<para>
In most cases on a Debian system, you can install Wine with a
single command, as root:
</para>
<screen>
<prompt># </><userinput>apt-get install wine</>
</screen>
<para>
<command>apt-get</command> will connect to a Debian archive
across the Internet (thus, you must be online), then download
the Wine package and install it on your system. End of story.
</para>
<para>
In most cases on a Debian system (or any other distribution that
uses packages that use the file name ending .deb, for that
matter), you can download and install Wine with a
single command, as <glossterm>root</glossterm>:
</para>
<screen>
<prompt># </><userinput>apt-get install wine</>
</screen>
<para>
<command>apt-get</command> will connect to a Debian archive
across the Internet (thus, you must be online), then download
the Wine package and install it on your system. End of story.
You might first need to properly update your package setup,
though, by using an <glossterm>editor</glossterm> as
<glossterm>root</glossterm> to add an entry to
<filename>/etc/apt/sources.list</filename> to point to an active
package server and then running <command>apt-get
update</command>.
</para>
<para>
Once you're done with that step, you may skip the Wine
installation chapter, since apt-get has not only downloaded,
but also installed the Wine files already.
Thus you can now go directly to the <link
linkend="config-wine-main">Configuration section</link>.
</para>
<para>
Of course, Debian's pre-packaged version of Wine may not be the
most recent release. If you are running the stable version of
Debian, you may be able to get a slightly newer version of Wine
by grabbing the package from the unstable distribution, although
this may be a little risky, depending on how far the unstable
distribution has diverged from the stable one. You can find a
list of Wine binary packages for the various Debian releases
using the package search engine at <ulink url="http://www.debian.org">
www.debian.org</ulink>.
</para>
<para>
However, if you don't want to or cannot use the automatic
download method for .deb packages that
<command>apt-get</command> provides, then please read on.
</para>
<para>
Of course, Debian's pre-packaged version of Wine may not be
the most recent release. If you are running the stable
version of Debian, you may be able to get a slightly newer
version of Wine by grabbing the package from the so-called
"unstable" Debian distribution, although this may be a little
risky, depending on how far the unstable distribution has
diverged from the stable one. You can find a list of Wine
binary packages for the various Debian releases using the
package search engine at <ulink
url="http://www.debian.org">www.debian.org</ulink>.
</para>
<para>
To install a package that's not part of your distribution, you
must use <command>dpkg</command> instead of
<command>apt-get</command>. Since <command>dpkg</command>
doesn't download the file for you, you must do it yourself.
Follow the link on the package search engine to the desired
package, then click on the <guibutton>Go To Download
Page</guibutton> button and follow the instructions. Save the
file to your hard drive, then run <command>dpkg</command> on it.
For example, if you saved the file to your home directory, you
might perform the following actions to install it:
</para>
<para>
If you downloaded a separate .deb package file (e.g. a newer
Wine release as stated above) that's not part of your
distribution and thus cannot be installed via
<command>apt-get</command>, you must use <command>dpkg</command> instead.
For instructions on how to do this, please proceed to the
<link linkend="installing">Installation section</link>.
</para>
</sect2>
<sect2 id="getting-dist-redhat">
<title>Red Hat Linux</title>
<para>
Red Hat users can use <ulink url="http://rpmfind.net/linux/RPM/">
rpmfind.net</ulink> to track down available Wine RPM binaries.
<ulink url="http://rpmfind.net/linux/RPM/WByName.html">This
page</ulink> contains a list of all rpmfind packages that start with
the letter "W", including a few Wine packages.
</para>
</sect2>
<sect2 id="getting-freebsd">
<title>FreeBSD</title>
<para>
In order to use Wine you need to build and install a new kernel
with options USER_LDT, SYSVSHM, SYSVSEM, and SYSVMSG.
</para>
<para>
If you want to install Wine using the FreeBSD port system, run
in a <glossterm>terminal</glossterm>:
</para>
<screen>
<prompt>$ </><userinput>su -</>
<prompt># </><userinput>cd /usr/port/emulators/</>
<prompt># </><userinput>make</>
<prompt># </><userinput>make install</>
<prompt># </><userinput>make clean</>
</screen>
<para>
This process will get wine source from the Internet,
then download the Wine package and install it on your system.
</para>
<para>
If you want to install Wine from the FreeBSD CD-ROM, run in a
<glossterm>terminal</glossterm>:
</para>
<screen>
<prompt>$ </><userinput>su -</>
Password:
<prompt># </><userinput>cd /home/user</>
<prompt># </><userinput>dpkg -i wine_<replaceable>0.0.20021031-1</>.deb</>
<prompt># </><userinput>mount /cdrom</>
<prompt># </><userinput>cd /cdrom/packages/All</>
<prompt># </><userinput>pkg_add wine_.X.X.X.tgz</>
</screen>
<para>
You may also want to install the
<systemitem>wine-doc</systemitem> package, and if you are
using Wine from the 2.3 distribution (Woody), the
<systemitem>wine-utils</systemitem> package as well.
</para>
</sect1>
<para>
</para>
<para>
These FreeBSD install instructions completely install the
Wine files on your system; you may then proceed to the <link
linkend="config-wine-main">Configuration section</link>.
</para>
</sect2>
<sect1 id="getting-dist-redhat">
<title>Getting Wine for a Red Hat System</title>
<sect2 id="getting-other">
<title>Other systems</title>
<para>
Red Hat/RPM users can use <ulink url="http://rpmfind.net/linux/RPM/">
rpmfind.net</ulink> to track down available Wine RPM binaries.
<ulink url="http://rpmfind.net/linux/RPM/WByName.html"> This
page</ulink> contains a list of all rpmfind packages that start with
the letter "W", including a few Wine packages.
</para>
<para>
The first place you should look if your system isn't
specifically mentioned above is the <ulink
url="http://www.winehq.com/download/">WineHQ Download
Page</ulink>. This page lists many assorted archives of
binary (precompiled) Wine files.
</para>
<para>
Of course now that you have the RPM package, you may be wondering
"What in the world do I do with this thing?".
</para>
<para>
You could also try to use
<ulink url="http://www.google.com/search?q=wine+package+download">
Google</ulink> to track down miscellaneous distribution packages.
</para>
<para>
The easiest way to install an RPM is to make sure that you have not
previously installed wine (perhaps, when you installed linux)
and then switch to the directory you downloaded the rpm file to.
Once there, type this one command as root:
</para>
<screen>
<prompt># </><userinput>rpm -ivh wine-<replaceable>20020605-2.i386</>.rpm</>
</screen>
<para>
You may also want to install the
<systemitem>wine-devel</systemitem> package.
</para>
</sect1>
<sect1 id="getting-dist-other">
<title>Getting Wine for Other Distributions</title>
<para>
The first place you should look if your system isn't Debian or
Red Hat is the <ulink
url="http://www.winehq.com/download/">WineHQ Download
Page</ulink>. This page lists many assorted archives of
binary (precompiled) Wine files.
</para>
<para>
<ulink url="http://ftpsearch.lycos.com/?form=medium">
Lycos FTPSearch</ulink> is another useful resource for
tracking down miscellaneous distribution packages.
</para>
<para>
NOTE: If you are running a Mandrake system, please see the page
on how to get wine for a
<link linkend="getting-dist-redhat">Redhat</link> system,
as Mandrake is based on Redhat.
</para>
<note>
<para>
If you are running a Mandrake system, please see the page
on how to get Wine for a
<link linkend="getting-dist-redhat">Red Hat</link> system,
as Mandrake is based on Red Hat.
</para>
</note>
</sect2>
<!-- *** Add other distributions, e.g., SUSE, Slackware *** -->
</sect1>
<sect1 id="getting-wine-source">
<title>Getting Wine source code</title>
<para>
If you are going to compile Wine (instead of installing binary
Wine files), either to use the most recent code possible or to
improve it, then the first thing to do is to obtain a copy of
the source code. We'll cover how to retrieve and compile the
official source releases from the <link
linkend="getting-source-ftp">FTP archives</link>, and also how
to get the cutting edge up-to-the-minute fresh Wine source code
from <link linkend="getting-source-cvs">CVS (Concurrent Versions
System)</link>.
</para>
<para>
Once you have downloaded Wine source code according to the
instructions below, there are two ways to proceed: If you want
to manually install and configure Wine, then go to the <link
linkend="compiling">Compiling</link> section. If instead you
want automatic installation, then go straight to the <link
linkend="config-wine-main">Configuration section</link> to make
use of <command>wineinstall</command> to automatically install
and configure Wine.
</para>
<para>
You may also need to know how to apply a source code patch to
your version of Wine. Perhaps you've uncovered
a bug in Wine, reported it to the
<ulink url="http://bugs.winehq.org">Wine Bugzilla</ulink>
or the
<ulink url="mailto:wine-devel@winehq.com">Wine mailing list</ulink>,
and received a patch from a developer to hopefully fix the
bug. We will show you how to
<link linkend="getting-upgrading-patch">safely apply the
patch</link> and revert it if it doesn't work.
</para>
<sect2 id="getting-source-ftp">
<title>Getting Wine Source Code from an FTP Archive</title>
<para>
The safest way to grab the source is from one of the official
FTP archives. An up to date listing is in the <ulink
url="http://www.winehq.com/source/ANNOUNCE">ANNOUNCE</ulink>
file in the Wine distribution (which you would have if you
already downloaded it). Here is a list
of FTP servers carrying Wine:
</para>
<itemizedlist>
<listitem>
<para>
<ulink url="ftp://ftp.ibiblio.org/pub/Linux/ALPHA/wine/development/">
ftp://ftp.ibiblio.org/pub/Linux/ALPHA/wine/development/
</ulink>
</para>
</listitem>
<listitem>
<para>
<ulink url="ftp://ftp.infomagic.com/pub/mirrors/linux/sunsite/ALPHA/wine/development/">
ftp://ftp.infomagic.com/pub/mirrors/linux/sunsite/ALPHA/wine/development/
</ulink>
</para>
</listitem>
<listitem>
<para>
<ulink url="ftp://ftp.fu-berlin.de/unix/linux/mirrors/sunsite.unc.edu/ALPHA/wine/development/">
ftp://ftp.fu-berlin.de/unix/linux/mirrors/sunsite.unc.edu/ALPHA/wine/development/
</ulink>
</para>
</listitem>
<listitem>
<para>
<ulink url="ftp://orcus.progsoc.uts.edu.au/pub/Wine/development/">
ftp://orcus.progsoc.uts.edu.au/pub/Wine/development/
</ulink>
</para>
</listitem>
</itemizedlist>
<para>
The official releases are tagged by date with the format
"Wine-<replaceable>YYYYMMDD</>.tar.gz". Your best bet is to grab
the latest one.
</para>
<para>
I'd recommend placing the Wine archive file that you chose
into the directory where you intend to extract Wine. In this
case, let's just assume that it is your home directory.
</para>
<para>
Once you have downloaded a Wine archive file, we need to
extract the archive file. This is not very hard to do. First
switch to the directory containing the file you just
downloaded. Then extract the source in a
<glossterm>terminal</glossterm> with (e.g.):
<screen>
<prompt>$ </><userinput>tar xvzf wine-<replaceable>20030115</>.tar.gz</>
</screen>
</para>
<para>
Just in case you happen to get a Wine archive that uses
<filename>.tar.bz2</filename> extension instead of
<filename>.tar.gz</filename>:
Simply use <command>tar xvjf</command> in that case instead.
</para>
<para>
Since you now have a fully working Wine source tree by
having followed the steps above, you're now well-prepared to
go to the Wine installation and configuration steps that follow.
</para>
</sect2>
<sect2 id="getting-source-cvs">
<title>Getting Wine Source Code from CVS</title>
<!-- this part is sort of duplicated in cvs.sgml
(this representation is meant to be a very short intro
instead, but it's similar). Please don't forget to update both!
-->
<para>
This part is intended to be quick and easy, showing the bare minimum
of what is needed to download Wine source code via CVS.
If you're interested in a very verbose explanation of CVS or
advanced CVS topics (configuration settings, CVS mirror servers,
other CVS modules on WineHQ, CVSWeb, ...), then please read
the full CVS chapter in the Wine Developer's Guide.
</para>
<sect3>
<title>CVS installation check</title>
<para>
First you need to make sure that you have <command>cvs</command>
installed.
To check whether this is the case, please run in a
<glossterm>terminal</glossterm>:
</para>
<screen>
<prompt>$ </><userinput>cvs</>
</screen>
<para>
If this was successful, then you should have gotten a nice CVS
"Usage" help output. Otherwise (e.g. an error "cvs: command
not found") you still need to install a CVS package for your
particular operating system, similar to the instructions given
in the chapters for getting and installing a Wine package on
various systems.
</para>
</sect3>
<sect3>
<title>Configuring Wine-specific CVS settings</title>
<para>
First, you should do a
</para>
<screen>
<prompt>$ </><userinput>touch ~/.cvspass</>
</screen>
<para>
to create or update the file <filename>.cvspass</filename> in
your home directory, since CVS needs this file (for password
and login management) and will complain loudly if it doesn't exist.
</para>
<para>
Second, we need to create the file
<filename>.cvsrc</filename> in your home directory
containing the CVS configuration settings needed for a valid
Wine CVS setup (use CVS compression, properly update file and
directory information, ...).
The content of this file should look like the following:
<programlisting>
cvs -z 3
update -PAd
diff -u
checkout -P
</programlisting>
Create the file with an <glossterm>editor</glossterm>
of your choice, either by running
<screen>
<prompt>$ </><userinput>&lt;editor&gt; ~/.cvsrc</>
</screen>
, where &lt;editor&gt; is the editor you want to use (e.g.
<command>joe</command>, <command>ae</command>,
<command>vi</command>),
or by creating the file <filename>.cvsrc</filename> in your
home directory with your favourite graphical editor like nedit, kedit,
gedit or others.
</para>
</sect3>
<sect3>
<title>Downloading the Wine CVS tree</title>
<para>
Once CVS is installed and the Wine specific CVS
configuration is done, you can now do a login on our CVS
server and checkout (download) the Wine source code.
First, let's do the server login:
</para>
<screen>
<prompt>$ </><userinput>cvs -d :pserver:cvs@cvs.winehq.com:/home/wine login</>
</screen>
<para>
If <command>cvs</command> successfully connects to the CVS server,
then you will get a "CVS password:" prompt.
Simply enter "cvs" as the password (the password is
<emphasis>case sensitive</emphasis>: no capital letters!).
</para>
<para>
After login, we are able to download the Wine source code tree.
Please make sure that you are in the directory that you want
to have the Wine source code in (the Wine source code will
use the subdirectory <filename>wine/</filename> in this
directory, since the subdirectory is named after the CVS module
that we want to check out). We assume that your current directory
might be your user's home directory.
To download the Wine tree into the subdirectory <filename>wine/</filename>, run:
</para>
<screen>
<prompt>$ </><userinput>cvs -d :pserver:cvs@cvs.winehq.com:/home/wine checkout wine</>
</screen>
<para>
Downloading the CVS tree might take a while (some minutes
to few hours), depending on your connection speed.
Once the download is finished, you should keep a note of
which directory the newly downloaded
<filename>wine/</filename> directory is in, by running
<command>pwd</command> (Print Working Directory):
</para>
<screen>
<prompt>$ </><userinput>pwd</>
</screen>
<para>
Later, you will be able to change to this directory by
running:
</para>
<screen>
<prompt>$ </><userinput>cd <replaceable>&lt;some_dir&gt;</></>
</screen>
<para>
, where &lt;some_dir&gt; is the directory that
<command>pwd</command> gave you.
By running
</para>
<screen>
<prompt>$ </><userinput>cd wine</>
</screen>
<para>
, you can now change to the directory of the Wine CVS tree
you just downloaded. Since you now have a fully working Wine
source tree by having followed the steps above, you're now
well-prepared to go to the Wine installation and configuration
steps that follow.
</para>
</sect3>
</sect2>
<sect2 id="getting-updating-cvs">
<title>Updating the Wine CVS tree</title>
<para>
After a while, you might want to update your Wine CVS tree to
the current version.
Before updating the Wine tree, it might also be a good idea
to run <command>make uninstall</command> as root in order to
uninstall the installation of the previous Wine version.
</para>
<para>
To proceed with updating Wine, simply <command>cd</command>
to the Wine CVS tree directory, then run:
</para>
<screen>
<prompt>$ </><userinput>make distclean</>
<prompt>$ </><userinput>cvs -d :pserver:cvs@cvs.winehq.com:/home/wine update</>
</screen>
<para>
The <command>make distclean</command> part is optional, but
it's a good idea to remove old build and compile configuration
files before updating to a newer Wine version. Once the CVS
update is finished, you can proceed with installing Wine again
as usual.
</para>
</sect2>
<sect2 id="getting-upgrading-patch">
<title>Updating Wine with a Patch</title>
<para>
If you got Wine source code (e.g. via a tar archive file), you
have the option of applying patches to the source tree to
update to a newer Wine release or to fix bugs and add
experimental features. Perhaps you've found a bug, reported
it to the <ulink url="mailto:wine-devel@winehq.com">Wine
mailing list</>, and received a patch file to fix the bug.
You can apply the patch with the <command>patch</> command,
which takes a streamed patch from <filename>stdin</>:
<screen>
<prompt>$ </><userinput>cd wine</>
<prompt>$ </><userinput>patch -p0 &lt;<replaceable>../patch_to_apply.diff</></>
</screen>
</para>
<para>
To remove the patch, use the <parameter>-R</> option:
<screen>
<prompt>$ </><userinput>patch -p0 -R &lt;<replaceable>../patch_to_apply.diff</></>
</screen>
</para>
<para>
If you want to do a test run to see if the patch will apply
successfully (e.g., if the patch was created from an older or
newer version of the tree), you can use the
<parameter>--dry-run</> parameter to run the patch
without writing to any files:
<screen>
<prompt>$ </><userinput>patch -p0 --dry-run &lt;<replaceable>../patch_to_apply.d
iff</></>
</screen>
</para>
<para>
<command>patch</> is pretty smart about extracting
patches from the middle of a file, so if you save an email with
an inlined patch to a file on your hard drive, you can invoke
patch on it without stripping out the email headers and other
text. <command>patch</> ignores everything that doesn't
look like a patch.
</para>
<para>
The <parameter>-p0</> option to <command>patch</>
tells it to keep the full file name from the patch file. For example,
if the file name in the patch file was
<filename>wine/programs/clock/main.c</>.
Setting the <parameter>-p0</> option would apply the patch
to the file of the same name i.e.
<filename>wine/programs/clock/main.c </>.
Setting the <parameter>-p1</> option would strip off the
first part of the file name and apply
the patch to <filename>programs/clock/main.c</>.
The <parameter>-p1</> option would be useful if you named your
top level wine directory differently than the person who sent
you the patch. For the <parameter>-p1</> option
<command>patch</> should be run from the top level wine
directory.
</para>
</sect2>
</sect1>
</chapter>
<!-- Keep this comment at the end of the file

186
documentation/glossary.sgml Normal file
View File

@ -0,0 +1,186 @@
<glossary>
<title>Glossary</title>
<!--
EXAMPLE:
<glossdiv>
<title>test</title>
<glossentry sortas="rme">
<glossterm id="bad_mistake">Very Stupid Mistake</glossterm>
<glosssee>things_to_avoid</glosssee>
<acronym>VSM</acronym>
<abbrev>Doh!</abbrev>
<glossseealso otherterm="accident">
<glossdef>
<para>Something you should try to avoid at all costs.</para>
</glossdef>
</glossentry>
</glossdiv>
-->
<glossdiv>
<title></title>
<glossentry>
<glossterm>Binary</glossterm>
<glossdef>
<para>
A file which is in machine executable, compiled form: hex data (as opposed to a source code file).
</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm>CVS</glossterm>
<glossdef>
<para>
Concurrent Versions System, a software package to manage software development done by several people. See the CVS chapter in the Wine Developers Guide for detailed usage information.
</glossdef>
</glossentry>
<glossentry>
<glossterm>Distribution</glossterm>
<glossdef>
<para>
A distribution is usually the way in which some "vendor" ships operating system CDs (usually mentioned in the context of Linux).
A Linux environment can be shipped in lots of different configurations: e.g. distributions could be built to be suitable for games, scientific
applications, server operation, desktop systems, etc.
</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm>DLL</glossterm>
<glossdef>
<para>
A DLL (Dynamic Link Library) is a file that can be loaded and executed by programs dynamically. Basically it's an external code repository for programs.
Since usually several different programs reuse the same DLL instead of having that code in their own file, this dramatically reduces required storage space.
A synonym for a DLL would be library.
</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm>Editor</glossterm>
<glossdef>
<para>
An editor is usually a program to create or modify text files.
There are various graphical and text mode editors available on
Linux.
</para>
<para>
Examples of graphical editors are: nedit, gedit, kedit, xemacs,
gxedit.
</para>
<para>
Examples of text mode editors are: joe, ae, emacs, vim, vi.
In a <glossterm>terminal</glossterm>, simply run them via:
</para>
<screen>
<prompt>$ </><userinput><replaceable>editorname</replaceable>
<replaceable>filename</replaceable></>
</screen>
</glossdef>
</glossentry>
<glossentry>
<glossterm>Environment variable</glossterm>
<glossdef>
<para>
Environment variables are text definitions used in a <glossterm>Shell</glossterm> to store important system settings.
In a <command>bash</command> shell (the most commonly used one in Linux),
you can view all environment variables by executing:
</para>
<screen>
<userinput>set</userinput>
</screen>
<para>
If you want to change an environment variable, you could run:
</para>
<screen>
<userinput>export <replaceable>MYVARIABLE</>=<replaceable>mycontent</></userinput>
</screen>
<para>
For deleting an environment variable, use:
</para>
<screen>
<userinput>unset <replaceable>MYVARIABLE</></userinput>
</screen>
</glossdef>
</glossentry>
<glossentry>
<glossterm>Package</glossterm>
<glossdef>
<para>
A package is a compressed file in a
<glossterm>distribution</glossterm> specific format. It contains the
files for a particular program you want to install. Packages are
usually installed via the <command>dpkg</command> or
<command>rpm</command> package managers.
</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm>root</glossterm>
<glossdef>
<para>
root is the account name of the system administrator.
In order to run programs as root, simply open a
<glossterm>Terminal</glossterm> window, then run:
</para>
<screen>
<prompt>$ </><userinput>su -</>
</screen>
<para>
This will prompt you for the password of the root user of your system,
and after that you will be able to system administration tasks
that require special root privileges. The root account is indicated by the
</para>
<screen>
<prompt># </>
</screen>
<para>
prompt, whereas '$' indicates a normal user account.
</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm>Shell</glossterm>
<glossdef>
<para>
A shell is a tool to enable users to interact with the
system. Usually shells are text based and command line oriented.
Examples of popular shells include <command>bash</command>,
<command>tcsh</command> and <command>ksh</command>. Wine assumes
that for Wine installation tasks, you use <command>bash</command>,
since this is the most popular shell on Linux.
Shells are usually run in a <glossterm>Terminal</glossterm> window.
</para>
<!-- <glossseealso otherterm="Terminal"> -->
</glossdef>
</glossentry>
<glossentry>
<glossterm>Source code</glossterm>
<glossdef>
<para>
Source code is the code that a program consists of before the program
is being compiled, i.e. it's the original building instructions of a
program that tell a compiler what the program should look like once
it's been compiled to a <glossterm>Binary</glossterm>.
</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm>Terminal</glossterm>
<glossdef>
<para>
A terminal window is usually a graphical window that one uses to
execute a <command>Shell</command>. If Wine asks you to open a
terminal, then you usually need to click on an icon on your desktop
that shows a big black window (or, in other cases, an icon displaying a
maritime shell).
Wine assumes you're using the <command>bash</command> shell in a
terminal window, so if your terminal happens to use a different
shell program, simply type:
</para>
<screen>
<userinput>bash</>
</screen>
<para>
in the terminal window.
</para>
</glossdef>
</glossentry>
</glossary>

2
documentation/implementation.sgml
View File

@ -23,7 +23,7 @@
<para>
This is the way to do some initializing when a process or
thread is attached to the dll. The function name is taken
thread is attached to the DLL. The function name is taken
from a <filename>*.spec</filename> file line:
</para>
<programlisting>

15
documentation/installation-und-konfiguration.german
View File

@ -1613,21 +1613,20 @@ die folgenden Programme und Dateien installiert sein:
Damit auch von 32bit Programmen aus gedruckt werden kann, ist es
notwendig, einige Einträge in der Registratur vorzunehmen. Diese
Einträge sind in der Datei psdrv.reg im Unterverzeichnis
documentation des WINE-Quellcodeverzeichnisses vorhanden und lassen
sich mit dem Programm regapi, welches sich im Unterverzeichnis
programs/regapi des Quellcodeverzeichnisses befindet,
importieren. Falls noch nicht geschehen, ist regapi dazu zunächst zu
übersetzen. Zu diesem Zweck ist in das Verzeichnis programs/regapi
Einträge sind in der Datei winedefault.reg im Wine-Hauptverzeichnis
vorhanden und lassen sich mit dem Programm regedit, welches sich im
Unterverzeichnis programs/regedit des Quellcodeverzeichnisses befindet,
importieren. Falls noch nicht geschehen, ist regedit dazu zunächst zu
übersetzen. Zu diesem Zweck ist in das Verzeichnis programs/regedit
zu wechseln und dort der Befehl make einzugeben (dies setzt
voraus, dass WINE bereits erfolgreich übersetzt wurde). Danach
können die erforderlichen Schlüssel durch die Eingabe des folgenden
Befehls importiert werden:
./regapi setValue < ../../documentation/psdrv.reg
./regedit ../../winedefault.reg
Achtung:
Bei dem Programm regapi handelt es sich um ein sogenanntes
Bei dem Programm regedit handelt es sich um ein sogenanntes
WineLib-Programm. Solche Programme benutzen WINE, um
Windows-spezifische Funktionen verwenden zu können. Damit sie
ausgeführt werden können, muss bereits eine funktionsfähige

835
documentation/installing.sgml
View File

@ -1,756 +1,153 @@
<chapter id="installing">
<title>Installing/compiling Wine</title>
<para>How to install Wine...</para>
<title>Installing or uninstalling Wine</title>
<sect1 id="replace-windows" xreflabel="--Installing Section--">
<title>WWN #52 Feature: Replacing Windows</title>
<para>
A standard Wine distribution form (which you probably downloaded
according to chapter <link linkend="getting-wine">Getting Wine</link>)
includes quite a few different programs, libraries
and configuration files. All of these
must be set up properly for Wine to work well. In order to
achieve this, this chapter will guide you through the necessary steps
to get the Wine files
installed on your system. It will <emphasis>not</emphasis>
deal with how to get Wine's Windows environment
<emphasis>configured</emphasis>; that's what the next chapter
will talk about.
</para>
<para>
When installing Wine, you should make sure that it doesn't happen
to overwrite a previous Wine installation (as this would cause
an overwhelming amount of annoying and fatal conflicts);
uninstalling any previous Wine version (as explained in this chapter)
to avoid this problem is recommended.
</para>
<sect1>
<title>Installing or uninstalling Wine packages</title>
<para>
Written by &name-ove-kaaven; <email>&email-ove-kaaven;</email>
Now that you have downloaded the Debian or RPM or whatever Wine
package file, probably via the instructions given in the
previous chapter, you may be wondering "What in the world do I
do with this thing?".
This section will hopefully be able to put an end to your
bewildered questioning, by giving detailed install instructions
for all sorts of well-known package types.
</para>
<sect2>
<title>Installation Overview</title>
<title>Debian Linux</title>
<para>
In case you haven't downloaded and automatically installed the
Wine package file via <command>apt-get</command> as described
in the <link linkend="getting-wine">Getting Wine</link>
section, you now need to use <command>dpkg</command> to
install it. Switch to the directory you downloaded the Debian
.deb package file to. Once there, type these commands,
adapting the package file name as required:
</para>
<screen>
<prompt>$ </><userinput>su -</>
Password:
<prompt># </><userinput>cd /home/user</>
<prompt># </><userinput>dpkg -i wine_<replaceable>0.0.20030115-1</>.deb</>
</screen>
<para>
(Type the root password at the "Password:" prompt)
</para>
<para>
A Windows installation consists of many different parts.
You may also want to install the
<systemitem>wine-doc</systemitem> package, and if you are
using Wine from the 2.3 distribution (Woody), the
<systemitem>wine-utils</systemitem> package as well.
</para>
<itemizedlist>
<listitem>
<para>
Registry. Many keys are supposed to exist and contain
meaningful data, even in a newly-installed Windows.
</para>
</listitem>
<listitem>
<para>
Directory structure. Applications expect to find and/or
install things in specific predetermined locations. Most
of these directories are expected to exist. But unlike
Unix directory structures, most of these locations are
not hardcoded, and can be queried via the Windows API
and the registry. This places additional requirements on
a Wine installation.
</para>
</listitem>
<listitem>
<para>
System DLLs. In Windows, these usually reside in the
<filename>system</filename> (or
<filename>system32</filename>) directories. Some Windows
applications check for their existence in these
directories before attempting to load them. While Wine
is able to load its own internal DLLs
(<filename>.so</filename> files) when the application
asks for a DLL, Wine does not simulate the existence of
nonexisting files.
</para>
</listitem>
</itemizedlist>
<para>
Uninstalling an installed Wine Debian package can be done by
running:
</para>
<screen>
<prompt># </><userinput>dpkg -l|grep wine</>
</screen>
<para>
While the users are of course free to set up everything
themselves, the Wine team will make the automated Wine source
installation script, <filename>tools/wineinstall</filename>,
do everything we find necessary to do; running the
conventional <userinput>configure && make depend && make && make
install</userinput> cycle is thus not recommended, unless
you know what you're doing. At the moment,
<filename>tools/wineinstall</filename> is able to create a
configuration file, install the registry, and create the
directory structure itself.
The second column of the output (if any) of this command will
indicate the installed packages dealing with "wine".
The corresponding packages can be uninstalled by running:
</para>
<screen>
<prompt># </><userinput>dpkg -r <replaceable>&lt;package_name&gt;</></>
</screen>
<para>
where &lt;package_name&gt; is the name of the Wine-related package
which you want to uninstall.
</para>
</sect2>
<sect2>
<title>The Registry</title>
<para>
The default registry is in the file
<filename>winedefault.reg</filename>. It contains directory
paths, class IDs, and more; it must be installed before most
<filename>INSTALL.EXE</filename> or
<filename>SETUP.EXE</filename> applications will work. The
registry is covered in more detail <link
linkend="registry">here</link>.
</para>
</sect2>
<sect2>
<title>Directory Structure</title>
<para>
Here's the fundamental layout that Windows applications and
installers expect. Without it, they seldom operate
correctly.
</para>
<programlisting>
C:\ Root directory of primary disk drive
Windows\ Windows directory, containing .INI files,
accessories, etc.
System\ Win3.x/95/98/ME directory for common DLLs
WinNT/2000 directory for common 16-bit DLLs
System32\ WinNT/2000 directory for common 32-bit DLLs
Start Menu\ Program launcher directory structure
Programs\ Program launcher links (.LNK files) to applications
Program Files\ Application binaries (.EXE and .DLL files)
</programlisting>
<title>Red Hat (RPM) Linux</title>
<para>
Wine emulates drives by placing their virtual drive roots to
user-configurable points in the Unix filesystem, so it's
your choice where <medialabel>C:</medialabel>'s root should
be (<filename>tools/wineinstall</filename> will even ask
you). If you choose, say, <filename>/var/wine</filename>, as
the root of your virtual drive <medialabel>C</medialabel>,
then you'd put this in your <filename>~/.wine/config</filename>:
Switch to the directory you downloaded the RPM package file to.
Once there, type this one command as root, adapting the
package file name as required:
</para>
<programlisting>
[Drive C]
"Path" = "/var/wine"
"Type" = "hd"
"Label" = "MS-DOS"
"Filesystem" = "win95"
</programlisting>
<screen>
<prompt># </><userinput>rpm -ivh wine-<replaceable>20020605-2.i386</>.rpm</>
</screen>
<para>
With this configuration, what windows apps think of as
"c:\windows\system" would map to
<filename>/var/wine/windows/system</filename> in the UNIX
filesystem. Note that you need to specify
<literal>"Filesystem" = "win95"</literal>, NOT
<literal>"Filesystem" = "unix"</literal>, to make Wine simulate a
Windows-compatible (case-insensitive) filesystem, otherwise
most apps won't work.
You may also want to install the
<systemitem>wine-devel</systemitem> package.
</para>
</sect2>
<sect2>
<title>System DLLs</title>
<para>
Uninstalling an installed Wine RPM package can be done by
running:
</para>
<screen>
<prompt># </><userinput>rpm -qa|grep -i wine</>
</screen>
<para>
The Wine team has determined that it is necessary to create
fake DLL files to trick many applications that check for
file existence to determine whether a particular feature
(such as Winsock and its TCP/IP networking) is available. If
this is a problem for you, you can create empty files in the
configured <filename>c:\windows\system</filename> directory
to make the application think it's there, and Wine's built-in DLL
will be loaded when the application actually asks for it.
(Unfortunately, <filename>tools/wineinstall</filename> does
not create such empty files itself.)
</para>
This command will indicate the installed packages dealing with "wine".
The corresponding packages can be uninstalled by running:
</para>
<screen>
<prompt># </><userinput>rpm -e <replaceable>&lt;package_name&gt;</></>
</screen>
<para>
Applications sometimes also try to inspect the version
resources from the physical files (for example, to determine
the DirectX version). Empty files will not do in this case,
it is rather necessary to install files with complete
version resources. This problem is currently being worked
on. In the meantime, you may still need to grab some real
DLL files to fool these apps with.
</para>
<para>
And there are of course DLLs that wine does not currently
implement very well (or at all). If you do not have a real
Windows you can steal necessary DLLs from, you can always
get some from one of the Windows DLL archive sites
that can be found via internet search engine.
Please make sure to obey any licenses on the DLLs you fetch...
(some are redistributable, some aren't).
where &lt;package_name&gt; is the name of the Wine-related package
which you want to uninstall.
</para>
</sect2>
</sect1>
<sect1 id="no-windows">
<title>Installing Wine Without Windows</title>
<sect1>
<title>Installing or uninstalling a Wine source code tree</title>
<para>
Written by &name-james-juran; <email>&email-james-juran;</email>
If you are in the directory of the Wine version that you just
compiled (e.g. by having run <command>make depend && make</command>), then you may now install this Wine version by running as <glossterm>root</glossterm>:
</para>
<screen>
<prompt># </><userinput>make install</>
</screen>
<para>
(Extracted from <filename>wine/documentation/no-windows</filename>)
This will copy the Wine binary files to their final destination
in your system. You can then proceed to the <link
linkend="config-wine-main">Configuration chapter</link> to
configure the Wine environment.
</para>
<para>
A major goal of Wine is to allow users to run Windows programs
without having to install Windows on their machine. Wine
implements the functionality of the main DLLs usually
provided with Windows. Therefore, once Wine is finished, you
will not need to have Windows installed to use Wine.
If instead you want to uninstall the currently installed Wine
source code version, then change to the main directory of this
version and run as <glossterm>root</glossterm>:
</para>
<para>
Wine has already made enough progress that it may be possible
to run your target applications without Windows installed. If
you want to try it, follow these steps:
</para>
<orderedlist>
<listitem>
<para>
Point <medialabel>[Drive C]</medialabel> in
<filename>~/.wine/config</filename> to the directory where you want
<filename>C:</filename> to be. Refer to the wine.conf man page
for more information.
The directory to be used for emulating a C: drive will be
the base directory for some Windows specific directories
created below.
Remember to use
<userinput>"Filesystem" = "win95"</userinput>!
</para>
</listitem>
<listitem>
<para>
Within the directory to be used for C:, create empty
<filename>windows</filename>,
<filename>windows/system</filename>,
<filename>windows/Start Menu</filename>, and
<filename>windows/Start Menu/Programs</filename>
directories. Do not point Wine to a
<filename>Windows</filename> directory full of old
installations and a messy registry. (Wine creates a
special registry in your <filename >home</filename>
directory, in <filename>$HOME/.wine/*.reg</filename>.
Perhaps you have to remove these files).
In one line:
mkdir -p windows windows/system windows/Start\ Menu windows/Start\ Menu/Programs
</para>
</listitem>
<listitem>
<para>
Use <filename>tools/wineinstall</filename> to compile Wine
and install the default registry. Or if you prefer to do
it yourself, compile <filename>programs/regedit</filename>,
and run:
</para>
<screen>
<userinput>programs/regedit/regedit &lt; winedefault.reg</userinput>
</screen>
</listitem>
<listitem>
<para>
Run and/or install your applications.
</para>
</listitem>
</orderedlist>
<para>
Because Wine is not yet complete, some programs will work
better with native Windows DLLs than with Wine's
replacements. Wine has been designed to make this possible.
Here are some tips by Juergen Schmied (and others) on how to
proceed. This assumes that your
<filename>C:\windows</filename> directory in the configuration
file does not point to a native Windows installation but is in
a separate Unix file system. (For instance, <quote>C:\windows</quote> is
really subdirectory <quote>windows</quote> located in
<quote>/home/ego/wine/drives/c</quote>).
</para>
<itemizedlist>
<listitem>
<para>
Run the application with <parameter>--debugmsg
+loaddll</parameter> to find out which files are
needed. Copy the required DLLs one by one to the
<filename>C:\windows\system</filename> directory. Do not
copy KERNEL/KERNEL32, GDI/GDI32, USER/USER32 or NTDLL. These
implement the core functionality of the Windows API, and
the Wine internal versions must be used.
</para>
</listitem>
<listitem>
<para>
Edit the <quote>[DllOverrides]</quote> section of
<filename>~/.wine/config</filename> to specify
<quote>native</quote> before <quote>builtin</quote> for
the Windows DLLs you want to use. For more information
about this, see the Wine manpage.
</para>
</listitem>
<listitem>
<para>
Note that some network DLLs are not needed even though
Wine is looking for them. The Windows
<filename>MPR.DLL</filename> currently does not work; you
must use the internal implementation.
</para>
</listitem>
<listitem>
<para>
Copy SHELL/SHELL32 and COMDLG/COMDLG32 COMMCTRL/COMCTL32
only as pairs to your Wine directory (these DLLs are
<quote>clean</quote> to use). Make sure you have these
specified in the <quote>[DllPairs]</quote> section of
<filename>~/.wine/config</filename>.
</para>
</listitem>
<listitem>
<para>
Be consistent: Use only DLLs from the same Windows version
together.
</para>
</listitem>
<listitem>
<para>
Put <filename>regedit.exe</filename> in the
<filename>C:\windows</filename> directory.
(<application>Office 95</application> imports a
<filename>*.reg</filename> file when it runs with an empty
registry, don't know about
<application>Office 97</application>).
</para>
</listitem>
<listitem>
<para>
Also add <filename>winhelp.exe</filename> and
<filename>winhlp32.exe</filename> if you want to be able
to browse through your programs' help function.
</para>
</listitem>
</itemizedlist>
<screen>
<prompt># </><userinput>make uninstall</>
</screen>
</sect1>
<sect1 id="with-windows">
<title>Installing Wine Using An Existing Windows Partition As Base</title>
<para>
Some people intend to use the data of an existing Windows partition
with Wine in order to gain some better compatibility or to run already
installed programs in a setup as original as possible.
Note that many Windows programs assume that they have full write
access to all windows directories.
This means that you either have to configure the Windows
partition mount point for write permission by your Wine user
(see <link linkend="vfat">Dealing with FAT/VFAT partitions</link>
on how to do that), or you'll have to copy over (some parts of) the Windows
partition content to a directory of a Unix partition and make
sure this directory structure is writable by your user.
We HIGHLY DISCOURAGE people from directly using a Windows partition with
write access as a base for Wine !! (some programs, notably
Explorer, corrupt large parts of the Windows partition in case
of an incorrect setup; you've been warned).
Not to mention that NTFS write support in Linux is still very
experimental and DANGEROUS (in case you're using an NT-based
Windows version using the NTFS file system).
Thus we advise you to go the Unix directory way.
</para>
</sect1>
<sect1 id="vfat">
<title>Dealing With FAT/VFAT Partitions</title>
<para>
Written by &name-steven-elliott; <email>&email-steven-elliott;</email>
</para>
<para>
(Extracted from <filename>wine/documentation/linux-fat-permissions</filename>)
</para>
<para>
This document describes how FAT and
VFAT file system permissions work in Linux
with a focus on configuring them for Wine.
</para>
<sect2>
<title>Introduction</title>
<para>
Linux is able to access DOS and Windows file systems using
either the FAT (older 8.3 DOS filesystems) or VFAT (newer
Windows 95 or later long filename filesystems) modules.
Mounted FAT or VFAT filesystems provide the primary means
for which existing applications and their data are accessed
through Wine for dual boot (Linux + Windows) systems.
</para>
<para>
Wine maps mounted FAT filesystems, such as
<filename>/c</filename>, to driver letters, such as
<quote>c:</quote>, as indicated by the
<filename>~/.wine/config</filename> file. The following excerpt
from a <filename>~/.wine/config</filename> file does this:
</para>
<programlisting>
[Drive C]
"Path" = "/c"
"Type" = "hd"
</programlisting>
<para>
Although VFAT filesystems are preferable to FAT filesystems
for their long filename support the term <quote>FAT</quote>
will be used throughout the remainder of this document to
refer to FAT filesystems and their derivatives. Also,
<quote>/c</quote> will be used as the FAT mount point in
examples throughout this document.
</para>
<para>
Most modern Linux distributions either detect or allow
existing FAT file systems to be configured so that they can be
mounted, in a location such as <filename>/c</filename>,
either persistently (on bootup) or on an as needed basis. In
either case, by default, the permissions will probably be
configured so that they look like:
</para>
<screen>
<prompt>~></prompt><userinput>cd /c</userinput>
<prompt>/c></prompt><userinput>ls -l</userinput>
<computeroutput>-rwxr-xr-x 1 root root 91 Oct 10 17:58 autoexec.bat
-rwxr-xr-x 1 root root 245 Oct 10 17:58 config.sys
drwxr-xr-x 41 root root 16384 Dec 30 1998 windows</computeroutput>
</screen>
<para>
where all the files are owned by "root", are in the "root"
group and are only writable by "root"
(<literal>755</literal> permissions). This is restrictive in
that it requires that Wine be run as root in order for
applications to be able to write to any part of the
filesystem.
</para>
<para>
There are three major approaches to overcoming the restrictive
permissions mentioned in the previous paragraph:
</para>
<orderedlist>
<listitem>
<para>
Run <application>Wine</application> as root
</para>
</listitem>
<listitem>
<para>
Mount the FAT filesystem with less restrictive
permissions
</para>
</listitem>
<listitem>
<para>
Shadow the FAT filesystem by completely or partially
copying it
</para>
</listitem>
</orderedlist>
<para>
Each approach will be discussed in the following sections.
</para>
</sect2>
<sect2>
<title>Running Wine as root</title>
<para>
Running Wine as root is the easiest and most thorough way of giving
applications that Wine runs unrestricted access to FAT files systems.
Running wine as root also allows applications to do things unrelated
to FAT filesystems, such as listening to ports that are less than
1024. Running Wine as root is dangerous since there is no limit to
what the application can do to the system.
</para>
</sect2>
<sect2>
<title>Mounting FAT filesystems</title>
<para>
The FAT filesystem can be mounted with permissions less restrictive
than the default. This can be done by either changing the user that
mounts the FAT filesystem or by explicitly changing the permissions
that the FAT filesystem is mounted with. The permissions are
inherited from the process that mounts the FAT filesystem. Since the
process that mounts the FAT filesystem is usually a startup script
running as root the FAT filesystem inherits root's permissions. This
results in the files on the FAT filesystem having permissions similar
to files created by root. For example:
</para>
<screen>
<prompt>~></prompt><userinput>whoami</userinput>
<computeroutput>root</computeroutput>
<prompt>~></prompt><userinput>touch root_file</userinput>
<prompt>~></prompt><userinput>ls -l root_file</userinput>
<computeroutput></computeroutput>-rw-r--r-- 1 root root 0 Dec 10 00:20 root_file
</screen>
<para>
which matches the owner, group and permissions of files seen
on the FAT filesystem except for the missing 'x's. The
permissions on the FAT filesystem can be changed by changing
root's umask (unset permissions bits). For example:
</para>
<screen>
<prompt>~></prompt><userinput>umount /c</userinput>
<prompt>~></prompt><userinput>umask</userinput>
<computeroutput>022</computeroutput>
<prompt>~></prompt><userinput>umask 073</userinput>
<prompt>~></prompt><userinput>mount /c</userinput>
<prompt>~></prompt><userinput>cd /c</userinput>
<prompt>/c></prompt><userinput>ls -l</userinput>
<computeroutput>-rwx---r-- 1 root root 91 Oct 10 17:58 autoexec.bat
-rwx---r-- 1 root root 245 Oct 10 17:58 config.sys
drwx---r-- 41 root root 16384 Dec 30 1998 windows</computeroutput>
</screen>
<para>
Mounting the FAT filesystem with a umask of
<literal>000</literal> gives all users complete control over
it. Explicitly specifying the permissions of the FAT
filesystem when it is mounted provides additional control.
There are three mount options that are relevant to FAT
permissions: <literal>uid</literal>, <literal>gid</literal>
and <literal>umask</literal>. They can each be specified
when the filesystem is manually mounted. For example:
</para>
<screen>
<prompt>~></prompt><userinput>umount /c</userinput>
<prompt>~></prompt><userinput>mount -o uid=500 -o gid=500 -o umask=002 /c</userinput>
<prompt>~></prompt><userinput>cd /c</userinput>
<prompt>/c></prompt><userinput>ls -l</userinput>
<computeroutput>-rwxrwxr-x 1 sle sle 91 Oct 10 17:58 autoexec.bat
-rwxrwxr-x 1 sle sle 245 Oct 10 17:58 config.sys
drwxrwxr-x 41 sle sle 16384 Dec 30 1998 windows</computeroutput>
</screen>
<para>
which gives "sle" complete control over
<filename>/c</filename>. The options listed above can be
made permanent by adding them to the
<filename>/etc/fstab</filename> file:
</para>
<screen>
<prompt>~></prompt><userinput>grep /c /etc/fstab</userinput>
<computeroutput>/dev/hda1 /c vfat uid=500,gid=500,umask=002,exec,dev,suid,rw 1 1</computeroutput>
</screen>
<para>
Note that the umask of <literal>002</literal> is common in
the user private group file permission scheme. On FAT file
systems this umask assures that all files are fully
accessible by all users in the specified group
(<literal>gid</literal>).
</para>
</sect2>
<sect2>
<title>Shadowing FAT filesystems</title>
<para>
Shadowing provides a finer granularity of control. Parts of
the original FAT filesystem can be copied so that the
application can safely work with those copied parts while
the application continues to directly read the remaining
parts. This is done with symbolic links. For example,
consider a system where an application named
<application>AnApp</application> must be able to read and
write to the <filename>c:\windows</filename> and
<filename>c:\AnApp</filename> directories as well as have
read access to the entire FAT filesystem. On this system
the FAT filesystem has default permissions which should not
be changed for security reasons or can not be changed due to
lack of root access. On this system a shadow directory
might be set up in the following manner:
</para>
<screen>
<prompt>~></prompt><userinput>cd /</userinput>
<prompt>/></prompt><userinput>mkdir c_shadow</userinput>
<prompt>/></prompt><userinput>cd c_shadow</userinput>
<prompt>/c_shadow></prompt><userinput>ln -s /c_/* .</userinput>
<prompt>/c_shadow></prompt><userinput>rm windows AnApp</userinput>
<prompt>/c_shadow></prompt><userinput>cp -R /c_/{windows,AnApp} .</userinput>
<prompt>/c_shadow></prompt><userinput>chmod -R 777 windows AnApp</userinput>
<prompt>/c_shadow></prompt><userinput>perl -p -i -e 's|/c$|/c_shadow|g' /usr/local/etc/wine.conf</userinput>
</screen>
<para>
The above gives everyone complete read and write access to
the <filename>windows</filename> and
<filename>AnApp</filename> directories while only root has
write access to all other directories.
</para>
</sect2>
</sect1>
<sect1 id="scsi-support">
<title>SCSI Support</title>
<para>
Written by &name-bruce-milner; <email>&email-bruce-milner;</email>;
Additions by &name-andreas-mohr; <email>&email-andreas-mohr;</email>
</para>
<para>
(Extracted from <filename>wine/documentation/aspi</filename>)
</para>
<para>
This file describes setting up the Windows ASPI interface.
</para>
<para>
<warning><title>Warning/Warning/Warning!!!!!!</title>
<para>This may trash your system if used incorrectly. It may
even trash your system when used <emphasis>correctly</>!
</para>
</warning>
</para>
<para>
Now that I have said that. ASPI is a direct link to SCSI devices from
windows programs. ASPI just forwards the SCSI commands that programs send
to it to the SCSI bus.
</para>
<para>
If you use the wrong SCSI device in your setup file, you can send
completely bogus commands to the wrong device - An example would be
formatting your hard drives (assuming the device gave you permission -
if you're running as root, all bets are off).
</para>
<para>
So please make sure that <emphasis>all</emphasis> SCSI devices not needed by the program
have their permissions set as restricted as possible !
</para>
<para>
Cookbook for setting up scanner: (At least how mine is to work)
(well, for other devices such as CD burners, MO drives, ..., too)
</para>
<sect2>
<title>Windows requirements</title>
<orderedlist>
<listitem>
<para>
The scanner software needs to use the "Adaptec"
compatible drivers (ASPI). At least with Mustek, they
allow you the choice of using the builtin card or the
"Adaptec (AHA)" compatible drivers. This will not work
any other way. Software that accesses the scanner via a
DOS ASPI driver (e.g. ASPI2DOS) is supported, too. [AM]
</para>
</listitem>
<listitem>
<para>
You probably need a real windows install of the software
to set the LUN's/SCSI id's up correctly. I'm not exactly
sure.
</para>
</listitem>
</orderedlist>
</sect2>
<sect2>
<title>Linux requirements</title>
<orderedlist>
<listitem>
<para>
Your SCSI card must be supported under Linux. This will
not work with an unknown SCSI card. Even for cheap'n
crappy "scanner only" controllers some special Linux
drivers exist on the net.
If you intend to use your IDE device, you need to use the
ide-scsi emulation.
Read
<ulink url="http://www.linuxdoc.org/HOWTO/CD-Writing-HOWTO.html">
http://www.linuxdoc.org/HOWTO/CD-Writing-HOWTO.html</ulink>
for ide-scsi setup instructions.
</para>
</listitem>
<listitem>
<para>
Compile generic SCSI drivers into your kernel.
</para>
</listitem>
<listitem>
<para>
This seems to be not required any more for newer (2.2.x) kernels:
Linux by default uses smaller SCSI buffers than Windows.
There is a kernel build define <literal>SG_BIG_BUFF</literal> (in
<filename>sg.h</filename>) that is by default set too
low. The SANE project recommends
<literal>130560</literal> and this seems to work just
fine. This does require a kernel rebuild.
</para>
</listitem>
<listitem>
<para>
Make the devices for the scanner (generic SCSI devices)
- look at the SCSI programming HOWTO at
<ulink url="http://www.linuxdoc.org/HOWTO/SCSI-Programming-HOWTO.html">
http://www.linuxdoc.org/HOWTO/SCSI-Programming-HOWTO.html</ulink>
for device numbering.
</para>
</listitem>
<listitem>
<para>
I would recommend making the scanner device writable by
a group. I made a group called
<literal>scanner</literal> and added myself to it.
Running as root increases your risk of sending bad SCSI
commands to the wrong device. With a regular user, you
are better protected.
</para>
</listitem>
<listitem>
<para>
For Win32 software (WNASPI32), Wine has auto-detection in place.
For Win16 software (WINASPI), you need to add a SCSI device entry
for your particular scanner to ~/.wine/config. The format is
<literal>[scsi cCtTdD]</literal> where
<literal>"C" = "controller"</literal>,
<literal>"T" = "target"</literal>, <literal>D=LUN</literal>
</para>
<para>
For example, I set mine up as controller <literal>0</literal>,
Target <literal>6</literal>, LUN <literal>0</literal>.
<programlisting>
[scsi c0t6d0]
"Device" = "/dev/sgi"
</programlisting>
Yours will vary with your particular SCSI setup.
</para>
</listitem>
</orderedlist>
</sect2>
<sect2>
<title>General Information</title>
<para>
The mustek scanner I have was shipped with a package
"ipplus". This program uses the TWAIN driver specification
to access scanners.
</para>
<para>
(TWAIN MANAGER)
</para>
<para>
<programlisting>
ipplus.exe &lt;-&gt; (TWAIN INTERFACE) &lt;-&gt; (TWAIN DATA SOURCE.ASPI) -&gt; WINASPI
</programlisting>
</para>
</sect2>
<sect2>
<title>NOTES/BUGS</title>
<para>
The biggest is that it only works under Linux at the moment.
</para>
<para>
The ASPI code has only been tested with:
</para>
<itemizedlist>
<listitem>
<para>
a Mustek 800SP with a Buslogic controller under Linux [BM]
</para>
</listitem>
<listitem>
<para>
a Siemens Nixdorf 9036 with Adaptec AVA-1505 under Linux
accessed via DOSASPI. Note that I had color problems,
though (barely readable result) [AM]
</para>
</listitem>
<listitem>
<para>
a Fujitsu M2513A MO drive (640MB) using generic SCSI
drivers. Formatting and ejecting worked perfectly.
Thanks to Uwe Bonnes for access to the hardware ! [AM]
</para>
</listitem>
</itemizedlist>
<para>
I make no warranty to the ASPI code. It makes my scanner
work. Your devices may explode. I have no way of determining
this. I take zero responsibility!
</para>
</sect2>
</sect1>
</chapter>
</chapter>
<!-- Keep this comment at the end of the file
Local variables:

490
documentation/introduction.sgml
View File

@ -1,13 +1,127 @@
<chapter id="introduction">
<title>Introduction</title>
<sect1>
<title>Overview / About</title>
<sect2>
<title>Purpose of this document and intended audience</title>
<para>
This document, called the Wine User Guide, is supposed to
be both an easy installation guide and an extensive reference guide.
Thus while it completely explains how to install and configure Wine,
it also tries to document all configuration features and support areas
of the Wine environment as a whole.
</para>
<para>
It tries to target both the new Wine user (aka "bloody newbie"),
by offering a step by step approach, and the experienced Wine
user or expert, by offering the reference material mentioned
above.
<para>
The whole document has been extensively rewritten (in other
words: the document then deserved to be called a document :-) by
&name-andreas-mohr; <email>&email-andreas-mohr;</email> in
March 2003.
</para>
</sect2>
<sect2>
<title>Burning questions and comments</title>
<para>
If during reading this document there is something you
can't figure out, or think could be explained better, or
that should have been included, please immediately mail to
either the &name-web-admin; <email>&email-web-admin;</email> or
the &name-wine-devel; <email>&email-wine-devel;</email>, or
post a bug report to
<ulink url="http://bugs.winehq.com/">Wine's Bugzilla</ulink> to
let us know how this document can be improved. Remember, Open
Source is "free as in free speech, not as in free beer": it can
only work in the case of very active involvement of its users!
</para>
<para>
<emphasis>
Note that I can't say that I'm too impressed with the amount
of feedback about this Guide that we have received so far
since I added this paragraph many months ago...
</emphasis>
</para>
</sect2>
<sect2>
<title>Content overview / Steps to take</title>
<para>
This section will try to give you a complete overview of
how to go all the way to a fully working Wine installation
by following this Guide.
We <emphasis>strongly recommend</emphasis> following every
single relevant step of this Guide, since you might miss important
information otherwise.
</para>
<para>
First, we start by explaining what Wine is and mentioning
everything else that's useful to know about it (that's
covered in this very chapter that you're reading a part of right now).
</para>
<para>
In order to be able to use Wine, you need to obtain a copy of
its files first. That's the purpose of the next chapter, <link
linkend="getting-wine">Getting Wine</link>: it tries to show
you how Wine can be installed on your particular system
(i.e. which installation methods are available in your case),
and then it explains the various methods: either getting Wine
via a binary package file suited for your particular system,
or getting it via a Wine <glossterm>source code</glossterm>
archive file, or getting the most current Wine development
source code via <glossterm>CVS</glossterm>.
</para>
<para>
Once you got your copy of Wine, you might need to follow the
next chapter <link linkend="compiling">Compiling</link> if you
got Wine source code.
Otherwise, the next chapter <link
linkend="installing">Installing Wine</link> will explain the
methods to use to install the Wine files to some location
on your system (alternatively the chapter <link
linkend="compiling">Compiling</link> will explain first how to
compile Wine if you choose to use Wine source code).
</para>
<para>
Once Wine is installed on your system, the next chapter <link
linkend="config-wine-main">Configuring Wine</link> will
focus on the available configuration methods for Wine: there are
either graphical (e.g. WineSetupTk) or text mode (wineinstall)
configuration helper applications available that will
fully configure the Wine environment for you.
And For those people who dislike a fully automated
installation (maybe because they really want to know what they're
doing), we'll describe how to manually set up a complete Wine
environment configuration.
</para>
<para>
Once the configuration of the Wine environment is done, the
next chapter <link linkend="running">Running Wine</link>
will show you how to run Wine and how to satisfy
the requirements of certain Windows programs.
</para>
<para>
In case you run into trouble, the chapter <link
linkend="bugs">Troubleshooting / Reporting bugs</link>
will list and explain some common troubleshooting and debugging
methods.
</para>
</sect2>
</sect1>
<sect1 id="what-is-wine">
<title>What is Wine?</title>
<para>
<literallayout>
Written by &name-john-sheets; <email>&email-john-sheets;</email>
Modified by <ulink url="mailto:&email-dustin-navea;">&name-dustin-navea;</ulink>
Modified by &name-dustin-navea; <email>&email-dustin-navea;</email>
</literallayout>
</para>
@ -26,7 +140,7 @@
A common solution to this problem is to install both operating
systems on the same computer, as a <quote>dual boot</quote>
system. If you want to write a document in MS Word, you can
boot up in Windows; if you want to run the GnuCash, the GNOME
boot up in Windows; if you want to run GnuCash, the GNOME
financial application, you can shut down your Windows session
and reboot into Linux. The problem with this is that you
can't do both at the same time. Each time you switch back and
@ -59,158 +173,57 @@
</sect2>
<sect2>
<title>Emulation versus Native Linking</title>
<title>What is Wine, and how can it help me?</title>
<!-- emulator vs. Winelib -->
<para>
Wine is a UNIX implementation of the win32 libraries,
Wine is a UNIX implementation of the win32 Windows libraries,
written from scratch by hundreds of volunteer developers and
released under an open source license. Anyone can download
released under an Open Source license (think of it as a
Windows compatibility layer for Linux and other similar
operating systems). Anyone can download
and read through the source code, and fix bugs that arise.
The Wine community is full of richly talented programmers
who have spent thousands of hours of personal time on
improving Wine so that it works well with the win32
<firstterm>Applications Programming Interface</firstterm>
<glossterm>Application Programming Interface</glossterm>
(API), and keeps pace with new developments from Microsoft.
</para>
<para>
Wine can run applications in two discrete ways: as
pre-compiled Windows binaries, or as natively compiled
Wine can run Windows applications in two discrete ways: as
pre-compiled Windows binaries (your average off-the-shelf
program package e.g. available on CD), or as natively compiled
<ulink url="http://www.xfree86.org/#whatis">X11 (X-Window
System)</ulink> applications. The former method uses
emulation to connect a Windows application to the Wine
libraries. You can run your Windows application directly
with the emulator, by installing through Wine or by simply
copying the Windows executables onto your Linux system.
</para>
<para>
The other way to run Windows applications with Wine requires
that you have the source code for the application. Instead
of compiling it with native Windows compilers, you can
compile it with a native Linux compiler --
<command>gcc</command> for example -- and link in the Wine
Libraries as you would with any other native UNIX
application. These natively linked applications are
referred to as Winelib applications.
</para>
<para>
The Wine Users Guide will focus on running precompiled
Windows applications using the Wine emulator.
The Winelib Users Guide will cover Winelib
applications.
System)</ulink> applications (via the part of Wine that's called
Winelib). If you're interested in compiling your Windows program
source code, then please refer to the Winelib User's Guide
instead, which explains this particular topic.
The Wine Users Guide however will focus on running standard
Windows applications using Wine.
</para>
<!-- the development model -->
<para>
</para>
</sect2>
<sect2>
<title>Burning questions and comments</title>
<para>
If during reading this document there is something you
can't figure out, or think could be explained better, or
that should have been included, please immediately mail to
either the &name-web-admin; <email>&email-web-admin;</email> or
the &name-wine-devel; <email>&email-wine-devel;</email>, or
post a bug report to
<ulink url="http://bugs.winehq.com/">Wine's Bugzilla</ulink> to
let us know how this document can be improved. Remember, Open
Source is "free as in free speech, not as in free beer": it can
only work in the case of very active involvement of its users !
</para>
</sect2>
</sect1>
<!-- *** Not really useful as is, but may be able to recycle this elsewhere...
<sect1 id="getting-started">
<title>Getting started</title>
<para>
Written by &name-john-sheets; <email>&email-john-sheets;</email>
</para>
<para>
Wine can be pretty intimidating at first. The Wine
distribution consists of over two thousand files and half a
million lines of source code
<footnote>
<para>Crudely calculated from running <command>find . | wc
-l</command> and <command>cat `find . -name "*.c"` | wc
-l</command>, respectively, from a fresh CVS checkout.</para>
</footnote>,
and is probably one of the steepest learning curves in the
open source world. This chapter will give you a crash course
in the important topics you need to know to get started with
running Wine applications.
</para>
</sect1>
-->
<sect1 id="wine-stats">
<title>Wine Requirements and Features</title>
<para>
<literallayout>
Written by &name-andreas-mohr; <email>&email-andreas-mohr;</email>
Modified by <ulink url="mailto:&email-dustin-navea;">&name-dustin-navea;</ulink>
</literallayout>
</para>
<sect2 id="system-requirements">
<title>System requirements</title>
<para>
In order to run Wine, you need the following:
</para>
<para>
<itemizedlist>
<listitem>
<para>
<literallayout>A computer ;-)</literallayout>
<literallayout> Wine: only PCs >= i386 are supported at the moment.</literallayout>
<literallayout> Winelib: selected other platforms are supported, but can be tricky.</literallayout>
</para>
</listitem>
<listitem>
<para>
A UNIX-like operating system such as Linux, *BSD,
Solaris x86, ReactOS, Cygwin
</para>
</listitem>
<listitem>
<para>
>= 32MB of RAM. Everything below is pretty much
unusable. >= 96 MB is needed for "good" execution.
</para>
</listitem>
<listitem>
<para>
An X11 window system (XFree86 etc.). Wine is prepared
for other graphics display drivers, but writing
support is not too easy. The text console display
driver (ttydrv) is nearly usable.
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
<sect2 id="wine-capabilities">
<title>Wine capabilities</title>
<para>
Now that you hopefully managed to fulfill the requirements
mentioned above, we tell you what Wine is able to do/support:
Now that we're done with the boring introductory babble,
let us tell you what Wine is able to do/support:
</para>
<para>
<itemizedlist>
<listitem>
<para>
Support for executing DOS, Win 3.x and Win9x/NT/Win2000/XP
programs (most of Win32's controls are supported)
Support for running Win32 (Win 95/98, NT/2000/XP), Win16 (Win 3.1) and DOS programs
</para>
</listitem>
<listitem>
<para>
Optional use of external vendor DLLs (e.g. original
Optional use of external vendor
<glossterm>DLLs</glossterm> (e.g. original
Windows DLLs)
</para>
</listitem>
@ -227,8 +240,7 @@
</listitem>
<listitem>
<para>
32 bit graphical coordinates for CAD applications,
pretty advanced DirectX support for games
Pretty advanced DirectX support for games
</para>
</listitem>
<listitem>
@ -238,7 +250,8 @@
</listitem>
<listitem>
<para>
Printing through internal PostScript driver
Printing: PostScript interface driver (psdrv) to
standard Unix PostScript print services
</para>
</listitem>
<listitem>
@ -271,6 +284,231 @@
</para>
</sect2>
</sect1>
<!-- *** Not really useful as is, but may be able to recycle this elsewhere...
<sect1 id="getting-started">
<title>Getting started</title>
<para>
Written by &name-john-sheets; <email>&email-john-sheets;</email>
</para>
<para>
Wine can be pretty intimidating at first. The Wine
distribution consists of over two thousand files and half a
million lines of source code
<footnote>
<para>Crudely calculated from running <command>find . | wc
-l</command> and <command>cat `find . -name "*.c"` | wc
-l</command>, respectively, from a fresh CVS checkout.</para>
</footnote>,
and is probably one of the steepest learning curves in the
open source world. This chapter will give you a crash course
in the important topics you need to know to get started with
running Wine applications.
</para>
</sect1>
-->
<sect1>
<title>Other, often "Enhanced" Wine offerings</title>
<para>
There are a number of offerings that are derived from the standard Wine
codebase in some way or another.
</para>
<para>
Some of these are commercial products from companies that actively contribute to Wine.
</para>
<para>
These products often try to stand out or distinguish themselves
from Wine, e.g. by offering greater compatibility or much easier
and flexible configuration than your average standard Wine
release. As such it is often a good idea to shell out some bucks
for the commercial versions, especially since these companies
contribute a lot of code to Wine, and plus, I'm sure they'll be happy about your support...
</para>
<table><title>Various Wine offerings</title>
<tgroup cols=3 align="left">
<thead>
<row>
<entry>Product</entry>
<entry>Description</entry>
<entry>Distribution form</entry>
</row>
</thead>
<tbody>
<row>
<entry>
<ulink
url="http://sourceforge.net/projects/rewind">ReWind</ulink>
</entry>
<entry>
ReWind is a Wine version derived from the old BSD
licensed Wine tree (it's the "completely free" BSD license fork of the currently LGPL'ed Wine).
Due to its BSD license it can't incorporate some Wine
patches that get licensed under the more restrictive
(or: protective) LGPL license by their authors.
</entry>
<entry>
Free, Open Source: BSD license
</entry>
</row>
<row>
<entry>
<ulink
url="http://www.codeweavers.com/products/office">CodeWeavers CrossOver Office</ulink>
</entry>
<entry>
CrossOver Office allows you to install your favorite
Windows productivity applications in Linux, without
needing a Microsoft Operating System license. CrossOver
includes an easy to use, single click interface, which
makes installing a Windows application simple and fast.
</entry>
<entry>
Commercial
</entry>
</row>
<row>
<entry>
<ulink
url="http://www.codeweavers.com/products/cxofficeserver">CodeWeavers CrossOver Office Server Edition</ulink>
</entry>
<entry>
CrossOver Office Server Edition allows you to run your
favorite Windows productivity applications in a
distributed thin-client environment under Linux, without
needing Microsoft Operating System licenses for each
client machine. CrossOver OfficeServer Edition allows you
to satisfy the needs of literally hundreds of concurrent
users, all from a single server.
</entry>
<entry>
Commercial
</entry>
</row>
<row>
<entry>
<ulink
url="http://www.codeweavers.com/products/crossover">CodeWeavers
CrossOver Plugin</ulink>
</entry>
<entry>
CrossOver Plugin lets you use many Windows plugins
directly from your Linux browser. In particular CrossOver
fully supports QuickTime, ShockWave Director,
Windows Media Player 6.4, Word Viewer, Excel Viewer,
PowerPoint Viewer, and more...
</entry>
<entry>
Commercial; Demo version available
</entry>
</row>
<row>
<entry>
<ulink
url="http://www.codeweavers.com/technology/wine/">CodeWeavers
Wine preview</ulink>
</entry>
<entry>
The Wine preview is a usually slightly older Wine release
that's been tested as extra stable.
It includes the graphical installer winesetuptk,
allowing for easy configuration.
</entry>
<entry>
Free, Open Source: LGPL license
</entry>
</row>
<row>
<entry>
<ulink url="http://www.transgaming.com">TransGaming Technologies WineX</ulink>
</entry>
<entry>
WineX is a Wine version derived from the old BSD licensed Wine tree, with currently better support for Direct3D and DirectX software than standard Wine, and with added copy protection support for multiple types of copy protection e.g. used in games.
</entry>
<entry>
Commercial; <ulink
url="http://sourceforge.net/projects/winex">free CVS
download</ulink> of reduced version (no copy protection
support etc.)
</entry>
</row>
</tbody>
</tgroup>
</table>
</sect1>
<sect1 id="wine-stats">
<title>Basic Wine Requirements</title>
<para>
<literallayout>
Written by &name-andreas-mohr; <email>&email-andreas-mohr;</email>
Modified by &name-dustin-navea; <email>&email-dustin-navea;</email>
</literallayout>
</para>
<para>
This section only mentions the most basic system requirements of
Wine, in order to ease your Wine "purchasing decision" ;-)
For an up-to-date much more detailed list of requirements for
compiling and/or installing Wine,
please read the REQUIREMENTS section of the <ulink
url="http://www.winehq.org/source/README">README</ulink> file,
which is also available in the main directory of a Wine source code tree.
</para>
<para>
In case of a binary Wine package, these Wine requirements will
probably be fulfilled automatically by the package installation
process; if you want to have a look at the detailed requirements
nevertheless (which definitely can't hurt!), then I'd like to
mention that the README file can also frequently be found in the
documentation files directory of a Wine package.
</para>
<sect2 id="system-requirements">
<title>System requirements</title>
<para>
In order to run Wine, you generally need the following:
</para>
<para>
<itemizedlist>
<listitem>
<para>
<literallayout>A computer ;-)</literallayout>
<literallayout> Wine: only PCs >= i386 are supported at the moment.</literallayout>
<literallayout> Winelib: selected other platforms are supported, but can be tricky.</literallayout>
</para>
</listitem>
<listitem>
<para>
A UNIX-like operating system such as Linux, *BSD,
Solaris x86, ReactOS, Cygwin
</para>
</listitem>
<listitem>
<para>
>= 32MB of RAM. Everything below is pretty much
unusable. >= 96 MB is needed for "good" execution.
</para>
</listitem>
<listitem>
<para>
An X11 window system (XFree86 etc.). Wine is prepared
for other graphics display drivers, but writing
support is not too easy. The text console display
driver (ttydrv) is nearly usable, so you don't
necessarily have to install X11 if you don't need it for
the programs you intend to run (in other words: mainly
for text mode programs).
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
</sect1>
</chapter>
<!-- Keep this comment at the end of the file

4
documentation/multimedia.sgml
View File

@ -801,7 +801,7 @@
<para>
MCI drivers are seen as regular Wine modules, and can be loaded (with
a correct load order between built-in, native, elfdll, so), as any
a correct load order between builtin, native, so), as any
other DLL. Please note, that MCI drivers module names must bear the
.drv extension to be correctly understood.
</para>
@ -911,7 +911,7 @@
<title>MMIO</title>
<para>
The API consists of the mmio* functions found in mdlls/winmm/mmio.c.
The API consists of the mmio* functions found in dlls/winmm/mmio.c.
Seems to work ok in most of the cases. There's some linear/segmented
issues with 16 bit code. There are also some bugs when writting MMIO
files.

15
documentation/packaging.sgml
View File

@ -142,7 +142,8 @@
</para>
<para>
The initial installation should require no user
input. An rpm -i wine.rpm or apt-get install wine
input. An <command>rpm -i wine.rpm</command>
or <command>apt-get install wine</command>
should suffice for initial installation.
</para>
</listitem>
@ -1529,7 +1530,7 @@ WINE REGISTRY Version 2
; Be careful here, wrong DllOverrides settings have the potential
; to pretty much kill your setup.
[DllOverrides]
; some dlls you may want to change
; some DLLs you may want to change
"oleaut32" = "builtin, native"
"ole32" = "builtin, native"
"commdlg" = "builtin, native"
@ -1548,7 +1549,7 @@ WINE REGISTRY Version 2
;"*notepad.exe" = "native, builtin"
; this one will apply only for a particular file
;"C:\\windows\\regedit.exe" = "native, builtin"
; default for all other dlls
; default for all other DLLs
"*" = "builtin, native"
[x11drv]
@ -1776,7 +1777,7 @@ WINE REGISTRY Version 2
<chapter id="pkg-implementation"> <title>Implementation</title>
<sect1 id="pkg-openlinux"><title>RedHat 8.0 Sample</title>
<sect1 id="pkg-openlinux"><title>Red Hat 8.0 Sample</title>
<orderedlist inheritnum="inherit">
<listitem>
@ -1808,7 +1809,7 @@ make install prefix=$BR/usr/X11R6/ sysconfdir=$BR/etc/wine/
install -d $BR/etc/wine/
install -m 644 wine.ini $BR/etc/wine/wine.conf
# Put all our dlls in a seperate directory. (this works only if
# Put all our DLLs in a seperate directory. (this works only if
# you have a buildroot)
install -d $BR/usr/X11R6/lib/wine
mv $BR/usr/X11R6/lib/lib* $BR/usr/X11R6/lib/wine/
@ -2095,7 +2096,7 @@ Path=/
</orderedlist>
<sect2 id=sample><title>Sample RedHat 8.0 .spec file for review purposes</title>
<sect2 id=sample><title>Sample Red Hat 8.0 .spec file for review purposes</title>
<programlisting>
@ -2224,7 +2225,7 @@ touch $RPM_BUILD_ROOT%{_datadir}/wine-c/config.sys
touch $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/win.ini
install -c -m 0644 documentation/samples/system.ini $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/system.ini
cat >RedHat &lt;&lt;EOF
cat >Red Hat &lt;&lt;EOF
Wine directory structure used in Red Hat Linux:
===============================================

34
documentation/printing.sgml
View File

@ -1,8 +1,8 @@
<sect1 id="printing">
<sect1 id="config-printing">
<title>Printing in Wine</title>
<para>How to print documents in Wine...</para>
<sect2 id="wine-printing">
<sect2 id="config-printing-intro">
<title>Printing</title>
<para>
@ -18,7 +18,7 @@
<orderedlist>
<listitem>
<para>
Use the builtin Wine PostScript driver (+ ghostscript to produce
Use the built-in Wine PostScript driver (+ ghostscript to produce
output for non-PostScript printers).
</para>
</listitem>
@ -34,7 +34,7 @@
</para>
<sect3>
<title>Builtin Wine PostScript driver</title>
<title>Built-in Wine PostScript driver</title>
<para>
Enables printing of PostScript files via a driver built into Wine. See
below for installation instructions. The code for the PostScript
@ -49,6 +49,7 @@
</para>
</sect3>
<!--
<sect3>
<title>External printer drivers (non-working as of Jul 8, 01)</title>
<para>
@ -71,6 +72,7 @@ printer=on
the driver interface is in <filename>graphics/win16drv</filename>.
</para>
</sect3>
-->
<sect3>
<title>Spooling</title>
@ -101,7 +103,7 @@ printer=on
</sect3>
</sect2>
<sect2 id="psdriver">
<sect2 id="config-printing-psdriver">
<title>The Wine PostScript Driver</title>
<para>
@ -182,31 +184,31 @@ printer=on
</para>
<para>
You also need to add certain entries to the registry.
The easiest way to do this is to customise the contents of
<filename>documentation/psdrv.reg</filename> (see below) and use the
Winelib program <command>programs/regapi/regapi</command>. For
The easiest way to do this is to customise the PostScript
driver contents of <filename>winedefault.reg</filename> (see below) and use the
Winelib program <command>programs/regedit/regedit</command>. For
example, if you have installed the Wine source tree in
<filename>/usr/src/wine</filename>, you could use the following
series of commands:
<itemizedlist>
<listitem>
<para>
<userinput>cp /usr/src/wine/documentation/psdrv.reg ~</userinput>
<userinput>cp /usr/src/wine/winedefault.reg ~</userinput>
</para>
</listitem>
<listitem>
<para><userinput>vi ~/psdrv.reg</userinput></para>
<para><userinput>vi ~/winedefault.reg</userinput></para>
</listitem>
<listitem>
<para>
Edit the copy of <filename>psdrv.reg</filename> to suit your
requirements. At a minimum, you must specify a PPD file for
each printer.
Edit the copy of <filename>winedefault.reg</filename> to suit your
PostScript printing requirements.
At a minimum, you must specify a PPD file for each printer.
</para>
</listitem>
<listitem>
<para>
<userinput>regapi setValue &lt; ~/psdrv.reg</userinput>
<userinput>regedit ~/winedefault.reg</userinput>
</para>
</listitem>
</itemizedlist>
@ -217,7 +219,7 @@ printer=on
<para>
You won't need Adobe Font Metric (AFM) files for the (type 1 PostScript)
fonts that you wish to use any more.
Wine now has this information builtin.
Wine now has this information built-in.
</para>
<para>
You'll need a PPD file for your printer. This describes
@ -239,7 +241,7 @@ printer=on
Note that you need not set <literal>printer=on</literal> in
the [wine] section of the wine config file, this
enables printing via external printer drivers and does not
affect the builtin PostScript driver.
affect the built-in PostScript driver.
</para>
<para>
If you're lucky you should now be able to produce PS files

125
documentation/registry.sgml
View File

@ -1,12 +1,9 @@
<sect1 id="registry">
<title>The Registry</title>
<para>
written by Ove Kåven
</para>
<para>
(Extracted from <filename>wine/documentation/registry</filename>)
</para>
<para>
Originally written by Ove Kåven
</para>
<para>
After Win3.x, the registry became a fundamental part of Windows.
@ -18,6 +15,72 @@
to support it somehow.
</para>
<sect2>
<title>The default registry</title>
<para>
A Windows registry contains many keys by default, and some of
them are necessary for even installers to operate correctly.
The keys that the Wine developers have found necessary to
install applications are distributed in a file called
<filename>winedefault.reg</filename>. It is automatically
installed for you if you use the
<filename>tools/wineinstall</filename> script in the Wine source,
but if you want to install it manually, you can do so by using the
<command>regedit</command> tool to be found in the
<filename>programs/regedit/</filename>
directory in Wine source.
<filename>winedefault.reg</filename> should even be applied if
you plan to use a native Windows registry, since Wine needs some
specific registry settings in its registry (for special
workarounds for certain programs etc.).
In the main Wine source code directory in a <glossterm>terminal</glossterm>, run:
</para>
<screen>
<prompt>$ </><userinput>cd programs/regedit</>
<prompt>$ </><userinput>./regedit ../../winedefault.reg</>
</screen>
</sect2>
<sect2>
<title>Using a Windows registry</title>
<para>
If you point Wine at an existing Windows installation (by
setting the appropriate directories in
<filename>~/.wine/config</filename>, then Wine is able to load
registry data from it. However, Wine will not save anything to
the real Windows registry, but rather to its own registry
files (see below). Of course, if a particular registry value
exists in both the Windows registry and in the Wine registry,
then Wine will use the latter. In the Wine config file, there
are a number of configuration settings in the [registry] section
(see below) specific to the handling of Windows registry content by Wine.
</para>
<para>
Occasionally, Wine may have trouble loading the Windows
registry. Usually, this is because the registry is
inconsistent or damaged in some way. If that becomes a
problem, you may want to download the
<filename>regclean.exe</filename> from the MS website and use
it to clean up the registry. Alternatively, you can always use
<filename>regedit.exe</filename> to export the registry data
you want into a text file, and then import it in Wine.
</para>
</sect2>
<sect2>
<title>The Registry</title>
<para>
The initial default registry content to be used by the Wine
registry files is in the file
<filename>winedefault.reg</filename>. It contains directory
paths, class IDs, and more; it must be installed before most
<filename>INSTALL.EXE</filename> or
<filename>SETUP.EXE</filename> applications will work.
</para>
</sect2>
<sect2>
<title>Registry structure</title>
@ -75,31 +138,6 @@
</variablelist>
</sect2>
<sect2>
<title>Using a Windows registry</title>
<para>
If you point Wine at an existing MS Windows installation (by
setting the appropriate directories in
<filename>~/.wine/config</filename>, then Wine is able to load
registry data from it. However, Wine will not save anything to
the real Windows registry, but rather to its own registry
files (see below). Of course, if a particular registry value
exists in both the Windows registry and in the Wine registry,
then Wine will use the latter.
</para>
<para>
Occasionally, Wine may have trouble loading the Windows
registry. Usually, this is because the registry is
inconsistent or damaged in some way. If that becomes a
problem, you may want to download the
<filename>regclean.exe</filename> from the MS website and use
it to clean up the registry. Alternatively, you can always use
<filename>regedit.exe</filename> to export the registry data
you want into a text file, and then import it in Wine.
</para>
</sect2>
<sect2>
<title>Wine registry data files</title>
@ -153,7 +191,7 @@
them, otherwise your changes will be discarded).
</para>
<para>
FIXME: global config currently not implemented.
FIXME: global configuration currently not implemented.
In addition to these files, Wine can also optionally load from
global registry files residing in the same directory as the
@ -228,31 +266,12 @@ ln -sf /usr/local/etc/wine.userreg wine.userreg
</para>
</sect2>
<sect2>
<title>The default registry</title>
<para>
A Windows registry contains many keys by default, and some of
them are necessary for even installers to operate correctly.
The keys that the Wine developers have found necessary to
install applications are distributed in a file called
<filename>winedefault.reg</filename>. It is automatically
installed for you if you use the
<filename>tools/wineinstall</filename> script in the Wine source,
but if you want to install it manually, you can do so by using the
<command>regedit</command> tool to be found in the
<filename>programs/regedit/</filename>
directory in Wine source.
</para>
</sect2>
<sect2>
<title>The [registry] section</title>
<para>
With the above information fresh in mind, let's look at the
<filename>wine.conf</filename> / <filename>~/.wine/config</filename>
options for handling the registry.
Now let's look at the <link linkend="config-file">Wine
configuration file</link> options for handling the registry.
</para>
<variablelist>

141
documentation/running.sgml
View File

@ -6,24 +6,36 @@
</para>
<para>
Extended by &name-mike-hearn; <email>&email-mike-hearn;</email>, &name-eric-pouech; <email>&email-eric-pouech;</email>
Modified by &name-andreas-mohr; <email>&email-andreas-mohr;</email>
</para>
<para>
This chapter will describe all aspects of running Wine, like e.g.
basic Wine invocation, command line parameters of various Wine
support programs etc.
</para>
<sect1 id="basic-usage">
<title>Basic usage: applications and control panel applets</title>
<para>
Assuming you are using a fake windows installation, you install
applications into Wine in the same way you would in Windows:
by running the installer. You can just accept the defaults
for where to install, most installers will default to "C:\Program Files",
which is fine. If the application installer requests it, you may find that
Wine creates icons on your desktop and in your app menu. If that happens, you
can start the app by clicking on them.
Assuming you are using a fake Windows installation, you install
applications into Wine in the same way you would in Windows: by
running the installer. You can just accept the defaults for
where to install, most installers will default to "C:\Program
Files", which is fine. If the application installer requests it,
you may find that Wine creates icons on your desktop and in your
app menu. If that happens, you can start the app by clicking on
them.
</para>
<para>
The standard way to uninstall things is for the application to provide an
uninstaller, usually registered with the "Add/Remove Programs" control panel
applet. To access the Wine equivalent, run the "uninstaller" program:
The standard way to uninstall things is for the application to
provide an uninstaller, usually registered with the "Add/Remove
Programs" control panel applet.
To access the Wine equivalent, run the <command>uninstaller</command>
program (it is located in the
<filename>programs/uninstaller/</filename> directory in a Wine
source directory) in a <glossterm>terminal</glossterm>:
</para>
<screen>
@ -31,8 +43,10 @@
</screen>
<para>
Some programs install associated control panel applets, examples of this would be
Internet Explorer and QuickTime. You can access the Wine control panel by running:
Some programs install associated control panel applets, examples
of this would be Internet Explorer and QuickTime. You can access
the Wine control panel by running in a
<glossterm>terminal</glossterm>:
</para>
<screen>
@ -40,12 +54,14 @@
</screen>
<para>
which will open a window with the installed control panel applets in it, as in Windows.
which will open a window with the installed control panel
applets in it, as in Windows.
</para>
<para>
If the application doesn't install menu or desktop items, you'll need to run the app
from the command line. Remembering where you installed to, something like:
If the application doesn't install menu or desktop items, you'll
need to run the app from the command line. Remembering where you
installed to, something like:
</para>
<screen>
@ -53,9 +69,11 @@
</screen>
<para>
will probably do the trick. The path isn't case sensitive, but remember to include the double quotes.
Some programs don't always use obvious naming for their directories and EXE files, so you might have
to look inside the program files directory to see what it put where
will probably do the trick. The path isn't case sensitive, but
remember to include the double quotes. Some programs don't
always use obvious naming for their directories and EXE files,
so you might have to look inside the program files directory to
see what it put where
</para>
</sect1>
@ -65,7 +83,7 @@
Wine is a very complicated piece of software with many ways to
adjust how it runs. With very few exceptions, you can
activate the same set of features through the <link
linkend="configuring">configuration file </link> as you can
linkend="config-file">configuration file</link> as you can
with command-line parameters. In this chapter, we'll briefly
discuss these parameters, and match them up with their
corresponding configuration variables.
@ -132,8 +150,23 @@ Options:
</para>
</sect1>
<sect1>
<title>Explorer-like graphical Wine environments</title>
<para>
If you don't feel like manually invoking Wine for every program
you want to run and instead want to have an integrated graphical
interface to run your Windows programs in, then installing e.g.
<ulink url="http://www.calmira.org">Calmira</ulink>, a
Win95-Explorer-like shell replacement, would probably be a great
idea. Calmira might still have a few problems running on Wine,
though. Other usable Explorer replacements should be listed here
in the future.
</para>
</sect1>
<sect1 id="command-line-options">
<title>Command-Line Options</title>
<title>Wine Command Line Options</title>
<sect2 id="config-parameter">
<title>--debugmsg [channels]</title>
@ -208,9 +241,9 @@ Options:
<prompt>$</prompt> <userinput>wine --debugmsg +all,-relay <replaceable>program_name</replaceable></userinput>
</screen>
<para>
Here is a master list of all the debug channels and classes
in Wine. More channels will be added to (or subtracted
from) later versions.
Here is a list of the debug channels and classes in Wine.
More channels will be added to (or subtracted from) later
versions.
</para>
<table frame="none"><title>Debug Channels</title>
@ -305,7 +338,7 @@ winspool</><entry>wnet</><entry>x11</>
<screen>
<prompt>$</prompt> <userinput>wine --dll setupx=n foo.exe</userinput>
</screen>
See the <link linkend="dll-config">DLL chapter</link> for more details.
See the <link linkend="config-dll">DLL chapter</link> for more details.
</para>
</sect2>
@ -324,6 +357,66 @@ winspool</><entry>wnet</><entry>x11</>
</sect2>
</sect1>
<sect1 id="wineserver-command-line-options">
<title>wineserver Command Line Options</title>
<para>
wineserver usually gets started automatically by Wine whenever
the first wine process gets started.
However, wineserver has some useful command line options that
you can add if you start it up manually, e.g. via a user login
script or so.
</para>
<sect2 id="wineserver-config-parameter">
<title>-d&lt;n&gt;</title>
<para>
Sets the debug level for debug output in the terminal that
wineserver got started in at level &lt;n&gt;.
In other words: everything greater than 0 will enable
wineserver specific debugging output (not to confuse with Wine's wineserver logging channel, --debugmsg +server, though!).
</para>
</sect2>
<sect2>
<title>-h</title>
<para>
Display wineserver command line options help message.
</para>
</sect2>
<sect2>
<title>-k[n]</title>
<para>
Kill the current wineserver, optionally with signal n.
</para>
</sect2>
<sect2>
<title>-p[n]</title>
<para>
This parameter makes wineserver persistent, optionally for n
seconds. It will prevent wineserver from shutting down immediately.
</para>
<para>
Usually, wineserver quits almost immediately after the last
wine process using this wineserver terminated.
However, since wineserver loads a lot of things on startup
(such as the whole Windows registry data), its startup might
be so slow that it's very useful to keep it from exiting after
the end of all Wine sessions, by making it persistent.
</para>
</sect2>
<sect2>
<title>-w</title>
<para>
This parameter makes a newly started wineserver wait until the
currently active wineserver instance terminates.
</para>
</sect2>
</sect1>
<sect1 id="environment-variables">
<title>Setting Windows/DOS environment variables</title>
<para>

38
documentation/wine-devel.sgml
View File

@ -4,26 +4,28 @@
<!entity % authors SYSTEM "authors.ent">
%authors;
<!entity compiling SYSTEM "compiling.sgml">
<!entity debugging SYSTEM "debugging.sgml">
<!entity debugger SYSTEM "debugger.sgml">
<!entity documentation SYSTEM "documentation.sgml">
<!entity testing SYSTEM "testing.sgml">
<!entity patches SYSTEM "patches.sgml">
<!entity testing SYSTEM "testing.sgml">
<!entity i18n SYSTEM "i18n.sgml">
<!entity porting SYSTEM "porting.sgml">
<!entity tools SYSTEM "tools.sgml">
<!entity architecture SYSTEM "architecture.sgml">
<!entity ole SYSTEM "ole.sgml">
<!entity debugger SYSTEM "debugger.sgml">
<!entity consoles SYSTEM "consoles.sgml">
<!entity implementation SYSTEM "implementation.sgml">
<!entity opengl SYSTEM "opengl.sgml">
<!entity build SYSTEM "build.sgml">
<!entity tools SYSTEM "tools.sgml">
<!entity dlls SYSTEM "dlls.sgml">
<!entity cvs-regression SYSTEM "cvs-regression.sgml">
<!entity debugging SYSTEM "debugging.sgml">
<!entity ole SYSTEM "ole.sgml">
<!entity build SYSTEM "build.sgml">
<!entity opengl SYSTEM "opengl.sgml">
<!entity multimedia SYSTEM "multimedia.sgml">
<!entity cvs SYSTEM "cvs.sgml">
<!entity implementation SYSTEM "implementation.sgml">
<!entity porting SYSTEM "porting.sgml">
<!entity consoles SYSTEM "consoles.sgml">
<!entity cvs-regression SYSTEM "cvs-regression.sgml">
<!--
<!entity status SYSTEM "status.sgml">
-->
@ -37,11 +39,10 @@
<part id="part-one">
<title>Developing Wine</title>
&compiling;
&debugger;
&documentation;
&testing;
&patches;
&testing;
&i18n;
&tools;
</part>
@ -50,15 +51,20 @@
<title>Wine Architecture</title>
&architecture;
&dlls;
&debugging;
&ole;
&opengl;
&build;
&dlls;
&opengl;
&multimedia;
</part>
<part id="part-three">
<title>Using CVS</title>
&cvs;
</part>
<part id="part-four">
<title>Advanced Topics</title>
&implementation;
&porting;

47
documentation/wine-doc.sgml
View File

@ -7,6 +7,7 @@
<!-- *** Entities for Wine User Guide *** -->
<!entity introduction SYSTEM "introduction.sgml">
<!entity getting SYSTEM "getting.sgml">
<!entity compiling SYSTEM "compiling.sgml">
<!entity installing SYSTEM "installing.sgml">
<!entity configuring SYSTEM "configuring.sgml">
<!entity registry SYSTEM "registry.sgml">
@ -14,26 +15,27 @@
<!entity printing SYSTEM "printing.sgml">
<!entity running SYSTEM "running.sgml">
<!entity bugs SYSTEM "bugs.sgml">
<!entity glossary SYSTEM "glossary.sgml">
<!-- *** Entities for Wine Developer Guide *** -->
<!entity compiling SYSTEM "compiling.sgml">
<!entity debugging SYSTEM "debugging.sgml">
<!entity documentation SYSTEM "documentation.sgml">
<!entity testing SYSTEM "testing.sgml">
<!entity patches SYSTEM "patches.sgml">
<!entity i18n SYSTEM "i18n.sgml">
<!entity porting SYSTEM "porting.sgml">
<!entity architecture SYSTEM "architecture.sgml">
<!entity ole SYSTEM "ole.sgml">
<!entity debugger SYSTEM "debugger.sgml">
<!entity consoles SYSTEM "consoles.sgml">
<!entity implementation SYSTEM "implementation.sgml">
<!entity opengl SYSTEM "opengl.sgml">
<!entity build SYSTEM "build.sgml">
<!entity documentation SYSTEM "documentation.sgml">
<!entity patches SYSTEM "patches.sgml">
<!entity testing SYSTEM "testing.sgml">
<!entity i18n SYSTEM "i18n.sgml">
<!entity tools SYSTEM "tools.sgml">
<!entity architecture SYSTEM "architecture.sgml">
<!entity dlls SYSTEM "dlls.sgml">
<!entity cvs-regression SYSTEM "cvs-regression.sgml">
<!entity debugging SYSTEM "debugging.sgml">
<!entity ole SYSTEM "ole.sgml">
<!entity build SYSTEM "build.sgml">
<!entity opengl SYSTEM "opengl.sgml">
<!entity multimedia SYSTEM "multimedia.sgml">
<!entity cvs SYSTEM "cvs.sgml">
<!entity implementation SYSTEM "implementation.sgml">
<!entity porting SYSTEM "porting.sgml">
<!entity consoles SYSTEM "consoles.sgml">
<!entity cvs-regression SYSTEM "cvs-regression.sgml">
<!-- *** Entities for Winelib User Guide *** -->
<!entity winelib-intro SYSTEM "winelib-intro.sgml">
@ -43,7 +45,7 @@
<!entity winelib-bindlls SYSTEM "winelib-bindlls.sgml">
<!entity winelib-packaging SYSTEM "winelib-pkg.sgml">
<!-- *** Entities for Wine Packager Guide *** -->
<!-- *** Entities for Wine Packagers Guide *** -->
<!entity packaging SYSTEM "packaging.sgml">
<!-- *** Entities for Wine FAQ *** -->
@ -74,11 +76,12 @@
&introduction;
&getting;
&compiling;
&installing;
&configuring;
&running;
&bugs;
&glossary;
</book>
<!-- *** Wine Developer Guide *** -->
@ -89,7 +92,6 @@
<part id="part-one">
<title>Developing Wine</title>
&compiling;
&debugger;
&documentation;
&testing;
@ -101,15 +103,20 @@
<part id="part-two">
<title>Wine Architecture</title>
&architecture;
&dlls;
&debugging;
&ole;
&opengl;
&build;
&dlls;
&opengl;
&multimedia;
</part>
<part>
<part id="part-three">
<title>Using CVS</title>
&cvs;
</part>
<part id="part-four">
<title>Advanced Topics</title>
&implementation;
&porting;

5
documentation/wine-user.sgml
View File

@ -6,6 +6,7 @@
<!entity introduction SYSTEM "introduction.sgml">
<!entity getting SYSTEM "getting.sgml">
<!entity compiling SYSTEM "compiling.sgml">
<!entity installing SYSTEM "installing.sgml">
<!entity configuring SYSTEM "configuring.sgml">
<!entity registry SYSTEM "registry.sgml">
@ -13,6 +14,7 @@
<!entity printing SYSTEM "printing.sgml">
<!entity running SYSTEM "running.sgml">
<!entity bugs SYSTEM "bugs.sgml">
<!entity glossary SYSTEM "glossary.sgml">
]>
<book id="index">
@ -22,10 +24,11 @@
&introduction;
&getting;
&compiling;
&installing;
&configuring;
&running;
&bugs;
&glossary;
</book>

24
documentation/winelib-bindlls.sgml
View File

@ -1,5 +1,5 @@
<chapter id="bindlls">
<title id="bindlls.title">Using Linux libraries as dlls</title>
<title id="bindlls.title">Using Linux libraries as DLLs</title>
<sect1 id="bindlls-intro">
<title id="binary-dlls-intro.title">Introduction</title>
<para>
@ -34,9 +34,9 @@
You need to write a spec file that will describe the library's
interface in the same format as a Dll (primarily what functions it
exports). Also you will want to write a small wrapper around the
library. You combine these to form a Wine builtin Dll that links to the
Linux library. Then you modify the Dll Overrides in the wine config
file to ensure that this new builtin dll is called rather than any
library. You combine these to form a Wine built-in Dll that links to the
Linux library. Then you modify the DllOverrides in the wine config
file to ensure that this new built-in DLL is called rather than any
windows version.
</para>
<para>
@ -76,11 +76,11 @@ signed short MyLinuxFunc (unsigned short a, void *b, void *c,
<title id="bindlls-spec.title">Writing the spec file</title>
<para>
Start by writing the spec file. This file will describe the interface
as if it were a dll. See elsewhere for the details of the format of
as if it were a DLL. See elsewhere for the details of the format of
a spec file (e.g. man winebuild).
</para>
<para>
In the simple example we want a Wine builtin Dll that corresponds to
In the simple example we want a Wine built-in Dll that corresponds to
the MyWin Dll. The spec file is <filename>MyWin.dll.spec</filename> and
looks something like this (depending on changes to the way that the
specfile is formatted since this was written).
@ -90,7 +90,7 @@ signed short MyLinuxFunc (unsigned short a, void *b, void *c,
#
# some sort of copyright
#
# Wine spec file for the MyWin.dll builtin library (a minimal wrapper around the
# Wine spec file for the MyWin.dll built-in library (a minimal wrapper around the
# linux library libMyLinux)
#
# For further details of wine spec files see the Winelib documentation at
@ -200,7 +200,7 @@ signed short WINAPI MyProxyWinFunc (unsigned short a, void *b, void *c,
<sect1 id="bindlls-building">
<title id="binary-dlls-building.title">Building</title>
<para>
So how do we actually build the Wine builtin Dll? The easiest way is
So how do we actually build the Wine built-in Dll? The easiest way is
to get Winemaker to do the hard work for us. For the simple example we
have two source files (the wrapper and the spec file). We also have
the 3rd party header and library files of course.
@ -258,18 +258,18 @@ signed short WINAPI MyProxyWinFunc (unsigned short a, void *b, void *c,
</para>
<para>
Put the proxy shared object (MyWin.dll.so) in the same place as the
rest of the builtin dlls. (If you used winemaker to set up your build
rest of the built-in DLLs. (If you used winemaker to set up your build
environment then running "make install" as root should do that for you)
Alternatively ensure that WINEDLLPATH includes the directory containing
the proxy shared object.
</para>
<para>
If you have both a Windows dll and a Linux Dll/proxy pair then you will
If you have both a Windows DLL and a Linux DLL/proxy pair then you will
have to ensure that the correct one gets called. The easiest way is
probably simply to rename the windows version so that it doesn't get
detected. Alternatively you could specify in the DllOverrides section
(or the AppDefaults\\myprog.exe\\DllOverrides section) of the config
file (in your .wine directory) that the builtin version be used. Note
file (in your .wine directory) that the built-in version be used. Note
that if the Windows version Dll is present and is in the same
directory as the executable (as opposed to being in the Windows
directory) then you will currently need to specify the whole path to
@ -293,7 +293,7 @@ signed short WINAPI MyProxyWinFunc (unsigned short a, void *b, void *c,
Suppose you want to convert incoming DOS format filenames to their
Unix equivalent. Of course there is no suitable function in the true
Microsoft Windows API, but wine provides a function for just this
task and exports it from its copy of the kernel32 dll. The function
task and exports it from its copy of the kernel32 DLL. The function
is wine_get_unix_file_name (defined in winbase.h). Use the -ikernel32
option to winemaker to link to it.
</para>

2
documentation/winelib-porting.sgml
View File

@ -366,7 +366,7 @@ printf("Processor architecture=%d\n",si ANONS .wProcessorArchitecture);
<para>
don't use it,
guide on how to replace it with normal C++ code (yes, how???):
extracting a .h and .lib from a COM dll
extracting a .h and .lib from a COM DLL
Can '-fno-rtti' be of some use or even required?
</para>
</sect1>

18
documentation/winelib-toolkit.sgml
View File

@ -59,18 +59,18 @@
files. Let's start with the targets.
</para>
<para>
First are executables and dlls. Each time it finds one of these in
First are executables and DLLs. Each time it finds one of these in
a directory, winemaker puts it in the list of things to build and
will later generate a <filename>Makefile.in</filename> file in this
directory. Note that Winemaker also knows about the commonly used
<filename>Release</filename> and <filename>Debug</filename>
directories, so it will attribute the executables and libraries
found in these to their parent directory. When it finds an
executable or a dll winemaker is happy because these give it more
executable or a DLL winemaker is happy because these give it more
information than the other cases described below.
</para>
<para>
If it does not find any executable or dll winemaker will look for
If it does not find any executable or DLL winemaker will look for
files with a <filename>.mak</filename> extension. If they are not
disguised Visual C++ projects (and currently even if they are),
winemaker will assume that a target by that name should be built
@ -156,7 +156,7 @@
<filename>configure.in</filename>,
<filename>Make.rules.in</filename>). From the above description
you can guess at the items that winemaker may get wrong in
this phase: macro definitions, include path, dll path, dlls to
this phase: macro definitions, include path, DLL path, DLLs to
import, library path, libraries to link with. You can deal with
these issues by using winemaker's <option>-D</>, <option>-P</>,
<option>-i</>, <option>-I</>, <option>-L</> and <option>-l</>
@ -182,11 +182,11 @@
<itemizedlist>
<listitem>
<para>
The target is not importing the right set of dlls, or is not
The target is not importing the right set of DLLs, or is not
being linked with the right set of libraries. You can avoid
this by using winemaker's <option>-P</>, <option>-i</>,
<option>-L</option> and <option>-l</> options or adding these
dlls and libraries to the <filename>Makefile.in</> file.
DLLs and libraries to the <filename>Makefile.in</> file.
</para>
</listitem>
<listitem>
@ -330,7 +330,7 @@ hello_exe_DEPENDS =
</para>
<para>
The <varname>DLLS</> field is where you would enumerate the list of
dlls that executable imports. It should contain the full dll name
DLLs that executable imports. It should contain the full DLL name
including the '.dll' extension, but not the '-l' option.
</para>
<para>
@ -601,7 +601,7 @@ hello.spec.c: hello.res
<term>@</term>
<listitem>
<note><para>
FIXME: You must now export functions from dlls.
FIXME: You must now export functions from DLLs.
</para></note>
<para>
This entry is not shown above because it is not always
@ -672,7 +672,7 @@ init FUNCTION
</programlisting>
<para>
This field is optional and specific to Win32 modules. It
specifies a function which will be called when the dll is loaded
specifies a function which will be called when the DLL is loaded
or the executable started.
</para>