make builtin dlls visible for applications?
wino at piments.com
wino at piments.com
Fri Nov 18 11:37:30 CST 2005
On Thu, 17 Nov 2005 23:56:40 +0100, Peter Beutner <p.beutner at gmx.net>
wrote:
> Hi
>
> There is yet another issue preventing SeriousSam from working.
> It fails to load opengl32.dll because before loading the dll it makes
> sure it can find it
> via SearchPath().The problem is that SearchPath doesn't know about the
> builtin dlls
> provided by wine, so it fails to find them and SeriousSam won't start.
>
> I can think of several ways to work around that, but i don't really like
> any of them.
> Maybe somebody else can throw in some comments or even has a better idea:
>
> possible solutions:
> 1) let SearchPath search for builtin dlls, and if found make it pretend
> the file exists in
> the c:\windows\system32\.
> This will cause all sorts of trouble if the application want to do
> anything else with the
> file beside trying to load it.(think of somebody browsing around with a
> Filemanager trying
> to copy/move/rename those files)
>
> 2) place dummy files for all builtin dlls in c:\windows\system32 (or
> symlinks pointing to
> corresponding *.dll.so files)
> hmm I guess you would get into trouble if you use WINEDLLOVERRIDE.
> Wouldn't
> LoadLibrary try to load those dummy files?
>
> 3) just put it under the category "application-specific hack", and put
> instructions
> somewhere(appdb,..) what to do to get it working.
> ie:"touch ~/.wine/drive_c/windows/system32/opengl32.dll", would do it in
> this case.
>
> 4) combination from 1) and 3), solve it like in 1) but make it a
> per-application
> configuration setting similar to dll overrides.
>
> Comments?
> Better ideas?
>
> Peter
>
>
>
well I think you've noted the disadvantages that make all those not really
workable on a wholesale basis. I dont think any artificial techniques in
SearchFile would be globally acceptable.
All I can think of is using winecfg to deal with them on a per application
basis.
For ex. I had an app which worked fine with the builtin version of a dll
but did a check for the file as you are seeing. I did touch the.dll and
then configured it to use built-in.
If other apps want a real one this does not conflict with the above, just
replace the zero-length one.
The next issue with startup checks is the current lack of version info in
most wine dlls.
I dont know whether this is simply "todo" or whether its just difficult to
say what version number best represents a given built-in's state of
development.
One idea here may be to provide a mechanism like DLLOVERRIDES= , eg
DLLVERSIONS="riched20-5.0.36.8" , firstly as a means (quicker than
patching the unit) to provide version info for a dll
More information about the wine-devel
mailing list