make builtin dlls visible for applications?

[wino at piments.com]

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