[Wine] Confusion about Dll Overriding

[Alan]

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[32]"
>> directory?  if so, why i have to bother with the winecfg, why not
>> directlly copy files into the "c:\windows\system[32]' and hope it
>> will be loaded as neccessary?
>>
>> and, i found there are still many DLLs in the "c:\windows\system[32]"
>> 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 
> them.
>
> 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 
> you.
> 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.
>
> alan
>
>
> _______________________________________________
> wine-users mailing list
> wine-users at winehq.org
> http://www.winehq.org/mailman/listinfo/wine-users
>
>
>
>
>