Login
View Cart
Ticket System
Documentation5.7. DLL configuration
5.7.1. Introduction
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.
5.7.2. Introduction To DLL Sections
There are a few things you will need to know before configuring the DLL sections in your wine configuration file.
5.7.2.1. Windows DLL Pairs
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:
5.7.2.2. Different Forms Of DLL's
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.
5.7.3. DLL Overrides
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.
5.7.3.1. DLL types
- 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.
5.7.3.2. The [DllDefaults] section
- 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.
5.7.3.3. The [DllPairs] 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.
5.7.3.4. The [DllOverrides] section
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.
5.7.4. System DLLs
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).
5.7.5. Missing DLLs
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.
5.7.6. Fetching native DLLs from a Windows CD
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.