Now that you hopefully managed to successfully install the Wine program files, this chapter will tell you how to configure the Wine environment properly to run your Windows programs. First, we'll give you an overview about which kinds of configuration and program execution aspects a fully configured Windows environment has to fulfill in order to ensure that many Windows programs run successfully without encountering any misconfigured or missing items. Next, we'll show you which easy helper programs exist to enable even novice users to complete the Wine environment configuration in a fast and easy way. The next section will explain the purpose of the Wine configuration file, and we'll list all of its settings. After that, the next section will detail the most important and unfortunately most difficult configuration part: how to configure the file system and DOS drive environment that Windows programs need. In the last step we'll tell you how to establish a working Windows registry base. Finally, the remaining parts of this chapter contain descriptions of specific Wine configuration items that might also be of interest to you. A Windows installation is a very complex structure. It consists of many different parts with very different functionality. We'll try to outline the most important aspects of it. Registry. Many keys are supposed to exist and contain meaningful data, even in a newly-installed Windows. 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. System DLLs. In Windows, these usually reside in the system (or system32) directory. Some Windows programs check for their existence in these directories before attempting to load them. While Wine is able to load its own internal DLLs (.so files) when the program asks for a DLL, Wine does not simulate the presence of non-existent files. While the users are of course free to set up everything themselves, the Wine team will make the automated Wine source installation script, tools/wineinstall, do everything we find necessary to do; running the conventional configure && make depend && make && make install cycle is thus not recommended, unless you know what you're doing. At the moment, tools/wineinstall is able to create a configuration file, install the registry, and create the directory structure itself. Managing the Wine configuration file settings can be a difficult task, sometimes too difficult for some people. That's why there are some helper applications for easily setting up an initial wine configuration file with useful default settings. WineSetupTk is a graphical Wine configuration tool with incredibly easy handling of Wine configuration issues, to be used for configuring the Wine environment after having installed the Wine files. It has been written by CodeWeavers in 2000 as part of a host of other efforts to make Wine more desktop oriented, and updated in 2003 by Vincent Béron, Alex Pasadyn and Ivan Leo Puoti. If you're using Debian, simply install the WineSetupTk package (as root): # apt-get install winesetuptk If you're using another distribution, you can get WineSetupTk from the sourceforge.net Wine download page wineinstall is a small configuration tool residing as tools/wineinstall in a Wine source code tree. It has been written to allow for an easy and complete compilation/installation of Wine source code for people who don't bother with reading heaps of very valuable and informative documentation ;-) Once you have successfully extracted the Wine source code tree, change to the main directory of it and then run (as user): $ ./tools/wineinstall Doing so will compile Wine, install Wine and configure the Wine environment (either by providing access to a Windows partition or by creating a properly configured no-windows directory environment). TODO: After you have finished configuring Wine you can verify your Wine configuration by running winecfg. This functionality will be added to winecfg in the near future. Please check out the configuration documentation below to find out more about Wine's configuration, or proceed to the Troubleshooting chapter. This section is meant to contain both an easy step-by-step introduction to the Wine configuration file (for new Wine users) and a complete reference to all Wine configuration file settings (for advanced users). The Wine configuration file is the central file to store configuration settings for Wine. This file (which is called config) can be found in the sub directory .wine/ of your user's home directory (directory /home/user/). In other words, the Wine configuration file is ~/.wine/config. Note that since the Wine configuration file is a part of the Wine registry file system, this file also requires a correct "WINE REGISTRY Version 2" header line to be recognized properly, just like all other Wine registry text files (just in case you decided to write your own registry file from scratch and wonder why Wine keeps rejecting it). The settings available in the configuration file include: Directory settings Port settings The Wine look and feel Wine's DLL usage Wine's multimedia drivers and DLL configuration If you just installed Wine for the first time and want to finish Wine installation by configuring it now, then you could use our sample configuration file config (which can be found in the directory documentation/samples/ of the Wine source code directory) as a base for adapting the Wine configuration file to the settings you want. First, I should mention that you should not forget to make sure that any previous configuration file at ~/.wine/config has been safely moved out of the way instead of simply overwriting it when you will now copy over the sample configuration file. If you don't have a pre-existing configuration file and thus need to copy over our sample configuration file to the standard Wine configuration file location, do in a terminal: $ mkdir ~/.wine/ $ cp dir_to_wine_source_code/documentation/samples/config ~/.wine/config Otherwise, simply use the already existing configuration file at ~/.wine/config. Now you can start adapting the configuration file's settings with an editor according to the documentation below. Note that you should only change configuration file settings if wineserver is not running (in other words: if your user doesn't have a Wine session running), otherwise Wine won't use them - and even worse, wineserver will overwrite them with the old settings once wineserver quits!! Let's start by giving an overview of which sections a configuration file may contain, and whether the inclusion of the respective section is needed or only recommended ("recmd"). Section Name Needed? What it Does [wine] yes General settings for Wine [DllOverrides] recmd Overrides defaults for DLL loading [x11drv] recmd Graphics driver settings [fonts] yes Font appearance and recognition [ppdev] no Parallelport emulation [spooler] no Print spooling [ports] no Direct port access [Debug] no What to do with certain debug messages [Registry] no Specifies locations of windows registry files [programs] no Programs to be run automatically [Console] no Console settings [Clipboard] no Interaction for Wine and X11 clipboard [afmdirs] no Postscript driver settings [WinMM] yes Multimedia settings [AppDefaults] no Overwrite the settings of previous sections for special programs Now let's explain the configuration file sections in a detailed way. The [wine] section of the configuration file contains all kinds of general settings for Wine. "Windows" = "c:\\windows" "System" = "c:\\windows\\system" "Temp" = "c:\\temp" "Path" = "c:\\windows;c:\\windows\\system;c:\\blanco" "ShowDirSymlinks" = "1" For a detailed description of drive layer configuration and the meaning of these parameters, please look at the Disc Drives, Serial and Parallel Ports section. "GraphicsDriver" = "x11drv|ttydrv" Sets the graphics driver to use for Wine output. x11drv is for X11 output, ttydrv is for text console output. WARNING: if you use ttydrv here, then you won't be able to run a lot of Windows GUI programs (ttydrv is still pretty "broken" at running graphical apps). Thus this option is mainly interesting for e.g. embedded use of Wine in web server scripts. Note that ttydrv is still very lacking, so if it doesn't work, resort to using "xvfb", a virtual X11 server. Another way to run Wine without display would be to run X11 via Xvnc, then connect to that VNC display using xvncviewer (that way you're still able to connect to your app and configure it if need be). "Printer" = "off|on" Tells wine whether to allow printing via printer drivers to work. This option isn't needed for our built-in psdrv printer driver at all. Using these things are pretty alpha, so you might want to watch out. Some people might find it useful, however. If you're not planning to work on printing via windows printer drivers, don't even add this to your wine configuration file (It probably isn't already in it). Check out the [spooler] and [parallelports] sections too. "ShellLinker" = "wineshelllink" This setting specifies the shell linker script to use for setting up Windows icons in e.g. KDE or Gnome that are given by programs making use of appropriate shell32.dll functionality to create icons on the desktop/start menu during installation. "SymbolTableFile" = "wine.sym" Sets up the symbol table file for the wine debugger. You probably don't need to fiddle with this. May be useful if your wine is stripped. The format for this section is the same for each line: <DLL>{,<DLL>,<DLL>...} = <FORM>{,<FORM>,<FORM>...} For example, to load built-in KERNEL pair (case doesn't matter here): "kernel,kernel32" = "builtin" To load the native COMMDLG pair, but if that doesn't work try built-in: "commdlg,comdlg32" = "native, builtin" To load the native COMCTL32: "comctl32" = "native" Here is a good generic setup (As it is defined in config that was included with your wine package): [DllOverrides] "rpcrt4" = "builtin, native" "oleaut32" = "builtin, native" "ole32" = "builtin, native" "commdlg" = "builtin, native" "comdlg32" = "builtin, native" "ver" = "builtin, native" "version" = "builtin, native" "shell" = "builtin, native" "shell32" = "builtin, native" "shfolder" = "builtin, native" "shlwapi" = "builtin, native" "shdocvw" = "builtin, native" "lzexpand" = "builtin, native" "lz32" = "builtin, native" "comctl32" = "builtin, native" "commctrl" = "builtin, native" "advapi32" = "builtin, native" "crtdll" = "builtin, native" "mpr" = "builtin, native" "winspool.drv" = "builtin, native" "ddraw" = "builtin, native" "dinput" = "builtin, native" "dsound" = "builtin, native" "opengl32" = "builtin, native" "msvcrt" = "native, builtin" "msvideo" = "builtin, native" "msvfw32" = "builtin, native" "mcicda.drv" = "builtin, native" "mciseq.drv" = "builtin, native" "mciwave.drv" = "builtin, native" "mciavi.drv" = "native, builtin" "mcianim.drv" = "native, builtin" "msacm.drv" = "builtin, native" "msacm" = "builtin, native" "msacm32" = "builtin, native" "midimap.drv" = "builtin, native" ; you can specify programs too "notepad.exe" = "native, builtin" ; default for all other DLLs "*" = "native, builtin" If loading of the libraries that are listed first fails, wine will just go on by using the second or third option. This section sets up wine's font handling. "Resolution" = "96" Since the way X handles fonts is different from the way Windows does, wine uses a special mechanism to deal with them. It must scale them using the number defined in the "Resolution" setting. 60-120 are reasonable values, 96 is a nice in the middle one. If you have the real windows fonts available , this parameter will not be as important. Of course, it's always good to get your X fonts working acceptably in wine. "Default" = "-adobe-times-" The default font wine uses. Fool around with it if you'd like. OPTIONAL: The Alias setting allows you to map an X font to a font used in wine. This is good for apps that need a special font you don't have, but a good replacement exists. The syntax is like so: "AliasX" = "[Fake windows name],[Real X name]"<,optional "masking" section> Pretty straightforward. Replace "AliasX" with "Alias0", then "Alias1" and so on. The fake windows name is the name that the font will be under a windows app in wine. The real X name is the font name as seen by X (Run "xfontsel"). The optional "masking" section allows you to utilize the fake windows name you define. If it is not used, then wine will just try to extract the fake windows name itself and not use the value you enter. Here is an example of an alias without masking. The font will show up in windows apps as "Google". "Alias0" = "Foo,--google-" Here is an example with masking enabled. The font will show up as "Foo" in windows apps. "Alias1" = "Foo,--google-,subst" For more information check out the Fonts chapter. The [spooler] section will inform wine where to spool print jobs. Use this if you want to try printing. Wine docs claim that spooling is "rather primitive" at this time, so it won't work perfectly. It is optional. The only setting you use in this section works to map a port (LPT1, for example) to a file or a command. Here is an example, mapping LPT1 to the file out.ps: "LPT1:" = "out.ps" The following command maps printing jobs to LPT1 to the command lpr. Notice the |: "LPT1:" = "|lpr" The [ports] section is usually useful only for people who need direct port access for programs requiring dongles or scanners. If you don't need it, don't use it! "read" = "0x779,0x379,0x280-0x2a0" Gives direct read access to those IO's. "write" = "0x779,0x379,0x280-0x2a0" Gives direct write access to those IO's. It's probably a good idea to keep the values of the read and write settings the same. This stuff will only work when you're root. [Debug] is used to include or exclude debug messages, and to output them to a file. The latter is rarely used. These are all optional and you probably don't need to add or remove anything in this section to your config. (In extreme cases you may want to use these options to manage the amount of information generated by WINEDEBUG=+relay ) "File" = "/blanco" Sets the logfile for wine. Set to CON to log to standard out. This is rarely used. "SpyExclude" = "WM_SIZE;WM_TIMER;" Excludes debug messages about WM_SIZE and WM_TIMER in the logfile. "SpyInclude" = "WM_SIZE;WM_TIMER;" Includes debug messages about WM_SIZE and WM_TIMER in the logfile. "RelayInclude" = "user32.CreateWindowA;comctl32.*" Include only the listed functions in a WINEDEBUG=+relay trace. This entry is ignored if there is a RelayExclude entry. "RelayExclude" = "RtlEnterCriticalSection;RtlLeaveCriticalSection" Exclude the listed functions in a WINEDEBUG=+relay trace. This entry overrides any settings in a RelayInclude entry. If neither entry is present then the trace includes everything. In both entries the functions may be specified either as a function name or as a module and function. In this latter case specify an asterisk for the function name to include/exclude all functions in the module. [Registry] can be used to tell wine where your old windows registry files exist. This section is completely optional and useless to people using wine without an existing windows installation. "UserFileName" = "/dirs/to/user.reg" The location of your old user.reg file. [programs] can be used to say what programs run under special conditions. "Default" = "/program/to/execute.exe" Sets the program to be run if wine is started without specifying a program. "Startup" = "/program/to/execute.exe" Sets the program to automatically be run at startup every time. [WinMM] is used to define which multimedia drivers have to be loaded. Since those drivers may depend on the multimedia interfaces available on your system (OSS, ALSA... to name a few), it's needed to be able to configure which driver has to be loaded. The content of the section looks like: [WinMM] "Drivers" = "wineoss.drv" "WaveMapper" = "msacm.drv" "MidiMapper" = "midimap.drv" All the keys must be defined: The "Drivers" key is a ';' separated list of modules name, each of them containing a low level driver. All those drivers will be loaded when MMSYSTEM/WINMM is started and will provide their inner features. The "WaveMapper" represents the name of the module containing the Wave Mapper driver. Only one wave mapper can be defined in the system. The "MidiMapper" represents the name of the module containing the MIDI Mapper driver. Only one MIDI mapper can be defined in the system. [Network] contains settings related to networking. Currently there is only one value that can be set. UseDnsComputerName A boolean setting (default: Y) that affects the way Wine sets the computer name. The computer name in the Windows world is the so-called NetBIOS name. It is contained in the ComputerName in the registry entry HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\ComputerName\ComputerName. If this option is set to "Y" or missing, Wine will set the NetBIOS name to the Unix host name of your computer, if necessary truncated to 31 characters. The Unix hostname is the output of the shell command hostname, up to but not including the first dot ('.'). Among other things, this means that Windows programs running under Wine cannot change the NetBIOS computer name. If this option is set to "N", Wine will use the registry value above to set the NetBIOS name. Only if the registry entry doesn't exist (usually only during the first wine startup) it will use the Unix hostname as usual. Windows programs can change the NetBIOS name. The change will be effective after a "reboot", i.e. after restarting Wine. The section is used to overwrite certain settings of this file for a special program with different settings. [AppDefaults] is not the real name of the section. The real name consists of the leading word AppDefaults followed by the name of the executable the section is valid for. The end of the section name is the name of the corresponding "standard" section of the configuration file that should have some of its settings overwritten with the program specific settings you define. The three parts of the section name are separated by two backslashes. Currently wine supports overriding selected settings within the sections [DllOverrides], [x11drv], [version] and [dsound] only. Here is an example that overrides the normal settings for a program: ;; default settings [x11drv] "Managed" = "Y" "Desktop" = "N" ;; run install in desktop mode [AppDefaults\\install.exe\\x11drv] "Managed" = "N" "Desktop" = "800x600" There is always a chance that things will go wrong. If the unthinkable happens, report the problem to Wine Bugzilla, try the newsgroup comp.emulators.ms-windows.wine, or the IRC channel #WineHQ found on irc.freenode.net, or connected servers. Make sure that you have looked over this document thoroughly, and have also read: README http://www.winehq.org/trouble/ If indeed it looks like you've done your research, be prepared for helpful suggestions. If you haven't, brace yourself for heaving flaming. If you're planning to include access to a CD-ROM drive in your Wine configuration on Linux, then make sure to add the unhide mount option to the CD-ROM file system entry in /etc/fstab, e.g.: /dev/cdrom /cdrom iso9660 ro,noauto,users,unhide 0 0 Several Windows program setup CD-ROMs or other CD-ROMs chose to do such braindamaged things as marking very important setup helper files on the CD-ROM as hidden. That's no problem on Windows, since the Windows CD-ROM driver by default displays even files that are supposed to be hidden. But on Linux, which chose to hide hidden files on CD by default, this is FATAL! (the programs will simply abort with an installation file not found or similar error) Thus you should never forget to add this setting. Windows applications refer to disc drives by letters such as A:, B: and C:, and to serial and parallel ports by names such as COM1: and LPT1:. You need to tell Wine how to interpret these. You do so by specifying the Unix file system nodes and devices that Wine should map them onto, as described later in this section. You can map a Windows fixed disc drive onto any node in your Unix file system - this need not be the root node of a drive. For example, you could map your Windows drive C: onto your Unix directory /usr/share/wine-C. Then the Windows folder C:\Windows\Fonts would be at /usr/share/wine-C/Windows/Fonts in your Unix file system. Make sure that you have assigned drive letters for directories that will cover all the items Wine needs to access. These include the programs that you run, the data files they need and the Wine debugger (in case anything goes wrong). It is best to use a number of drive letters, and map them onto directories that cover small sections of the file system containing the files that Wine will need to access. This is safer than simply assigning a single drive letter to the Unix root directory /, which would allow Windows applications to access the whole of your Unix file system (subject, of course, to Unix permissions). If one of them misbehaved, or if you accidentally installed a virus, this might leave you vulnerable. For replaceable media, such as floppy discs and CD-ROMs, you should map Windows drive letters onto the mount points for these drives in your Unix file system - for example /mnt/floppy or /mnt/cdrom. If your applications access serial and parallel ports directly, you should map these onto the corresponding Unix devices - for example /dev/ttyS0 and /dev/lp0. Here's the fundamental layout that Windows programs and installers expect and that we thus need to configure properly in Wine. Without it, they seldomly operate correctly. If you intend to use a no-windows environment (not using an existing Windows partition), then it is recommended to use either WineSetupTk's or wineinstall's capabilities to create an initial windows directory tree, since creating a directory structure manually is tiresome and error-prone. C:\ Root directory of primary disk drive Windows\ Windows directory, containing .INI files, accessories, etc. System\ Win3.x/95/98/ME directory for common DLLs WinNT/2000 directory for common 16-bit DLLs System32\ WinNT/2000 directory for common 32-bit DLLs Start Menu\ Program launcher directory structure Programs\ Program launcher links (.LNK files) to programs Program Files\ Application binaries (.EXE and .DLL files) The dosdevices directory contains the entries that tell Wine how to map Windows disc drive letters onto Unix file system nodes, and how to map Windows serial and parallel ports onto Unix devices. It is located in the .wine sub-directory of your home directory, i.e. ~/.wine/dosdevices. The entries in the dosdevices directory are symbolic links to Unix file system nodes and devices. You can create them by using the ln command in a Unix terminal. Alternatively, many File Managers have the capability of creating symbolic links. For example, if you have decided to map your Windows C: drive onto /usr/share/wine-c, you could type the following (after changing to your dosdevices directory): ln -s /usr/share/wine-c c: Replaceable media are a little more complicated. In addition to creating a link for the file system on the medium, for example: ln -s /mnt/floppy a: you also need to create a link for the device itself. Notice that this has a double colon after the drive letter: ln -s /dev/fd0 a:: For serial and parallel ports, you simply create a link to the device; notice that no colon is required after the Windows device name: ln -s /dev/ttyS0 com1 ln -s /dev/lp0 lpt1 Windows shares can are mapped into the unc/ directory so anything trying to access \\machinename\some\dir\and\file will look in ~/.wine/dosdevices/unc/machinename/some/dir/and/file. For example, if you used Samba to mount \\machinename\some on /mnt/smb/machinename/some then you can do ln -s /mnt/smb/machinename/some unc/machinename/some to make it available in wine (don't forget to create the unc directory if it doesn't alrady exist). "Windows" = "c:\\windows" This tells Wine and Windows programs where the Windows directory is. It is recommended to have this directory somewhere on your configured C drive, and it's also recommended to just call the directory "windows" (this is the default setup on Windows, and some stupid programs might rely on this). So in case you chose a "Windows" setting of "c:\\windows" and you chose to set up a drive C e.g. at /usr/local/wine_c, the corresponding directory would be /usr/local/wine_c/windows. Make one if you don't already have one. No trailing slash (not C:\\windows\)! Write access strongly recommended, as Windows programs always assume write access to the Windows directory! "System" = "c:\\windows\\system" This sets up where the windows system files are. The Windows system directory should reside below the directory used for the Windows setting. Thus when using the example above, the system directory would be /usr/local/wine_c/windows/system. Again, no trailing slash, and write access! "Temp" = "c:\\temp" This should be the directory you want your temp files stored in, /usr/local/wine_c/temp in our example. Again, no trailing slash, and write access!! "Path" = "c:\\windows;c:\\windows\\system;c:\\blanco" Behaves like the PATH setting on UNIX boxes. When wine is run like wine sol.exe, if sol.exe resides in a directory specified in the Path setting, wine will run it (Of course, if sol.exe resides in the current directory, wine will run that one). Make sure it always has your windows directory and system directory (For this setup, it must have "c:\\windows;c:\\windows\\system"). "ShowDirSymlinks" = "1" Wine doesn't pass directory symlinks to Windows programs by default, as doing so may crash some programs that do recursive lookups of whole subdirectory trees whenever a directory symlink points back to itself or one of its parent directories. That's why we disallowed the use of directory symlinks and added this setting to reenable ("1") this functionality. If you really need Wine to take into account symlinked directories, then reenable it, but be prepared for crashes in certain Windows programs when using the above method! (in other words: enabling it is certainly not recommended) Windows uses a different (and inferior) way than Unix to describe the location of files in a computer. Thus Windows programs also expect to find this different way supported by the system. Since we intend to run Windows programs on a Unix system, we're in trouble, as we need to translate between these different file access techniques. Windows uses drive letters to describe drives or any other form of storage media and to access files on them. For example, common drive names are C: for the main Windows system partition on the first harddisk and A: for the first floppy drive. Also, Windows uses \ (backslash) as the directory separator sign, whereas Unix uses / (slash). Thus, an example document on the first data partition in Windows might be accessed by the name of D:\mywork\mydocument.txt. So much for the Windows way of doing things. Well, the problem is, in Unix there is no such thing as drive letters. Instead, Unix chose to go the much better way of having one single uniform directory tree (starting with the root directory /), which has various storage devices such as e.g. harddisk partitions appended at various directory locations within the tree (an example would be /data1/mywork, which is the first data partition mounted/attached to a directory called data1 in the root directory /; mywork is a sub directory of the data partition file system that's mounted under /data1). In Unix, the Windows example document mentioned above could e.g. be accessed by the name of /data1/mywork/mydocument.txt, provided that the administrator decided to mount (attach) the first data partition at the directory /data1 inside the Unix directory tree. Note that in Unix, the administrator can choose any custom partition location he wants (here, /data1), whereas in Windows the system selects any drive letter it deems suitable for the first data partition (here, D:), and, even worse, if there is some change in partition order, Windows automatically changes the drive letter, and you might suddenly find yourself with a first data partition at drive letter E:, with all the file naming and referencing confusion that entails. Thus, the Windows way of using ever-changing drive letters is clearly inferior to the Unix way of assigning fixed directory tree locations for every data storage medium. As we'll see soon, fortunately this Windows limitation of changing drive letters doesn't affect us in Wine at all, since we can properly map never-changing drive letters to fixed locations inside the Unix directory tree (and even if the location of the respective Unix directory changes, we can still simply update the Wine drive mapping to reflect the updated location and at the same time keep the original drive letter). OK, now that we know some theory about Windows and Unix drive and filename mapping, it's probably time to ask how Wine achieves the magic of mapping a Unix directory location to a Windows drive... Wine chose to do the following: In Wine, you don't assign some real physical storage medium (such as a harddisk partition or similar) to each drive letter mapping entry. Instead, you choose certain sub directory trees inside the Unix directory tree (that starts with /) that you would like to assign a drive letter to. Note that for every Unix sub directory tree that you intend to start Windows programs in, it is absolutely required to have a Wine drive mapping entry: For example, if you had a publicly writable Windows directory space under /usr/mywine, then in order to be able to access this sub directory tree from Wine, you should have a drive mapping entry that maps a certain drive letter (for example, let's take drive letter P:) either to /usr/mywine or /usr (to also access any directories belonging to the parent directory) or / (to also access any directory whatsoever on this system by this drive letter mapping). The DOS drive/directory location to access files in /usr/mywine in Wine in these configuration cases would then be P:\ or P:\mywine or P:\usr\mywine, respectively. 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. Wine has already made enough progress that it may be possible to run your target programs without Windows installed. If you want to try it, follow these steps: Make a symbolic link in ~/.wine/dosdevices to the directory where you want C: to be. Refer to the wine man page for more information. The directory to be used for emulating a C: drive will be the base directory for some Windows specific directories created below. Within the directory to be used for C:, create empty windows, windows/system, windows/Start Menu, and windows/Start Menu/Programs directories. Do not point Wine to a Windows directory full of old installations and a messy registry. (Wine creates a special registry in your home directory, in $HOME/.wine/*.reg. Perhaps you have to remove these files). In one line: mkdir -p windows windows/system windows/Start\ Menu windows/Start\ Menu/Programs Run and/or install your programs. 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 C:\windows directory in the configuration file does not point to a native Windows installation but is in a separate Unix file system. (For instance, C:\windows is really subdirectory windows located in /home/ego/wine/drives/c). Run the program with WINEDEBUG=+loaddll to find out which files are needed. Copy the required DLLs one by one to the C:\windows\system directory. Do not copy KERNEL/KERNEL32, GDI/GDI32, USER/USER32 or NTDLL. These implement the core functionality of the Windows API, and the Wine internal versions must be used. Edit the [DllOverrides] section of ~/.wine/config to specify native before builtin for the Windows DLLs you want to use. For more information about this, see the Wine manpage. Note that some network DLLs are not needed even though Wine is looking for them. The Windows MPR.DLL currently does not work; you must use the internal implementation. Copy SHELL.DLL/SHELL32.DLL, COMMDLG.DLL/COMDLG32.DLL and COMMCTRL.DLL/COMCTL32.DLL only as pairs to your Wine directory (these DLLs are clean to use). Make sure you have these specified in the [DllPairs] section of ~/.wine/config. Be consistent: Use only DLLs from the same Windows version together. Put regedit.exe in the C:\windows directory. (Office 95 imports a *.reg file when it runs with an empty registry, don't know about Office 97). As of now, it might not be necessary any more to use regedit.exe, since Wine has its own regedit Winelib application now. Also add winhelp.exe and winhlp32.exe if you want to be able to browse through your programs' help function (or in case Wine's winhelp implementation in programs/winhelp/ is not good enough, for example). Some people intend to use the data of an existing Windows partition with Wine in order to gain some better compatibility or to run already installed programs in a setup as original as possible. Note that many Windows programs assume that they have full write access to all windows directories. This means that you either have to configure the Windows partition mount point for write permission by your Wine user (see Dealing with FAT/VFAT partitions on how to do that), or you'll have to copy over (some parts of) the Windows partition content to a directory of a Unix partition and make sure this directory structure is writable by your user. We HIGHLY DISCOURAGE people from directly using a Windows partition with write access as a base for Wine!! (some programs, notably Explorer, corrupt large parts of the Windows partition in case of an incorrect setup; you've been warned). Not to mention that NTFS write support in Linux is still very experimental and dangerous (in case you're using an NT-based Windows version using the NTFS file system). Thus we advise you to go the Unix directory way. This document describes how FAT and VFAT file system permissions work in Linux with a focus on configuring them for Wine. 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 programs and their data are accessed through Wine for dual boot (Linux + Windows) systems. Wine maps mounted FAT file systems, such as /c, to drive letters, such as c:, by means of symbolic links in the dosdevices directory. Thus, in your dosdevices directory, you could type the command: ln -s /c c: Although VFAT filesystems are preferable to FAT filesystems for their long filename support, the term FAT will be used throughout the remainder of this document to refer to FAT filesystems and their derivatives. Also, /c will be used as the FAT mount point in examples throughout this document. 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 /c, 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: ~>cd /c /c>ls -l -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 where all the files are owned by "root", are in the "root" group and are only writable by "root" (755 permissions). This is restrictive in that it requires that Wine be run as root in order for programs to be able to write to any part of the filesystem. There are three major approaches to overcoming the restrictive permissions mentioned in the previous paragraph: Run Wine as root Mount the FAT filesystem with less restrictive permissions Shadow the FAT filesystem by completely or partially copying it Each approach will be discussed in the following sections. Running Wine as root is the easiest and most thorough way of giving programs that Wine runs unrestricted access to FAT files systems. Running wine as root also allows programs 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 program can do to the system, so it's HIGHLY DISCOURAGED. 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: ~>whoami root ~>touch root_file ~>ls -l root_file -rw-r--r-- 1 root root 0 Dec 10 00:20 root_file 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: ~>umount /c ~>umask 022 ~>umask 073 ~>mount /c ~>cd /c /c>ls -l -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 Mounting the FAT filesystem with a umask of 000 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: uid, gid and umask. They can each be specified when the filesystem is manually mounted. For example: ~>umount /c ~>mount -o uid=500 -o gid=500 -o umask=002 /c ~>cd /c /c>ls -l -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 which gives "sle" complete control over /c. The options listed above can be made permanent by adding them to the /etc/fstab file: ~>grep /c /etc/fstab /dev/hda1 /c vfat uid=500,gid=500,umask=002,exec,dev,suid,rw 1 1 Note that the umask of 002 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 user group (gid). Shadowing provides a finer granularity of control. Parts of the original FAT filesystem can be copied so that the program can safely work with those copied parts while the program continues to directly read the remaining parts. This is done with symbolic links. For example, consider a system where a program named AnApp must be able to read and write to the c:\windows and c:\AnApp 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: ~>cd / />mkdir c_shadow />cd c_shadow /c_shadow>ln -s /c_/* . /c_shadow>rm windows AnApp /c_shadow>cp -R /c_/{windows,AnApp} . /c_shadow>chmod -R 777 windows AnApp /c_shadow>perl -p -i -e 's|/c$|/c_shadow|g' ~/.wine/config The above gives everyone complete read and write access to the windows and AnApp directories while only root has write access to all other directories. Wine can read drive volume labels and serial numbers directly from the device. This may be useful for many Win 9x games or for setup programs distributed on CD-ROMs that check for volume label. File System Types Comment FAT systems hd, floppy reads labels and serial numbers ISO9660 cdrom reads labels and serial numbers (not mixed-mode CDs yet!) Reading labels and serial numbers just works automatically if you specify the correct symbolic links for the devices (with double colons after the drive letters) in your dosdevices directory. Note that the device has to exist and must be accessible by the user running Wine if you do this, though. If you don't want to read labels and serial numbers directly from the device, you can create files at the root of the drive named .windows-label and .windows-serial respectively. These are simple ASCII files that you can create with any text editor; the label can be set to any string you like, the serial number should be expressed as an hexadecimal number. Here's a simple example of CD-ROM and floppy: cd ~/.wine/dosdevices ln -s /mnt/floppy a: ln -s /dev/fd0 a:: ln -s /mnt/cdrom r: ln -s /dev/hda1 r:: The CD-ROM label can be read only if the data track of the disk resides in the first track and the cdrom is iso9660. Support for labels/serial nums WRITING. What about reading ext2 volume label? .... ®istry; If your programs don't work as expected, then it's often because one DLL or another is failing. This can often be resolved by changing certain DLLs from Wine built-in to native Windows DLL file and vice versa. A very useful help to find out which DLLs are loaded as built-in and which are loaded as native Windows file can be the debug channel loaddll, activated via the environment variable WINEDEBUG=+loaddll. There are a few things you will need to know before configuring the DLL sections in your wine configuration file. Most windows DLL's have a win16 (Windows 3.x) and win32 (Windows 9x/NT) form. The combination of the win16 and win32 DLL versions are called the "DLL pair". This is a list of the most common pairs: Win16 Win32 Native Is it possible to use native DLL with wine? (See next section) KERNEL KERNEL32 No! USER USER32 No! SHELL SHELL32 Yes GDI GDI32 No! COMMDLG COMDLG32 Yes VER VERSION Yes There are a few different forms of DLL's wine can load: native The DLL's that are included with windows. Many windows DLL's can be loaded in their native form. Many times these native versions work better than their non-Microsoft equivalent -- other times they don't. builtin The most common form of DLL loading. This is what you will use if the DLL is too system-specific or error-prone in native form (KERNEL for example), you don't have the native DLL, or you just want to be Microsoft-free. so Native ELF libraries. Has became obsolete, ignored. elfdll ELF encapsulated windows DLL's. No longer used, ignored. The wine configuration file directives [DllDefaults] and [DllOverrides] are the subject of some confusion. The overall purpose of most of these directives are clear enough, though - given a choice, should Wine use its own built-in DLLs, or should it use .DLL files found in an existing Windows installation? This document explains how this feature works. native A "native" DLL is a .DLL file written for the real Microsoft Windows. builtin A "built-in" DLL is a Wine DLL. These can either be a part of libwine.so, or more recently, in a special .so file that Wine is able to load on demand. DefaultLoadOrder This specifies in what order Wine should search for available DLL types, if the DLL in question was not found in the [DllOverrides] section. At one time, there was a section called [DllPairs] in the default configuration file, but this has been obsoleted because the pairing information has now been embedded into Wine itself. (The purpose of this section was merely to be able to issue warnings if the user attempted to pair codependent 16-bit/32-bit DLLs of different types.) If you still have this in your ~/.wine/config or wine.conf, you may safely delete it. This section specifies how you want specific DLLs to be handled, in particular whether you want to use "native" DLLs or not, if you have some from a real Windows configuration. Because built-ins do not mix seamlessly with native DLLs yet, certain DLL dependencies may be problematic, but workarounds exist in Wine for many popular DLL configurations. Also see WWN's [16]Status Page to figure out how well your favorite DLL is implemented in Wine. It is of course also possible to override these settings by explicitly using Wine's --dll command-line option (see the man page for details). Some hints for choosing your optimal configuration (listed by 16/32-bit DLL pair): krnl386, kernel32 Native versions of these will never work, so don't try. Leave at builtin. gdi, gdi32 Graphics Device Interface. No effort has been made at trying to run native GDI. Leave at builtin. user, user32 Window management and standard controls. It was possible to use Win95's native versions at some point (if all other DLLs that depend on it, such as comctl32 and comdlg32, were also run native). However, this is no longer possible after the Address Space Separation, so leave at builtin. ntdll NT kernel API. Although badly documented, the native version of this will never work. Leave at builtin. w32skrnl Win32s (for Win3.x). The native version will probably never work. Leave at builtin. wow32 Win16 support library for NT. The native version will probably never work. Leave at builtin. system Win16 kernel stuff. Will never work native. Leave at builtin. display Display driver. Definitely leave at builtin. toolhelp Tool helper routines. This is rarely a source of problems. Leave at builtin. ver, version Versioning. Seldom useful to mess with. advapi32 Registry and security features. Trying the native version of this may or may not work. commdlg, comdlg32 Common Dialogs, such as color picker, font dialog, print dialog, open/save dialog, etc. It is safe to try native. commctrl, comctl32 Common Controls. This is toolbars, status bars, list controls, the works. It is safe to try native. shell, shell32 Shell interface (desktop, filesystem, etc). Being one of the most undocumented pieces of Windows, you may have luck with the native version, should you need it. winsock, wsock32 Windows Sockets. The native version will not work under Wine, so leave at builtin. icmp ICMP routines for wsock32. As with wsock32, leave at builtin. mpr The native version may not work due to thunking issues. Leave at builtin. lzexpand, lz32 Lempel-Ziv decompression. Wine's builtin version ought to work fine. winaspi, wnaspi32 Advanced SCSI Peripheral Interface. The native version will probably never work. Leave at builtin. crtdll C Runtime library. The native version will easily work better than Wine's on this one. winspool.drv Printer spooler. You are not likely to have more luck with the native version. ddraw DirectDraw/Direct3D. Since Wine does not implement the DirectX HAL, the native version will not work at this time. dinput DirectInput. Running this native may or may not work. dsound DirectSound. It may be possible to run this native, but don't count on it. dplay/dplayx DirectPlay. The native version ought to work best on this, if at all. mmsystem, winmm Multimedia system. The native version is not likely to work. Leave at builtin. msacm, msacm32 Audio Compression Manager. The builtin version works best, if you set msacm.drv to the same. msvideo, msvfw32 Video for Windows. It is safe (and recommended) to try native. mcicda.drv CD Audio MCI driver. mciseq.drv MIDI Sequencer MCI driver (.MID playback). mciwave.drv Wave audio MCI driver (.WAV playback). mciavi.drv AVI MCI driver (.AVI video playback). Best to use native. mcianim.drv Animation MCI driver. msacm.drv Audio Compression Manager. Set to same as msacm32. midimap.drv MIDI Mapper. wprocs This is a pseudo-DLL used by Wine for thunking purposes. A native version of this doesn't exist. The Wine team has determined that it is necessary to create fake DLL files to trick many programs 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 configured c:\windows\system directory to make the program think it's there, and Wine's built-in DLL will be loaded when the program actually asks for it. (Unfortunately, tools/wineinstall does not create such empty files itself.) 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. 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 one of the Windows DLL archive sites that can be found via internet search engine. Please make sure to obey any licenses on the DLLs you fetch... (some are redistributable, some aren't). In case Wine complains about a missing DLL, you should check whether this file is a publicly available DLL or a custom DLL belonging to your program (by searching for its name on the internet). If you managed to get hold of the DLL, then you should make sure that Wine is able to find and load it. DLLs usually get loaded according to the mechanism of the SearchPath() function. This function searches directories in the following order: The directory the program was started from. The current directory. The Windows system directory. The Windows directory. The PATH variable directories. In short: either put the required DLL into your program directory (might be ugly), or usually put it into the Windows system directory. Just find out its directory by having a look at the Wine configuration file variable "System" (which indicates the location of the Windows system directory) and the associated drive entry. Note that you probably shouldn't use NT-based native DLLs, since Wine's NT API support is somewhat weaker than its Win9x API support (thus leading to even worse compatibility with NT DLLs than with a no-windows setup!), so better use Win9x native DLLs instead or no native DLLs at all. The Linux cabextract utility can be used to extract native Windows .dll files from .cab files that are to be found on many Windows installation CDs. Wine currently supports several different display subsystems (graphics / text) that are available on various operating systems today. For each of these, Wine implements its own interfacing driver. This section explains how to select one of these drivers and how to further configure the respective driver. Once you're finished with that, you can consider your Wine installation to be finished. The display drivers currently implemented in Wine are: x11drv, which is used for interfacing to X11 graphics (the one you'll most likely want to use) and ttydrv (used for text mode console apps mainly that don't really need any graphics output). Once you have decided which display driver to use, it is chosen with the GraphicsDriver option in the [wine] section of ~/.wine/config. The x11drv driver consists of two conceptually distinct pieces, the graphics driver (GDI part), and the windowing driver (USER part). Both of these are linked into the libx11drv.so module, though (which you load with the GraphicsDriver option). In Wine, running on X11, the graphics driver must draw on drawables (window interiors) provided by the windowing driver. This differs a bit from the Windows model, where the windowing system creates and configures device contexts controlled by the graphics driver, and programs are allowed to hook into this relationship anywhere they like. Thus, to provide any reasonable tradeoff between compatibility and usability, the x11drv has three different modes of operation. Managed The default. Specified by using the Managed wine configuration file option (see below). Ordinary top-level frame windows with thick borders, title bars, and system menus will be managed by your window manager. This lets these programs integrate better with the rest of your desktop, but may not always work perfectly (a rewrite of this mode of operation, to make it more robust and less patchy, is currently being done, though, and it's planned to be finished before the Wine 1.0 release). Unmanaged / Normal Window manager independent (any running window manager is ignored completely). Window decorations (title bars, borders, etc) are drawn by Wine to look and feel like the real Windows. This is compatible with programs that depend on being able to compute the exact sizes of any such decorations, or that want to draw their own. Unmanaged mode is only used if both Managed and Desktop are set to disabled. Desktop-in-a-Box Specified by using the Desktop wine configuration file option (see below). (adding a geometry, e.g. 800x600 for a such-sized desktop, or even 800x600+0+0 to automatically position the desktop at the upper-left corner of the display). This is the mode most compatible with the Windows model. All program windows will just be Wine-drawn windows inside the Wine-provided desktop window (which will itself be managed by your window manager), and Windows programs can roam freely within this virtual workspace and think they own it all, without disturbing your other X apps. Note: currently there's one desktop window for every program; this will be fixed at some time. Managed Wine can let frame windows be managed by your window manager. This option specifies whether you want that by default. Desktop Creates a main desktop window of a specified size to display all Windows programs in. The size argument could e.g. be "800x600". DXGrab If you don't use DGA, you may want an alternative means to convince the mouse cursor to stay within the game window. This option does that. Of course, as with DGA, if Wine crashes, you're in trouble (although not as badly as in the DGA case, since you can still use the keyboard to get out of X). UseDGA This specifies whether you want DirectDraw to use XFree86's Direct Graphics Architecture (DGA), which is able to take over the entire display and run the game full-screen at maximum speed. (With DGA1 (XFree86 3.x), you still have to configure the X server to the game's requested bpp first, but with DGA2 (XFree86 4.x), runtime depth-switching may be possible, depending on your driver's capabilities.) But be aware that if Wine crashes while in DGA mode, it may not be possible to regain control over your computer without rebooting. DGA normally requires either root privileges or read/write access to /dev/mem. DesktopDoubleBuffered Applies only if you use the --desktop command-line option to run in a desktop window. Specifies whether to create the desktop window with a double-buffered visual, something most OpenGL games need to run correctly. AllocSystemColors Applies only if you have a palette-based display, i.e. if your X server is set to a depth of 8bpp, and if you haven't requested a private color map. It specifies the maximum number of shared colormap cells (palette entries) Wine should occupy. The higher this value, the less colors will be available to other programs. PrivateColorMap Applies only if you have a palette-based display, i.e. if your X server is set to a depth of 8bpp. It specifies that you don't want to use the shared color map, but a private color map, where all 256 colors are available. The disadvantage is that Wine's private color map is only seen while the mouse pointer is inside a Wine window, so psychedelic flashing and funky colors will become routine if you use the mouse a lot. Synchronous To be used for debugging X11 operations. If Wine crashes with an X11 error, then you should enable Synchronous mode to disable X11 request caching in order to make sure that the X11 error happens directly after the corresponding X11 call in the log file appears. Will slow down X11 output! ScreenDepth Applies only to multi-depth displays. It specifies which of the available depths Wine should use (and tell Windows apps about). Display This specifies which X11 display to use, and if specified, will override the DISPLAY environment variable. PerfectGraphics This option only determines whether fast X11 routines or exact Wine routines will be used for certain ROP codes in blit operations. Most users won't notice any difference. Currently, the ttydrv doesn't have any special configuration options to set in the configuration file. The windows and DOS version value a program gets e.g. by calling the Windows function GetVersion() plays a very important role: If your Wine installation for whatever reason fails to provide to your program the correct version value that it expects, then the program might assume some very bad things and fail (in the worst case even silently!). Fortunately Wine contains some more or less intelligent Windows version guessing algorithm that will try to guess the Windows version a program might expect and pass that one on to the program. Thus you should not lightly configure a version value, as this will be a "forced" value and thus turn out to be rather harmful to proper operation. In other words: only explicitly set a Windows version value in case Wine's own version detection was unable to provide the correct Windows version and the program fails. The version values can be configured in the wine configuration file in the [Version] section. "Windows" = "<version string>" default: none; chosen by semi-intelligent detection mechanism based on DLL environment. Used to specify which Windows version to return to programs (forced value, overrides standard detection mechanism!). Valid settings are e.g. "win31", "win95", "win98", "win2k", "winxp". Also valid as an AppDefaults setting (recommended/preferred use). "DOS"="<version string>" Used to specify the DOS version that should be returned to programs. Only takes effect in case Wine acts as "win31" Windows version! Common DOS version settings include 6.22, 6.20, 6.00, 5.00, 4.00, 3.30, 3.10. Also valid as an AppDefaults setting (recommended/preferred use). &fonts; &printing; This file describes setting up the Windows ASPI interface. 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. 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). So please make sure that all SCSI devices not needed by the program have their permissions set as restricted as possible! The software needs to use the "Adaptec" compatible drivers (ASPI). At least with Mustek, they allow you the choice of using the built-in 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. 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. 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 http://www.linuxdoc.org/HOWTO/CD-Writing-HOWTO.html for ide-scsi setup instructions. Compile generic SCSI drivers into your kernel. 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 SG_BIG_BUFF (in sg.h) that is by default set too low. The SANE project recommends 130560 and this seems to work just fine. This does require a kernel rebuild. Make the devices for the scanner (generic SCSI devices) - look at the SCSI programming HOWTO at http://www.linuxdoc.org/HOWTO/SCSI-Programming-HOWTO.html for device numbering. I would recommend making the scanner device writable by a group. I made a group called scanner 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. 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/config. The format is [scsi cCtTdD] where "C" = "controller", "T" = "target", D=LUN For example, I set mine up as controller 0, Target 6, LUN 0. [scsi c0t6d0] "Device" = "/dev/sgi" Yours will vary with your particular SCSI setup. The biggest drawback is that it only works under Linux at the moment. The ASPI code has only been tested with: a Mustek 800SP with a Buslogic controller under Linux [BM] a Siemens Nixdorf 9036 with Adaptec AVA-1505 under Linux accessed via DOSASPI. Note that I had color problems, though (barely readable result) [AM] 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] This section describes how ODBC works within Wine and how to configure it. 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). 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: export LIB_ODBC_DRIVER_MANAGER=/usr/lib/libodbc.so.1.0.0 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 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.