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.
Serial and parallel port configuration is very similar to drive
configuration - simply create a symbolic link in
~/.wine/dosdevices with the name of the
device. Windows serial ports follow a naming convention of the
word "com" followed by a number, such as
com1, com2, etc.
Similarly, parallel ports use "lpt" followed by a number, such as
lpt1.
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:
Windows shares can are mapped into the unc/
directory so anything trying to access
\\myserver\some\file will look in
~/.wine/dosdevices/unc/myserver/some/file/.
For example, if you used Samba to mount
\\myserver\some on
/mnt/smb/myserver/some then you can do
ln -s /mnt/smb/myserver/some unc/myserver/some
to make it available in wine (don't forget to create the unc
directory if it doesn't alrady exist).
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 .ttf files
into c:\windows\fonts.
Wine can interact directly with the local 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. Wine still needs the command
lpr(from CUPS), when printing a Document.
If you do not use CUPS, the old BSD-Printing system is used:
All Printers from /etc/printcap are installed automatically in Wine.
Wine needs a PPD-File for every Printer (generic.ppd comes with Wine)
The command lpr is called when printing a Document
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
xscanimage 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.
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.
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). 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 isql, which will allow
you to access the data from the command line so that you can check
that the system is working.
The next step is to hook the Unix ODBC library to the wine built-in
odbc32 DLL. The built-in odbc32 (currently) looks to the
environment variable LIB_ODBC_DRIVER_MANAGER
for the name of the ODBC library. For example in the author's
.bashrc file is the line:
If that environment variable is not set then it looks for a
library called libodbc.so and so you can add a symbolic link to
equate that to your own library. For example as root you could
run the commands:
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
configuration. This built-in DLL merely acts as a stub between the
calling code and the Unix ODBC library.
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
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.
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.
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.
Types successfully tested under wine:
DB Type
Usefulness
MS SQL
100%
Please report any other successes to the
wine-devel
mailing list.
English
Español
