On Sun, Jun 14, 2009 at 5:33 PM, Stefan Dösingerstefandoesinger@gmx.at wrote:
*) 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.
*) 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
Can we form a mob after the people that do this? For the first point that would mean the app has hardcoded mappings since we only report one filename. But this situation is also possible in windows if you switch video cards, so it would fail on windows as well.
For the second point, as said previously, we can have a generic stub dll and a specific one. Since (as Erich notes) nvdia doesn't export any symbols, we can use the generic one for it. If ATI exports symbols we write a specialized one. And in the worst case we fail in DllMain. I doubt there are many apps that do this.
On Sun, Jun 14, 2009 at 7:09 PM, Erich Hooverehoover@mines.edu wrote:
Does the attached sound more like what people are looking for (with driver_filename_table filled in a bit more, of course)?
Erich Hoover ehoover@mines.edu
I'm a little queasy about a forceful vendor-os combo: what stops vendors from having different driver filenames for different cards? What I had in mind when I was thinking of the multi-version solution was: struct driver_version_information { WORD vendor; /* reported PCI card vendor ID */ WORD card; /* reported PCI card device ID */ + driver_os_version os; const char *description; /* Description of the card e.g. NVIDIA RIVA TNT */ + const char *driver_filename; WORD hipart_hi, hipart_lo; /* driver hiword to report */ WORD lopart_hi, lopart_lo; /* driver loword to report */ };
But if noone has problems about the vendor-os combo then this is perfect.
Mike.