Request for comments on patch

Mike Kaplinskiy mike.kaplinskiy at gmail.com
Sun Jun 14 16:33:21 CDT 2009


On Sun, Jun 14, 2009 at 5:20 PM, Erich Hoover<ehoover at mines.edu> wrote:
> On Sun, Jun 14, 2009 at 3:13 PM, Mike
> Kaplinskiy<mike.kaplinskiy at gmail.com> wrote:
>> ...
>>
>> Then perhaps when this mechanism is in place, we can add a way to have
>> 1 general "funnel" dll and symlink it on prefix creation (if it's not
>> already there). This way we don't have to worry about newer graphics
>> cards as much, and if there is a specific implementation for a
>> specific brand/card we can use it instead of the general one.
>>
>> As for the files being different on different windows' - maybe
>> extending the list to also return different rows based on the windows
>> version (and also add WINVER_ALL as wildcard) would work. But that
>> seems rather hacky, and the whole business doesn't seem like it would
>> give too much benefit.
>>
>> Mike.
>>
>
> I was considering that method of "funneling" at first, but since there
> are no DLL symlinks in */lib/wine/ currently I figured this would
> prove objectionable.  I also didn't realize the driver name is
> reported differently on different OS versions (which makes for a lot
> more driver filenames).

I didn't mean symlinking to the /lib/wine directory, but rather,
symlinking to prefix/windows/system32/ from /lib/wine/ . But since
that isn't done either, just copying to a new filename also seems
reasonable. Sadly if we do have a registry-based mechanism for
selection, this might not be possible to do on wineboot (unless there
is a way to check on every startup?)

Stubbing dlls for every possible driver (even if there are only 2-3)
seems too much, so a general driver should be available. I'm just not
too sure on how to convert between that driver's filename and the
specific filename that our table gives.

>
> "struct driver_version_information" contains the vendor as an integer
> already, a separate structure could easily contain columns for
> matching the Vendor and OS in order to return a driver filename.  That
> way you wouldn't end up with a giant "struct
> driver_version_information".

Yes that is what I meant to say, sorry if I didn't make my intentions
clear. I was just thinking about the size of the driver_version_table
array - 5-10 os's, 30-40 drivers already there...that's 150-400
entries, and adding something like WINVER_ANY (as a last resort when
matching) would make it a smaller.

>
> Erich Hoover
> ehoover at mines.edu
>

Mike.



More information about the wine-devel mailing list