Request for comments on patch

Mike Kaplinskiy mike.kaplinskiy at gmail.com
Sun Jun 14 20:28:29 CDT 2009


On Sun, Jun 14, 2009 at 8:33 PM, Ben Klein<shacklein at gmail.com> wrote:
> 2009/6/15 Mike Kaplinskiy <mike.kaplinskiy at gmail.com>:
>> On Sun, Jun 14, 2009 at 5:33 PM, Stefan Dösinger<stefandoesinger at 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.
>
> The point is that Wine shouldn't act as if there are (or have been)
> multiple video cards for this reason - the apps could hate you for it.
> As Roderick said, the correct driver name has to be selected at
> runtime, and based on the features exposed by the OpenGL/GLX/driver
> implementation.
>

The correct driver name will be selected. I believe what Stefan is
saying is that other dlls may be present due to previous
configurations. What I am trying to say is that this will fail to work
on windows as well. In the best case where the driver filename never
gets changed, our behavior will match that of windows.

If this is still undesirable, we can purge system32 of all the
driver-specific dll's and copy the correct dll at init every time.

>> 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.
>
> You make it sound easy!
>

I'm talking about building an empty dll and then copying it over when
the driver file name we return doesn't actually exist. Perhaps we
can't (easily) change the version information during the copy but as a
starting point, just copying the file will be good enough. So
something like:

if (!exists(prefix/system32/current driver's .dll)) {
   if (exists(/usr/lib/wine/current driver's .dll.so))
      copy(/usr/lib/wine/current driver's .dll.so,
prefix/system32/current driver's .dll);
   else
      copy(/usr/lib/wine/generic driver .dll.so,
prefix/system32/current driver's .dll);
}

And the generic driver.dll.so will have a DllMain which returns false.
Am I missing something important?

Mike.



More information about the wine-devel mailing list