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. Make sure you have the needed access rights to that device. For example, to configure one serial port and one parallel port, run the following commands:
ln -s /dev/ttyS0 com1 ln -s /dev/lp0 lpt1
Windows shares can be 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/someto make it available in Wine (don't forget to create the unc directory if it doesn't already 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 lpr command (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 lpr command is called when printing a document
In Windows, scanners use the TWAIN API to access the underlying hardware. Wine 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 it 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 binary packages etc. There are several Unix ODBC systems available such as unixODBC or an 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:
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:
# ln -s libodbc.so.1.0.0 /usr/lib/libodbc.so # /sbin/ldconfig
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
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
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 www.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:
Please report any other successes to the wine-devel mailing list.