Build the debugger as a .so.
[wine/multimedia.git] / documentation / installing.sgml
blob9aed0147cda34cc330a8b499bdc292c0191f5aea
1 <chapter id="installing">
2 <title>Installing Wine</title>
3 <para>How to install Wine...</para>
5 <sect1 id="replace-windows">
6 <title>WWN #52 Feature: Replacing Windows</title>
8 <para>
9 Written by Ove Kåven <email>ovek@winehq.com</email>
10 </para>
12 <sect2>
13 <title>Installation Overview</title>
15 <para>
16 A Windows installation consists of many different parts.
17 </para>
19 <itemizedlist>
20 <listitem>
21 <para>
22 Registry. Many keys are supposed to exist and contain
23 meaningful data, even in a newly-installed Windows.
24 </para>
25 </listitem>
26 <listitem>
27 <para>
28 Directory structure. Applications expect to find and/or
29 install things in specific predetermined locations. Most
30 of these directories are expected to exist. But unlike
31 Unix directory structures, most of these locations are
32 not hardcoded, and can be queried via the Windows API
33 and the registry. This places additional requirements on
34 a Wine installation.
35 </para>
36 </listitem>
37 <listitem>
38 <para>
39 System DLLs. In Windows, these usually reside in the
40 <filename>system</filename> (or
41 <filename>system32</filename>) directories. Some Windows
42 applications check for their existence in these
43 directories before attempting to load them. While Wine
44 is able to load its own internal DLLs
45 (<filename>.so</filename> files) when the application
46 asks for a DLL, Wine does not simulate the existence of
47 nonexisting files.
48 </para>
49 </listitem>
50 </itemizedlist>
52 <para>
53 While the users are of course free to set up everything
54 themselves, the Wine team will make the automated Wine
55 installation script, <filename>tools/wineinstall</filename>,
56 do everything we find necessary to do; running the
57 conventional <command>configure && make depend && make && make
58 install</command> cycle is thus not recommended, unless
59 you know what you're doing. At the moment,
60 <filename>tools/wineinstall</filename> is able to create a
61 configuration file, install the registry, and create the
62 directory structure itself.
63 </para>
64 </sect2>
66 <sect2>
67 <title>The Registry</title>
68 <para>
69 The default registry is in the file
70 <filename>winedefault.reg</filename>. It contains directory
71 paths, class IDs, and more; it must be installed before most
72 <filename>INSTALL.EXE</filename> or
73 <filename>SETUP.EXE</filename> applications will work. The
74 registry is covered in more detail in an earlier article.
75 </para>
76 </sect2>
78 <sect2>
79 <title>Directory Structure</title>
80 <para>
81 Here's the fundamental layout that Windows applications and
82 installers expect. Without it, they seldom operate
83 correctly.
84 </para>
86 <informaltable frame="none">
87 <tgroup cols="5">
88 <tbody>
89 <row>
90 <entry>C:\</entry>
91 <entry></entry><entry></entry><entry></entry>
92 <entry>Root directory of primary disk drive</entry>
93 </row>
94 <row>
95 <entry></entry>
96 <entry>Windows\</entry>
97 <entry></entry><entry></entry>
98 <entry>Windows directory, containing .INI files, accessories, etc</entry>
99 </row>
100 <row>
101 <entry></entry><entry></entry>
102 <entry valign="middle">System\</entry>
103 <entry></entry>
104 <entry><literallayout>Win3.x/95/98/ME directory for common DLLs
105 WinNT/2000 directory for common 16-bit DLLs</literallayout></entry>
106 </row>
107 <row>
108 <entry></entry><entry></entry>
109 <entry>System32\</entry>
110 <entry></entry>
111 <entry>WinNT/2000 directory for common 32-bit DLLs</entry>
112 </row>
113 <row>
114 <entry></entry><entry></entry>
115 <entry>Start Menu\</entry>
116 <entry></entry>
117 <entry>Program launcher directory structure</entry>
118 </row>
119 <row>
120 <entry></entry><entry></entry><entry></entry>
121 <entry>Programs\</entry>
122 <entry>Program launcher links (.LNK files) to applications</entry>
123 </row>
124 <row>
125 <entry></entry>
126 <entry>Program Files\</entry>
127 <entry></entry><entry></entry>
128 <entry>Application binaries (.EXE and .DLL files)</entry>
129 </row>
130 </tbody>
131 </tgroup>
132 </informaltable>
134 <para>
135 Wine emulates drives by placing their virtual drive roots to
136 user-configurable points in the Unix filesystem, so it's
137 your choice where <medialabel>C:</medialabel>'s root should
138 be (<filename>tools/wineinstall</filename> will even ask
139 you). If you choose, say, <filename>/var/wine</filename>, as
140 the root of your virtual drive <medialabel>C</medialabel>,
141 then you'd put this in your <filename>wine.conf</filename>:
142 </para>
144 <programlisting>
145 [Drive C]
146 Path=/var/wine
147 Type=hd
148 Label=MS-DOS
149 Filesystem=win95
150 </programlisting>
152 <para>
153 With this configuration, what windows apps think of as
154 "c:\windows\system" would map to
155 <filename>/var/wine/windows/system</filename> in the UNIX
156 filesystem. Note that you need to specify
157 <literal>Filesystem=win95</literal>, NOT
158 <literal>Filesystem=unix</literal>, to make Wine simulate a
159 Windows-compatible (case-insensitive) filesystem, otherwise
160 most apps won't work.
161 </para>
162 </sect2>
164 <sect2>
165 <title>System DLLs</title>
166 <para>
167 The Wine team has determined that it is necessary to create
168 fake DLL files to trick many applications that check for
169 file existence to determine whether a particular feature
170 (such as Winsock and its TCP/IP networking) is available. If
171 this is a problem for you, you can create empty files in the
172 <filename>system</filename> directory to make the
173 application think it's there, and Wine's built-in DLL will
174 be loaded when the application actually asks for it.
175 (Unfortunately, <filename>tools/wineinstall</filename> does
176 not create such empty files itself.)
177 </para>
178 <para>
179 Applications sometimes also try to inspect the version
180 resources from the physical files (for example, to determine
181 the DirectX version). Empty files will not do in this case,
182 it is rather necessary to install files with complete
183 version resources. This problem is currently being worked
184 on. In the meantime, you may still need to grab some real
185 DLL files to fool these apps with.
186 </para>
187 <para>
188 And there are of course DLLs that wine does not currently
189 implement very well (or at all). If you do not have a real
190 Windows you can steal necessary DLLs from, you can always
191 get some from a DLL archive such as
192 <ulink url="http://solo.abac.com/dllarchive/">http://solo.abac.com/dllarchive/</ulink>.
193 </para>
194 </sect2>
195 </sect1>
197 <sect1 id="no-windows">
198 <title>Installing Wine Without Windows</title>
199 <para>
200 written by ???
201 </para>
202 <para>
203 (Extracted from <filename>wine/documentation/no-windows</filename>)
204 </para>
206 <para>
207 A major goal of Wine is to allow users to run Windows programs
208 without having to install Windows on their machine. Wine
209 implements the functionality of the main DLL's usually
210 provided with Windows. Therefore, once Wine is finished, you
211 will not need to have windows installed to use Wine.
212 </para>
213 <para>
214 Wine has already made enough progress that it may be possible
215 to run your target applications without Windows installed. If
216 you want to try it, follow these steps:
217 </para>
219 <orderedlist>
220 <listitem>
221 <para>
222 Create empty <filename>C:\windows</filename>,
223 <filename>C:\windows\system</filename>,
224 <filename>C:\windows\Start Menu</filename>, and
225 <filename>C:\windows\Start Menu\Programs</filename>
226 directories. Do not point Wine to a
227 <filename>Windows</filename> directory full of old
228 installations and a messy registry. (Wine creates a
229 special registry in your <filename >home</filename>
230 directory, in <filename>$HOME/.wine/*.reg</filename>.
231 Perhaps you have to remove these files).
232 </para>
233 </listitem>
234 <listitem>
235 <para>
236 Point <medialabel>[Drive C]</medialabel> in
237 <filename>wine.conf</filename> or
238 <filename>.winerc</filename> to where you want
239 <filename>C:</filename> to be. Refer to the Wine man page
240 for more information. Remember to use
241 <userinput>filesystem=win95</userinput>!
242 </para>
243 </listitem>
244 <listitem>
245 <para>
246 Use <filename>tools/wineinstall</filename> to compile Wine
247 and install the default registry. Or if you prefer to do
248 it yourself, compile <filename>programs/regapi</filename>,
249 and run: <command>programs/regapi/regapi setValue &lt;
250 winedefault.reg</command>
251 </para>
252 </listitem>
253 <listitem>
254 <para>
255 Run and/or install your applications.
256 </para>
257 </listitem>
258 </orderedlist>
260 <para>
261 Because Wine is not yet complete, some programs will work
262 better with native Windows DLL's than with Wine's
263 replacements. Wine has been designed to make this possible.
264 Here are some tips by Juergen Schmied (and others) on how to
265 proceed. This assumes that your
266 <filename>C:\windows</filename> directory in the configuration
267 file does not point to a native Windows installation but is in
268 a separate Unix file system. (For instance, <quote>C:\windows</quote> is
269 really subdirectory <quote>windows</quote> located in
270 <quote>/home/ego/wine/drives/c</quote>).
271 </para>
273 <itemizedlist>
274 <listitem>
275 <para>
276 Run the application with <parameter>--debugmsg
277 +module,+file</parameter> to find out which files are
278 needed. Copy the required DLL's one by one to the
279 <filename>C:\windows\system</filename> directory. Do not
280 copy KERNEL/KERNEL32, GDI/GDI32, or USER/USER32. These
281 implement the core functionality of the Windows API, and
282 the Wine internal versions must be used.
283 </para>
284 </listitem>
285 <listitem>
286 <para>
287 Edit the <quote>[DllOverrides]</quote> section of
288 <filename>wine.conf</filename> or
289 <filename>.winerc</filename> to specify
290 <quote>native</quote> before <quote>builtin</quote> for
291 the Windows DLL's you want to use. For more information
292 about this, see the Wine manpage.
293 </para>
294 </listitem>
295 <listitem>
296 <para>
297 Note that some network DLL's are not needed even though
298 Wine is looking for them. The Windows
299 <filename>MPR.DLL</filename> currently does not work; you
300 must use the internal implementation.
301 </para>
302 </listitem>
303 <listitem>
304 <para>
305 Copy SHELL/SHELL32 and COMDLG/COMDLG32 COMMCTRL/COMCTL32
306 only as pairs to your Wine directory (these DLL's are
307 <quote>clean</quote> to use). Make sure you have these
308 specified in the <quote>[DllPairs]</quote> section of
309 <filename>wine.conf</filename> or .winerc.
310 </para>
311 </listitem>
312 <listitem>
313 <para>
314 Be consistent: Use only DLL's from the same Windows version
315 together.
316 </para>
317 </listitem>
318 <listitem>
319 <para>
320 Put <filename>regedit.exe</filename> in the
321 <filename>C:\windows</filename> directory
322 (<application>office95</application> imports a
323 <filename>*.reg</filename> file when it runs with a empty
324 registry, don't know about
325 <application>office97</application>).
326 </para>
327 </listitem>
328 <listitem>
329 <para>
330 Also add <filename>winhelp.exe</filename> and
331 <filename>winhlp32.exe</filename> if you want to be able
332 to browse through your programs' help function.
333 </para>
334 </listitem>
335 </itemizedlist>
336 </sect1>
338 <sect1 id="vfat">
339 <title>Dealing With FAT/VFAT Partitions</title>
340 <para>
341 written by Steven Elliott (elliotsl@mindspring.com)
342 </para>
343 <para>
344 (Extracted from <filename>wine/documentation/linux-fat-permissions</filename>)
345 </para>
346 <para>
347 This document describes how FAT and
348 VFAT file system permissions work in Linux
349 with a focus on configuring them for Wine.
350 </para>
352 <sect2>
353 <title>Introduction</title>
354 <para>
355 Linux is able to access DOS and Windows file systems using
356 either the FAT (older 8.3 DOS filesystems) or VFAT (newer
357 Windows 95 or later long filename filesystems) modules.
358 Mounted FAT or VFAT filesystems provide the primary means
359 for which existing applications and their data are accessed
360 through Wine for dual boot (Linux + Windows) systems.
361 </para>
362 <para>
363 Wine maps mounted FAT filesystems, such as
364 <filename>/c</filename>, to driver letters, such as
365 <quote>c:</quote>, as indicated by the
366 <filename>wine.conf</filename> file. The following excerpt
367 from a <filename>wine.conf</filename> file does this:
368 </para>
369 <programlisting>
370 [Drive C]
371 Path=/c
372 Type=hd
373 </programlisting>
374 <para>
375 Although VFAT filesystems are preferable to FAT filesystems
376 for their long filename support the term <quote>FAT</quote>
377 will be used throughout the remainder of this document to
378 refer to FAT filesystems and their derivatives. Also,
379 <quote>/c</quote> will be used as the FAT mount point in
380 examples throughout this document.
381 </para>
382 <para>
383 Most modern Linux distributions either detect or allow
384 existing FAT file systems to be configured so that can be
385 mounted, in a location such as <filename>/c</filename>,
386 either persistently (on bootup) or on an as needed basis. In
387 either case, by default, the permissions will probably be
388 configured so that they look something like:
389 </para>
390 <screen>
391 <prompt>~></prompt><userinput>cd /c</userinput>
392 <prompt>/c></prompt><userinput>ls -l</userinput>
393 <computeroutput>-rwxr-xr-x 1 root root 91 Oct 10 17:58 autoexec.bat
394 -rwxr-xr-x 1 root root 245 Oct 10 17:58 config.sys
395 drwxr-xr-x 41 root root 16384 Dec 30 1998 windows</computeroutput>
396 </screen>
397 <para>
398 where all the files are owned by "root", are in the "root"
399 group and are only writable by "root"
400 (<literal>755</literal> permissions). This is restrictive in
401 that it requires that Wine be run as root in order for
402 applications to be able to write to any part of the
403 filesystem.
404 </para>
405 <para>
406 There three major approaches to overcoming the restrictive
407 permissions mentioned in the previous paragraph:
408 </para>
409 <orderedlist>
410 <listitem>
411 <para>
412 Run <application>Wine</application> as root
413 </para>
414 </listitem>
415 <listitem>
416 <para>
417 Mount the FAT filesystem with less restrictive
418 permissions
419 </para>
420 </listitem>
421 <listitem>
422 <para>
423 Shadow the FAT filesystem by completely or partially
424 copying it
425 </para>
426 </listitem>
427 </orderedlist>
428 <para>
429 Each approach will be discussed in the following sections.
430 </para>
431 </sect2>
433 <sect2>
434 <title>Running Wine as root</title>
435 <para>
436 Running Wine as root is the easiest and most thorough way of giving
437 applications that Wine runs unrestricted access to FAT files systems.
438 Running wine as root also allows applications to do things unrelated
439 to FAT filesystems, such as listening to ports that are less than
440 1024. Running Wine as root is dangerous since there is no limit to
441 what the application can do to the system.
442 </para>
443 </sect2>
445 <sect2>
446 <title>Mounting FAT filesystems</title>
447 <para>
448 The FAT filesystem can be mounted with permissions less restrictive
449 than the default. This can be done by either changing the user that
450 mounts the FAT filesystem or by explicitly changing the permissions
451 that the FAT filesystem is mounted with. The permissions are
452 inherited from the process that mounts the FAT filesystem. Since the
453 process that mounts the FAT filesystem is usually a startup script
454 running as root the FAT filesystem inherits root's permissions. This
455 results in the files on the FAT filesystem having permissions similar
456 to files created by root. For example:
457 </para>
458 <screen>
459 <prompt>~></prompt><userinput>whoami</userinput>
460 <computeroutput>root</computeroutput>
461 <prompt>~></prompt><userinput>touch root_file</userinput>
462 <prompt>~></prompt><userinput>ls -l root_file</userinput>
463 <computeroutput></computeroutput>-rw-r--r-- 1 root root 0 Dec 10 00:20 root_file
464 </screen>
465 <para>
466 which matches the owner, group and permissions of files seen
467 on the FAT filesystem except for the missing 'x's. The
468 permissions on the FAT filesystem can be changed by changing
469 root's umask (unset permissions bits). For example:
470 </para>
471 <screen>
472 <prompt>~></prompt><userinput>umount /c</userinput>
473 <prompt>~></prompt><userinput>umask</userinput>
474 <computeroutput>022</computeroutput>
475 <prompt>~></prompt><userinput>umask 073</userinput>
476 <prompt>~></prompt><userinput>mount /c</userinput>
477 <prompt>~></prompt><userinput>cd /c</userinput>
478 <prompt>/c></prompt><userinput>ls -l</userinput>
479 <computeroutput>-rwx---r-- 1 root root 91 Oct 10 17:58 autoexec.bat
480 -rwx---r-- 1 root root 245 Oct 10 17:58 config.sys
481 drwx---r-- 41 root root 16384 Dec 30 1998 windows</computeroutput>
482 </screen>
483 <para>
484 Mounting the FAT filesystem with a umask of
485 <literal>000</literal> gives all users complete control over
486 it. Explicitly specifying the permissions of the FAT
487 filesystem when it is mounted provides additional control.
488 There are three mount options that are relevant to FAT
489 permissions: <literal>uid</literal>, <literal>gid</literal>
490 and <literal>umask</literal>. They can each be specified
491 when the filesystem is manually mounted. For example:
492 </para>
493 <screen>
494 <prompt>~></prompt><userinput>umount /c</userinput>
495 <prompt>~></prompt><userinput>mount -o uid=500 -o gid=500 -o umask=002 /c</userinput>
496 <prompt>~></prompt><userinput>cd /c</userinput>
497 <prompt>/c></prompt><userinput>ls -l</userinput>
498 <computeroutput>-rwxrwxr-x 1 sle sle 91 Oct 10 17:58 autoexec.bat
499 -rwxrwxr-x 1 sle sle 245 Oct 10 17:58 config.sys
500 drwxrwxr-x 41 sle sle 16384 Dec 30 1998 windows</computeroutput>
501 </screen>
502 <para>
503 which gives "sle" complete control over
504 <filename>/c</filename>. The options listed above can be
505 made permanent by adding them to the
506 <filename>/etc/fstab</filename> file:
507 </para>
508 <screen>
509 <prompt>~></prompt><userinput>grep /c /etc/fstab</userinput>
510 <computeroutput>/dev/hda1 /c vfat uid=500,gid=500,umask=002,exec,dev,suid,rw 1 1</computeroutput>
511 </screen>
512 <para>
513 Note that the umask of <literal>002</literal> is common in
514 the user private group file permission scheme. On FAT file
515 systems this umask assures that all files are fully
516 accessible by all users in the specified group
517 (<literal>gid</literal>).
518 </para>
519 </sect2>
521 <sect2>
522 <title>Shadowing FAT filesystems</title>
523 <para>
524 Shadowing provides a finer granularity of control. Parts of
525 the original FAT filesystem can be copied so that the
526 application can safely work with those copied parts while
527 the application continue to directly read the remaining
528 parts. This is done with symbolic links. For example,
529 consider a system where an application named
530 <application>AnApp</application> must be able to read and
531 write to the <filename>c:\windows</filename> and
532 <filename>c:\AnApp</filename> directories as well as have
533 read access to the entire FAT filesystem. On this system
534 the FAT filesystem has default permissions which should not
535 be changed for security reasons or can not be changed due to
536 lack of root access. On this system a shadow directory
537 might be set up in the following manner:
538 </para>
539 <screen>
540 <prompt>~></prompt><userinput>cd /</userinput>
541 <prompt>/></prompt><userinput>mkdir c_shadow</userinput>
542 <prompt>/></prompt><userinput>cd c_shadow</userinput>
543 <prompt>/c_shadow></prompt><userinput>ln -s /c_/* .</userinput>
544 <prompt>/c_shadow></prompt><userinput>rm windows AnApp</userinput>
545 <prompt>/c_shadow></prompt><userinput>cp -R /c_/{windows,AnApp} .</userinput>
546 <prompt>/c_shadow></prompt><userinput>chmod -R 777 windows AnApp</userinput>
547 <prompt>/c_shadow></prompt><userinput>perl -p -i -e 's|/c$|/c_shadow|g' /usr/local/etc/wine.conf</userinput>
548 </screen>
549 <para>
550 The above gives everyone complete read and write access to
551 the <filename>windows</filename> and
552 <filename>AnApp</filename> directories while only root has
553 write access to all other directories.
554 </para>
555 </sect2>
556 </sect1>
558 <sect1 id="scsi-support">
559 <title>SCSI Support</title>
560 <para>
561 written by Bruce Milner; Additions by Andreas Mohr
562 </para>
563 <para>
564 (Extracted from <filename>wine/documentation/aspi</filename>)
565 </para>
567 <para>
568 This file describes setting up the Windows ASPI interface.
569 </para>
571 <para>
572 <warning>
573 <title>Warning/Warning/Warning!!!!!!</title>
574 <para>
575 <screen>
576 THIS MAY TRASH YOUR SYSTEM IF USED INCORRECTLY
577 THIS MAY TRASH YOUR SYSTEM IF USED CORRECTLY
578 </screen>
579 </para>
580 </warning>
581 </para>
583 <para>
584 Now that I have said that. ASPI is a direct link to SCSI devices from
585 windows programs. ASPI just forwards the SCSI commands that programs send
586 to it to the SCSI bus.
587 </para>
588 <para>
589 If you use the wrong scsi device in your setup file, you can send
590 completely bogus commands to the wrong device - An example would be
591 formatting your hard drives (assuming the device gave you permission -
592 if you're running as root, all bets are off).
593 </para>
594 <para>
595 So please make sure that **all** SCSI devices not needed by the program
596 have their permissions set as restricted as possible !
597 </para>
599 <para>
600 Cookbook for setting up scanner: (At least how mine is to work)
601 </para>
603 <sect2>
604 <title>Windows requirements</title>
605 <orderedlist>
606 <listitem>
607 <para>
608 The scanner software needs to use the "Adaptec"
609 compatible drivers (ASPI). At least with Mustek, they
610 allow you the choice of using the builtin card or the
611 "Adaptec (AHA)" compatible drivers. This will not work
612 any other way. Software that accesses the scanner via a
613 DOS ASPI driver (e.g. ASPI2DOS) is supported, too. [AM]
614 </para>
615 </listitem>
616 <listitem>
617 <para>
618 You probably need a real windows install of the software
619 to set the LUN's/SCSI id's up correctly. I'm not exactly
620 sure.
621 </para>
622 </listitem>
623 </orderedlist>
624 </sect2>
626 <sect2>
627 <title>LINUX requirements:</title>
628 <orderedlist>
629 <listitem>
630 <para>
631 Your scsi card must be supported under linux. This will
632 not work with an unknown scsi card. Even for cheap'n
633 crappy "scanner only" controllers some special Linux
634 drivers exist on the net.
635 </para>
636 </listitem>
637 <listitem>
638 <para>
639 Compile generic scsi drivers into your kernel.
640 </para>
641 </listitem>
642 <listitem>
643 <para>
644 Linux by default uses smaller scsi buffers than Windows.
645 There is a kernel build define <literal>SG_BIG_BUFF</literal> (in
646 <filename>sg.h</filename>) that is by default set too
647 low. The SANE project recommends
648 <literal>130560</literal> and this seems to work just
649 fine. This does require a kernel rebuild.
650 </para>
651 </listitem>
652 <listitem>
653 <para>
654 Make the devices for the scanner (generic scsi devices)
655 - look at the scsi programming how-to for device
656 numbering.
657 </para>
658 </listitem>
659 <listitem>
660 <para>
661 I would recommend making the scanner device writable by
662 a group. I made a group called
663 <literal>scanner</literal> and added myself to it.
664 Running as root increases your risk of sending bad scsi
665 commands to the wrong device. With a regular user, you
666 are better protected.
667 </para>
668 </listitem>
669 <listitem>
670 <para>
671 Add a scsi device entry for your particular scanner to
672 wine.conf. The format is <literal>[scsi
673 cCtTdD]</literal> where
674 <literal>C=controller</literal>,
675 <literal>T=target</literal>, <literal>D=LUN</literal>
676 </para>
677 <para>
678 For example, I set mine up as controller <literal>0</literal>,
679 Target <literal>6</literal>, LUN <literal>0</literal>.
680 <programlisting>
681 [scsi c0t6d0]
682 Device=/dev/sgi
683 </programlisting>
684 Yours will vary with your particular SCSI setup.
685 </para>
686 </listitem>
687 </orderedlist>
688 </sect2>
690 <sect2>
691 <title>General Information</title>
692 <para>
693 The mustek scanner I have was shipped with a package
694 "ipplus". This program uses the TWAIN driver specification
695 to access scanners.
696 </para>
697 <para>
698 (TWAIN MANAGER)
699 </para>
700 <para>
701 <programlisting>
702 ipplus.exe &lt;---> (TWAIN INTERFACE) &lt;---> (TWAIN DATA SOURCE . ASPI) -> WINASPI
703 </programlisting>
704 </para>
705 </sect2>
707 <sect2>
708 <title>NOTES/BUGS</title>
709 <para>
710 The biggest is that it only works under linux at the moment.
711 </para>
712 <para>
713 The ASPI code has only been tested with:
714 </para>
715 <itemizedlist>
716 <listitem>
717 <para>
718 a Mustek 800SP with a Buslogic controller under Linux [BM]
719 </para>
720 </listitem>
721 <listitem>
722 <para>
723 a Siemens Nixdorf 9036 with Adaptec AVA-1505 under Linux
724 accessed via DOSASPI. Note that I had color problems,
725 though (barely readable result) [AM]
726 </para>
727 </listitem>
728 <listitem>
729 <para>
730 a Fujitsu M2513A MO drive (640MB) using generic scsi
731 drivers. Formatting and ejecting worked perfectly.
732 Thanks to Uwe Bonnes for access to the hardware ! [AM]
733 </para>
734 </listitem>
735 </itemizedlist>
736 <para>
737 I make no warranty to the aspi code. It makes my scanner
738 work. Your devices may explode. I have no way of determining
739 this. I take zero responsibility!
740 </para>
741 </sect2>
742 </sect1>
744 </chapter>
746 <!-- Keep this comment at the end of the file
747 Local variables:
748 mode: sgml
749 sgml-parent-document:("wine-doc.sgml" "book" "chapter" "")
750 End: