On Sun, Jun 14, 2009 at 3:33 PM, Stefan Dösinger<stefandoesin...@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 ehoo...@mines.edu