Written by Ove Kåven <ovek@arcticnet.no>
(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.
A "native" DLL is a .DLL file written for the real Microsoft Windows.
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.
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.
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):
Native versions of these will never work, so don't try. Leave at builtin.
Graphics Device Interface. No effort has been made at trying to run native GDI. Leave at builtin.
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.
NT kernel API. Although badly documented, the native version of this will never work. Leave at builtin.
Win32s (for Win3.x). The native version will probably never work. Leave at builtin.
Win16 support library for NT. The native version will probably never work. Leave at builtin.
Win16 kernel stuff. Will never work native. Leave at builtin.
Display driver. Definitely leave at builtin.
Tool helper routines. This is rarely a source of problems. Leave at builtin.
Versioning. Seldom useful to mess with.
Registry and security features. Trying the native version of this may or may not work.
Common Dialogs, such as color picker, font dialog, print dialog, open/save dialog, etc. It is safe to try native.
Common Controls. This is toolbars, status bars, list controls, the works. It is safe to try native.
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.
Windows Sockets. The native version will not work under Wine, so leave at builtin.
ICMP routines for wsock32. As with wsock32, leave at builtin.
The native version may not work due to thunking issues. Leave at builtin.
Lempel-Ziv decompression. Wine's builtin version ought to work fine.
Advanced SCSI Peripheral Interface. The native version will probably never work. Leave at builtin.
C Runtime library. The native version will easily work better than Wine's on this one.
Printer spooler. You are not likely to have more luck with the native version.
DirectDraw/Direct3D. Since Wine does not implement the DirectX HAL, the native version will not work at this time.
DirectInput. Running this native may or may not work.
DirectSound. It may be possible to run this native, but don't count on it.
DirectPlay. The native version ought to work best on this, if at all.
Multimedia system. The native version is not likely to work. Leave at builtin.
Audio Compression Manager. The builtin version works best, if you set msacm.drv to the same.
Video for Windows. It is safe (and recommended) to try native.
CD Audio MCI driver.
MIDI Sequencer MCI driver (.MID playback).
Wave audio MCI driver (.WAV playback).
AVI MCI driver (.AVI video playback). Best to use native.
Animation MCI driver.
Audio Compression Manager. Set to same as msacm32.
MIDI Mapper.
This is a pseudo-DLL used by Wine for thunking purposes. A native version of this doesn't exist.
Written by Andreas Mohr <andi@rhlx01.fht-esslingen.de>
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.
Written by Andreas Mohr <andi@rhlx01.fht-esslingen.de>
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.