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
On Thu, 17 Nov 2005 23:56:40 +0100, Peter Beutner p.beutner@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:
- 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)
- 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?
- 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.
- 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
-
Peter Beutner -
wino＠piments.com