Re: Confusion about Dll Overriding

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 
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@xxxxxxxxxx
http://www.winehq.org/mailman/listinfo/wine-users


[Index of Archives]     [Gimp for Windows]     [Red Hat]     [Samba]     [Yosemite Camping]     [Graphics Cards]     [Wine Home]

  Powered by Linux