5.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 Wine command line parameter --debugmsg +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:

Win16Win32 Native [a]
KERNELKERNEL32No!
USERUSER32No!
SHELLSHELL32Yes
GDIGDI32No!
COMMDLGCOMDLG32Yes
VERVERSIONYes
Notes:
a. Is it possible to use native DLL with wine? (See next section)

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 been deprecated, ignored.

elfdll

ELF encapsulated windows DLL's. No longer used, ignored.

5.7.3. DLL Overrides

Written by Ove Kåven

(Extracted from wine/documentation/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 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.

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

Written by 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:

  1. The directory the program was started from.

  2. The current directory.

  3. The Windows system directory.

  4. The Windows directory.

  5. 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.

5.7.6. Fetching native DLLs from a Windows CD

Written by 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.