mirror of
https://github.com/reactos/wine.git
synced 2024-12-04 01:41:18 +00:00
765 lines
30 KiB
Plaintext
765 lines
30 KiB
Plaintext
<chapter id="installing">
|
|
<title>Installing/compiling Wine</title>
|
|
<para>How to install Wine...</para>
|
|
|
|
<sect1 id="replace-windows" xreflabel="--Installing Section--">
|
|
<title>WWN #52 Feature: Replacing Windows</title>
|
|
|
|
<para>
|
|
Written by &name-ove-kaaven; <email>&email-ove-kaaven;</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 &name-james-juran; <email>&email-james-juran;</email>
|
|
</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 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 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 <
|
|
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 DLLs than with Wine's
|
|
replacements. Wine has been designed to make this possible.
|
|
Here are some tips by Juergen Schmied (and others) on how to
|
|
proceed. This assumes that your
|
|
<filename>C:\windows</filename> directory in the configuration
|
|
file does not point to a native Windows installation but is in
|
|
a separate Unix file system. (For instance, <quote>C:\windows</quote> is
|
|
really subdirectory <quote>windows</quote> located in
|
|
<quote>/home/ego/wine/drives/c</quote>).
|
|
</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
Run the application with <parameter>--debugmsg
|
|
+module,+file</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, 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 DLLs you want to use. For more information
|
|
about this, see the Wine manpage.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Note that some network DLLs are not needed even though
|
|
Wine is looking for them. The Windows
|
|
<filename>MPR.DLL</filename> currently does not work; you
|
|
must use the internal implementation.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Copy SHELL/SHELL32 and COMDLG/COMDLG32 COMMCTRL/COMCTL32
|
|
only as pairs to your Wine directory (these DLLs are
|
|
<quote>clean</quote> to use). Make sure you have these
|
|
specified in the <quote>[DllPairs]</quote> section of
|
|
<filename>wine.conf</filename> or .winerc.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Be consistent: Use only DLLs from the same Windows version
|
|
together.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Put <filename>regedit.exe</filename> in the
|
|
<filename>C:\windows</filename> directory.
|
|
(<application>Office 95</application> imports a
|
|
<filename>*.reg</filename> file when it runs with an empty
|
|
registry, don't know about
|
|
<application>Office 97</application>).
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Also add <filename>winhelp.exe</filename> and
|
|
<filename>winhlp32.exe</filename> if you want to be able
|
|
to browse through your programs' help function.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</sect1>
|
|
|
|
<sect1 id="vfat">
|
|
<title>Dealing With FAT/VFAT Partitions</title>
|
|
<para>
|
|
Written by &name-steven-elliott; <email>&email-steven-elliott;</email>
|
|
</para>
|
|
<para>
|
|
(Extracted from <filename>wine/documentation/linux-fat-permissions</filename>)
|
|
</para>
|
|
<para>
|
|
This document describes how FAT and
|
|
VFAT file system permissions work in Linux
|
|
with a focus on configuring them for Wine.
|
|
</para>
|
|
|
|
<sect2>
|
|
<title>Introduction</title>
|
|
<para>
|
|
Linux is able to access DOS and Windows file systems using
|
|
either the FAT (older 8.3 DOS filesystems) or VFAT (newer
|
|
Windows 95 or later long filename filesystems) modules.
|
|
Mounted FAT or VFAT filesystems provide the primary means
|
|
for which existing applications and their data are accessed
|
|
through Wine for dual boot (Linux + Windows) systems.
|
|
</para>
|
|
<para>
|
|
Wine maps mounted FAT filesystems, such as
|
|
<filename>/c</filename>, to driver letters, such as
|
|
<quote>c:</quote>, as indicated by the
|
|
<filename>wine.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 they can be
|
|
mounted, in a location such as <filename>/c</filename>,
|
|
either persistently (on bootup) or on an as needed basis. In
|
|
either case, by default, the permissions will probably be
|
|
configured so that they look like:
|
|
</para>
|
|
<screen>
|
|
<prompt>~></prompt><userinput>cd /c</userinput>
|
|
<prompt>/c></prompt><userinput>ls -l</userinput>
|
|
<computeroutput>-rwxr-xr-x 1 root root 91 Oct 10 17:58 autoexec.bat
|
|
-rwxr-xr-x 1 root root 245 Oct 10 17:58 config.sys
|
|
drwxr-xr-x 41 root root 16384 Dec 30 1998 windows</computeroutput>
|
|
</screen>
|
|
<para>
|
|
where all the files are owned by "root", are in the "root"
|
|
group and are only writable by "root"
|
|
(<literal>755</literal> permissions). This is restrictive in
|
|
that it requires that Wine be run as root in order for
|
|
applications to be able to write to any part of the
|
|
filesystem.
|
|
</para>
|
|
<para>
|
|
There are three major approaches to overcoming the restrictive
|
|
permissions mentioned in the previous paragraph:
|
|
</para>
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>
|
|
Run <application>Wine</application> as root
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Mount the FAT filesystem with less restrictive
|
|
permissions
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Shadow the FAT filesystem by completely or partially
|
|
copying it
|
|
</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
<para>
|
|
Each approach will be discussed in the following sections.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Running Wine as root</title>
|
|
<para>
|
|
Running Wine as root is the easiest and most thorough way of giving
|
|
applications that Wine runs unrestricted access to FAT files systems.
|
|
Running wine as root also allows applications to do things unrelated
|
|
to FAT filesystems, such as listening to ports that are less than
|
|
1024. Running Wine as root is dangerous since there is no limit to
|
|
what the application can do to the system.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Mounting FAT filesystems</title>
|
|
<para>
|
|
The FAT filesystem can be mounted with permissions less restrictive
|
|
than the default. This can be done by either changing the user that
|
|
mounts the FAT filesystem or by explicitly changing the permissions
|
|
that the FAT filesystem is mounted with. The permissions are
|
|
inherited from the process that mounts the FAT filesystem. Since the
|
|
process that mounts the FAT filesystem is usually a startup script
|
|
running as root the FAT filesystem inherits root's permissions. This
|
|
results in the files on the FAT filesystem having permissions similar
|
|
to files created by root. For example:
|
|
</para>
|
|
<screen>
|
|
<prompt>~></prompt><userinput>whoami</userinput>
|
|
<computeroutput>root</computeroutput>
|
|
<prompt>~></prompt><userinput>touch root_file</userinput>
|
|
<prompt>~></prompt><userinput>ls -l root_file</userinput>
|
|
<computeroutput></computeroutput>-rw-r--r-- 1 root root 0 Dec 10 00:20 root_file
|
|
</screen>
|
|
<para>
|
|
which matches the owner, group and permissions of files seen
|
|
on the FAT filesystem except for the missing 'x's. The
|
|
permissions on the FAT filesystem can be changed by changing
|
|
root's umask (unset permissions bits). For example:
|
|
</para>
|
|
<screen>
|
|
<prompt>~></prompt><userinput>umount /c</userinput>
|
|
<prompt>~></prompt><userinput>umask</userinput>
|
|
<computeroutput>022</computeroutput>
|
|
<prompt>~></prompt><userinput>umask 073</userinput>
|
|
<prompt>~></prompt><userinput>mount /c</userinput>
|
|
<prompt>~></prompt><userinput>cd /c</userinput>
|
|
<prompt>/c></prompt><userinput>ls -l</userinput>
|
|
<computeroutput>-rwx---r-- 1 root root 91 Oct 10 17:58 autoexec.bat
|
|
-rwx---r-- 1 root root 245 Oct 10 17:58 config.sys
|
|
drwx---r-- 41 root root 16384 Dec 30 1998 windows</computeroutput>
|
|
</screen>
|
|
<para>
|
|
Mounting the FAT filesystem with a umask of
|
|
<literal>000</literal> gives all users complete control over
|
|
it. Explicitly specifying the permissions of the FAT
|
|
filesystem when it is mounted provides additional control.
|
|
There are three mount options that are relevant to FAT
|
|
permissions: <literal>uid</literal>, <literal>gid</literal>
|
|
and <literal>umask</literal>. They can each be specified
|
|
when the filesystem is manually mounted. For example:
|
|
</para>
|
|
<screen>
|
|
<prompt>~></prompt><userinput>umount /c</userinput>
|
|
<prompt>~></prompt><userinput>mount -o uid=500 -o gid=500 -o umask=002 /c</userinput>
|
|
<prompt>~></prompt><userinput>cd /c</userinput>
|
|
<prompt>/c></prompt><userinput>ls -l</userinput>
|
|
<computeroutput>-rwxrwxr-x 1 sle sle 91 Oct 10 17:58 autoexec.bat
|
|
-rwxrwxr-x 1 sle sle 245 Oct 10 17:58 config.sys
|
|
drwxrwxr-x 41 sle sle 16384 Dec 30 1998 windows</computeroutput>
|
|
</screen>
|
|
<para>
|
|
which gives "sle" complete control over
|
|
<filename>/c</filename>. The options listed above can be
|
|
made permanent by adding them to the
|
|
<filename>/etc/fstab</filename> file:
|
|
</para>
|
|
<screen>
|
|
<prompt>~></prompt><userinput>grep /c /etc/fstab</userinput>
|
|
<computeroutput>/dev/hda1 /c vfat uid=500,gid=500,umask=002,exec,dev,suid,rw 1 1</computeroutput>
|
|
</screen>
|
|
<para>
|
|
Note that the umask of <literal>002</literal> is common in
|
|
the user private group file permission scheme. On FAT file
|
|
systems this umask assures that all files are fully
|
|
accessible by all users in the specified group
|
|
(<literal>gid</literal>).
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Shadowing FAT filesystems</title>
|
|
<para>
|
|
Shadowing provides a finer granularity of control. Parts of
|
|
the original FAT filesystem can be copied so that the
|
|
application can safely work with those copied parts while
|
|
the application continues to directly read the remaining
|
|
parts. This is done with symbolic links. For example,
|
|
consider a system where an application named
|
|
<application>AnApp</application> must be able to read and
|
|
write to the <filename>c:\windows</filename> and
|
|
<filename>c:\AnApp</filename> directories as well as have
|
|
read access to the entire FAT filesystem. On this system
|
|
the FAT filesystem has default permissions which should not
|
|
be changed for security reasons or can not be changed due to
|
|
lack of root access. On this system a shadow directory
|
|
might be set up in the following manner:
|
|
</para>
|
|
<screen>
|
|
<prompt>~></prompt><userinput>cd /</userinput>
|
|
<prompt>/></prompt><userinput>mkdir c_shadow</userinput>
|
|
<prompt>/></prompt><userinput>cd c_shadow</userinput>
|
|
<prompt>/c_shadow></prompt><userinput>ln -s /c_/* .</userinput>
|
|
<prompt>/c_shadow></prompt><userinput>rm windows AnApp</userinput>
|
|
<prompt>/c_shadow></prompt><userinput>cp -R /c_/{windows,AnApp} .</userinput>
|
|
<prompt>/c_shadow></prompt><userinput>chmod -R 777 windows AnApp</userinput>
|
|
<prompt>/c_shadow></prompt><userinput>perl -p -i -e 's|/c$|/c_shadow|g' /usr/local/etc/wine.conf</userinput>
|
|
</screen>
|
|
<para>
|
|
The above gives everyone complete read and write access to
|
|
the <filename>windows</filename> and
|
|
<filename>AnApp</filename> directories while only root has
|
|
write access to all other directories.
|
|
</para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="scsi-support">
|
|
<title>SCSI Support</title>
|
|
<para>
|
|
Written by &name-bruce-milner; <email>&email-bruce-milner;</email>;
|
|
Additions by &name-andreas-mohr; <email>&email-andreas-mohr;</email>
|
|
</para>
|
|
<para>
|
|
(Extracted from <filename>wine/documentation/aspi</filename>)
|
|
</para>
|
|
|
|
<para>
|
|
This file describes setting up the Windows ASPI interface.
|
|
</para>
|
|
|
|
<para>
|
|
<warning>
|
|
<title>Warning/Warning/Warning!!!!!!</title>
|
|
<para>
|
|
<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 <emphasis>all</emphasis> SCSI devices not needed by the program
|
|
have their permissions set as restricted as possible !
|
|
</para>
|
|
|
|
<para>
|
|
Cookbook for setting up scanner: (At least how mine is to work)
|
|
(well, for other devices such as CD burners, MO drives, ..., too)
|
|
</para>
|
|
|
|
<sect2>
|
|
<title>Windows requirements</title>
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>
|
|
The scanner software needs to use the "Adaptec"
|
|
compatible drivers (ASPI). At least with Mustek, they
|
|
allow you the choice of using the builtin card or the
|
|
"Adaptec (AHA)" compatible drivers. This will not work
|
|
any other way. Software that accesses the scanner via a
|
|
DOS ASPI driver (e.g. ASPI2DOS) is supported, too. [AM]
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
You probably need a real windows install of the software
|
|
to set the LUN's/SCSI id's up correctly. I'm not exactly
|
|
sure.
|
|
</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>LINUX requirements:</title>
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>
|
|
Your SCSI card must be supported under linux. This will
|
|
not work with an unknown SCSI card. Even for cheap'n
|
|
crappy "scanner only" controllers some special Linux
|
|
drivers exist on the net.
|
|
If you intend to use your IDE device, you need to use the
|
|
ide-scsi emulation.
|
|
Read
|
|
<ulink url="http://www.linuxdoc.org/HOWTO/CD-Writing-HOWTO.html">
|
|
http://www.linuxdoc.org/HOWTO/CD-Writing-HOWTO.html</ulink>
|
|
for ide-scsi setup instructions.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Compile generic SCSI drivers into your kernel.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
This seems to be not required any more for newer (2.2.x) kernels:
|
|
Linux by default uses smaller SCSI buffers than Windows.
|
|
There is a kernel build define <literal>SG_BIG_BUFF</literal> (in
|
|
<filename>sg.h</filename>) that is by default set too
|
|
low. The SANE project recommends
|
|
<literal>130560</literal> and this seems to work just
|
|
fine. This does require a kernel rebuild.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Make the devices for the scanner (generic SCSI devices)
|
|
- look at the SCSI programming HOWTO at
|
|
<ulink url="http://www.linuxdoc.org/HOWTO/SCSI-Programming-HOWTO.html">
|
|
http://www.linuxdoc.org/HOWTO/SCSI-Programming-HOWTO.html</ulink>
|
|
for device numbering.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
I would recommend making the scanner device writable by
|
|
a group. I made a group called
|
|
<literal>scanner</literal> and added myself to it.
|
|
Running as root increases your risk of sending bad SCSI
|
|
commands to the wrong device. With a regular user, you
|
|
are better protected.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
For Win32 software (WNASPI32), Wine has auto-detection in place.
|
|
For Win16 software (WINASPI), you need to add a SCSI device entry
|
|
for your particular scanner to wine.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 <---> (TWAIN INTERFACE) <---> (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" "set" "book" "chapter" "")
|
|
End:
|
|
-->
|