On Sun, Jun 14, 2009 at 3:33 PM, Stefan Dösingerstefandoesinger@gmx.at wrote:
Am Sonntag, 14. Juni 2009 23:11:42 schrieb Erich Hoover:
So, a patch similar to the one Mike pointed out* but able to report different drivers for different OSes would prove acceptable (possibly w/ a second patch for overrides)? The email was some time ago, but I thought someone was pretty adamant that Wine should not report a driver that does not exist and that was the major show-stopper.
Is there any app that depends on the real display driver name, or just the device description string? I lost overview of the situation :-/
Yes, the one I'm most familiar with is Fallout 3. It's very tempting to whack Bethesda upside the head...
There are some other problems to deal with:
*) If we create a stub / thunk driver for each known windows display driver, we potentially have all those thunks around. E.g. an app might complain that it finds BOTH nv4_disp.dll AND atiumdag.dll.
You think that the very existence of extra DLLs would pose a problem? Even if the DLL detected that it was incorrect and failed on DllMain?
*) Providing these vendor specific DLLs can trigger other problems - for example, apps might start trying to call functions in the driver, but skip gracefully now. So we should see if the driver APIs are at least pseudo-documented
At least for the nvidia driver (nv4_disp.dll) there are no exposed functions, I don't currently have a driver disk for other manufacturers. However, it's possible that routines are exposed in some other way.
*) Centralized detection. If the gdi32 detection comes to a different conclusion than the wined3d one this may cause trouble. It may require moving the current wined3d GL based detection code to winex11.drv and use it from wined3d and gdi and others to report the same result everywhere.
I believe in the example that I attached that I found all of the detection code and put it in one centralized location.
Erich Hoover ehoover@mines.edu