Re: Confusion about Dll Overriding

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

 



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






_______________________________________________
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