ReceiveTempSMS
/
Sweden-Number
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
Sweden-Number/documentation/installing.sgml

752 lines
29 KiB
Plaintext
Raw Normal View History

Converted Wine documentation to SGML format.
2000-08-08 03:24:00 +02:00
<chapter id="installing">
<title>Installing Wine</title>
<para>How to install Wine...</para>
<sect1 id="replace-windows">
<title>WWN #52 Feature: Replacing Windows</title>
<para>
Written by Ove K<>ven <email>ovek@winehq.com</email>
</para>
<sect2>
<title>Installation Overview</title>
<para>
A Windows installation consists of many different parts.
</para>
<itemizedlist>
<listitem>
<para>
Registry. Many keys are supposed to exist and contain
meaningful data, even in a newly-installed Windows.
</para>
</listitem>
<listitem>
<para>
Directory structure. Applications expect to find and/or
install things in specific predetermined locations. Most
of these directories are expected to exist. But unlike
Unix directory structures, most of these locations are
not hardcoded, and can be queried via the Windows API
and the registry. This places additional requirements on
a Wine installation.
</para>
</listitem>
<listitem>
<para>
System DLLs. In Windows, these usually reside in the
<filename>system</filename> (or
<filename>system32</filename>) directories. Some Windows
applications check for their existence in these
directories before attempting to load them. While Wine
is able to load its own internal DLLs
(<filename>.so</filename> files) when the application
asks for a DLL, Wine does not simulate the existence of
nonexisting files.
</para>
</listitem>
</itemizedlist>
<para>
While the users are of course free to set up everything
themselves, the Wine team will make the automated Wine
installation script, <filename>tools/wineinstall</filename>,
do everything we find necessary to do; running the
conventional <command>configure && make depend && make && make
install</command> 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>
</sect2>
<sect2>
<title>The Registry</title>
<para>
The default registry is in the file
<filename>winedefault.reg</filename>. It contains directory
paths, class IDs, and more; it must be installed before most
<filename>INSTALL.EXE</filename> or
<filename>SETUP.EXE</filename> applications will work. The
registry is covered in more detail in an earlier article.
</para>
</sect2>
<sect2>
<title>Directory Structure</title>
<para>
Here's the fundamental layout that Windows applications and
installers expect. Without it, they seldom operate
correctly.
</para>
<informaltable frame="none">
<tgroup cols="5">
<tbody>
<row>
<entry>C:\</entry>
<entry></entry><entry></entry><entry></entry>
<entry>Root directory of primary disk drive</entry>
</row>
<row>
<entry></entry>
<entry>Windows\</entry>
<entry></entry><entry></entry>
<entry>Windows directory, containing .INI files, accessories, etc</entry>
</row>
<row>
<entry></entry><entry></entry>
<entry valign="middle">System\</entry>
<entry></entry>
<entry><literallayout>Win3.x/95/98/ME directory for common DLLs
WinNT/2000 directory for common 16-bit DLLs</literallayout></entry>
</row>
<row>
<entry></entry><entry></entry>
<entry>System32\</entry>
<entry></entry>
<entry>WinNT/2000 directory for common 32-bit DLLs</entry>
</row>
<row>
<entry></entry><entry></entry>
<entry>Start Menu\</entry>
<entry></entry>
<entry>Program launcher directory structure</entry>
</row>
<row>
<entry></entry><entry></entry><entry></entry>
<entry>Programs\</entry>
<entry>Program launcher links (.LNK files) to applications</entry>
</row>
<row>
<entry></entry>
<entry>Program Files\</entry>
<entry></entry><entry></entry>
<entry>Application binaries (.EXE and .DLL files)</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>
Wine emulates drives by placing their virtual drive roots to
user-configurable points in the Unix filesystem, so it's
your choice where <medialabel>C:</medialabel>'s root should
be (<filename>tools/wineinstall</filename> will even ask
you). If you choose, say, <filename>/var/wine</filename>, as
the root of your virtual drive <medialabel>C</medialabel>,
then you'd put this in your <filename>wine.conf</filename>:
</para>
<programlisting>
[Drive C]
Path=/var/wine
Type=hd
Label=MS-DOS
Filesystem=win95
</programlisting>
<para>
With this configuration, what windows apps think of as
"c:\windows\system" would map to
<filename>/var/wine/windows/system</filename> in the UNIX
filesystem. Note that you need to specify
<literal>Filesystem=win95</literal>, NOT
<literal>Filesystem=unix</literal>, to make Wine simulate a
Windows-compatible (case-insensitive) filesystem, otherwise
most apps won't work.
</para>
</sect2>
<sect2>
<title>System DLLs</title>
<para>
The Wine team has determined that it is necessary to create
fake DLL files to trick many applications that check for
file existence to determine whether a particular feature
(such as Winsock and its TCP/IP networking) is available. If
this is a problem for you, you can create empty files in the
<filename>system</filename> directory to make the
application think it's there, and Wine's built-in DLL will
be loaded when the application actually asks for it.
(Unfortunately, <filename>tools/wineinstall</filename> does
not create such empty files itself.)
</para>
<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 a DLL archive such as
<ulink url="http://solo.abac.com/dllarchive/">http://solo.abac.com/dllarchive/</ulink>.
</para>
</sect2>
</sect1>
<sect1 id="no-windows">
<title>Installing Wine Without Windows</title>
<para>
written by ???
</para>
<para>
(Extracted from <filename>wine/documentation/no-windows</filename>)
</para>
<para>
A major goal of Wine is to allow users to run Windows programs
without having to install Windows on their machine. Wine
implements the functionality of the main DLL's 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 applications without Windows installed. If
you want to try it, follow these steps:
</para>
<orderedlist>
<listitem>
<para>
Create empty <filename>C:\windows</filename>,
<filename>C:\windows\system</filename>,
<filename>C:\windows\Start Menu</filename>, and
<filename>C:\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).
</para>
</listitem>
<listitem>
<para>
Point <medialabel>[Drive C]</medialabel> in
<filename>wine.conf</filename> or
<filename>.winerc</filename> to where you want
<filename>C:</filename> to be. Refer to the Wine man page
for more information. Remember to use
<userinput>filesystem=win95</userinput>!
</para>
</listitem>
<listitem>
<para>
Use <filename>tools/wineinstall</filename> to compile Wine
and install the default registry. Or if you prefer to do
it yourself, compile <filename>programs/regapi</filename>,
and run: <command>programs/regapi/regapi setValue &lt;
winedefault.reg</command>
</para>
</listitem>
<listitem>
<para>
Run and/or install your applications.
</para>
</listitem>
</orderedlist>
<para>
Because Wine is not yet complete, some programs will work
better with native Windows DLL's than with Wine's
replacements. Wine has been designed to make this possible.
Here are some tips by Juergen Schmied (and others) on how to
proceed. This assumes that your
<filename>C:\windows</filename> directory in the configuration
file does not point to a native Windows installation but is in
a separate Unix file system. (For instance, <quote>C:\windows</quote> is
really subdirectory <quote>windows</quote> located in
<quote>/home/ego/wine/drives/c</quote>).
</para>
<itemizedlist>
<listitem>
<para>
Run the application with <parameter>--debugmsg
+module,+file</parameter> to find out which files are
needed. Copy the required DLL's one by one to the
<filename>C:\windows\system</filename> directory. Do not
copy KERNEL/KERNEL32, GDI/GDI32, or USER/USER32. 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.conf</filename> or
<filename>.winerc</filename> to specify
<quote>native</quote> before <quote>builtin</quote> for
the Windows DLL's you want to use. For more information
about this, see the Wine manpage.
</para>
</listitem>
<listitem>
<para>
Note that some network DLL's are not needed even though
Wine is looking for them. The Windows
<filename>MPR.DLL</filename> currently does not work; you
must use the internal implementation.
</para>
</listitem>
<listitem>
<para>
Copy SHELL/SHELL32 and COMDLG/COMDLG32 COMMCTRL/COMCTL32
only as pairs to your Wine directory (these DLL's are
<quote>clean</quote> to use). Make sure you have these
specified in the <quote>[DllPairs]</quote> section of
<filename>wine.conf</filename> or .winerc.
</para>
</listitem>
<listitem>
<para>
Be consistent: Use only DLL's from the same Windows version
together.
</para>
</listitem>
<listitem>
<para>
Put <filename>regedit.exe</filename> in the
<filename>C:\windows</filename> directory
(<application>office95</application> imports a
<filename>*.reg</filename> file when it runs with a empty
registry, don't know about
<application>office97</application>).
</para>
</listitem>
<listitem>
<para>
Also add <filename>winhelp.exe</filename> and
<filename>winhlp32.exe</filename> if you want to be able
to browse through your programs' help function.
</para>
</listitem>
</itemizedlist>
</sect1>
<sect1 id="vfat">
<title>Dealing With FAT/VFAT Partitions</title>
<para>
written by Steven Elliott (elliotsl@mindspring.com)
</para>
<para>
(Extracted from <filename>wine/documentation/linux-fat-permissions</filename>)
</para>
<para>
This document describes how FAT and
VFAT file system permissions work in Linux
with a focus on configuring them for Wine.
</para>
<sect2>
<title>Introduction</title>
<para>
Linux is able to access DOS and Windows file systems using
either the FAT (older 8.3 DOS filesystems) or VFAT (newer
Windows 95 or later long filename filesystems) modules.
Mounted FAT or VFAT filesystems provide the primary means
for which existing applications and their data are accessed
through Wine for dual boot (Linux + Windows) systems.
</para>
<para>
Wine maps mounted FAT filesystems, such as
<filename>/c</filename>, to driver letters, such as
<quote>c:</quote>, as indicated by the
<filename>wine.conf</filename> file. The following excerpt
from a <filename>wine.conf</filename> file does this:
</para>
<programlisting>
[Drive C]
Path=/c
Type=hd
</programlisting>
<para>
Although VFAT filesystems are preferable to FAT filesystems
for their long filename support the term <quote>FAT</quote>
will be used throughout the remainder of this document to
refer to FAT filesystems and their derivatives. Also,
<quote>/c</quote> will be used as the FAT mount point in
examples throughout this document.
</para>
<para>
Most modern Linux distributions either detect or allow
existing FAT file systems to be configured so that 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 something like:
</para>
<screen>
<prompt>~></prompt><userinput>cd /c</userinput>
<prompt>/c></prompt><userinput>ls -l</userinput>
<computeroutput>-rwxr-xr-x 1 root root 91 Oct 10 17:58 autoexec.bat
-rwxr-xr-x 1 root root 245 Oct 10 17:58 config.sys
drwxr-xr-x 41 root root 16384 Dec 30 1998 windows</computeroutput>
</screen>
<para>
where all the files are owned by "root", are in the "root"
group and are only writable by "root"
(<literal>755</literal> permissions). This is restrictive in
that it requires that Wine be run as root in order for
applications to be able to write to any part of the
filesystem.
</para>
<para>
There three major approaches to overcoming the restrictive
permissions mentioned in the previous paragraph:
</para>
<orderedlist>
<listitem>
<para>
Run <application>Wine</application> as root
</para>
</listitem>
<listitem>
<para>
Mount the FAT filesystem with less restrictive
permissions
</para>
</listitem>
<listitem>
<para>
Shadow the FAT filesystem by completely or partially
copying it
</para>
</listitem>
</orderedlist>
<para>
Each approach will be discussed in the following sections.
</para>
</sect2>
<sect2>
<title>Running Wine as root</title>
<para>
Running Wine as root is the easiest and most thorough way of giving
applications that Wine runs unrestricted access to FAT files systems.
Running wine as root also allows applications to do things unrelated
to FAT filesystems, such as listening to ports that are less than
1024. Running Wine as root is dangerous since there is no limit to
what the application can do to the system.
</para>
</sect2>
<sect2>
<title>Mounting FAT filesystems</title>
<para>
The FAT filesystem can be mounted with permissions less restrictive
than the default. This can be done by either changing the user that
mounts the FAT filesystem or by explicitly changing the permissions
that the FAT filesystem is mounted with. The permissions are
inherited from the process that mounts the FAT filesystem. Since the
process that mounts the FAT filesystem is usually a startup script
running as root the FAT filesystem inherits root's permissions. This
results in the files on the FAT filesystem having permissions similar
to files created by root. For example:
</para>
<screen>
<prompt>~></prompt><userinput>whoami</userinput>
<computeroutput>root</computeroutput>
<prompt>~></prompt><userinput>touch root_file</userinput>
<prompt>~></prompt><userinput>ls -l root_file</userinput>
<computeroutput></computeroutput>-rw-r--r-- 1 root root 0 Dec 10 00:20 root_file
</screen>
<para>
which matches the owner, group and permissions of files seen
on the FAT filesystem except for the missing 'x's. The
permissions on the FAT filesystem can be changed by changing
root's umask (unset permissions bits). For example:
</para>
<screen>
<prompt>~></prompt><userinput>umount /c</userinput>
<prompt>~></prompt><userinput>umask</userinput>
<computeroutput>022</computeroutput>
<prompt>~></prompt><userinput>umask 073</userinput>
<prompt>~></prompt><userinput>mount /c</userinput>
<prompt>~></prompt><userinput>cd /c</userinput>
<prompt>/c></prompt><userinput>ls -l</userinput>
<computeroutput>-rwx---r-- 1 root root 91 Oct 10 17:58 autoexec.bat
-rwx---r-- 1 root root 245 Oct 10 17:58 config.sys
drwx---r-- 41 root root 16384 Dec 30 1998 windows</computeroutput>
</screen>
<para>
Mounting the FAT filesystem with a umask of
<literal>000</literal> gives all users complete control over
it. Explicitly specifying the permissions of the FAT
filesystem when it is mounted provides additional control.
There are three mount options that are relevant to FAT
permissions: <literal>uid</literal>, <literal>gid</literal>
and <literal>umask</literal>. They can each be specified
when the filesystem is manually mounted. For example:
</para>
<screen>
<prompt>~></prompt><userinput>umount /c</userinput>
<prompt>~></prompt><userinput>mount -o uid=500 -o gid=500 -o umask=002 /c</userinput>
<prompt>~></prompt><userinput>cd /c</userinput>
<prompt>/c></prompt><userinput>ls -l</userinput>
<computeroutput>-rwxrwxr-x 1 sle sle 91 Oct 10 17:58 autoexec.bat
-rwxrwxr-x 1 sle sle 245 Oct 10 17:58 config.sys
drwxrwxr-x 41 sle sle 16384 Dec 30 1998 windows</computeroutput>
</screen>
<para>
which gives "sle" complete control over
<filename>/c</filename>. The options listed above can be
made permanent by adding them to the
<filename>/etc/fstab</filename> file:
</para>
<screen>
<prompt>~></prompt><userinput>grep /c /etc/fstab</userinput>
<computeroutput>/dev/hda1 /c vfat uid=500,gid=500,umask=002,exec,dev,suid,rw 1 1</computeroutput>
</screen>
<para>
Note that the umask of <literal>002</literal> is common in
the user private group file permission scheme. On FAT file
systems this umask assures that all files are fully
accessible by all users in the specified group
(<literal>gid</literal>).
</para>
</sect2>
<sect2>
<title>Shadowing FAT filesystems</title>
<para>
Shadowing provides a finer granularity of control. Parts of
the original FAT filesystem can be copied so that the
application can safely work with those copied parts while
the application continue to directly read the remaining
parts. This is done with symbolic links. For example,
consider a system where an application named
<application>AnApp</application> must be able to read and
write to the <filename>c:\windows</filename> and
<filename>c:\AnApp</filename> directories as well as have
read access to the entire FAT filesystem. On this system
the FAT filesystem has default permissions which should not
be changed for security reasons or can not be changed due to
lack of root access. On this system a shadow directory
might be set up in the following manner:
</para>
<screen>
<prompt>~></prompt><userinput>cd /</userinput>
<prompt>/></prompt><userinput>mkdir c_shadow</userinput>
<prompt>/></prompt><userinput>cd c_shadow</userinput>
<prompt>/c_shadow></prompt><userinput>ln -s /c_/* .</userinput>
<prompt>/c_shadow></prompt><userinput>rm windows AnApp</userinput>
<prompt>/c_shadow></prompt><userinput>cp -R /c_/{windows,AnApp} .</userinput>
<prompt>/c_shadow></prompt><userinput>chmod -R 777 windows AnApp</userinput>
<prompt>/c_shadow></prompt><userinput>perl -p -i -e 's|/c$|/c_shadow|g' /usr/local/etc/wine.conf</userinput>
</screen>
<para>
The above gives everyone complete read and write access to
the <filename>windows</filename> and
<filename>AnApp</filename> directories while only root has
write access to all other directories.
</para>
</sect2>
</sect1>
<sect1 id="scsi-support">
<title>SCSI Support</title>
<para>
written by Bruce Milner; Additions by Andreas Mohr
</para>
<para>
(Extracted from <filename>wine/documentation/aspi</filename>)
</para>
<para>
This file describes setting up the Windows ASPI interface.
</para>
<para>
<warning>
<title>Warning/Warning/Warning!!!!!!</title>
<para>
<screen>
THIS MAY TRASH YOUR SYSTEM IF USED INCORRECTLY
THIS MAY TRASH YOUR SYSTEM IF USED CORRECTLY
</screen>
</para>
</warning>
</para>
<para>
Now that I have said that. ASPI is a direct link to SCSI devices from
windows programs. ASPI just forwards the SCSI commands that programs send
to it to the SCSI bus.
</para>
<para>
If you use the wrong scsi device in your setup file, you can send
completely bogus commands to the wrong device - An example would be
formatting your hard drives (assuming the device gave you permission -
if you're running as root, all bets are off).
</para>
<para>
So please make sure that **all** SCSI devices not needed by the program
have their permissions set as restricted as possible !
</para>
<para>
Cookbook for setting up scanner: (At least how mine is to work)
</para>
<sect2>
<title>Windows requirements</title>
<orderedlist>
<listitem>
<para>
The scanner software needs to use the "Adaptec"
compatible drivers (ASPI). At least with Mustek, they
allow you the choice of using the builtin card or the
"Adaptec (AHA)" compatible drivers. This will not work
any other way. Software that accesses the scanner via a
DOS ASPI driver (e.g. ASPI2DOS) is supported, too. [AM]
</para>
</listitem>
<listitem>
<para>
You probably need a real windows install of the software
to set the LUN's/SCSI id's up correctly. I'm not exactly
sure.
</para>
</listitem>
</orderedlist>
</sect2>
<sect2>
<title>LINUX requirements:</title>
<orderedlist>
<listitem>
<para>
Your scsi card must be supported under linux. This will
not work with an unknown scsi card. Even for cheap'n
crappy "scanner only" controllers some special Linux
drivers exist on the net.
</para>
</listitem>
<listitem>
<para>
Compile generic scsi drivers into your kernel.
</para>
</listitem>
<listitem>
<para>
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 how-to 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>
Add a scsi device entry for your particular scanner to
wine.conf. The format is <literal>[scsi
cCtTdD]</literal> where
<literal>C=controller</literal>,
<literal>T=target</literal>, <literal>D=LUN</literal>
</para>
<para>
For example, I set mine up as controller <literal>0</literal>,
Target <literal>6</literal>, LUN <literal>0</literal>.
<programlisting>
[scsi c0t6d0]
Device=/dev/sgi
</programlisting>
Yours will vary with your particular SCSI setup.
</para>
</listitem>
</orderedlist>
</sect2>
<sect2>
<title>General Information</title>
<para>
The mustek scanner I have was shipped with a package
"ipplus". This program uses the TWAIN driver specification
to access scanners.
</para>
<para>
(TWAIN MANAGER)
</para>
<para>
<programlisting>
ipplus.exe &lt;---> (TWAIN INTERFACE) &lt;---> (TWAIN DATA SOURCE . ASPI) -> WINASPI
</programlisting>
</para>
</sect2>
<sect2>
<title>NOTES/BUGS</title>
<para>
The biggest is that it only works under linux at the moment.
</para>
<para>
The ASPI code has only been tested with:
</para>
<itemizedlist>
<listitem>
<para>
a Mustek 800SP with a Buslogic controller under Linux [BM]
</para>
</listitem>
<listitem>
<para>
a Siemens Nixdorf 9036 with Adaptec AVA-1505 under Linux
accessed via DOSASPI. Note that I had color problems,
though (barely readable result) [AM]
</para>
</listitem>
<listitem>
<para>
a Fujitsu M2513A MO drive (640MB) using generic scsi
drivers. Formatting and ejecting worked perfectly.
Thanks to Uwe Bonnes for access to the hardware ! [AM]
</para>
</listitem>
</itemizedlist>
<para>
I make no warranty to the aspi code. It makes my scanner
work. Your devices may explode. I have no way of determining
this. I take zero responsibility!
</para>
</sect2>
</sect1>
</chapter>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-parent-document:("wine-doc.sgml" "book" "chapter" "")
End:
-->