docs/en Makefile.in wineusr-bugs.sgml wineusr- ...
Dimi Paun
dimi at users.sourceforge.net
Mon Oct 17 07:16:25 CDT 2005
ChangeSet ID: 1129551384532239619250507
CVSROOT: /cvsroot/wine
Module name: docs
Changes by: dimi at sc8-pr-cvs1.sourceforge.net 2005/10/17 05:16:24
Modified files:
en : Makefile.in wineusr-bugs.sgml
wineusr-configuring.sgml wineusr-guide.sgml
wineusr-running.sgml
Removed files:
en : wineusr-fonts.sgml wineusr-printing.sgml
wineusr-registry.sgml
Log message:
Brian Vincent <vinn at theshell.com>
Update Winw User Guide to reflect the switch from the
~/.wine/config file to the registry and winecfg.
Remove outdated information about fonts, printing, and registry.
Old revision New revision Changes Path
1.4 1.5 +0 -3 docs/en/Makefile.in
1.4 1.5 +6 -1 docs/en/wineusr-bugs.sgml
1.4 1.5 +727 -2618 docs/en/wineusr-configuring.sgml
1.2 1.3 +0 -3 docs/en/wineusr-guide.sgml
1.2 1.3 +2 -3 docs/en/wineusr-running.sgml
1.2 Removed +0 -0 docs/en/wineusr-fonts.sgml
1.2 Removed +0 -0 docs/en/wineusr-printing.sgml
1.2 Removed +0 -0 docs/en/wineusr-registry.sgml
Index: docs/en/Makefile.in
diff -u -p docs/en/Makefile.in:1.4 docs/en/Makefile.in:1.5
--- docs/en/Makefile.in 17 Oct 2005 12:16:24 -0000
+++ /dev/null 17 Oct 2005 12:16:24 -0000
@@ -8,12 +8,9 @@ DOCLOCALE = en
WINEUSR_SRCS = \
wineusr-bugs.sgml \
wineusr-configuring.sgml \
- wineusr-fonts.sgml \
wineusr-getting.sgml \
wineusr-glossary.sgml \
wineusr-introduction.sgml \
- wineusr-printing.sgml \
- wineusr-registry.sgml \
wineusr-running.sgml
WINEDEV_SRCS = \
Index: docs/en/wineusr-bugs.sgml
diff -u -p docs/en/wineusr-bugs.sgml:1.4 docs/en/wineusr-bugs.sgml:1.5
--- docs/en/wineusr-bugs.sgml 17 Oct 2005 12:16:24 -0000
+++ /dev/null 17 Oct 2005 12:16:24 -0000
@@ -16,7 +16,12 @@
<sect2>
<title>Verify your wine configuration</title>
<para>
- Refer to the <link linkend="config-verify">Configuration verification section</link>
+ Look at the output from <prompt>$ </prompt>
+ <userinput>wine --version</userinput> to make sure you're running
+ a recent version of Wine. Launch winecfg and look over the
+ settings to make sure you have settings that look normal. Look
+ in <filename>~/.wine/dosdevices</filename> to make sure you're
+ c: points to where you think it should.
</para>
</sect2>
Index: docs/en/wineusr-configuring.sgml
diff -u -p docs/en/wineusr-configuring.sgml:1.4 docs/en/wineusr-configuring.sgml:1.5
--- docs/en/wineusr-configuring.sgml 17 Oct 2005 12:16:24 -0000
+++ /dev/null 17 Oct 2005 12:16:24 -0000
@@ -1,2649 +1,756 @@
- <chapter id="config-wine-main">
+<chapter id="config-wine-main">
<title>Configuring Wine</title>
- <para>
- Now that you hopefully managed to successfully install
- the Wine program files,
- this chapter will tell you how to configure the Wine environment
- properly to run your Windows programs.
- </para>
- <para>
- First, we'll give you an overview about which kinds of
- configuration and program execution aspects a fully configured
- Windows environment has to fulfill in order to ensure that many
- Windows programs run successfully without encountering any
- misconfigured or missing items.
- Next, we'll show you which easy helper programs exist
- to enable even novice users to complete the Wine environment
- configuration in a fast and easy way.
- The next section will explain the purpose of the Wine configuration file,
- and we'll list all of its settings.
- After that, the next section will detail the most important and
- unfortunately most difficult configuration part:
- how to configure the file system and DOS drive environment that
- Windows programs need.
- In the last step we'll tell you how to establish a working Windows
- registry base.
- Finally, the remaining parts of this chapter contain descriptions
- of specific Wine configuration items that might also be
- of interest to you.
- </para>
-
- <sect1 id="config-requirements-windows" xreflabel="--Installing Section--">
- <title>What are the requirements of a fully working Windows environment?</title>
-
- <para>
- A Windows installation is a very complex structure. It consists of
- many different parts with very different functionality.
- We'll try to outline the most important aspects of it.
- </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>) directory. Some Windows
- programs 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 program
- asks for a DLL, Wine does not simulate the presence of
- nonexistent files.
- </para>
- </listitem>
- </itemizedlist>
-
- <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.
- </para>
-
- </sect1>
-
- <sect1 id="config-helper-programs">
- <title>Easy configuration helper programs</title>
-
- <para>
- Managing the Wine configuration file settings can be a
- difficult task, sometimes too difficult for some people.
- That's why there are some helper applications for easily setting up an
- initial wine configuration file with useful default settings.
- </para>
-
-
- <sect2 id="config-helper-wineinstall">
- <title>wineinstall</title>
- <para>
- <command>wineinstall</command> is a small configuration tool
- residing as <filename>tools/wineinstall</filename> in a Wine
- source code tree. It has been written to allow for an easy
- and complete compilation/installation of Wine source code for
- people who don't bother with reading heaps of very valuable
- and informative documentation ;-)
- </para>
- <para>
- Once you have successfully extracted the Wine source code
- tree, change to the main directory of it and then run (as
- user):
- </para>
- <screen>
- <prompt>$ </prompt><userinput>./tools/wineinstall</userinput>
- </screen>
- <para>
- Doing so will compile Wine, install Wine and configure the
- Wine environment (either by providing access to a Windows
- partition or by creating a properly configured no-windows
- directory environment).
- </para>
-
- </sect2>
-<!--
- Commenting out until winecfg doesn't actually do something.
- <sect2 id="config-helper-winecfg">
- <title>winecfg</title>
- <para>
- <command>winecfg</command> is a small graphical configuration tool
- residing as <filename>programs/winecfg</filename> in a Wine
- source code tree. It is a Winelib app making use of standard
- Win32 GUI controls to easily customize entries in a Wine
- configuration file.
- </para>
- </sect2>
--->
- </sect1>
-
- <sect1 id="config-verify">
- <title>Verification of correct configuration</title>
-
- <para>
- TODO: After you have finished configuring Wine you can verify
- your Wine configuration by running winecfg.
- This functionality will be added to winecfg
- in the near future.
- </para>
- <para>
- Please check out the
- configuration documentation below to find out more about Wine's
- configuration, or proceed to the <link linkend="bugs">Troubleshooting
- chapter</link>.
- </para>
- </sect1>
-
- <sect1 id="config-file">
- <title>The Wine Configuration File</title>
<para>
- This section is meant to contain both an easy step-by-step introduction
- to the Wine configuration file (for new Wine users)
- and a complete reference to all Wine configuration file settings (for
- advanced users).
- </para>
-
- <sect2>
- <title>Configuration File Introduction</title>
+ Most of the most common configuration changes can be done with the
+ Winecfg tool. We'll go through an easy, step-by-step introduction
+ to Winecfg and outline the options available.
+ In the next section we'll go over more advanced changes you can make
+ using regedit as well as provide a complete reference to all Wine
+ configuration settings. Finally, some things you might want to
+ configure fall out of the scope of Winecfg and regedit, and we'll
+ go over those.
+ </para>
+ <sect1 id="using-winecfg">
+ <title>Using Winecfg</title>
+ <para>
+ In the past, Wine used a special configuration file that could be
+ found in <filename>~/.wine/config</filename>. If you are still using
+ a version of Wine that references this file (older than June, 2005)
+ you should upgrade before doing anything else. All settings are now
+ stored directly in the registry and accessed by Wine when it starts.
+ </para>
+ <para>
+ Winecfg should have been installed on your computer along with the
+ rest of the Wine programs. If you can't figure out how to start it,
+ try running the command:
+ <prompt>$ </prompt><userinput>/usr/local/bin/winecfg</userinput>
+ </para>
<para>
- The Wine configuration file is the central file to store
- configuration settings for Wine.
- This file (which is called <filename>config</filename>)
- can be found in the sub directory <filename>.wine/</filename>
- of your user's home directory
- (directory <filename>/home/user/</filename>). In other words, the Wine
- configuration file is <filename>~/.wine/config</filename>.
- Note that since the Wine configuration file is a part of the
- Wine registry file system, this file also
- <emphasis>requires</emphasis> a correct "WINE REGISTRY
- Version 2" header line to be recognized properly, just like
- all other Wine registry text files (just in case you decided
- to write your own registry file from scratch and wonder why
- Wine keeps rejecting it).
+ or possibly just:
+ <prompt>$ </prompt><userinput>winecfg</userinput>
</para>
<para>
- The settings available in the configuration file include:
+ When the program starts you'll notice there are tabs along the top
+ of the window for:
<itemizedlist>
<listitem>
<para>
- Directory settings
+ Applications
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Libraries
</para>
</listitem>
<listitem>
<para>
- Port settings
+ Graphics
</para>
</listitem>
<listitem>
<para>
- The Wine look and feel
+ Appearance
</para>
</listitem>
<listitem>
<para>
- Wine's DLL usage
+ Drives
</para>
</listitem>
<listitem>
<para>
- Wine's multimedia drivers and DLL configuration
+ Audio
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ About
</para>
</listitem>
</itemizedlist>
</para>
+ <para>
+ Changing settings in the
+ <emphasis>Applications</emphasis> and <emphasis>Libraries</emphasis>
+ tab will have the most impact on getting an application to run. The
+ other settings focus on getting Wine itself to behave the way
+ you want it to.
+ </para>
+ <para>
+ Note: The Applications, Libraries, and Graphics tabs are linked
+ together! If you have Default Settings selected under Applications,
+ all of the changes made within the Libraries and Graphics tabs will
+ be changed for all applications. If you've configured a specfic
+ application under the Applications tab and have it selected, then
+ any changes made in Libraries or Graphics will affect only that
+ application. This allows for custom settings for specific
+ applications.
+ </para>
+ <sect2 id="config-windows-versions">
+ <title>Application Settings</title>
+ <para>
+ Wine has the ability to mimic the behavior of different versions of
+ Windows. In general, the biggest difference is whether Wine
+ behaves as a Win9x version or an NT version. Some applications
+ require a specific behavior in order to function and changing
+ this setting may cause a buggy app to work. Recently Wine's
+ default Windows version has changed to Windows 2000. It's known
+ that many applications will perform better if you choose Windows
+ 98.
+ </para>
+ <para>
+ Within the tab you'll notice there is a
+ <emphasis>Default Settings</emphasis> entry. If you select that
+ you'll see the current default <emphasis>Windows Version</emphasis>
+ for all applications. A troublesome application
+ is best configured separately from the Default Settings. To do that:
+ <orderedlist>
+ <listitem>
+ <para>
+ Click on the <emphasis>Add application</emphasis> button.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Browse until you locate the .exe
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ After it's been added you can choose the specific Windows
+ version Wine will emulate for that application.
+ </para>
+ </listitem>
+ </orderedlist>
+ </para>
</sect2>
-
<sect2>
- <title>Creating Or Modifying The Configuration File</title>
+ <title>Libraries Settings</title>
<para>
- If you just installed Wine for the first time and want to
- finish Wine installation by configuring it now, then you could
- use our sample configuration file <filename>config</filename>
- (which can be found in the directory
- <filename>documentation/samples/</filename> of the Wine source
- code directory) as a base for adapting the Wine configuration
- file to the settings you want.
- First, I should mention that you should not forget to make
- sure that any previous configuration file at
- <filename>~/.wine/config</filename> has been safely moved out
- of the way instead of simply overwriting it when you will now
- copy over the sample configuration file.
+ Likewise, some applications require specific libraries in order
+ to run. Wine reproduces the Windows system libraries (so-called
+ native DLL's) with completely custom versions designed to
+ function exactly the same way but without requiring licenses
+ from Microsoft. Wine has many known deficiencies in it's
+ built-in versions, but in many instances the functionality
+ is sufficient. Using only builtin DLL's ensures that your
+ system is Microsoft-free. However, Wine has the ability to
+ load native Windows DLL's.
</para>
- <para>
- If you don't have a pre-existing configuration file and thus
- need to copy over our sample configuration file to the
- standard Wine configuration file location, do in a
- <glossterm>terminal</glossterm>:
- <screen>
- <prompt>$ </><userinput>mkdir ~/.wine/</>
- <prompt>$ </><userinput>cp <replaceable>dir_to_wine_source_code</replaceable>/documentation/samples/config ~/.wine/config</>
- </screen>
- Otherwise, simply use the already existing configuration file
- at <filename>~/.wine/config</filename>.
- </para>
- <para>
- Now you can start adapting the configuration file's settings with an
- <glossterm>editor</glossterm> according to the documentation
- below.
- Note that you should <emphasis>only</emphasis> change
- configuration file settings if wineserver is not running (in
- other words: if your user doesn't have a Wine session running),
- otherwise Wine won't use them - and even worse, wineserver will
- overwrite them with the old settings once wineserver quits!!
- </para>
- </sect2>
-
- <sect2 id="config-file-how">
- <title>What Does It Contain?</title>
-
- <para>
- Let's start by giving an overview of which sections a
- configuration file may contain, and whether the inclusion of
- the respective section is <emphasis>needed</emphasis> or only <emphasis>recommended</emphasis> ("recmd").
- </para>
-
- <informaltable frame="all">
- <tgroup cols="3">
- <thead>
- <row>
- <entry>Section Name</entry>
- <entry>Needed?</entry>
- <entry>What it Does</entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry>[wine]</entry>
- <entry>yes</entry>
- <entry>General settings for Wine</entry>
- </row>
- <row>
- <entry>[DllOverrides]</entry>
- <entry>recmd</entry>
- <entry>Overrides defaults for DLL loading</entry>
- </row>
- <row>
- <entry>[x11drv]</entry>
- <entry>recmd</entry>
- <entry>Graphics driver settings</entry>
- </row>
- <row>
- <entry>[fonts]</entry>
- <entry>yes</entry>
- <entry>Font appearance and recognition</entry>
- </row>
- <row>
- <entry>[ppdev]</entry>
- <entry>no</entry>
- <entry>Parallelport emulation</entry>
- </row>
- <row>
- <entry>[spooler]</entry>
- <entry>no</entry>
- <entry>Print spooling</entry>
- </row>
- <row>
- <entry>[ports]</entry>
- <entry>no</entry>
- <entry>Direct port access</entry>
- </row>
- <row>
- <entry>[Debug]</entry>
- <entry>no</entry>
- <entry>What to do with certain debug messages</entry>
- </row>
- <row>
- <entry>[Registry]</entry>
- <entry>no</entry>
- <entry>Specifies locations of windows registry files</entry>
- </row>
- <row>
- <entry>[programs]</entry>
- <entry>no</entry>
- <entry>Programs to be run automatically</entry>
- </row>
- <row>
- <entry>[Console]</entry>
- <entry>no</entry>
- <entry>Console settings</entry>
- </row>
- <row>
- <entry>[Clipboard]</entry>
- <entry>no</entry>
- <entry>Interaction for Wine and X11 clipboard</entry>
- </row>
- <row>
- <entry>[afmdirs]</entry>
- <entry>no</entry>
- <entry>Postscript driver settings</entry>
- </row>
- <row>
- <entry>[WinMM]</entry>
- <entry>yes</entry>
- <entry>Multimedia settings</entry>
- </row>
- <row>
- <entry>[AppDefaults]</entry>
- <entry>no</entry>
- <entry>Overwrite the settings of previous sections for special programs</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>
- Now let's explain the configuration file sections in a
- detailed way.
- </para>
-
- <sect3 id="config-wine">
- <title>The [wine] Section </title>
- <para>
- The [wine] section of the configuration file contains basic settings for Wine.
- </para>
- <para>
- <programlisting>
-"Windows" = "c:\\windows"
-"ShowDirSymlinks" = "1"
-"ShowDotFiles" = "1"
- </programlisting>
- For a detailed description of drive layer configuration and
- the meaning of these parameters, please look at the <link
- linkend="config-drive-main">Disc Drives, Serial and Parallel
- Ports section</link>.
- </para>
- <para>
- <programlisting>"GraphicsDriver" = "x11drv|ttydrv"</programlisting>
- Sets the graphics driver to use for Wine output.
- x11drv is for X11 output, ttydrv is for text console output.
- WARNING: if you use ttydrv here, then you won't be able to run
- a lot of Windows GUI programs (ttydrv is still pretty "broken"
- at running graphical apps). Thus this option is mainly interesting
- for e.g. embedded use of Wine in web server scripts.
- Note that ttydrv is still very lacking, so if it doesn't work,
- resort to using "xvfb", a virtual X11 server.
- Another way to run Wine without display would be to run X11
- via Xvnc, then connect to that VNC display using xvncviewer
- (that way you're still able to connect to your app and
- configure it if need be).
- </para>
- <para>
- <programlisting>"Printer" = "off|on"</programlisting> Tells wine
- whether to allow printing via printer drivers to work.
- This option isn't needed for our built-in psdrv printer driver
- at all.
- Using these things are pretty alpha, so you might want to
- watch out. Some people might find it useful, however. If
- you're not planning to work on printing via windows printer
- drivers, don't even add this to your wine configuration file
- (It probably isn't already in it).
- Check out the [spooler] and [parallelports] sections too.
- </para>
- <para>
- <programlisting>"ShellLinker" = "wineshelllink"</programlisting>
- This setting specifies the shell linker script to use for setting
- up Windows icons in e.g. KDE or Gnome that are given by programs
- making use of appropriate shell32.dll functionality to create
- icons on the desktop/start menu during installation.
- </para>
- <para>
- <programlisting>"SymbolTableFile" = "wine.sym"</programlisting>
- Sets up the symbol table file for the wine debugger. You
- probably don't need to fiddle with this. May be useful if
- your wine is stripped.
- </para>
- </sect3>
-
- <sect3 id="config-dlloverrides">
- <title>The [DllOverrides] Section</title>
- <para>
- The format for this section is the same for each line:
- <programlisting><DLL>{,<DLL>,<DLL>...} = <FORM>{,<FORM>,<FORM>...}</programlisting>
- For example, to load built-in KERNEL pair (case doesn't
- matter here):
- <programlisting>"kernel,kernel32" = "builtin"</programlisting>
- To load the native COMMDLG pair, but if that doesn't work
- try built-in:
- <programlisting>"commdlg,comdlg32" = "native, builtin"</programlisting>
- To load the native COMCTL32:
- <programlisting>"comctl32" = "native"</programlisting>
- Here is a good generic setup (As it is defined in config
- that was included with your wine package):
- <programlisting>
-[DllOverrides]
-"rpcrt4" = "builtin, native"
-"oleaut32" = "builtin, native"
-"ole32" = "builtin, native"
-"commdlg" = "builtin, native"
-"comdlg32" = "builtin, native"
-"ver" = "builtin, native"
-"version" = "builtin, native"
-"shell" = "builtin, native"
-"shell32" = "builtin, native"
-"shfolder" = "builtin, native"
-"shlwapi" = "builtin, native"
-"shdocvw" = "builtin, native"
-"lzexpand" = "builtin, native"
-"lz32" = "builtin, native"
-"comctl32" = "builtin, native"
-"commctrl" = "builtin, native"
-"advapi32" = "builtin, native"
-"crtdll" = "builtin, native"
-"mpr" = "builtin, native"
-"winspool.drv" = "builtin, native"
-"ddraw" = "builtin, native"
-"dinput" = "builtin, native"
-"dsound" = "builtin, native"
-"opengl32" = "builtin, native"
-"msvcrt" = "native, builtin"
-"msvideo" = "builtin, native"
-"msvfw32" = "builtin, native"
-"mcicda.drv" = "builtin, native"
-"mciseq.drv" = "builtin, native"
-"mciwave.drv" = "builtin, native"
-"mciavi.drv" = "native, builtin"
-"mcianim.drv" = "native, builtin"
-"msacm.drv" = "builtin, native"
-"msacm" = "builtin, native"
-"msacm32" = "builtin, native"
-"midimap.drv" = "builtin, native"
-; you can specify programs too
-"notepad.exe" = "native, builtin"
-; default for all other DLLs
-"*" = "native, builtin"
- </programlisting>
- </para>
- <note>
- <para>
- If loading of the libraries that are listed first fails,
- wine will just go on by using the second or third option.
- </para>
- </note>
- </sect3>
-
- <sect3 id="config-fonts">
- <title>The [fonts] Section</title>
- <para>
- This section sets up wine's font handling.
- </para>
- <para>
- <programlisting>"Resolution" = "96"</programlisting>
- Since the way X handles fonts is different from the way
- Windows does, wine uses a special mechanism to deal with
- them. It must scale them using the number defined in the
- "Resolution" setting. 60-120 are reasonable values, 96 is
- a nice in the middle one. If you have the real windows
- fonts available , this parameter will not be as
- important. Of course, it's always good to get your X fonts
- working acceptably in wine.
- </para>
- <para>
- <programlisting>"Default" = "-adobe-times-"</programlisting>
- The default font wine uses. Fool around with it if you'd like.
- </para>
- <para>
- OPTIONAL:
- </para>
- <para>
- The <literal>Alias</literal> setting allows you to map an X font to a font
- used in wine. This is good for apps that need a special font you don't have,
- but a good replacement exists. The syntax is like so:
- <programlisting>"AliasX" = "[Fake windows name],[Real X name]"<,optional "masking" section></programlisting>
- Pretty straightforward. Replace "AliasX" with "Alias0",
- then "Alias1" and so on. The fake windows name is the name
- that the font will be under a windows app in wine. The
- real X name is the font name as seen by X (Run
- "xfontsel"). The optional "masking" section allows you to
- utilize the fake windows name you define. If it is not
- used, then wine will just try to extract the fake windows
- name itself and not use the value you enter.
- </para>
- <para>
- Here is an example of an alias without masking. The font will show up in windows
- apps as "Google".
- <programlisting>"Alias0" = "Foo,--google-"</programlisting>
- Here is an example with masking enabled. The font will show up as "Foo" in
- windows apps.
- <programlisting>"Alias1" = "Foo,--google-,subst"</programlisting>
- For more information check out the <link linkend="config-fonts-main">Fonts</link>
- chapter.
- </para>
- </sect3>
-
- <sect3 id="config-io">
- <title>The [spooler] and [ports] Sections</title>
- <para>
- The [spooler] section will inform wine where to spool
- print jobs. Use this if you want to try printing. Wine
- docs claim that spooling is "rather primitive" at this
- time, so it won't work perfectly. <emphasis>It is optional.</emphasis> The only
- setting you use in this section works to map a port (LPT1,
- for example) to a file or a command. Here is an example,
- mapping LPT1 to the file <filename>out.ps</filename>:
- <programlisting>"LPT1:" = "out.ps"</programlisting>
- The following command maps printing jobs to LPT1 to the
- command <command>lpr</command>. Notice the |:
- <programlisting>"LPT1:" = "|lpr"</programlisting>
- The [ports] section is usually useful only for people who
- need direct port access for programs requiring dongles or
- scanners. <emphasis>If you don't need it, don't use
- it!</emphasis>
- </para>
- <para>
- <programlisting>"read" = "0x779,0x379,0x280-0x2a0"</programlisting>
- Gives direct read access to those IO's.
- </para>
- <para>
- <programlisting>"write" = "0x779,0x379,0x280-0x2a0"</programlisting>
- Gives direct write access to those IO's. It's probably a
- good idea to keep the values of the
- <literal>read</literal> and <literal>write</literal>
- settings the same. This stuff will only work when you're
- root.
- </para>
- </sect3>
-
- <sect3 id="config-debug-etc">
- <title>The [Debug], [Registry], and [programs] Sections</title>
- <para>
- [Debug] is used to include or exclude debug messages, and to
- output them to a file. The latter is rarely used. <emphasis>These
- are all optional and you probably don't need to add or
- remove anything in this section to your config.</emphasis> (In extreme
- cases you may want to use these options to manage the amount
- of information generated by <parameter>WINEDEBUG=+relay
- </parameter> )
- </para>
- <para>
- <programlisting>"File" = "/blanco"</programlisting>
- Sets the logfile for wine. Set to CON to log to standard out.
- <emphasis>This is rarely used.</emphasis>
- </para>
- <para>
- <programlisting>"SpyExclude" = "WM_SIZE;WM_TIMER;"</programlisting>
- Excludes debug messages about <constant>WM_SIZE</constant>
- and <constant>WM_TIMER</constant> in the logfile.
- </para>
- <para>
- <programlisting>"SpyInclude" = "WM_SIZE;WM_TIMER;"</programlisting>
- Includes debug messages about <constant>WM_SIZE</constant>
- and <constant>WM_TIMER</constant> in the logfile.
- </para>
- <para>
- <programlisting>"RelayInclude" = "user32.CreateWindowA;comctl32.*"</programlisting>
- Include only the listed functions in a
- <parameter>WINEDEBUG=+relay</parameter> trace. This entry is
- ignored if there is a <parameter>RelayExclude</parameter> entry.
- </para>
- <para>
- <programlisting>"RelayExclude" = "RtlEnterCriticalSection;RtlLeaveCriticalSection"</programlisting>
- Exclude the listed functions in a
- <parameter>WINEDEBUG=+relay</parameter> trace. This entry
- overrides any settings in a <parameter>RelayInclude</parameter>
- entry. If neither entry is present then the trace includes
- everything.
- </para>
- <para>
- In both entries the functions may be specified either as a
- function name or as a module and function. In this latter
- case specify an asterisk for the function name to include/exclude
- all functions in the module.
- </para>
- <para>
- [Registry] can be used to tell wine where your old windows
- registry files exist. This section is completely optional
- and useless to people using wine without an existing
- windows installation.
- </para>
- <para>
- <programlisting>"UserFileName" = "/dirs/to/user.reg"</programlisting>
- The location of your old <filename>user.reg</filename> file.
- </para>
- <para>
- [programs] can be used to say what programs run under
- special conditions.
- </para>
- <para>
- <programlisting>"Default" = "/program/to/execute.exe"</programlisting>
- Sets the program to be run if wine is started without specifying a program.
- </para>
- <para>
- <programlisting>"Startup" = "/program/to/execute.exe"</programlisting>
- Sets the program to automatically be run at startup every time.
- </para>
- </sect3>
-
- <sect3 id="config-winmm">
- <title>The [WinMM] Section</title>
- <para>
- [WinMM] is used to define which multimedia drivers have to be loaded. Since
- those drivers may depend on the multimedia interfaces available on your system
- (OSS, ALSA... to name a few), it's needed to be able to configure which driver
- has to be loaded.
- </para>
-
- <para>
- The content of the section looks like:
- <programlisting>
-[WinMM]
-"Drivers" = "wineoss.drv"
-"WaveMapper" = "msacm.drv"
-"MidiMapper" = "midimap.drv"
- </programlisting>
- All the keys must be defined:
- <itemizedlist>
- <listitem>
- <para>
- The "Drivers" key is a ';' separated list of modules name, each of
- them containing a low level driver. All those drivers will be loaded
- when MMSYSTEM/WINMM is started and will provide their inner features.
- </para>
- </listitem>
- <listitem>
- <para>
- The "WaveMapper" represents the name of the module containing the Wave
- Mapper driver. Only one wave mapper can be defined in the system.
- </para>
- </listitem>
- <listitem>
- <para>
- The "MidiMapper" represents the name of the module containing the MIDI
- Mapper driver. Only one MIDI mapper can be defined in the system.
- </para>
- </listitem>
- </itemizedlist>
- </para>
- </sect3>
-
- <sect3 id="config-network">
- <title>The [Network] Section</title>
- <para>
- [Network] contains settings related to
- networking. Currently there is only one value that can be set.
- </para>
- <variablelist>
- <varlistentry>
- <term>UseDnsComputerName</term>
- <listitem>
- <para>
- A boolean setting (default: <literal>Y</literal>)
- that affects the way Wine sets the computer name. The computer
- name in the Windows world is the so-called <emphasis>NetBIOS name</emphasis>.
- It is contained in the <varname>ComputerName</varname> in the registry entry
- <varname>HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\ComputerName\ComputerName</varname>.
- </para>
- <para>
- If this option is set to "Y" or missing, Wine will set the
- NetBIOS name to the Unix host name of your computer, if
- necessary truncated to 31 characters. The Unix hostname is the output
- of the shell command <command>hostname</command>, up to but not
- including the first dot ('.'). Among other things, this means that
- Windows programs running under Wine cannot change the NetBIOS computer name.
- </para>
- <para>
- If this option is set to "N", Wine will use the registry value above
- to set the NetBIOS name. Only if the registry entry doesn't exist (usually
- only during the first wine startup) it will use the Unix hostname as
- usual. Windows programs can change the NetBIOS name. The change
- will be effective after a "reboot", i.e. after restarting Wine.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- </sect3>
-
- <sect3 id="config-appdefaults">
- <title>The [AppDefaults] Section</title>
- <para>
- The section is used to overwrite certain settings of this file for a
- special program with different settings.
- [AppDefaults] is not the real name of the section. The real name
- consists of the leading word AppDefaults followed by the name
- of the executable the section is valid for.
- The end of the section name is the name of the
- corresponding "standard" section of the configuration file
- that should have some of its settings overwritten with the
- program specific settings you define.
- The three parts of the section name are separated by two backslashes.
- </para>
- <para>
- Currently wine supports overriding selected settings within
- the sections [DllOverrides], [x11drv], [version] and [dsound] only.
- </para>
+ <sect3>
+ <title>DLL Overrides</title>
<para>
- Here is an example that overrides the normal settings for a
- program:
- <programlisting>
-;; default settings
-[x11drv]
-"Managed" = "Y"
-"Desktop" = "N"
-
-;; run install in desktop mode
-[AppDefaults\\install.exe\\x11drv]
-"Managed" = "N"
-"Desktop" = "800x600"
- </programlisting>
- </para>
- </sect3>
+ It's not always possible to run an application on builtin
+ DLL's. Sometimes native DLL's simply work better. After
+ you've located a native DLL on a Windows system, you'll
+ need to place it in suitable place for Wine to find it
+ and then configure it to be used. Generally the place
+ you need to put it is in the directory you've configured
+ to be <filename>c:\windows\system</filename> (more on that in
+ the drives section). There are four DLL's you should never
+ try to use the native versions of:
+ <filename>kernel32.dll</filename>,
+ <filename>gdi32.dll</filename>,
+ <filename>user32.dll</filename>,
+ and <filename>ntdll.dll</filename>. These libraries require
+ low-level Windows kernel access that simply doesn't exist
+ within Wine.
+ </para>
+ <para>
+ With that in mind, once you've copied the DLL you just need to
+ tell Wine to try to use it. You can configure Wine to choose
+ between native and builtin DLL's at two different levels.
+ If you have <emphasis>Default Settings</emphasis> selected
+ in the <emphasis>Applications</emphasis> tab, the changes you
+ make will affect all applications. Or, you can override the
+ global settings on a per-application level by adding and
+ selecting an application in the <emphasis>Applications</emphasis>
+ tab.
+ </para>
+ <para>
+ To add an override for FOO.DLL, enter "FOO" into the box
+ labeled <emphasis>New override for library:</emphasis> and
+ click on the <emphasis>Add</emphasis> button. To change how
+ the DLL behaves, select it within the <emphasis>Existing
+ overrides:</emphasis> box and choose <emphasis>Edit</emphasis>.
+ By default the new load order will be native Windows libraries
+ before Wine's own builtin ones (<emphasis>Native then
+ Builtin</emphasis>). You can also choose native only, builtin
+ only, or disable it altogether.
+ </para>
+ </sect3>
+ <sect3>
+ <title>Notes About System DLL's</title>
+ <para>
+ The Wine team has determined that it is necessary to create fake DLL
+ files to trick many programs 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 c:\windows\system directory
+ to make the program think it's there, and Wine's built-in DLL will
+ be loaded when the program actually asks for it. (Unfortunately,
+ tools/wineinstall does not create such empty files itself.)
+ </para>
+ <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>
+ 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
+ copy 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.
+ </para>
+ </sect3>
+ <sect3>
+ <title>Missing DLL's</title>
+ <para>
+ In case Wine complains about a missing DLL, you should check whether
+ this file is a publicly available DLL or a custom DLL belonging
+ to your program (by searching for its name on the internet).
+ After you've located the DLL, you need to make sure Wine is able to
+ use it. DLLs usually get loaded in the following order:
+ <orderedlist>
+ <listitem>
+ <para>
+ The directory the program was started from.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The current directory.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The Windows system directory.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The Windows directory.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The PATH variable directories.
+ </para>
+ </listitem>
+ </orderedlist>
+ In short: either put the required DLL into your program
+ directory (might be ugly), or put it into the Windows system
+ directory. Also, if possible you probably shouldn't use NT-based
+ native DLLs, since Wine's NT API support is somewhat weaker than
+ its Win9x API support (possibly leading to even worse compatibility
+ with NT DLLs than with a no-windows setup!).
+ </para>
+ </sect3>
+ </sect2>
+ <sect2>
+ <title>Graphics Settings</title>
+ <para>
+ There are basically five different graphics settings you
+ can configure. For most people the defaults are fine.
+ </para>
+ <para>
+ The first is the "screen color depth" and
+ represents the number of colors that can be displayed on the
+ screen. Older graphics cards had a hard time displaying a
+ full-range of colors and for them it's useful to be able to
+ specify an "8-bit" display. Modern video cards, namely anything
+ with over 8MB of memory, have no problem using a full 24 or 32-bit
+ depth.
+ </para>
+ <para>
+ The next few settings primarily affect games and are somewhat
+ self-explanatory. You can prevent the mouse from leaving the
+ window of a DirectX program (i.e. a game.) and the default is
+ to have that box checked. There's lots of
+ reasons you might want to do that, not the least of which
+ includes it's easier to play the game if the cursor is
+ confined to a smaller area. The other reason to turn this
+ option on is for more precise control of the mouse - Wine
+ warps the location of the mouse to mimic the way Windows
+ works. Similarly, "desktop double buffering" allows for
+ smoother updates to the screen, which games can benefit from,
+ and the default is to leave it turned on. The tradeoff is
+ increased memory use.
+ </para>
+ <para>
+ You may find it helpful to <emphasis>Emulate a virtual
+ desktop</emphasis>.
+ In this case, all programs will run in a separate window. You
+ may find this useful as a way to test buggy games that change
+ (possibly unsuccessfully) the screen resolution. Confining them
+ to a window can allow for more control over them at the possible
+ expense of decreased usability. Sizes you might want to try are
+ 640x480 (the default) or 800x600.
+ </para>
+ <para>
+ Finally, you can configure some Direct3D settings. For the
+ most part these settings are detected automatically, but you
+ can force them to behave in a specific manner. Some games
+ attempt to probe the underlying system to see if it supports
+ specific features. By turning these off Wine won't report
+ the ability to render games in a certain way. It may lead
+ to the game running faster at the expense of the quality of
+ the graphics or the game may not run at all.
+ </para>
+ </sect2>
+ <sect2>
+ <title>Drive Settings</title>
+ <para>
+ Windows requires a fairly rigid drive configuration that Wine
+ imitates. Most people are familiar with the standard notation
+ of the "A:" drive representing the floppy disk, the "C:"
+ drive representing the primary system disk, etc. Wine uses
+ the same concept and maps those drives to the underlying native
+ filesystem.
+ </para><para>
+ Wine's drive configuration is relatively simple.
+ In Winecfg under the <emphasis>Drives</emphasis> tab you'll
+ see buttons to add and remove available drives.
+ When you choose to add a drive, a new entry will be made
+ and a default drive mapping will appear. You can change where
+ this drives points to by changing what's in the
+ <emphasis>Path:</emphasis> box. If you're unsure of the
+ exact path you can choose "Browse" to search for it.
+ Removing a drive is as easy as selecting the drive and
+ clicking "Remove".
+ </para><para>
+ Winecfg has the ability to automatically detect the drives
+ available on your system. It's recommended you try this
+ before attempting to configure drives manually. Simply
+ click on the <emphasis>Autodetect</emphasis> button to
+ have Wine search for drives on your system.
+ </para><para>
+ You may be interested in configuring your drive settings
+ outside of Winecfg, in which case you're in luck because it's
+ quite easy. All of the drive settings reside in a special
+ directory, <filename>~/.wine/dosdevices</filename>. Each "drive"
+ is simply a link to where it actually resides. Wine automatically
+ sets up two drives the first time you run Wine:
+ </para>
+ <programlisting>
+ $ ls -la ~/.wine/dosdevices/
+ lrwxrwxrwx 1 wineuser wineuser 10 Jul 23 15:12 c: -> ../drive_c
+ lrwxrwxrwx 1 wineuser wineuser 1 Jul 23 15:12 z: -> /
+ </programlisting>
+ <para>
+ To add another drive, for example your CD-ROM, just create a new
+ link pointing to it:
+ <prompt>$ </prompt>
+ <userinput>ln -s /mnt/cdrom ~/.wine/dosdevices/d:</userinput>
+ Take note of the DOS-style naming convention used for links -
+ the format is a letter followed by a colon, such as "a:". So,
+ if the link to your c: drive points to
+ <filename> ~/.wine/drive_c</filename>, you
+ can interpret references to <filename>c:\windows\system</filename>
+ to mean <filename> ~/.wine/drive_c/windows/system</filename>.
+ </para>
+ </sect2>
+ <sect2>
+ <title>Audio Settings</title>
+ <para>
+ Wine can work with quite a few different audio subsystems
+ which you can choose under the "Audio" tab. The
+ "Autodetect" button can figure it all out for you, or you can
+ manually select a driver. Older
+ Linux distributions using the 2.4 kernel or earlier typically
+ use the "OSS" driver. Newer 2.6 kernels have switched to "ALSA".
+ If you're using KDE, regardless of the kernel, you can probably
+ also use "aRts". If you're using GNOME you can probably use
+ EsounD. The OSS and ALSA audio drivers get the most testing, so
+ it's recommended you stick with them if possible.
+ If you need to use "Jack" or "NAS" you probably already know why.
+ </para>
+ <para>
+ DirectSound settings are primarily used by games. You can
+ choose what level of hardware acceleration you'd like, but
+ for most people "Full" is fine.
+ </para>
</sect2>
-
- <sect2 id="config-trouble">
- <title>What If It Doesn't Work?</title>
- <para>
- There is always a chance that things will go wrong. If the
- unthinkable happens, report the problem to
- <ulink url="http://bugs.winehq.org/">Wine Bugzilla</ulink>,
- try the newsgroup
- <systemitem>comp.emulators.ms-windows.wine</systemitem>,
- or the IRC channel <systemitem>#WineHQ</systemitem> found on
- irc.freenode.net, or connected servers.
- Make sure that you have looked over this document thoroughly,
- and have also read:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- <filename>README</filename>
- </para>
- </listitem>
- <listitem>
- <para>
- <filename>http://www.winehq.org/trouble/</filename>
- </para>
- </listitem>
- </itemizedlist>
- <para>
- If indeed it looks like you've done your research, be
- prepared for helpful suggestions. If you haven't, brace
- yourself for heaving flaming.
+ <sect2>
+ <title>Appearance</title>
+ <para>
+ Wine can load Windows themes if you have them available. While
+ this certainly isn't necessary in order to use Wine or applications,
+ it does allow you to customize the look and feel of a program. Wine
+ supports the newer MSStyles typ of themese. Unlike the older Microsoft
+ Plus! style themes, the uxtheme engine supports special .msstyles files
+ that can retheme all of the Windows controls. This is more or less the
+ same kind of theming that modern Linux desktops have supported for
+ years. If you'd like to try this out:
+ <orderedlist>
+ <listitem>
+ <para>
+ Download a Windows XP theme. Be sure it contains a .msstyles
+ file.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Create a set of new directories in your fake Windows drive:
+ <prompt>$ </prompt>
+ <userinput>mkdir -p ~/.wine/drive_c/windows/Resources/themes/name-of-your-theme</userinput>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Move the .msstyles to that new name-of-your-theme directory.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Use the new Appearance tab of winecfg to select the new theme.
+ </para>
+ </listitem>
+ </orderedlist>
</para>
</sect2>
</sect1>
-
- <sect1 id="config-drive-main">
- <title>Disc Drives, Serial and Parallel Ports</title>
- <sect2>
- <title>Extremely Important Prerequisites</title>
- <para>
- If you're planning to include access to a CD-ROM drive in your Wine
- configuration on Linux, then <emphasis>make sure</emphasis> to add
- the <quote>unhide</quote> mount option to the CD-ROM file system
- entry in <filename>/etc/fstab</filename>, e.g.:
- <programlisting>/dev/cdrom /cdrom iso9660 ro,noauto,users,unhide 0 0</programlisting>
- Several Windows program setup CD-ROMs or other CD-ROMs chose
- to do such braindamaged things as marking very important setup
- helper files on the CD-ROM as <quote>hidden</quote>.
- That's no problem on Windows, since the Windows CD-ROM driver by
- default displays even files that are supposed to be
- <quote>hidden</quote>. But on Linux, which chose to
- <emphasis>hide</emphasis> <quote>hidden</quote> files on CD by
- default, this is <emphasis>FATAL</emphasis>!
- (the programs will simply abort with an <quote>installation file not found</quote> or similar error)
- Thus you should never forget to add this setting.
- </para>
+ <sect1 id="using-regedit">
+ <title>Using the Registry and Regedit</title>
+ <para>
+ All of the settings you change in Winecfg, with exception of
+ the drive settings, are ultimately stored in the registry.
+ In Windows, this is a central repository for the configuration
+ of applications and the operating system. Likewise, Wine
+ implements a registry and some settings not found in Winecfg
+ can be changed within it. (There's actually more of a chance
+ you'll need to dip into the registry to change an applications'
+ settings than Wine itself.)
+ </para>
+ <para>
+ Now, the fact that Wine itself uses the registry to store settings
+ has been controversial. Some people argue that it's too much like
+ Windows. To counter this, there's several things to consider.
+ First, it's impossible to avoid implementing a registry simply
+ because applications expect to be able to store their settings there.
+ In order for Wine to store and access settings in a separate
+ configuration file would require a separate set of code to basically
+ do the same thing as the Win32 API's Wine already implements.
+ Finally, unlike Windows, the Wine registry is written in plain text
+ and can be changed using your favorite text editor. While most sane
+ system administrators (and Wine developers) curse madly at the twisted
+ nature of the Windows registry, it is still necessary for Wine to
+ support it somehow.
+ </para>
+ <sect2>
+ <title>Registry Structure</title>
+ <para>
+ Okay.. with that out of the way, let's dig into the registry a bit
+ to see how it's laid out. The Windows registry is an elaborate tree
+ structure, and not even most Windows programmers are fully aware of
+ how the registry is laid out, with its different "hives" and numerous
+ links between them; a full coverage is out of the scope of
+ this document. But here are the basic registry keys you might
+ need to know about for now:
+ </para>
+ <variablelist>
+ <varlistentry>
+ <term>HKEY_LOCAL_MACHINE</term>
+ <listitem>
+ <para>
+ This fundamental root key (in win9x it's stored in the
+ hidden file <filename>system.dat</filename>) contains
+ everything pertaining to the current Windows
+ installation. This is often abbreviated HKLM.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>HKEY_USERS</term>
+ <listitem>
+ <para>
+ This fundamental root key (in win9x it's stored in the
+ hidden file <filename>user.dat</filename>) contains
+ configuration data for every user of the installation.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>HKEY_CLASSES_ROOT</term>
+ <listitem>
+ <para>
+ This is a link to HKEY_LOCAL_MACHINE\Software\Classes.
+ It contains data describing things like file
+ associations, OLE document handlers, and COM classes.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>HKEY_CURRENT_USER</term>
+ <listitem>
+ <para>
+ This is a link to HKEY_USERS\your_username, i.e., your
+ personal configuration.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
</sect2>
-
<sect2>
- <title>Short Introduction</title>
+ <title>Registry Files</title>
<para>
- Windows applications refer to disc drives by letters such as
- <filename>A:</filename>, <filename>B:</filename> and
- <filename>C:</filename>, and to serial and parallel ports by names
- such as <filename>COM1</filename>: and <filename>LPT1:</filename>.
+ Now, what you're probably wondering is how that translates
+ into Wine's structure. The registry layout described above
+ actually lives in four different files within each user's
+ ~/.wine directory:
</para>
+ <variablelist>
+ <varlistentry>
+ <term><filename>system.reg</filename></term>
+ <listitem>
+ <para>
+ This file contains HKEY_LOCAL_MACHINE.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><filename>user.reg</filename></term>
+ <listitem>
+ <para>
+ This file contains HKEY_CURRENT_USER.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><filename>userdef.reg</filename></term>
+ <listitem>
+ <para>
+ This file contains HKEY_USERS\.Default (i.e. the default
+ user settings).
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><filename>wine.userreg</filename></term>
+ <listitem>
+ <para>
+ Wine saves HKEY_USERS to this file (both current and
+ default user), but does not load from it, unless
+ <filename>userdef.reg</filename> is missing.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
<para>
- You need to tell Wine how to interpret these. You do so by
- specifying the Unix file system nodes and devices that Wine
- should map them onto, as described later in this section.
+ These files are automatically created by
+ <filename>wineprefixcreate</filename> the first time you use
+ Wine. A set of global settings is stored in the
+ <filename>c:\windows\inf\wine.inf</filename> and is processed by the
+ <filename>rundll32.exe</filename> program. The first time you run
+ Wine the <filename>wine.inf</filename> file gets processed to
+ populate the initial registry. For more details, check
+ out the <filename>wineprefixcreate</filename> script to see how
+ it's all done.
+ </para>
+ <para>
+ Like we mentioned, you can edit those .reg files using whatever text
+ editor you want. Just make sure Wine isn't running when you do
+ it, otherwise all of the changes will be lost.
</para>
- <para>
- You can map a Windows fixed disc drive onto any node in your
- Unix file system - this need not be the root node of a drive.
- For example, you could map your Windows drive <filename>C:</filename>
- onto your Unix directory <filename>/usr/share/wine-C</filename>.
- Then the Windows folder <filename>C:\Windows\Fonts</filename> would
- be at <filename>/usr/share/wine-C/Windows/Fonts</filename> in your
- Unix file system.
+ </sect2>
+ <sect2>
+ <title>Using Regedit</title>
+ <para>
+ An easier way to access and change the registry is with the
+ tool <filename>regedit</filename>. Similar to the Windows
+ program it replaces, regedit serves to provide a system level
+ view of the registry containing all of the keys. Simply run
+ <emphasis>regedit</emphasis> and it should pop up. You'll
+ immediately notice that the cryptic keys displayed in the text file
+ are organized in a hierarchical fashion.
+ </para>
+ <para>
+ To navigate through the registry, click on the keys on the
+ left to drill down deeper. To delete a key, click on it and
+ choose "Delete" from the Edit menu. To add a key or value,
+ locate where you want to put it and choose "New" from the
+ Edit menu. Likewise, you modify an existing key by highlighting
+ it in the right-hand window pane and choosing "Modify" from the
+ Edit menu. Another way to perform these same actions is to
+ right-click on the key or value.
+ </para>
+ <para>
+ Of particular interest to Wine users are the settings stored in
+ <filename>HKEY_CURRENT_USER\Software\Wine</filename>. Most of
+ the settings you change within winecfg are written to this area
+ of the registry.
</para>
- <para>
- Make sure that you have assigned drive letters for directories
- that will cover all the items Wine needs to access. These include
- the programs that you run, the data files they need and the Wine
- debugger (in case anything goes wrong).
+ </sect2>
+ <sect2>
+ <title>System Administration Tips</title>
+ <para>
+ With the above file structure, it is possible for a system
+ administrator to configure the system so that a system Wine
+ installation (and applications) can be shared by all the
+ users, and still let the users all have their own personalized
+ configuration. An administrator can, after having installed
+ Wine and any Windows application software he wants the users
+ to have access to, copy the resulting
+ <filename>system.reg</filename> and
+ <filename>user.reg</filename> over to the global registry
+ files (which we assume will reside in
+ <filename>/usr/local/etc</filename> here), with:
</para>
+ <programlisting>
+ cd ~/.wine
+ cp system.reg /usr/local/etc/wine.systemreg
+ cp user.reg /usr/local/etc/wine.userreg
+ </programlisting>
<para>
- It is best to use a number of drive letters, and map them onto
- directories that cover small sections of the file system containing
- the files that Wine will need to access. This is safer than simply
- assigning a single drive letter to the Unix root directory
- <filename></filename>/, which would allow Windows applications to
- access the whole of your Unix file system (subject, of course,
- to Unix permissions). If one of them misbehaved, or if you
- accidentally installed a virus, this might leave you vulnerable.
+ and perhaps even symlink these back to the administrator's
+ account, to make it easier to install apps system-wide later:
</para>
+ <programlisting>
+ ln -sf /usr/local/etc/wine.systemreg system.reg
+ ln -sf /usr/local/etc/wine.userreg user.reg
+ </programlisting>
<para>
- For replaceable media, such as floppy discs and CD-ROMs, you should
- map Windows drive letters onto the mount points for these drives in
- your Unix file system - for example <filename>/mnt/floppy</filename>
- or <filename>/mnt/cdrom</filename>.
+ Note that the <filename>tools/wineinstall</filename> script
+ already does all of this for you, if you install Wine source as root.
+ If you then install Windows applications while logged in as
+ root, all your users will automatically be able to use them.
+ While the application setup will be taken from the global
+ registry, the users' personalized configurations will be saved
+ in their own home directories.
+ </para>
+ <para>
+ But be careful with what you do with the administrator account
+ - if you do copy or link the administrator's registry to the
+ global registry, any user might be able to read the
+ administrator's preferences, which might not be good if
+ sensitive information (passwords, personal information, etc)
+ is stored there. Only use the administrator account to install
+ software, not for daily work; use an ordinary user account for
+ that.
</para>
- <para>
- If your applications access serial and parallel ports directly,
- you should map these onto the corresponding Unix devices
- - for example <filename>/dev/ttyS0</filename> and
- <filename>/dev/lp0</filename>.
+ </sect2>
+ <sect2>
+ <title>Complete List of Regedit Keys</title>
+ <para>
+ For reference sake, we should probably list all of the keys
+ you can change that affect Wine's behavior. For now, we'll
+ describe how to find them all to give you a pointer for
+ generating that list and including it here. Within the
+ Wine source tree:
+ <prompt>$ </prompt><userinput>find . -exec grep "@@" {} \; | grep registry</userinput>
</para>
-
</sect2>
-
- <sect2 id="config-drive-dir">
- <title>Windows Directory Structure</title>
+ </sect1>
+ <sect1 id="misc-things-to-configure">
+ <title>Other Things to Configure</title>
+ <para>
+ This section is meant to cover the rest of the things you can configure.
+ It also serves as a collection of tips and tricks to get the most out
+ of using Wine.
+ </para>
+ <sect2>
+ <title>Serial and Parallel Ports</title>
<para>
- Here's the fundamental layout that Windows programs and
- installers expect and that we thus need to configure properly
- in Wine. Without it, they seldomly operate correctly. If you
- intend to use a no-windows environment (not using an existing
- Windows partition), then it is recommended to use either
- <command>WineSetupTk</command>'s or
- <command>wineinstall</command>'s capabilities to create an
- initial windows directory tree, since creating a directory
- structure manually is tiresome and error-prone.
+ Serial and parallel port configuration is very similar to drive
+ configuration - simply create a symbolic link in
+ <filename>~/.wine/dosdevices</filename> with the name of the
+ device. Windows serial ports follow a naming convention of the
+ word "com" followed by a number, such as
+ <filename>com1</filename>, <filename>com2</filename>, etc.
+ Similarly, parallel ports use "lpt" followed by a number, such as
+ <filename>lpt1</filename>.
+ You should link these directly to the corresponding Unix
+ devices, such as /dev/ttyS0 and /dev/lp0. For example, to configure
+ one serial port and one parallel port, run the following commands:
</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 programs
- Program Files\ Application binaries (.EXE and .DLL files)
-</programlisting>
+ <programlisting>
+ ln -s /dev/ttyS0 com1
+ ln -s /dev/lp0 lpt1
+ </programlisting>
</sect2>
+ <sect2>
+ <title>Network Shares</title>
- <sect2 id="config-drive-sections">
- <title>The dosdevices Directory</title>
- <para>
- The <filename>dosdevices</filename> directory contains the entries
- that tell Wine how to map Windows disc drive letters onto Unix file
- system nodes, and how to map Windows serial and parallel ports onto
- Unix devices. It is located in the <filename>.wine</filename>
- sub-directory of your home directory,
- i.e. <filename>~/.wine/dosdevices</filename>.
- </para>
- <para>
- The entries in the <filename>dosdevices</filename> directory are
- symbolic links to Unix file system nodes and devices. You can
- create them by using the <command>ln</command> command in a Unix
- terminal. Alternatively, many File Managers have the capability of
- creating symbolic links.
- </para>
- <para>
- For example, if you have decided to map your Windows
- <filename>C:</filename> drive onto
- <filename>/usr/share/wine-c</filename>, you could type the
- following (after changing to your <filename>dosdevices</filename>
- directory):
- <programlisting>
-ln -s /usr/share/wine-c c:
- </programlisting>
- </para>
- <para>
- Replaceable media are a little more complicated. In addition to
- creating a link for the file system on the medium, for example:
- <programlisting>
-ln -s /mnt/floppy a:
- </programlisting>
- you also need to create a link for the device itself. Notice that
- this has a double colon after the drive letter:
- <programlisting>
-ln -s /dev/fd0 a::
- </programlisting>
- </para>
- <para>
- For serial and parallel ports, you simply create a link to
- the device; notice that no colon is required after the Windows
- device name:
- <programlisting>
-ln -s /dev/ttyS0 com1
-ln -s /dev/lp0 lpt1
- </programlisting>
- </para>
<para>
Windows shares can are mapped into the <filename>unc/</filename>
directory so anything trying to access
- <filename>\\machinename\some\dir\and\file</filename> will look in
- <filename>~/.wine/dosdevices/unc/machinename/some/dir/and/file</filename>.
+ <filename>\\myserver\some\file</filename> will look in
+ <filename>~/.wine/dosdevices/unc/myserver/some/file/</filename>.
For example, if you used Samba to mount
- <filename>\\machinename\some</filename> on
- <filename>/mnt/smb/machinename/some</filename> then you can do
-
+ <filename>\\myserver\some</filename> on
+ <filename>/mnt/smb/myserver/some</filename> then you can do
<programlisting>
- ln -s /mnt/smb/machinename/some unc/machinename/some
+ ln -s /mnt/smb/myserver/some unc/myserver/some
</programlisting>
to make it available in wine (don't forget to create the unc
directory if it doesn't alrady exist).
</para>
</sect2>
-
<sect2>
- <title>File system settings in the [wine] section</title>
- <para>
- <programlisting>"Windows" = "c:\\windows"</programlisting>
- This tells Wine and Windows programs where the
- <filename>Windows</filename> directory is. It is
- recommended to have this directory somewhere on your
- configured <medialabel>C</medialabel> drive, and it's also
- recommended to just call the directory "windows" (this is
- the default setup on Windows, and some stupid programs
- might rely on this). So in case you chose a "Windows"
- setting of "c:\\windows" and you chose to set up a drive C
- e.g. at <filename>/usr/local/wine_c</filename>, the
- corresponding directory would be
- <filename>/usr/local/wine_c/windows</filename>. Make one
- if you don't already have one. <emphasis>No trailing slash</emphasis> (<emphasis>not</emphasis>
- <filename>C:\\windows\</filename>)! Write access strongly
- recommended, as Windows programs always assume write access
- to the Windows directory!
- </para>
- <para id="dirsymlinks">
- <programlisting>"ShowDirSymlinks" = "1"</programlisting>
- Wine doesn't pass directory symlinks to Windows programs by
- default, as doing so may crash some programs that do
- recursive lookups of whole subdirectory trees
- whenever a directory symlink points back to itself or one of its
- parent directories.
- That's why we disallowed the use of directory symlinks
- and added this setting to reenable ("1") this functionality.
- If you <emphasis>really</emphasis> need Wine to take into
- account symlinked directories, then reenable it, but
- <emphasis>be prepared for crashes</emphasis> in certain
- Windows programs when using the above method! (in other words:
- enabling it is certainly not recommended)
- </para>
- <para>Old Path, Temp, System configuration are now moved into the
- registry. See the <link linkend="environment-variables">Environment
- Variables</link> paragraph.</para>
- </sect2>
-
- <sect2>
- <title>More detailed explanation about file system differences</title>
- <para>
- Windows uses a different (and inferior) way than Unix to describe the
- location of files in a computer. Thus Windows programs also expect
- to find this different way supported by the system.
- Since we intend to run Windows programs on
- a Unix system, we're in trouble, as we need to translate
- between these different file access techniques.
- </para>
+ <title>Fonts</title>
<para>
- Windows uses drive letters to describe drives or
- any other form of storage media and to access files on them.
- For example, common drive names are
- <filename>C:</filename> for the main Windows system partition
- on the first harddisk and <filename>A:</filename> for the
- first floppy drive.
- Also, Windows uses <filename>\</filename> (backslash) as the
- directory separator sign, whereas Unix uses
- <filename>/</filename> (slash).
- Thus, an example document on the first data partition in
- Windows might be accessed by the name of
- <filename>D:\mywork\mydocument.txt</filename>.
- </para>
- <para>
- So much for the Windows way of doing things.
- </para>
- <para>
- Well, the problem is, in Unix there is no such thing as
- <quote>drive letters</quote>. Instead, Unix chose to go the
- much better way of having one single uniform directory tree
- (starting with the root directory
- <filename>/</filename>), which has various storage devices
- such as e.g. harddisk partitions appended at various directory
- locations within the tree (an example would be
- <filename>/data1/mywork</filename>, which is the first data
- partition mounted/attached to a directory called data1 in the
- root directory <filename>/</filename>; mywork is a sub
- directory of the data partition file system that's mounted
- under <filename>/data1</filename>).
- In Unix, the Windows example document mentioned above could e.g.
- be accessed by the name of
- <filename>/data1/mywork/mydocument.txt</filename>,
- provided that the administrator decided to mount (attach) the first
- data partition at the directory /data1 inside the Unix
- directory tree. Note that in Unix, the administrator can
- <emphasis>choose</emphasis> any custom partition location he
- wants (here, <filename>/data1</filename>), whereas in Windows the system
- <emphasis>selects</emphasis> any drive letter it deems
- suitable for the first data partition (here,
- <filename>D:</filename>), and, even worse, if there is some
- change in partition order, Windows automatically
- <emphasis>changes</emphasis> the drive letter, and you might
- suddenly find yourself with a first data partition at drive
- letter <filename>E:</filename>, with all the file naming and
- referencing confusion that entails. Thus, the Windows way of
- using ever-changing drive letters is <emphasis>clearly
- inferior</emphasis> to the Unix way of assigning
- <emphasis>fixed</emphasis> directory tree locations for every
- data storage medium.
- As we'll see soon, fortunately this Windows limitation of
- changing drive letters doesn't affect us in Wine at all, since
- we can properly map <emphasis>never-changing</emphasis> drive letters to <emphasis>fixed</emphasis> locations inside the Unix directory tree (and even if the location of the respective Unix directory changes, we can still simply update the Wine drive mapping to reflect the updated location and at the same time keep the original drive letter).
- </para>
- <para>
- OK, now that we know some theory about Windows and Unix drive
- and filename mapping, it's probably time to ask how Wine
- achieves the magic of mapping a Unix directory location to a
- Windows drive...
- </para>
- <para>
- Wine chose to do the following:
- In Wine, you don't assign some real physical storage medium
- (such as a harddisk partition or similar) to each drive letter
- mapping entry.
- Instead, you choose certain sub directory trees inside the Unix
- directory tree (that starts with <filename>/</filename>) that
- you would like to assign a drive letter to.
- </para>
- <para>
- Note that for every Unix sub directory tree that you intend to
- start Windows programs in, it is <emphasis>absolutely
- required</emphasis> to have a Wine drive mapping entry:
- </para>
- <para>
- For example, if you had a publicly writable <quote>Windows
- directory space</quote> under <filename>/usr/mywine</filename>, then in order to be
- able to access this sub directory tree from Wine, you should
- have a drive mapping entry that maps a certain drive letter
- (for example, let's take drive letter <filename>P:</filename>)
- either to <filename>/usr/mywine</filename> or <filename>/usr</filename> (to also access any directories belonging to the parent directory) or <filename>/</filename> (to also access any directory whatsoever on this system by this drive letter mapping). The DOS drive/directory location to access files in <filename>/usr/mywine</filename> <emphasis>in Wine</emphasis> in these configuration cases would then be <filename>P:\</filename> or <filename>P:\mywine</filename> or <filename>P:\usr\mywine</filename>, respectively.
- </para>
- </sect2>
-
- <sect2 id="config-no-windows">
- <title>Installing Wine Without Windows</title>
-
- <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.
- </para>
- <para>
- Wine has already made enough progress that it may be possible
- to run your target programs without Windows installed. If
- you want to try it, follow these steps:
- </para>
-
- <orderedlist>
- <listitem>
- <para>
- Make a symbolic link in <filename>~/.wine/dosdevices</filename>
- to the directory where you want
- <filename>C:</filename> to be. Refer to the wine man page
- for more information. The directory to be used for emulating
- a <filename>C:</filename> drive will be
- the base directory for some Windows specific directories
- created below.
- </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>
- Run and/or install your programs.
- </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 program with <parameter>WINEDEBUG=+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.DLL/SHELL32.DLL, COMMDLG.DLL/COMDLG32.DLL
- and COMMCTRL.DLL/COMCTL32.DLL
- 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>).
- As of now, it might not be necessary any more to use
- regedit.exe, since Wine has its own regedit Winelib
- application now.
- </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
- (or in case Wine's winhelp implementation in programs/winhelp/
- is not good enough, for example).
- </para>
- </listitem>
- </itemizedlist>
- </sect2>
-
- <sect2 id="config-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="config-drive-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 <emphasis>HIGHLY DISCOURAGE</emphasis> 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 <emphasis>dangerous</emphasis> (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.
+ Font configuration, once a nasty problem, is now much simpler.
+ If you have a collection of TrueType fonts in Windows it's
+ simply a matter of copying the <filename>.ttf</filename> files
+ into <filename>c:\windows\fonts</filename>.
</para>
</sect2>
-
- <sect2 id="config-drive-vfat">
- <title>Dealing With FAT/VFAT Partitions</title>
+ <sect2>
+ <title>Printers</title>
<para>
- This document describes how FAT and
- VFAT file system permissions work in Linux
- with a focus on configuring them for Wine.
+ Wine can interact directly with the CUPS printing system to
+ find the printers available on your system. Configuring
+ printers with Wine is as simple as making sure your CUPS
+ configuration works.
</para>
-
- <sect3>
- <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 programs and their data are accessed
- through Wine for dual boot (Linux + Windows) systems.
- </para>
- <para>
- Wine maps mounted FAT file systems, such as
- <filename>/c</filename>, to drive letters, such as
- <quote>c:</quote>, by means of symbolic links in the
- <link linkend="config-drive-sections"><filename>dosdevices</filename></link>
- directory. Thus, in your dosdevices directory, you could type
- the command:
- <programlisting>
-ln -s /c c:
- </programlisting>
- </para>
- <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
- programs 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>
- </sect3>
-
- <sect3>
- <title>Running Wine as root</title>
- <para>
- Running Wine as root is the easiest and most thorough way of giving
- programs that Wine runs unrestricted access to FAT files systems.
- Running wine as root also allows programs 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 program can do to the system, so it's <emphasis>HIGHLY DISCOURAGED</emphasis>.
- </para>
- </sect3>
-
- <sect3>
- <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 user group
- (<literal>gid</literal>).
- </para>
- </sect3>
-
- <sect3>
- <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
- program can safely work with those copied parts while
- the program continues to directly read the remaining
- parts. This is done with symbolic links. For example,
- consider a system where a program 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 cannot 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' ~/.wine/config</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>
- </sect3>
</sect2>
-
- <sect2 id="config-drive-cdrom-labels">
-
- <title>Drive labels and serial numbers</title>
- <para>
- Wine can read drive volume labels and serial numbers directly
- from the device. This may be useful for many Win 9x games or
- for setup programs distributed on CD-ROMs that check for
- volume label.
- </para>
-
- <sect3>
- <title>What's Supported?</title>
-
- <informaltable frame="all">
- <tgroup cols="3">
- <thead>
- <row>
- <entry>File System</entry>
- <entry>Types</entry>
- <entry>Comment</entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry>FAT systems</entry>
- <entry>hd, floppy</entry>
- <entry>reads labels and serial numbers</entry>
- </row>
- <row>
- <entry>ISO9660</entry>
- <entry>cdrom</entry>
- <entry>reads labels and serial numbers (not mixed-mode CDs yet!)</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- </sect3>
-
- <sect3>
- <title>How To Set Up?</title>
- <para>
- Reading labels and serial numbers just works automatically
- if you specify the correct symbolic links for the devices
- (with double colons after the drive letters) in your
- <link linkend="config-drive-sections"><filename>dosdevices</filename></link>
- directory.
- Note that the device has to exist and must be accessible by the user
- running Wine if you do this, though.
- </para>
- <para>
- If you don't want to read labels and serial numbers directly from
- the device, you can create files at the root of the drive
- named <filename>.windows-label</filename> and
- <filename>.windows-serial</filename> respectively. These are
- simple ASCII files that you can create with any text editor;
- the label can be set to any string you like, the serial
- number should be expressed as an hexadecimal number.
- </para>
- </sect3>
-
- <sect3>
- <title>Examples</title>
+ <sect2>
+ <title>Scanners</title>
<para>
- Here's a simple example of CD-ROM and floppy:
+ In Windows, scanners use the TWAIN API to access the underlying
+ hardware. Wine's builtin TWAIN DLL simply forwards those requests
+ to the Linux SANE libraries. So, to utilize your scanner under
+ Wine you'll first need to make sure you can access it using
+ SANE. After that you'll need to make sure you have
+ <filename>xscanimage</filename> available for use. Currently
+ xscanimage is shipped with the sane-frontends package but it
+ may not be installed with your distribution. Scanner access
+ is currently known to have problems. If you find it works for
+ you, please consider updating this section of the user guide to
+ provide details on using SANE with Wine.
</para>
- <programlisting>
-cd ~/.wine/dosdevices
-
-ln -s /mnt/floppy a:
-ln -s /dev/fd0 a::
-
-ln -s /mnt/cdrom r:
-ln -s /dev/hda1 r::
- </programlisting>
- </sect3>
-
- <sect3>
- <title>Todo / Open Issues</title>
- <itemizedlist>
- <listitem> <para>
- The CD-ROM label can be read only if the data track of
- the disk resides in the first track and the cdrom is
- iso9660.
- </para> </listitem>
- <listitem> <para>
- Support for labels/serial nums WRITING.
- </para> </listitem>
- <listitem> <para>
- What about reading ext2 volume label? ....
- </para> </listitem>
- </itemizedlist>
- </sect3>
- </sect2>
- </sect1>
-
- ®istry;
-
-<sect1 id="config-dll">
-<title>DLL configuration</title>
-
-<sect2>
-<title>Introduction</title>
-<para>
- If your programs don't work as expected, then it's often because one
- DLL or another is failing. This can often be resolved by changing
- certain DLLs from Wine built-in to native Windows DLL file and vice
- versa.
-</para>
-<para>
- A very useful help to find out which DLLs are loaded as built-in and
- which are loaded as native Windows file can be the debug channel
- loaddll, activated via the environment variable
- <command>WINEDEBUG=+loaddll</command>.
-</para>
-</sect2>
-
-<sect2>
-<!-- FIXME intro!!! -->
-<title>Introduction To DLL Sections</title>
-<para>
- There are a few things you will need to know before
- configuring the DLL sections in your wine configuration
- file.
-</para>
-<sect3>
- <title>Windows DLL Pairs</title>
- <para>
- Most windows DLLs have a win16 (Windows 3.x) and win32
- (Windows 9x/NT) form. The combination of the win16 and
- win32 DLL versions are called the "DLL pair". This is a
- list of the most common pairs:
- </para>
-
- <informaltable>
- <tgroup cols="3">
- <thead>
- <row>
- <entry>Win16</entry>
- <entry>Win32</entry>
- <entry>
- Native
- <footnote>
- <para>
- Is it possible to use native DLL with wine?
- (See next section)
- </para>
- </footnote>
- </entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry>KERNEL</entry>
- <entry>KERNEL32</entry>
- <entry>No!</entry>
- </row>
- <row>
- <entry>USER</entry>
- <entry>USER32</entry>
- <entry>No!</entry>
- </row>
- <row>
- <entry>SHELL</entry>
- <entry>SHELL32</entry>
- <entry>Yes</entry>
- </row>
- <row>
- <entry>GDI</entry>
- <entry>GDI32</entry>
- <entry>No!</entry>
- </row>
- <row>
- <entry>COMMDLG</entry>
- <entry>COMDLG32</entry>
- <entry>Yes</entry>
- </row>
- <row>
- <entry>VER</entry>
- <entry>VERSION</entry>
- <entry>Yes</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-</sect3>
-
-<sect3>
- <title>Different Forms Of DLLs</title>
- <para>
- There are a few different forms of DLLs wine can load:
- <variablelist>
- <varlistentry>
- <term>native</term>
- <listitem><para>
- The DLLs that are included with windows. Many
- windows DLLs can be loaded in their native
- form. Many times these native versions work
- better than their non-Microsoft equivalent --
- other times they don't.
- </para></listitem>
- </varlistentry>
- <varlistentry>
- <term>builtin</term>
- <listitem><para>
- The most common form of DLL loading. This is
- what you will use if the DLL is too system-specific
- or error-prone in native form (KERNEL for example),
- you don't have the native DLL, or you just want to be
- Microsoft-free.
- </para></listitem>
- </varlistentry>
- <varlistentry>
- <term>so</term>
- <listitem><para>
- Native ELF libraries. Has became obsolete, ignored.
- </para></listitem>
- </varlistentry>
- <varlistentry>
- <term>elfdll</term>
- <listitem><para>
- ELF encapsulated windows DLLs.
- No longer used, ignored.
- </para></listitem>
- </varlistentry>
- </variablelist>
- </para>
-</sect3>
-</sect2>
-
-<sect2 id="config-dll-overrides">
-<title>DLL Overrides</title>
-
-<para>
- The wine configuration file directives [DllDefaults]
- and [DllOverrides] are the subject of some confusion. The
- overall purpose of most of these directives are clear enough,
- though - given a choice, should Wine use its own built-in
- DLLs, or should it use <filename>.DLL</filename> files found
- in an existing Windows installation? This document explains
- how this feature works.
-</para>
-
-<sect3>
- <title>DLL types</title>
- <variablelist>
- <varlistentry>
- <term>native</term>
- <listitem> <para>
- A "native" DLL is a <filename>.DLL</filename> file
- written for the real Microsoft Windows.
- </para> </listitem>
- </varlistentry>
- <varlistentry>
- <term>builtin</term>
- <listitem> <para>
- A "built-in" DLL is a Wine DLL. These can either be a
- part of <filename>libwine.so</filename>, or more
- recently, in a special <filename>.so</filename> file
- that Wine is able to load on demand.
- </para> </listitem>
- </varlistentry>
- </variablelist>
-</sect3>
-
-<sect3>
- <title>The [DllDefaults] section</title>
- <variablelist>
- <varlistentry>
- <term>DefaultLoadOrder</term>
- <listitem> <para>
- This specifies in what order Wine should search for
- available DLL types, if the DLL in question was not
- found in the [DllOverrides] section.
- </para> </listitem>
- </varlistentry>
- </variablelist>
-</sect3>
-
-<sect3>
- <title>The [DllPairs] section</title>
- <para>
- At one time, there was a section called [DllPairs] in the
- default configuration file, but this has been obsoleted
- because the pairing information has now been embedded into
- Wine itself. (The purpose of this section was merely to be
- able to issue warnings if the user attempted to pair
- codependent 16-bit/32-bit DLLs of different types.) If you
- still have this in your <filename>~/.wine/config</filename> or
- <filename>wine.conf</filename>, you may safely delete it.
- </para>
-</sect3>
-
-<sect3>
- <title>The [DllOverrides] section</title>
- <para>
- This section specifies how you want specific DLLs to be
- handled, in particular whether you want to use "native" DLLs
- or not, if you have some from a real Windows configuration.
- Because built-ins do not mix seamlessly with native DLLs yet,
- certain DLL dependencies may be problematic, but workarounds
- exist in Wine for many popular DLL configurations. Also see
- WWN's [16]Status Page to figure out how well your favorite
- DLL is implemented in Wine.
- </para>
- <para>
- It is of course also possible to override these settings by
- explicitly using Wine's <parameter>--dll</parameter>
- command-line option (see the man page for details). Some
- hints for choosing your optimal configuration (listed by
- 16/32-bit DLL pair):
- </para>
- <variablelist>
- <varlistentry>
- <term>krnl386, kernel32</term>
- <listitem> <para>
- Native versions of these will never work, so don't try. Leave
- at <literal>builtin</literal>.
- </para> </listitem>
- </varlistentry>
- <varlistentry>
- <term>gdi, gdi32</term>
- <listitem> <para>
- Graphics Device Interface. No effort has been made at trying to
- run native GDI. Leave at <literal>builtin</literal>.
- </para> </listitem>
- </varlistentry>
- <varlistentry>
- <term>user, user32</term>
- <listitem> <para>
- Window management and standard controls. It was
- possible to use Win95's <literal>native</literal>
- versions at some point (if all other DLLs that depend
- on it, such as comctl32 and comdlg32, were also run
- <literal>native</literal>). However, this is no longer
- possible after the Address Space Separation, so leave
- at <literal>builtin</literal>.
- </para> </listitem>
- </varlistentry>
- <varlistentry>
- <term>ntdll</term>
- <listitem> <para>
- NT kernel API. Although badly documented, the
- <literal>native</literal> version of this will never
- work. Leave at <literal>builtin</literal>.
- </para> </listitem>
- </varlistentry>
- <varlistentry>
- <term>w32skrnl</term>
- <listitem> <para>
- Win32s (for Win3.x). The <literal>native</literal>
- version will probably never work. Leave at
- <literal>builtin</literal>.
- </para> </listitem>
- </varlistentry>
- <varlistentry>
- <term>wow32</term>
- <listitem> <para>
- Win16 support library for NT. The
- <literal>native</literal> version will probably never
- work. Leave at <literal>builtin</literal>.
- </para> </listitem>
- </varlistentry>
- <varlistentry>
- <term>system</term>
- <listitem> <para>
- Win16 kernel stuff. Will never work
- <literal>native</literal>. Leave at
- <literal>builtin</literal>.
- </para> </listitem>
- </varlistentry>
- <varlistentry>
- <term>display</term>
- <listitem> <para>
- Display driver. Definitely leave at <literal>builtin</literal>.
- </para> </listitem>
- </varlistentry>
- <varlistentry>
- <term>toolhelp</term>
- <listitem> <para>
- Tool helper routines. This is rarely a source of problems.
- Leave at <literal>builtin</literal>.
- </para> </listitem>
- </varlistentry>
- <varlistentry>
- <term>ver, version</term>
- <listitem> <para>
- Versioning. Seldom useful to mess with.
- </para> </listitem>
- </varlistentry>
- <varlistentry>
- <term>advapi32</term>
- <listitem> <para>
- Registry and security features. Trying the
- <literal>native</literal> version of this may or may
- not work.
- </para> </listitem>
- </varlistentry>
- <varlistentry>
- <term>commdlg, comdlg32</term>
- <listitem> <para>
- Common Dialogs, such as color picker, font dialog,
- print dialog, open/save dialog, etc. It is safe to try
- <literal>native</literal>.
- </para> </listitem>
- </varlistentry>
- <varlistentry>
- <term>commctrl, comctl32</term>
- <listitem> <para>
- Common Controls. This is toolbars, status bars, list controls,
- the works. It is safe to try <literal>native</literal>.
- </para> </listitem>
- </varlistentry>
- <varlistentry>
- <term>shell, shell32</term>
- <listitem> <para>
- Shell interface (desktop, filesystem, etc). Being one of the
- most undocumented pieces of Windows, you may have luck with the
- <literal>native</literal> version, should you need it.
- </para> </listitem>
- </varlistentry>
- <varlistentry>
- <term>winsock, wsock32</term>
- <listitem> <para>
- Windows Sockets. The <literal>native</literal> version
- will not work under Wine, so leave at
- <literal>builtin</literal>.
- </para> </listitem>
- </varlistentry>
- <varlistentry>
- <term>icmp</term>
- <listitem> <para>
- ICMP routines for wsock32. As with wsock32, leave at
- <literal>builtin</literal>.
- </para> </listitem>
- </varlistentry>
- <varlistentry>
- <term>mpr</term>
- <listitem> <para>
- The <literal>native</literal> version may not work due
- to thunking issues. Leave at
- <literal>builtin</literal>.
- </para> </listitem>
- </varlistentry>
- <varlistentry>
- <term>lzexpand, lz32</term>
- <listitem> <para>
- Lempel-Ziv decompression. Wine's
- <literal>builtin</literal> version ought to work fine.
- </para> </listitem>
- </varlistentry>
- <varlistentry>
- <term>winaspi, wnaspi32</term>
- <listitem> <para>
- Advanced SCSI Peripheral Interface. The
- <literal>native</literal> version will probably never
- work. Leave at <literal>builtin</literal>.
- </para> </listitem>
- </varlistentry>
- <varlistentry>
- <term>crtdll</term>
- <listitem> <para>
- C Runtime library. The <literal>native</literal>
- version will easily work better than Wine's on this
- one.
- </para> </listitem>
- </varlistentry>
- <varlistentry>
- <term>winspool.drv</term>
- <listitem> <para>
- Printer spooler. You are not likely to have more luck
- with the <literal>native</literal> version.
- </para> </listitem>
- </varlistentry>
- <varlistentry>
- <term>ddraw</term>
- <listitem> <para>
- DirectDraw/Direct3D. Since Wine does not implement the
- DirectX HAL, the <literal>native</literal> version
- will not work at this time.
- </para> </listitem>
- </varlistentry>
- <varlistentry>
- <term>dinput</term>
- <listitem> <para>
- DirectInput. Running this <literal>native</literal>
- may or may not work.
- </para> </listitem>
- </varlistentry>
- <varlistentry>
- <term>dsound</term>
- <listitem> <para>
- DirectSound. It may be possible to run this
- <literal>native</literal>, but don't count on it.
- </para> </listitem>
- </varlistentry>
- <varlistentry>
- <term>dplay/dplayx</term>
- <listitem> <para>
- DirectPlay. The <literal>native</literal> version
- ought to work best on this, if at all.
- </para> </listitem>
- </varlistentry>
- <varlistentry>
- <term>mmsystem, winmm</term>
- <listitem> <para>
- Multimedia system. The <literal>native</literal>
- version is not likely to work. Leave at
- <literal>builtin</literal>.
- </para> </listitem>
- </varlistentry>
- <varlistentry>
- <term>msacm, msacm32</term>
- <listitem> <para>
- Audio Compression Manager. The
- <literal>builtin</literal> version works best, if you
- set msacm.drv to the same.
- </para> </listitem>
- </varlistentry>
- <varlistentry>
- <term>msvideo, msvfw32</term>
- <listitem> <para>
- Video for Windows. It is safe (and recommended) to try
- <literal>native</literal>.
- </para> </listitem>
- </varlistentry>
- <varlistentry>
- <term>mcicda.drv</term>
- <listitem> <para>
- CD Audio MCI driver.
- </para> </listitem>
- </varlistentry>
- <varlistentry>
- <term>mciseq.drv</term>
- <listitem> <para>
- MIDI Sequencer MCI driver (<filename>.MID</filename>
- playback).
- </para> </listitem>
- </varlistentry>
- <varlistentry>
- <term>mciwave.drv</term>
- <listitem> <para>
- Wave audio MCI driver (<filename>.WAV</filename> playback).
- </para> </listitem>
- </varlistentry>
- <varlistentry>
- <term>mciavi.drv</term>
- <listitem> <para>
- AVI MCI driver (<filename>.AVI</filename> video
- playback). Best to use <literal>native</literal>.
- </para> </listitem>
- </varlistentry>
- <varlistentry>
- <term>mcianim.drv</term>
- <listitem> <para>
- Animation MCI driver.
- </para> </listitem>
- </varlistentry>
- <varlistentry>
- <term>msacm.drv</term>
- <listitem> <para>
- Audio Compression Manager. Set to same as msacm32.
- </para> </listitem>
- </varlistentry>
- <varlistentry>
- <term>midimap.drv</term>
- <listitem> <para>
- MIDI Mapper.
- </para> </listitem>
- </varlistentry>
- <varlistentry>
- <term>wprocs</term>
- <listitem> <para>
- This is a pseudo-DLL used by Wine for thunking
- purposes. A <literal>native</literal> version of this
- doesn't exist.
- </para> </listitem>
- </varlistentry>
- </variablelist>
-</sect3>
-</sect2>
-
-<sect2 id="config-system-dlls">
-<title>System DLLs</title>
-<para>
- The Wine team has determined that it is necessary to create
- fake DLL files to trick many programs 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 program think it's there, and Wine's built-in DLL
- will be loaded when the program actually asks for it.
- (Unfortunately, <filename>tools/wineinstall</filename> does
- not create such empty files itself.)
-</para>
-<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).
-</para>
-</sect2>
-
-<sect2 id="config-dll-missing">
-<title>Missing DLLs</title>
-
-<para>
- In case Wine complains about a missing DLL, you should check whether
- this file is a publicly available DLL or a custom DLL belonging
- to your program (by searching for its name on the internet).
- If you managed to get hold of the DLL, then you should make sure
- that Wine is able to find and load it.
- DLLs usually get loaded according to the mechanism of the
- SearchPath() function.
- This function searches directories in the following order:
-
- <orderedlist>
- <listitem>
- <para>
- The directory the program was started from.
- </para>
- </listitem>
- <listitem>
- <para>
- The current directory.
- </para>
- </listitem>
- <listitem>
- <para>
- The Windows system directory.
- </para>
- </listitem>
- <listitem>
- <para>
- The Windows directory.
- </para>
- </listitem>
- <listitem>
- <para>
- The PATH variable directories.
- </para>
- </listitem>
- </orderedlist>
-
- In short: either put the required DLL into your program
- directory (might be ugly), or usually put it into the Windows system
- directory. Just find out its directory by having a look at the Wine
- configuration file variable "System" (which indicates the location of the
- Windows system directory) and the associated drive entry.
- Note that you probably shouldn't use NT-based native DLLs,
- since Wine's NT API support is somewhat weaker than its Win9x
- API support (thus leading to even worse compatibility with NT DLLs
- than with a no-windows setup!), so better use Win9x native DLLs
- instead or no native DLLs at all.
-</para>
-</sect2>
-
-<sect2 id="config-dll-windows">
-<title>Fetching native DLLs from a Windows CD</title>
-
-<para>
-The Linux <command>cabextract</command> utility can be used to
-extract native Windows .dll files from .cab files that are to be
-found on many Windows installation CDs.
-</para>
-</sect2>
-</sect1>
-
-<sect1 id="config-graphics-driver">
-<title>Configuring the graphics driver (x11drv, ttydrv etc.)</title>
-
-<para>
-Wine currently supports several different display subsystems
-(graphics / text) that are available on various operating
-systems today.
-For each of these, Wine implements its own interfacing driver.
-This section explains how to select one of these drivers
-and how to further configure the respective driver.
-Once you're finished with that, you can consider your Wine installation
-to be finished.
-</para>
-
-<para>
-The display drivers currently implemented in Wine are:
-x11drv, which is used for interfacing to X11 graphics
-(the one you'll most likely want to use) and ttydrv
-(used for text mode console apps mainly that don't really need
-any graphics output).
-Once you have decided which display driver to use, it is chosen
-with the <literal>GraphicsDriver</literal> option in the
-[wine] section of <filename>~/.wine/config</filename>.
-</para>
-
-<sect2>
-<title>Configuring the x11drv graphics driver</title>
-
-<sect3>
- <title>x11drv modes of operation</title>
-
- <para>
- The x11drv driver consists of two conceptually distinct
- pieces, the graphics driver (GDI part), and the windowing
- driver (USER part). Both of these are linked into the
- <filename>libx11drv.so</filename> module, though (which you
- load with the <literal>GraphicsDriver</literal> option). In
- Wine, running on X11, the graphics driver must draw on
- drawables (window interiors) provided by the windowing
- driver. This differs a bit from the Windows model, where the
- windowing system creates and configures device contexts
- controlled by the graphics driver, and programs are
- allowed to hook into this relationship anywhere they like.
- Thus, to provide any reasonable tradeoff between
- compatibility and usability, the x11drv has three different
- modes of operation.
- </para>
-
- <variablelist>
- <varlistentry>
- <term>Managed</term>
- <listitem>
- <para>
- The default. Specified by using the <literal>Managed</literal>
- wine configuration file option (see below).
- Ordinary top-level frame windows with thick borders,
- title bars, and system menus will be managed by your
- window manager. This lets these programs integrate
- better with the rest of your desktop, but may not
- always work perfectly (a rewrite of this mode of
- operation, to make it more robust and less patchy, is
- currently being done, though, and it's planned to be
- finished before the Wine 1.0 release).
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>Unmanaged / Normal</term>
- <listitem>
- <para>
- Window manager independent (any running
- window manager is ignored completely). Window
- decorations (title bars, borders, etc) are drawn by
- Wine to look and feel like the real Windows. This is
- compatible with programs that depend on being able
- to compute the exact sizes of any such decorations, or
- that want to draw their own.
- Unmanaged mode is only used if both Managed and Desktop
- are set to disabled.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>Desktop-in-a-Box</term>
- <listitem>
- <para>
- Specified by using the <literal>Desktop</literal>
- wine configuration file option (see below).
- (adding a geometry, e.g. <literal>800x600</literal>
- for a such-sized desktop, or
- even <literal>800x600+0+0</literal> to
- automatically position the desktop at the upper-left
- corner of the display). This is the mode most
- compatible with the Windows model. All program
- windows will just be Wine-drawn windows inside the
- Wine-provided desktop window (which will itself be
- managed by your window manager), and Windows
- programs can roam freely within this virtual
- workspace and think they own it all, without
- disturbing your other X apps.
- Note: currently there's one desktop window for every
- program; this will be fixed at some time.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
-</sect3>
-
-<sect3>
- <title>The [x11drv] section</title>
-
- <variablelist>
- <varlistentry>
- <term>Managed</term>
- <listitem>
- <para>
- Wine can let frame windows be managed by your window
- manager. This option specifies whether you want that
- by default.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>Desktop</term>
- <listitem>
- <para>
- Creates a main desktop window of a specified size
- to display all Windows programs in.
- The size argument could e.g. be "800x600".
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>DXGrab</term>
- <listitem>
- <para>
- If you don't use DGA, you may want an alternative
- means to convince the mouse cursor to stay within the
- game window. This option does that. Of course, as with
- DGA, if Wine crashes, you're in trouble (although not
- as badly as in the DGA case, since you can still use
- the keyboard to get out of X).
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>UseDGA</term>
- <listitem>
- <para>
- This specifies whether you want DirectDraw to use
- XFree86's <firstterm>Direct Graphics
- Architecture</firstterm> (DGA), which is able to
- take over the entire display and run the game
- full-screen at maximum speed. (With DGA1 (XFree86
- 3.x), you still have to configure the X server to the
- game's requested bpp first, but with DGA2 (XFree86
- 4.x), runtime depth-switching may be possible,
- depending on your driver's capabilities.) But be aware
- that if Wine crashes while in DGA mode, it may not be
- possible to regain control over your computer without
- rebooting. DGA normally requires either root
- privileges or read/write access to
- <filename>/dev/mem</filename>.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>DesktopDoubleBuffered</term>
- <listitem>
- <para>
- Applies only if you use the
- <parameter>--desktop</parameter> command-line option
- to run in a desktop window. Specifies whether to
- create the desktop window with a double-buffered
- visual, something most OpenGL games need to run
- correctly.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>AllocSystemColors</term>
- <listitem>
- <para>
- Applies only if you have a palette-based display, i.e.
- if your X server is set to a depth of 8bpp, and if you
- haven't requested a private color map. It specifies
- the maximum number of shared colormap cells (palette
- entries) Wine should occupy. The higher this value,
- the less colors will be available to other
- programs.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>PrivateColorMap</term>
- <listitem>
- <para>
- Applies only if you have a palette-based display, i.e.
- if your X server is set to a depth of 8bpp. It
- specifies that you don't want to use the shared color
- map, but a private color map, where all 256 colors are
- available. The disadvantage is that Wine's private
- color map is only seen while the mouse pointer is
- inside a Wine window, so psychedelic flashing and
- funky colors will become routine if you use the mouse
- a lot.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>Synchronous</term>
- <listitem>
- <para>
- To be used for debugging X11 operations.
- If Wine crashes with an X11 error, then you should enable
- Synchronous mode to disable X11 request caching in order
- to make sure that the X11 error happens directly after
- the corresponding X11 call in the log file appears.
- Will slow down X11 output!
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>ScreenDepth</term>
- <listitem>
- <para>
- Applies only to multi-depth displays. It specifies
- which of the available depths Wine should use (and
- tell Windows apps about).
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>Display</term>
- <listitem>
- <para>
- This specifies which X11 display to use, and if
- specified, will override the
- <envar>DISPLAY</envar> environment variable.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>PerfectGraphics</term>
- <listitem>
- <para>
- This option only determines whether fast X11 routines
- or exact Wine routines will be used for certain ROP
- codes in blit operations. Most users won't notice any
- difference.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
-</sect3>
-</sect2>
-
-<sect2>
-<title>Configuring the ttydrv graphics driver</title>
-<para>
- Currently, the ttydrv doesn't have any special configuration
- options to set in the configuration file.
-</para>
-</sect2>
-
-</sect1>
-
-<sect1 id="config-windows-versions">
-
-<title>Setting the Windows and DOS version value</title>
-
-<para>
-The windows and DOS version value a program gets e.g. by calling the
-Windows function GetVersion() plays a very important role:
-If your Wine installation for whatever reason fails to provide
-to your program the correct version value that it expects,
-then the program might assume some very bad things and fail (in
-the worst case even silently!).
-
-Fortunately Wine contains some more or less intelligent Windows
-version guessing algorithm that will try to guess the Windows
-version a program might expect and pass that one on to the
-program.
-
-Thus you should <emphasis>not</emphasis> lightly configure a version value, as this will be a "forced" value and thus turn out to be rather harmful to proper operation. In other words: only explicitly set a Windows version value in case Wine's own version detection was unable to provide the correct Windows version and the program fails.
-</para>
-
-<sect2>
-<title>How to configure the Windows and DOS version value Wine
-should return</title>
-
-<para>
-The version values can be configured in the wine configuration file in
-the [Version] section.
-</para>
-
-<variablelist>
- <varlistentry>
- <term>"Windows" = "<version string>"</term>
- <listitem>
- <para>
- default: none; chosen by semi-intelligent detection
- mechanism based on DLL environment.
- Used to specify which Windows version to return to
- programs (forced value, overrides standard detection
- mechanism!). Valid settings are e.g. "win31", "win95",
- "win98", "win2k", "winxp".
- Also valid as an
- <link linkend="config-appdefaults">AppDefaults</link>
- setting (recommended/preferred use).
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>"DOS"="<version string>"</term>
- <listitem>
- <para>
- Used to specify the DOS version that should be returned
- to programs. Only takes effect in case Wine acts as
- "win31" Windows version! Common DOS version settings
- include 6.22, 6.20, 6.00, 5.00, 4.00, 3.30, 3.10.
- Also valid as an
- <link linkend="config-appdefaults">AppDefaults</link>
- setting (recommended/preferred use).
- </para>
- </listitem>
- </varlistentry>
-</variablelist>
-</sect2>
-</sect1>
-
-&fonts;
-&printing;
-
- <sect1 id="config-scsi-support">
- <title>SCSI Support</title>
- <para>
- This file describes setting up the Windows ASPI interface.
- 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>
-
- <sect2>
- <title>Windows requirements</title>
- <orderedlist>
- <listitem>
- <para>
- The software needs to use the "Adaptec"
- compatible drivers (ASPI). At least with Mustek, they
- allow you the choice of using the built-in 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.
- </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>Notes</title>
+ <title>ODBC Databases</title>
<para>
- The biggest drawback is that it only works under Linux at the moment.
- The ASPI code has only been tested with:
+ The ODBC system within Wine, as with the printing system, is designed
+ to hook across to the Unix system at a high level. Rather than
+ ensuring that all the windows code works under wine it uses a suitable
+ Unix ODBC provider, such as UnixODBC. Thus if you configure Wine to
+ use the built-in odbc32.dll, that Wine DLL will interface to your
+ Unix ODBC package and let that do the work, whereas if you configure
+ Wine to use the native odbc32.dll it will try to use the native
+ ODBC32 drivers etc.
</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>
- </sect2>
- </sect1>
-
- <sect1 id="config-odbc">
- <title>Using ODBC</title>
- <para>
- This section describes how ODBC works within Wine and how to configure it.
- </para>
- <para>
- The ODBC system within Wine, as with the printing system, is designed
- to hook across to the Unix system at a high level. Rather than
- ensuring that all the windows code works under wine it uses a suitable
- Unix ODBC provider, such as UnixODBC. Thus if you configure Wine to
- use the built-in odbc32.dll, that Wine DLL will interface to your
- Unix ODBC package and let that do the work, whereas if you configure
- Wine to use the native odbc32.dll it will try to use the native
- ODBC32 drivers etc.
- </para>
- <sect2>
- <title>Using a Unix ODBC system with Wine</title>
+ <sect3>
+ <title>Configuring ODBC on Unix</title>
<para>
The first step in using a Unix ODBC system with Wine is, of course,
to get the Unix ODBC system working itself. This may involve
downloading code or RPMs etc. There are several Unix ODBC systems
available; the one the author is used to is unixODBC (with the
- IBM DB2 driver). Typically such systems will include a tool, such
- as <command>isql</command>, which will allow you to access the data from the command
- line so that you can check that the system is working.
+ IBM DB2 driver). There is also and ODBC-ODBC bridge that can be used
+ to access a Microsoft Access database. Typically such systems will
+ include a tool, such as <command>isql</command>, which will allow
+ you to access the data from the command line so that you can check
+ that the system is working.
</para>
<para>
The next step is to hook the Unix ODBC library to the wine built-in
@@ -2653,7 +760,7 @@ the [Version] section.
.bashrc file is the line:
</para>
<programlisting>
-export LIB_ODBC_DRIVER_MANAGER=/usr/lib/libodbc.so.1.0.0
+ export LIB_ODBC_DRIVER_MANAGER=/usr/lib/libodbc.so.1.0.0
</programlisting>
<para>
If that environment variable is not set then it looks for a
@@ -2661,10 +768,10 @@ export LIB_ODBC_DRIVER_MANAGER=/usr/lib/
equate that to your own library. For example as root you could
run the commands:
</para>
- <screen>
-<prompt># </prompt><userinput>ln -s libodbc.so.1.0.0 /usr/lib/libodbc.so</userinput>
-<prompt># </prompt><userinput>/sbin/ldconfig</userinput>
- </screen>
+ <programlisting>
+ <prompt>$ </prompt><userinput>ln -s libodbc.so.1.0.0 /usr/lib/libodbc.so</userinput>
+ <prompt>$ </prompt><userinput>/sbin/ldconfig</userinput>
+ </programlisting>
<para>
The last step in configuring this is to ensure that Wine is set up
to run the built-in version of odbc32.dll, by modifying the DLL
@@ -2673,60 +780,62 @@ export LIB_ODBC_DRIVER_MANAGER=/usr/lib/
</para>
<para>
If you have any problems then you can use WINEDEBUG=+odbc32 command
- before running wine to trace what is happening. One word of
- warning. Some programs actually cheat a little and bypass the ODBC
- library. For example the Crystal Reports engine goes to the registry
+ before running wine to trace what is happening. One word of
+ warning. Some programs actually cheat a little and bypass the ODBC
+ library. For example the Crystal Reports engine goes to the registry
to check on the DSN. The fix for this is documented at unixODBC's
site where there is a section on using unixODBC with Wine.
</para>
- </sect2>
- <sect2>
- <title>Using Windows ODBC drivers</title>
- <para>
- Native ODBC drivers have been reported to work for many types of
- databases including MSSQL and Oracle. In fact, some like MSSQL can
- only be accessed on Linux through a Winelib app. Rather than
- just copying DLL files, most ODBC drivers require a Windows-based
- installer to run to properly configure things such as registry keys.
- </para>
- <para>
- In order to set up MSSQL support you will first need to download
- and run the mdac_typ.exe installer from microsoft.com. In order to
- configure your ODBC connections you must then run CLICONFG.EXE and
- ODBCAD32.EXE under Wine. You can find them in the windows\system
- directory after mdac_typ runs. Compare the output of these programs
- with the output on a native Windows machine. Some things, such
- as protocols, may be missing because they rely on being installed
- along with the operating system. If so, you may be able to copy
- missing functionality from an existing Windows installation as
- well as any registry values required. A native Windows installation
- configured to be used by Wine should work the same way it did
- when run natively.
- </para>
- <para>
- Types successfully tested under wine:
- </para>
- <informaltable>
- <tgroup cols="2">
- <thead>
- <row>
- <entry>DB Type</entry>
- <entry>Usefulness</entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry>MS SQL</entry>
- <entry>100%</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
- <para>
- Please report any other successes to the
- <ulink url="mailto:wine-devel at winehq.org">wine-devel</ulink>
- mailing list.
- </para>
+ </sect3>
+ <sect3>
+ <title>Using Windows ODBC drivers</title>
+ <para>
+ Native ODBC drivers have been reported to work for many types of
+ databases including MSSQL and Oracle. In fact, some like MSSQL can
+ only be accessed on Linux through a Winelib app. Rather than
+ just copying DLL files, most ODBC drivers require a Windows-based
+ installer to run to properly configure things such as registry keys.
+ </para>
+ <para>
+ In order to set up MSSQL support you will first need to download
+ and run the mdac_typ.exe installer from microsoft.com. In order to
+ configure your ODBC connections you must then run CLICONFG.EXE and
+ ODBCAD32.EXE under Wine. You can find them in the windows\system
+ directory after mdac_typ runs. Compare the output of these programs
+ with the output on a native Windows machine. Some things, such
+ as protocols, may be missing because they rely on being installed
+ along with the operating system. If so, you may be able to copy
+ missing functionality from an existing Windows installation as
+ well as any registry values required. A native Windows installation
+ configured to be used by Wine should work the same way it did
+ when run natively.
+ </para>
+ <para>
+ Types successfully tested under wine:
+ </para>
+ <informaltable>
+ <tgroup cols="2">
+ <thead>
+ <row>
+ <entry>DB Type</entry>
+ <entry>Usefulness</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>MS SQL</entry>
+ <entry>100%</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </informaltable>
+ <para>
+ Please report any other successes to the
+ <ulink url="mailto:wine-devel at winehq.org">wine-devel</ulink>
+ mailing list.
+ </para>
+ </sect3>
+
</sect2>
</sect1>
Index: docs/en/wineusr-guide.sgml
diff -u -p docs/en/wineusr-guide.sgml:1.2 docs/en/wineusr-guide.sgml:1.3
--- docs/en/wineusr-guide.sgml 17 Oct 2005 12:16:24 -0000
+++ /dev/null 17 Oct 2005 12:16:24 -0000
@@ -3,9 +3,6 @@
<!entity introduction SYSTEM "wineusr-introduction.sgml">
<!entity getting SYSTEM "wineusr-getting.sgml">
<!entity configuring SYSTEM "wineusr-configuring.sgml">
-<!entity registry SYSTEM "wineusr-registry.sgml">
-<!entity fonts SYSTEM "wineusr-fonts.sgml">
-<!entity printing SYSTEM "wineusr-printing.sgml">
<!entity running SYSTEM "wineusr-running.sgml">
<!entity bugs SYSTEM "wineusr-bugs.sgml">
<!entity glossary SYSTEM "wineusr-glossary.sgml">
Index: docs/en/wineusr-running.sgml
diff -u -p docs/en/wineusr-running.sgml:1.2 docs/en/wineusr-running.sgml:1.3
--- docs/en/wineusr-running.sgml 17 Oct 2005 12:16:25 -0000
+++ /dev/null 17 Oct 2005 12:16:25 -0000
@@ -178,9 +178,8 @@ Path="c:\windows;c:\windows\system;e:\;e
complex application, your debug logs can easily top 1 MB and
higher. A <parameter>relay</parameter> trace can often
generate more than 10 MB of log messages, depending on how
- long you run the application. (As described in the
- <link linkend = "config-debug-etc">Debug</link>
- section of configuring wine you can
+ long you run the application. (You'll want to check out
+ RelayExclude registry key to
modify what the <parameter>relay</parameter> trace reports).
Logging does slow down Wine
quite a bit, so don't use <parameter>WINEDEBUG</parameter>
Index: docs/en/wineusr-fonts.sgml
diff -u -p docs/en/wineusr-fonts.sgml:1.2 /dev/null
--- docs/en/wineusr-fonts.sgml 17 Oct 2005 12:16:25 -0000
+++ /dev/null 17 Oct 2005 12:16:25 -0000
@@ -1,501 +0,0 @@
- <sect1 id="config-fonts-main">
- <title>Dealing with Fonts</title>
-
- <sect2 id="config-windows-fonts">
- <title>Fonts</title>
-
- <para>
- <note>
- <para>
- The <command>fnt2bdf</command> utility is included with
- Wine. It can be found in the <filename>tools</filename>
- directory. Links to the other tools mentioned in this
- document can be found in the Wine Developer's Guide:
- <ulink url="http://www.winehq.org/site/docs/wine-devel/index">http://www.winehq.org/site/docs/wine-devel/index</ulink>
- </para>
- </note>
- </para>
-
- <sect3>
- <title>How To Convert Windows Fonts</title>
- <para>
- If you have access to a Windows installation you should use the
- <command>fnt2bdf</command> utility (found in the
- <filename>tools</filename> directory) to convert bitmap
- fonts (<filename>VGASYS.FON</filename>,
- <filename>SSERIFE.FON</filename>, and
- <filename>SERIFE.FON</filename>) into the format that the X
- Window System can recognize.
- </para>
-
- <orderedlist>
- <listitem>
- <para>
- Extract bitmap fonts with <command>fnt2bdf</command>.
- </para>
- </listitem>
- <listitem>
- <para>
- Convert <filename>.bdf</filename> files produced by Step
- 1 into <filename>.pcf</filename> files with
- <command>bdftopcf</command>.
- </para>
- </listitem>
- <listitem>
- <para>
- Copy <filename>.pcf</filename> files to the font server
- directory which is usually
- <filename>/usr/lib/X11/fonts/misc</filename> (you will
- probably need superuser privileges). If you want to
- create a new font directory you will need to add it to
- the font path.
- </para>
- </listitem>
- <listitem>
- <para>
- Run <command>mkfontdir</command> for the directory you
- copied fonts to. If you are already in X you should run
- <command>xset fp rehash</command> to make X server aware
- 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 Red Hat 7.1)
- </para>
- </listitem>
- <listitem>
- <para>
- Edit the <filename>~/.wine/config</filename> file to remove
- aliases for the fonts you've just installed.
- </para>
- </listitem>
- </orderedlist>
- <para>
- Wine can get by without these fonts but 'the look and feel'
- may be quite different. Also, some applications try to load
- their custom fonts on the fly (WinWord 6.0) and since Wine
- does not implement this yet it instead prints out something
- like;
- </para>
- <screen>
-STUB: AddFontResource( SOMEFILE.FON )
- </screen>
- <para>
- You can convert this file too. Note that
- <filename>.FON</filename> file may not hold any bitmap
- fonts and <command>fnt2bdf</command> will fail if this is
- the case. Also note that although the above message will not
- disappear Wine will work around the problem by using the
- font you extracted from the
- <filename>SOMEFILE.FON</filename>.
- <command>fnt2bdf</command> will only work for Windows 3.1
- fonts. It will not work for TrueType fonts.
- </para>
- <para>
- What to do with TrueType fonts? There are several commercial
- font tools that can convert them to the Type1 format but the
- quality of the resulting fonts is far from stellar. The
- other way to use them is to get a font server capable of
- rendering TrueType (Caldera has one, there also is the free
- <command>xfstt</command> in
- <filename>Linux/X11/fonts</filename> on sunsite and mirrors,
- if you're on FreeBSD you can use the port in
- <filename>/usr/ports/x11-servers/Xfstt</filename>. And
- there is <command>xfsft</command> which uses the freetype
- library, see <link linkend="ttfont-server">freetype</link>
- description).
- </para>
- <para>
- However, there is a possibility of the native TrueType
- support via FreeType renderer in the future (hint, hint :-)
- </para>
- </sect3>
-
- <sect3>
- <title>How To Add Font Aliases To <filename>~/.wine/config</filename></title>
- <para>
- Many Windows applications assume that fonts included in
- original Windows 3.1 distribution are always present. By
- default Wine creates a number of aliases that map them on
- the existing X fonts:
- </para>
-
- <informaltable>
- <tgroup cols="3">
- <thead>
- <row>
- <entry>Windows font</entry>
- <entry>...is mapped to...</entry>
- <entry>X font</entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry>"MS Sans Serif"</entry>
- <entry align="center">-></entry>
- <entry>"-adobe-helvetica-"</entry>
- </row>
- <row>
- <entry>"MS Serif"</entry>
- <entry align="center">-></entry>
- <entry>"-bitstream-charter-"</entry>
- </row>
- <row>
- <entry>"Times New Roman"</entry>
- <entry align="center">-></entry>
- <entry>"-adobe-times-"</entry>
- </row>
- <row>
- <entry>"Arial"</entry>
- <entry align="center">-></entry>
- <entry>"-adobe-helvetica-"</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>
- There is no default alias for the "System" font. Also, no
- aliases are created for the fonts that applications install
- at runtime. The recommended way to deal with this problem
- is to convert the missing font (see above). If it proves
- impossible, like in the case with TrueType fonts, you can
- force the font mapper to choose a closely related X font by
- adding an alias to the [fonts] section. Make sure that the
- X font actually exists (with <command>xfontsel</command>
- tool).
- </para>
- <screen>
-AliasN = [Windows font], [X font] <, optional "mask X font" flag>
- </screen>
- <para>
- Example:
- </para>
- <screen>
-Alias0 = System, --international-, subst
-Alias1 = ...
-...
- </screen>
- <para>
- Comments:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- There must be no gaps in the sequence <literal>{0, ...,
- N}</literal> otherwise all aliases after the first gap
- won't be read.
- </para>
- </listitem>
- <listitem>
- <para>
- Usually font mapper translates X font names into font
- names visible to Windows programs in the following
- fashion:
- </para>
-
- <informaltable>
- <tgroup cols="3">
- <thead>
- <row>
- <entry>X font</entry>
- <entry>...will show up as...</entry>
- <entry>Extracted name</entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry>--international-...</entry>
- <entry align="center">-></entry>
- <entry>"International"</entry>
- </row>
- <row>
- <entry>-adobe-helvetica-...</entry>
- <entry align="center">-></entry>
- <entry>"Helvetica"</entry>
- </row>
- <row>
- <entry>-adobe-utopia-...</entry>
- <entry align="center">-></entry>
- <entry>"Utopia"</entry>
- </row>
- <row>
- <entry>-misc-fixed-...</entry>
- <entry align="center">-></entry>
- <entry>"Fixed"</entry>
- </row>
- <row>
- <entry>-...</entry>
- <entry align="center">-></entry>
- <entry></entry>
- </row>
- <row>
- <entry>-sony-fixed-...</entry>
- <entry align="center">-></entry>
- <entry>"Sony Fixed"</entry>
- </row>
- <row>
- <entry>-...</entry>
- <entry align="center">-></entry>
- <entry></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>
- Note that since <literal>-misc-fixed-</literal> and
- <literal>-sony-fixed-</literal> are different fonts Wine
- modified the second extracted name to make sure Windows
- programs can distinguish them because only extracted
- names appear in the font selection dialogs.
- </para>
- </listitem>
- <listitem>
- <para>
- "Masking" alias replaces the original extracted name so
- that in the example case we will have the following
- mapping:
- </para>
- <informaltable>
- <tgroup cols="3">
- <thead>
- <row>
- <entry>X font</entry>
- <entry>...is masked to...</entry>
- <entry>Extracted name</entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry>--international-...</entry>
- <entry align="center">-></entry>
- <entry>"System"</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
- <para>
- "Nonmasking" aliases are transparent to the user and
- they do not replace extracted names.
- </para>
- <para>
- Wine discards an alias when it sees that the native X
- font is available.
- </para>
- </listitem>
- <listitem>
- <para>
- If you do not have access to Windows fonts mentioned in
- the first paragraph you should try to substitute the
- "System" font with nonmasking alias. The
- <command>xfontsel</command> application will show you
- the fonts available to X.
- </para>
- <screen>
-Alias.. = System, ...bold font without serifs
- </screen>
- </listitem>
- </itemizedlist>
- <para>
- Also, some Windows applications request fonts without
- specifying the typeface name of the font. Font table starts
- with Arial in most Windows installations, however X font
- table starts with whatever is the first line in the
- <filename>fonts.dir</filename>. Therefore Wine uses the
- following entry to determine which font to check first.
- </para>
- <para>
- Example:
- </para>
- <screen>
-Default = -adobe-times-
- </screen>
- <para>
- Comments:
- </para>
- <para>
- It is better to have a scalable font family (bolds and
- italics included) as the default choice because mapper
- checks all available fonts until requested height and other
- attributes match perfectly or the end of the font table is
- reached. Typical X installations have scalable fonts in the
- <filename>../fonts/Type1</filename> and
- <filename>../fonts/Speedo</filename> directories.
- </para>
- </sect3>
-
- <sect3>
- <title>How To Manage Cached Font Metrics</title>
- <para>
- Wine stores detailed information about available fonts in
- the <filename>~/.wine/cachedmetrics.[display]</filename> file. You
- can copy it elsewhere and add this entry to the [fonts]
- section in your <filename>~/.wine/config</filename>:
- </para>
- <screen>
-FontMetrics = <file with metrics>
- </screen>
- <para>
- If Wine detects changes in the X font configuration it will
- rebuild font metrics from scratch and then it will overwrite
- <filename>~/.wine/cachedmetrics.[display]</filename> with the new
- information. This process can take a while.
- </para>
- </sect3>
-
- <sect3>
- <title>Too Small Or Too Large Fonts</title>
- <para>
- Windows programs may ask Wine to render a font with the
- height specified in points. However, point-to-pixel ratio
- depends on the real physical size of your display (15",
- 17", etc...). X tries to provide an estimate of that but it
- can be quite different from the actual size. You can change
- this ratio by adding the following entry to the [fonts]
- section:
- </para>
- <screen>
-Resolution = <integer value>
- </screen>
- <para>
- In general, higher numbers give you larger fonts. Try to
- experiment with values in the 60 - 120 range. 96 is a good
- starting point.
- </para>
- </sect3>
-
- <sect3>
- <title>"FONT_Init: failed to load ..." Messages On Startup</title>
- <para>
- The most likely cause is a broken
- <filename>fonts.dir</filename> file in one of your font
- directories. You need to rerun <command>mkfontdir</command>
- to rebuild this file. Read its manpage for more information.
- If you can't run <command>mkfontdir</command> on this
- machine as you are not root, use <command>xset -fp
- xxx</command> to remove the broken font path.
- </para>
- </sect3>
- </sect2>
-
- <sect2 id="ttfont-server">
- <title>Setting up a TrueType Font Server</title>
- <para>
- Follow these instructions to set up a TrueType font server on your system.
- </para>
-
- <orderedlist>
- <listitem>
- <para>
- Get a freetype source archive (<filename>freetype-X.Y.tar.gz</filename> ?).
- </para>
- </listitem>
- <listitem>
- <para>
- Read docs, unpack, configure and install
- </para>
- </listitem>
- <listitem>
- <para>
- Test the library, e.g. <command>ftview 20 /dosc/win95/fonts/times</command>
- </para>
- </listitem>
- <listitem>
- <para>
- Get <filename>xfsft-beta1e.linux-i586</filename>
- </para>
- </listitem>
- <listitem>
- <para>
- Install it and start it when booting, e.g. in an
- rc-script. The manpage for <command>xfs</command>
- applies.
- </para>
- </listitem>
- <listitem>
- <para>
- Follow the hints given by <email>williamc at dai.ed.ac.uk</email>
- </para>
- </listitem>
- <listitem>
- <para>
- I got <command>xfsft</command> from
- <ulink url="http://www.dcs.ed.ac.uk/home/jec/progindex.html">http://www.dcs.ed.ac.uk/home/jec/progindex.html</ulink>.
- I have it running all the time. Here is
- <filename>/usr/X11R6/lib/X11/fs/config</filename>:
- </para>
- <programlisting>
-clone-self = on
-use-syslog = off
-catalogue = /c/windows/fonts
-error-file = /usr/X11R6/lib/X11/fs/fs-errors
-default-point-size = 120
-default-resolutions = 75,75,100,100
- </programlisting>
- <para>
- Obviously <filename>/c/windows/fonts</filename> is where
- my Windows fonts on my Win95 <medialabel>C:</medialabel>
- drive live; could be e.g.
- <filename>/mnt/dosC/windows/system</filename> for Win31.
- </para>
- <para>
- In <filename>/c/windows/fonts/fonts.scale</filename> I
- have:
- </para>
- <programlisting>
-14
-arial.ttf -monotype-arial-medium-r-normal--0-0-0-0-p-0-iso8859-1
-arialbd.ttf -monotype-arial-bold-r-normal--0-0-0-0-p-0-iso8859-1
-arialbi.ttf -monotype-arial-bold-o-normal--0-0-0-0-p-0-iso8859-1
-ariali.ttf -monotype-arial-medium-o-normal--0-0-0-0-p-0-iso8859-1
-cour.ttf -monotype-courier-medium-r-normal--0-0-0-0-p-0-iso8859-1
-courbd.ttf -monotype-courier-bold-r-normal--0-0-0-0-p-0-iso8859-1
-courbi.ttf -monotype-courier-bold-o-normal--0-0-0-0-p-0-iso8859-1
-couri.ttf -monotype-courier-medium-o-normal--0-0-0-0-p-0-iso8859-1
-times.ttf -monotype-times-medium-r-normal--0-0-0-0-p-0-iso8859-1
-timesbd.ttf -monotype-times-bold-r-normal--0-0-0-0-p-0-iso8859-1
-timesbi.ttf -monotype-times-bold-i-normal--0-0-0-0-p-0-iso8859-1
-timesi.ttf -monotype-times-medium-i-normal--0-0-0-0-p-0-iso8859-1
-symbol.ttf -monotype-symbol-medium-r-normal--0-0-0-0-p-0-microsoft-symbol
-wingding.ttf -microsoft-wingdings-medium-r-normal--0-0-0-0-p-0-microsoft-symbol
- </programlisting>
- <para>
- In <filename>/c/windows/fonts/fonts.dir</filename> I have
- exactly the same.
- </para>
- <para>
- In <filename>/usr/X11R6/lib/X11/XF86Config</filename> I have
- </para>
- <programlisting>
-FontPath "tcp/localhost:7100"
- </programlisting>
- <para>
- in front of the other <literal>FontPath</literal> lines.
- That's it! As an interesting by-product of course, all
- those web pages which specify Arial come up in Arial in
- Netscape ...
- </para>
- </listitem>
- <listitem>
- <para>
- Shut down X and restart (and debug errors you did while
- setting up everything).
- </para>
- </listitem>
- <listitem>
- <para>
- Test with e.g. <command>xlsfont | grep arial</command>
- </para>
- </listitem>
- </orderedlist>
-
- </sect2>
-
-</sect1>
-
-<!-- Keep this comment at the end of the file
-Local variables:
-mode: sgml
-sgml-parent-document:("wineusr-guide.sgml" "set" "book" "chapter" "")
-End:
--->
Index: docs/en/wineusr-printing.sgml
diff -u -p docs/en/wineusr-printing.sgml:1.2 /dev/null
--- docs/en/wineusr-printing.sgml 17 Oct 2005 12:16:25 -0000
+++ /dev/null 17 Oct 2005 12:16:25 -0000
@@ -1,214 +0,0 @@
- <sect1 id="config-printing">
- <title>Printing in Wine</title>
- <para>How to print documents in Wine...</para>
-
- <sect2 id="config-printing-intro">
- <title>Printing</title>
-
- <para>
- Printing in Wine can be done using the built-in Wine PostScript driver (+ ghostscript to produce
- output for non-PostScript printers).
- </para>
- <para>
- Note that at the moment WinPrinters (cheap, dumb printers that require
- the host computer to explicitly control the head) will not work with
- their Windows printer drivers. It is unclear whether they ever will.
- </para>
-
- <sect3>
- <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
- driver is in <filename>dlls/wineps/</filename>.
- </para>
- <para>
- The driver behaves as if it were a DRV file called
- <filename>wineps.drv</filename> which at the moment is built into
- Wine.
- Although it mimics a 16 bit driver, it will work with both 16 and 32
- bit apps, just as win9x drivers do.
- </para>
- </sect3>
-
- <sect3>
- <title>Spooling</title>
- <para>
- Spooling is rather primitive. The [spooler] section of
- the wine config file maps a port (e.g.
- <systemitem>LPT1:</systemitem>) to a file or a command via a pipe. For
- example the following lines
- </para>
- <screen>
-"LPT1:" = "foo.ps"
-"LPT2:" = "|lpr"
- </screen>
- <para>
- map <systemitem>LPT1:</systemitem> to file <filename>foo.ps</filename>
- and <systemitem>LPT2:</systemitem> to the <command>lpr</command>
- command. If a job is sent to an unlisted port, then a file is created
- with that port's name; e.g. for <systemitem>LPT3:</systemitem> a file
- called <systemitem>LPT3:</systemitem> would be created.
- </para>
- <para>
- There are now also virtual spool queues called
- <systemitem>LPR:printername</systemitem>, which send the data
- to <command>lpr -Pprintername</command>. You do not need to
- specify those in the config file, they are handled automatically by
- <filename>dlls/gdi/printdrv.c</filename>.
- </para>
- </sect3>
- </sect2>
-
- <sect2 id="config-printing-psdriver">
- <title>The Wine PostScript Driver</title>
-
- <para>
- This allows Wine to generate PostScript files without
- needing an external printer driver. Wine in this case uses the
- system provided PostScript printer filters, which almost all use
- ghostscript if necessary. Those should be configured during the
- original system installation or by your system administrator.
- </para>
-
- <sect3>
- <title>Installation</title>
- <sect4>
- <title>Installation of CUPS printers</title>
- <para>
- If you are using CUPS, you do not need to configure .ini or
- registry entries, everything is autodetected.
- </para>
- </sect4>
- <sect4>
- <title>Installation of LPR /etc/printcap based printers</title>
- <para>
- If your system is not yet using CUPS, it probably uses LPRng
- or a LPR based system with configuration based on <filename>/etc/printcap</filename>.
- </para>
- <para>
- If it does, your printers in <filename>/etc/printcap</filename>
- are scanned with a heuristic whether they are PostScript capable
- printers and also configured mostly automatic.
- </para>
- <para>
- Since Wine cannot find out what type of printer this is, you
- need to specify a PPD file in the [ppd] section of
- <filename>~/.wine/config</filename>. Either use the shortcut
- name and make the entry look like:
- </para>
- <screen>
- [ppd]
- "ps1" = "/usr/lib/wine/ps1.ppd"
- </screen>
- <para>
- Or you can specify a generic PPD file that is to match for all
- of the remaining printers. A generic PPD file can be found in
- <filename>documentation/samples/generic.ppd</filename>.
- </para>
- </sect4>
- <sect4>
- <title>Installation of other printers</title>
- <para>
- You do not need to do this if the above 2 sections apply, only if
- you have a special printer.
- </para>
- <screen>
- Wine PostScript Driver=WINEPS,LPT1:
- </screen>
- <para>
- to the [devices] section and
- </para>
- <screen>
- Wine PostScript Driver=WINEPS,LPT1:,15,45
- </screen>
- <para>
- to the [PrinterPorts] section of <filename>win.ini</filename>,
- and to set it as the default printer also add
- </para>
- <screen>
- device = Wine PostScript Driver,WINEPS,LPT1:
- </screen>
- <para>
- to the [windows] section of <filename>win.ini</filename>.
- </para>
- <para>
- You also need to add certain entries to the registry.
- The easiest way to do this is to customize the PostScript
- driver contents of <filename>wine.inf</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>#vi /usr/share/wine/wine.inf</userinput>
- </para>
- </listitem>
- <listitem>
- <para>
- Edit the copy of <filename>wine.inf</filename> to suit your
- PostScript printing requirements.
- At a minimum, you must specify a PPD file for each printer.
- </para>
- </listitem>
- <listitem>
- <para>
- <userinput>$wineprefixcreate</userinput>
- </para>
- </listitem>
- </itemizedlist>
- </para>
- </sect4>
- <sect4>
- <title>Required configuration for all printer types</title>
- <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 built-in.
- </para>
- <para>
- You'll need a PPD file for your printer. This describes
- certain characteristics of the printer such as which fonts are
- installed, how to select manual feed etc. Adobe has many of
- these on its website, have a look in
- <ulink url="ftp://ftp.adobe.com/pub/adobe/printerdrivers/win/all/">
- ftp://ftp.adobe.com/pub/adobe/printerdrivers/win/all/</ulink>.
- See above for information on configuring the driver to use this
- file.
- </para>
- <para>
- To enable colour printing you need to have the
- <literal>*ColorDevice</literal> entry in the PPD set to
- <literal>true</literal>, otherwise the driver will generate
- greyscale.
- </para>
- <para>
- 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 built-in PostScript driver.
- </para>
- <para>
- If you're lucky you should now be able to produce PS files
- from Wine!
- </para>
- <para>
- I've tested it with win3.1 notepad/write, Winword6 and
- Origin4.0 and 32 bit apps such as win98 wordpad, Winword97,
- Powerpoint2000 with some degree of success - you should be
- able to get something out, it may not be in the right place.
- </para>
- </sect4>
- </sect3>
-
- </sect2>
- </sect1>
-
-<!-- Keep this comment at the end of the file
-Local variables:
-mode: sgml
-sgml-parent-document:("wineusr-guide.sgml" "set" "book" "chapter" "")
-End:
--->
Index: docs/en/wineusr-registry.sgml
diff -u -p docs/en/wineusr-registry.sgml:1.2 /dev/null
--- docs/en/wineusr-registry.sgml 17 Oct 2005 12:16:25 -0000
+++ /dev/null 17 Oct 2005 12:16:25 -0000
@@ -1,359 +0,0 @@
- <sect1 id="registry">
- <title>The Registry</title>
-
- <para>
- After Win3.x, the registry became a fundamental part of Windows.
- It is the place where both Windows itself, and all
- Win95/98/NT/2000/XP/etc.-compliant applications, store
- configuration and state data. While most sane system
- administrators (and Wine developers) curse badly at the twisted
- nature of the Windows registry, it is still necessary for Wine
- 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>wine.inf</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>wine.inf</filename> is applied even 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.).
- This is done automatically by wine the first time you run it.
- </para>
- </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>
- </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>wine.inf</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>
-
- <para>
- The Windows registry is an elaborate tree structure, and not
- even most Windows programmers are fully aware of how the
- registry is laid out, with its different "hives" and numerous
- links between them; a full coverage is out of the scope of
- this document. But here are the basic registry keys you might
- need to know about for now.
- </para>
-
-
- <variablelist>
- <varlistentry>
- <term>HKEY_LOCAL_MACHINE</term>
- <listitem>
- <para>
- This fundamental root key (in win9x it's stored in the
- hidden file <filename>system.dat</filename>) contains
- everything pertaining to the current Windows
- installation.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>HKEY_USERS</term>
- <listitem>
- <para>
- This fundamental root key (in win9x it's stored in the
- hidden file <filename>user.dat</filename>) contains
- configuration data for every user of the installation.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>HKEY_CLASSES_ROOT</term>
- <listitem>
- <para>
- This is a link to HKEY_LOCAL_MACHINE\Software\Classes.
- It contains data describing things like file
- associations, OLE document handlers, and COM classes.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>HKEY_CURRENT_USER</term>
- <listitem>
- <para>
- This is a link to HKEY_USERS\your_username, i.e., your
- personal configuration.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- </sect2>
-
- <sect2>
- <title>Wine registry data files</title>
-
- <para>
- In the user's home directory, there is a subdirectory named
- <filename>.wine</filename>, where Wine will try to save its
- registry by default. It saves into four files, which are:
- </para>
-
- <variablelist>
- <varlistentry>
- <term><filename>system.reg</filename></term>
- <listitem>
- <para>
- This file contains HKEY_LOCAL_MACHINE.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><filename>user.reg</filename></term>
- <listitem>
- <para>
- This file contains HKEY_CURRENT_USER.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><filename>userdef.reg</filename></term>
- <listitem>
- <para>
- This file contains HKEY_USERS\.Default (i.e. the default
- user settings).
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><filename>wine.userreg</filename></term>
- <listitem>
- <para>
- Wine saves HKEY_USERS to this file (both current and
- default user), but does not load from it, unless
- <filename>userdef.reg</filename> is missing.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- <para>
- All of these files are human-readable text files, so unlike
- Windows, you can actually use an ordinary text editor on them
- if you want (make sure you don't have Wine running when modifying
- them, otherwise your changes will be discarded).
- </para>
- <para>
- 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
- global <filename>wine.conf</filename> (i.e.
- <filename>/usr/local/etc</filename> if you compiled from
- source). These are:
- </para>
-
- <variablelist>
- <varlistentry>
- <term><filename>wine.systemreg</filename></term>
- <listitem>
- <para>
- Contains HKEY_LOCAL_MACHINE.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><filename>wine.userreg</filename></term>
- <listitem>
- <para>
- Contains HKEY_USERS.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- </sect2>
-
- <sect2>
- <title>System administration</title>
-
- <para>
- With the above file structure, it is possible for a system
- administrator to configure the system so that a system Wine
- installation (and applications) can be shared by all the
- users, and still let the users all have their own personalized
- configuration. An administrator can, after having installed
- Wine and any Windows application software he wants the users
- to have access to, copy the resulting
- <filename>system.reg</filename> and
- <filename>user.reg</filename> over to the global registry
- files (which we assume will reside in
- <filename>/usr/local/etc</filename> here), with:
- </para>
- <screen>
- cd ~/.wine
- cp system.reg /usr/local/etc/wine.systemreg
- cp user.reg /usr/local/etc/wine.userreg
- </screen>
- <para>
- and perhaps even symlink these back to the administrator's
- account, to make it easier to install apps system-wide later:
- </para>
- <screen>
- ln -sf /usr/local/etc/wine.systemreg system.reg
- ln -sf /usr/local/etc/wine.userreg user.reg
- </screen>
- <para>
- Note that the <filename>tools/wineinstall</filename> script
- already does all of this for you, if you install Wine source as root.
- If you then install Windows applications while logged in as
- root, all your users will automatically be able to use them.
- While the application setup will be taken from the global
- registry, the users' personalized configurations will be saved
- in their own home directories.
- </para>
- <para>
- But be careful with what you do with the administrator account
- - if you do copy or link the administrator's registry to the
- global registry, any user might be able to read the
- administrator's preferences, which might not be good if
- sensitive information (passwords, personal information, etc)
- is stored there. Only use the administrator account to install
- software, not for daily work; use an ordinary user account for
- that.
- </para>
- </sect2>
-
- <sect2>
- <title>The [registry] section</title>
-
- <para>
- Now let's look at the <link linkend="config-file">Wine
- configuration file</link> options for handling the registry.
- </para>
-
- <variablelist>
- <varlistentry>
- <term>GlobalRegistryDir</term>
- <listitem>
- <para>
- Optional. Sets the path to look for the Global
- Registry.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>LoadGlobalRegistryFiles</term>
- <listitem>
- <para>
- Controls whether to try to load the global registry
- files, if they exist.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>LoadHomeRegistryFiles</term>
- <listitem>
- <para>
- Controls whether to try to load the user's registry
- files (in the <filename>.wine</filename> subdirectory of
- the user's home directory).
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>LoadWindowsRegistryFiles</term>
- <listitem>
- <para>
- Controls whether Wine will attempt to load registry data
- from a real Windows registry in an existing MS Windows
- installation.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>WritetoHomeRegistryFiles</term>
- <listitem>
- <para>
- Controls whether registry data will be written to the
- user's registry files. (Currently, there is no
- alternative, so if you turn this off, Wine cannot save
- the registry on disk at all; after you exit Wine, your
- changes will be lost.)
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>SaveOnlyUpdatedKeys</term>
- <listitem>
- <para>
- Controls whether the entire registry is saved to the
- user's registry files, or only subkeys the user have
- actually changed. Considering that the user's registry
- will override any global registry files and Windows
- registry files, it usually makes sense to only save
- user-modified subkeys; that way, changes to the rest of
- the global or Windows registries will still affect the
- user.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>PeriodicSave</term>
- <listitem>
- <para>
- If this option is set to a nonzero value, it specifies
- that you want the registry to be saved to disk at the
- given interval. If it is not set, the registry will only
- be saved to disk when the wineserver terminates.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>UseNewFormat</term>
- <listitem>
- <para>
- This option is obsolete. Wine now always uses the new
- format; support for the old format was removed a while
- ago.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- </sect2>
- </sect1>
-
-<!-- Keep this comment at the end of the file
-Local variables:
-mode: sgml
-sgml-parent-document:("wineusr-configuring.sgml" "chapter" "sect1" "")
-End:
--->
More information about the wine-cvs
mailing list