[Wine] Confusion about Dll Overriding
alan at cb.transcon.com.br
Thu Nov 16 13:07:40 CST 2006
Alan McKinnon escreveu:
> On Thursday 16 November 2006 16:30, Steven Woody wrote:
>> the winecfg confused me about DLL overriding. In the 'libraries'
>> tab, if i specified a Dll file name and click 'Add', how does Wine
>> know where to load the native file when need? does it mean i also
>> have to copy the native file into the "c:\windows\system"
>> directory? if so, why i have to bother with the winecfg, why not
>> directlly copy files into the "c:\windows\system' and hope it
>> will be loaded as neccessary?
>> and, i found there are still many DLLs in the "c:\windows\system"
>> and get much smaller size than orignial windows native files. what
>> does this mean?
> From Wine's point of view, there are two kinds of windows dll's:
> 1. One that is actually a Linux .so and implements the stuff you expect
> to find in the dll. The wine devs write this stuff. How this happens is
> black magic and you don't need to worry about it. What you do need to
> know is that wine calls these things "builtin"
> 2. Actually real Windows .dll files that you pinched off a windows
> install somewhere, or were installed by a third party package/app. You
> can make these things happen by copying a .dll from somewhere else to
> the appropriate directory in ~/.wine/drive_c/<somewhere>. Wine calls
> these things "native". They look like windows binaries becuase they are
> windows binaries in every respect. Forget for now that they are living
> on a disk being run by a Linux install - wine knows what to do with
> Enter winecfg. Some .dlls work better as builtin than as native, and
> some work better as native. For example, there's a builtin called
> gdi.<something_or_other> that will never in a brazillion years work as
What you mean whyt
"never in a brazillion years"
> a native. These things are tagged as builtin in winecfg. For the rest,
> the normal way of doing things is to say that everything is a builtin,
> and adjust if and when you realize that the builtin doesn't have some
> essential functionality. The wine devs want you to use builtins as much
> as possible, then you can tell them what is broken so they can fix it.
> This is the default in winecfg.
> Wine will never use a native .dll unless you say it must in winecfg. To
> do this you must:
> 1. Copy the native .dll (which you often steal from a Windows install)
> into .wine/windows/system32,or let the program's installer do it for
> 2. Tag it as a native in winecfg. You can do this on a glocal or per-app
> basis, do you know how to do this?
> The main trick is that wine will only use natives if you told it to do
> so in winecfg, and then the .dll must exist on disk in the palce
> windows expects it to be.
> wine-users mailing list
> wine-users at winehq.org
More information about the wine-users