Setting up config files, etc. Copyright 1999 &name-adam-sacarny; &email-adam-sacarny; (Extracted from wine/documentation/config) The Wine config file stores various settings for Wine. These include: Drives and information about them Directory settings Port settings The Wine look and feel Wine's DLL usage Wine's multimedia drivers and DLL configuration This section will guide you through the process of making a config file. Take a look at the file <dirs to wine>/documentation/samples/config. It is organized by section. Section Name Needed? What it Does [Drive X] yes Sets up drives recognized by wine [wine] yes Settings for wine directories [DllDefaults] recmd Defaults for loading DLL's [DllPairs] recmd Sanity checkers for DLL's [DllOverrides] recmd Overides defaults for DLL loading [x11drv] recmd Graphic driver settings [fonts] yes Font appearance and recognition [serialports] no COM ports seen by wine [parallelports] no LPT ports seen by wine [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 [tweak.layout] recmd Appearance of wine [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 These sections are supposed to make certain Unix directory locations accessible to Wine as a DOS/Windows drive (drive 'X:') and thus accessible to Windows programs under the drive name you specified. Every DOS/Windows program sort of expects at least a C: drive (and sometimes also an A: floppy drive), so your config file should at least contain the corresponding sections, [Drive C] and [Drive A]. You need to decide on whether you want to use an existing Windows partition as the C drive or whether you want to create your own Wine drive C directory tree somewhere (take care about permissions !). Each drive section may specify up to 6 different settings as explained below. [Drive X] The above line begins the section for a drive whose letter is X (DOS notation: drive 'X:'). You could e.g. create an equivalent to a drive 'C:' under DOS/Windows by using a [Drive C] section name. "Path" = "/dir/to/path" This specifies the directory where the drive will begin. When Wine is browsing in drive X, it will be able to see the files that are in the directory /dir/to/path and below. (note that symlinks to directories won't get included ! see "ShowDirSymlinks" config setting) You can also make use of environment variables like $HOME here, an example for using a mywinedrive directory in your home dir would be "Path" = "${HOME}/mywinedrive" Don't forget to leave off the trailing slash! "Type" = "hd|cdrom|network|floppy" Sets up the type of drive Wine will see it as. Type must equal one of the four floppy, hd, cdrom, or network. They are self-explanatory. (The |'s mean "Type = '<one of the options>'".) Usually, you choose "hd" for a drive ("hd" is default anyway). "Label" = "blah" Defines the drive label. Generally only needed for programs that look for a special CD-ROM. The label may be up to 11 characters. Note that the preferred way of managing labels and serial numbers of CD-ROMs and floppies is to give Wine raw device access for reading these on a per-CD case (see "Device" below) instead of hardcoding one specific "Label". "Serial" = "deadbeef" Tells Wine the serial number of the drive. A few programs with intense protection for pirating might need this, but otherwise it's not needed. Up to 8 characters and hexadecimal. Using a "Device" entry instead of hardcoding the "Serial" probably is a smarter choice. "Filesystem" = "win95|unix|msdos" Sets up the way Wine looks at files on the drive. win95 Case insensitive. Alike to Windows 9x/NT 4. This is the long filename filesystem you are probably used to working with. The filesystem of choice for most applications to be run under wine. PROBABLY THE ONE YOU WANT! unix Case sensitive. This filesystem has almost no use (Windows apps expect case insensitive filenames). Try it if you dare, but win95 is a much better choice. msdos Case insensitive filesystem. Alike to DOS and Windows 3.x. 8.3 is the maximum length of files (eightdot.123) - longer ones will be truncated. (NOTE: this is a very bad choice if you plan on running apps that use long filenames. win95 should work fine with apps that were designed to run under the msdos system. In other words, you might not want to use this.) "Device" = "/dev/xx" Needed for raw device access and label and serial number reading. Use this ONLY for floppy and cdrom devices. Using it on Extended2 or other Unix file systems can have dire results (when a windows app tries to do a lowlevel write, they do it in a FAT way -- FAT format is completely different from any Unix file system). Also, make sure that you have proper permissions to this device file. This setting is not really important; almost all apps will have no problem if it remains unspecified. For CD-ROMs it's quite useful in order to get automatic label detection, though. If you are unsure about specifying device names, just leave out this setting for your drives. Here are a few sample entries: Here is a setup for Drive C, a generic hard drive: [Drive C] "Path" = "/dosc" "Type" = "hd" "Label" = "Hard Drive" "Filesystem" = "win95" This is a setup for Drive E, a generic CD-ROM drive: [Drive E] "Path" = "/mnt/cdrom" "Type" = "cdrom" "Label" = "Total Annihilation" "Filesystem" = "win95" "Device" = "/dev/cdrom" And here is a setup for Drive A, a generic floppy drive: [Drive A] "Type" = "floppy" "Path" = "/mnt/floppy" "Label" = "Floppy Drive" "Serial" = "87654321" "Filesystem" = "win95" "Device" = "/dev/fd0" The [wine] section of the configuration file contains all kinds of general settings for Wine. "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 applications 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! "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"). "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 any Windows GUI programs. 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. "Printer" = "off|on" Tells wine whether to allow printing via printer drivers to work. This option isn't needed for our builtin 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 on working on printing via windows printer drivers, don't even add this to your wine config 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. "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. "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. 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 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. Will not work yet. elfdll ELF encapsulated windows DLL's. No longer used, ignored. These settings provide wine's default handling of DLL loading. "DefaultLoadOrder" =" native, so, builtin" This setting is a comma-delimited list of the order in which to attempt loading DLLs. If the first option fails, it will try the second, and so on. The order specified above is probably the best in most conditions. 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. The format for this section is the same for each line: <DLL>{,<DLL>,<DLL>...} = <FORM>{,<FORM>,<FORM>...} For example, to load builtin KERNEL pair (case doesn't matter here): "kernel,kernel32" = "builtin" To load the native COMMDLG pair, but if that doesn't work try builtin: "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 applications 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 (<dirs to wine>/documentation/ttfserver and fonts), 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 info check out the Fonts chapter. Even though it sounds like a lot of sections, these are all closely related. They are all for communications and parallel ports. The [serialports] section tells wine what serial ports it is allowed to use. "ComX" = "/dev/cuaY" Replace X with the number of the COM port in Windows (1-8) and Y with the number of it in X (Usually the number of the port in Windows minus 1). ComX can actually equal any device (/dev/modem is acceptable). It is not always necessary to define any COM ports (An optional setting). Here is an example: "Com1" = "/dev/cua0" Use as many of these as you like in the section to define all of the COM ports you need. The [parallelports] section sets up any parallel ports that will be allowed access under wine. "LptX" = "/dev/lpY" Sounds familiar? Syntax is just like the COM port setting. Replace X with a value from 1-4 as it is in Windows and Y with a value from 0-3 (Y is usually the value in windows minus 1, just like for COM ports). You don't always need to define a parallel port (AKA, it's optional). As with the other section, LptX can equal any device (Maybe /dev/printer). Here is an example: "Lpt1" = "/dev/lp0" 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 the --debugmsg +relay option.) "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 --debugmsg +relay trace. This entry is ignored if there is a RelayExclude entry. "RelayExclude" = "RtlEnterCriticalSection;RtlLeaveCriticalSection" Exclude the listed functions in a --debugmsg +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 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. [tweak.layout] is devoted to wine's look. There is only one setting for it. "WineLook" = "win31|win95|win98" Will change the look of wine from Windows 3.1 to Windows 95. The win98 setting behaves just like win95 most of the time. [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 and 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 applications 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 application specific settings you define. The three parts of the section name are separated by two backslashes. Currently wine supports only overwriting the sections [DllOverrides], [x11drv], [version] and [dsound]. Here is an example that overwrites 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" The wine config file can go in two places. /usr/local/etc/wine.conf A systemwide config file, used for anyone who doesn't have their own. NOTE: this file is currently unused as a new global configuration mechanism is not in place at this time. $HOME/.wine/config Your own config file (which only is used for your user). So copy your version of the wine config file to $HOME/.wine/config or /usr/local/etc/wine.conf for wine to recognize it. 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 IRCnet channel #WineHQ found on irc.stealth.net:6668, 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. Written by &name-ove-kaaven; &email-ove-kaaven; (Extracted from wine/documentation/x11drv) Most Wine users run Wine under the windowing system known as X11. During most of Wine's history, this was the only display driver available, but in recent years, parts of Wine has been reorganized to allow for other display drivers (although the only alternative currently available is Patrik Stridvall's ncurses-based ttydrv, which he claims works for displaying calc.exe). The display driver is chosen with the GraphicsDriver option in the [wine] section of ~/.wine/config, but I will only cover the x11drv driver in this article. 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 applications 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 config 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 applications 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 applications 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 config 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 application windows will just be Wine-drawn windows inside the Wine-provided desktop window (which will itself be managed by your window manager), and Windows applications 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 application; 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 applications 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. UseXShm If you don't want DirectX to use DGA, you can at least use X Shared Memory extensions (XShm). It is much slower than DGA, since the app doesn't have direct access to the physical frame buffer, but using shared memory to draw the frame is at least faster than sending the data through the standard X11 socket, even though Wine's XShm support is still known to crash sometimes. 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 applications. 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. TextCP Codepage to be used for rendering the text in X11 output. Some sample values would be 437 (USA, Canada), 850 (Europe), 852 (Central/Eastern Europe), 855 (Cyrillic). For additional suitable values, see e.g. the Linux kernel's codepage configuration page. ®istry; Written by &name-andreas-mohr; &email-andreas-mohr; Oct 18 2002 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 config 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). Petr Tomasek

&email-petr-tomasek;

Nov 14 1999 Andreas Mohr

&email-andreas-mohr;

Jan 25 2000 Written by &name-petr-tomasek; &email-petr-tomasek; Nov 14 1999 Changes by &name-andreas-mohr; &email-andreas-mohr; Jan 25 2000 (Extracted from wine/documentation/cdrom-labels) Until now, your only possibility of specifying drive volume labels and serial numbers was to set them manually in the wine config file. By now, wine can read them directly from the device as well. 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 automagically if you specify a Device= line in the [Drive X] section in your ~/.wine/config. Note that the device has to exist and must be accessible if you do this, though. If you don't do that, then you should give fixed "Label" = or "Serial" = entries in ~/.wine/config, as Wine returns these entries instead if no device is given. If they don't exist, then Wine will return default values (label Drive X and serial 12345678). If you want to give a "Device" = entry only for drive raw sector accesses, but not for reading the volume info from the device (i.e. you want a fixed, preconfigured label), you need to specify "ReadVolInfo" = "0" to tell Wine to skip the volume reading. Here's a simple example of cdrom and floppy; labels will be read from the device on both cdrom and floppy; serial numbers on floppy only: [Drive A] "Path" = "/mnt/floppy" "Type" = "floppy" "Device" = "/dev/fd0" "Filesystem" = "msdos" [Drive R] "Path" = "/mnt/cdrom" "Type" = "cdrom" "Device" = "/dev/hda1" "Filesystem" = "win95" Here's an example of overriding the CD-ROM label: [Drive J] "Path" = "/mnt/cdrom" "Type" = "cdrom" "Label" = "X234GCDSE" ; note that the device isn't really needed here as we have a fixed label "Device" = "/dev/cdrom" "Filesystem" = "msdos" The cdrom label can be read only if the data track of the disk resides in the first track and the cdrom is iso9660. Better checking for FAT superblock (it now checks only one byte). Support for labels/serial nums WRITING. Can the label be longer than 11 chars? (iso9660 has 32 chars). What about reading ext2 volume label? .... Written by &name-ove-kaaven; &email-ove-kaaven; (Extracted from wine/documentation/dll-overrides) The wine config 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 "builtin" 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. so A native Unix .so file, with calling convention conversion thunks generated on the fly as the library is loaded. This is mostly useful for libraries such as "glide" that have exactly the same API on both Windows and Unix. 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 builtins 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 explictly 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. Written by &name-andreas-mohr; &email-andreas-mohr; 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 application 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 config 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. Written by &name-andreas-mohr; &email-andreas-mohr; 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. &fonts; &printing; Written by &name-david-cuthbert; &email-david-cuthbert; (Extracted from wine/documentation/win95look) Win95/Win98 interface code is being introduced. Instead of compiling Wine for Win3.1 vs. Win95 using #define switches, the code now looks in a special [Tweak.Layout] section of ~/.wine/config for a "WineLook" = "Win95" or "WineLook" = "Win98" entry. A few new sections and a number of entries have been added to the ~/.wine/config file -- these are for debugging the Win95 tweaks only and may be removed in a future release! These entries/sections are: [Tweak.Fonts] "System.Height" = "<point size>" # Sets the height of the system typeface "System.Bold" = "[true|false]" # Whether the system font should be boldfaced "System.Italic" = "[true|false]" # Whether the system font should be italicized "System.Underline" = "[true|false]" # Whether the system font should be underlined "System.StrikeOut" = "[true|false]" # Whether the system font should be struck out "OEMFixed.xxx" # Same parameters for the OEM fixed typeface "AnsiFixed.xxx" # Same parameters for the Ansi fixed typeface "AnsiVar.xxx" # Same parameters for the Ansi variable typeface "SystemFixed.xxx" # Same parameters for the System fixed typeface [Tweak.Layout] "WineLook" = "[Win31|Win95|Win98]" # Changes Wine's look and feel Written by &name-ove-kaaven; &email-ove-kaaven; (Extracted from wine/documentation/keyboard) Wine now needs to know about your keyboard layout. This requirement comes from a need from many apps to have the correct scancodes available, since they read these directly, instead of just taking the characters returned by the X server. This means that Wine now needs to have a mapping from X keys to the scancodes these applications expect. On startup, Wine will try to recognize the active X layout by seeing if it matches any of the defined tables. If it does, everything is alright. If not, you need to define it. To do this, open the file dlls/x11drv/keyboard.c and take a look at the existing tables. Make a backup copy of it, especially if you don't use CVS. What you really would need to do, is find out which scancode each key needs to generate. Find it in the main_key_scan table, which looks like this: static const int main_key_scan[MAIN_LEN] = { /* this is my (102-key) keyboard layout, sorry if it doesn't quite match yours */ 0x29,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0A,0x0B,0x0C,0x0D, 0x10,0x11,0x12,0x13,0x14,0x15,0x16,0x17,0x18,0x19,0x1A,0x1B, 0x1E,0x1F,0x20,0x21,0x22,0x23,0x24,0x25,0x26,0x27,0x28,0x2B, 0x2C,0x2D,0x2E,0x2F,0x30,0x31,0x32,0x33,0x34,0x35, 0x56 /* the 102nd key (actually to the right of l-shift) */ }; Next, assign each scancode the characters imprinted on the keycaps. This was done (sort of) for the US 101-key keyboard, which you can find near the top in keyboard.c. It also shows that if there is no 102nd key, you can skip that. However, for most international 102-key keyboards, we have done it easy for you. The scancode layout for these already pretty much matches the physical layout in the main_key_scan, so all you need to do is to go through all the keys that generate characters on your main keyboard (except spacebar), and stuff those into an appropriate table. The only exception is that the 102nd key, which is usually to the left of the first key of the last line (usually Z), must be placed on a separate line after the last line. For example, my Norwegian keyboard looks like this § ! " # ¤ % & / ( ) = ? ` Back- | 1 2@ 3£ 4$ 5 6 7{ 8[ 9] 0} + \´ space Tab Q W E R T Y U I O P Å ^ ¨~ Enter Caps A S D F G H J K L Ø Æ * Lock ' Sh- > Z X C V B N M ; : _ Shift ift < , . - Ctrl Alt Spacebar AltGr Ctrl Note the 102nd key, which is the <> key, to the left of Z. The character to the right of the main character is the character generated by AltGr. This keyboard is defined as follows: static const char main_key_NO[MAIN_LEN][4] = { "|§","1!","2\"@","3#£","4¤$","5%","6&","7/{","8([","9)]","0=}","+?","\\´", "qQ","wW","eE","rR","tT","yY","uU","iI","oO","pP","åÅ","¨^~", "aA","sS","dD","fF","gG","hH","jJ","kK","lL","øØ","æÆ","'*", "zZ","xX","cC","vV","bB","nN","mM",",;",".:","-_", "<>" }; Except that " and \ needs to be quoted with a backslash, and that the 102nd key is on a separate line, it's pretty straightforward. After you have written such a table, you need to add it to the main_key_tab[] layout index table. This will look like this: static struct { WORD lang, ansi_codepage, oem_codepage; const char (*key)[MAIN_LEN][4]; } main_key_tab[]={ ... ... {MAKELANGID(LANG_NORWEGIAN,SUBLANG_DEFAULT), 1252, 865, &main_key_NO}, ... After you have added your table, recompile Wine and test that it works. If it fails to detect your table, try running wine --debugmsg +key,+keyboard >& key.log and look in the resulting key.log file to find the error messages it gives for your layout. Note that the LANG_* and SUBLANG_* definitions are in include/winnls.h, which you might need to know to find out which numbers your language is assigned, and find it in the debugmsg output. The numbers will be (SUBLANG * 0x400 + LANG), so, for example the combination LANG_NORWEGIAN (0x14) and SUBLANG_DEFAULT (0x1) will be (in hex) 14 + 1*400 = 414, so since I'm Norwegian, I could look for 0414 in the debugmsg output to find out why my keyboard won't detect. Once it works, submit it to the Wine project. If you use CVS, you will just have to do cvs -z3 diff -u dlls/x11drv/keyboard.c > layout.diff from your main Wine directory, then submit layout.diff to wine-patches@winehq.com along with a brief note of what it is. If you don't use CVS, you need to do diff -u the_backup_file_you_made dlls/x11drv/keyboard.c > layout.diff and submit it as explained above. If you did it right, it will be included in the next Wine release, and all the troublesome applications (especially remote-control applications) and games that use scancodes will be happily using your keyboard layout, and you won't get those annoying fixme messages either. Good luck. This section describes how ODBC works within Wine and how to configure it to do what you want (if it can do what you want). 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 builtin 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 builtin odbc32 dll. The builtin odbc32 (currently) looks to the environmental 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 environmental 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 builtin version of odbc32.dll, by modifying the DLL configuration. This builtin dll merely acts as a stub between the calling code and the Unix ODBC library. If you have any problems then you can use the debugmsg channel odbc32 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. Does anyone actually have any experience of this and anything to add?