WinelibVersion() [was: bit-blit ops]

[Alexandre Julliard]

cdr <cedar at 3web.net> writes:

> Wine used to be almost exclusively for end users who had win32
> applications (binaries), and wanted to run them under Linux,
> not only without any help, bu almost "againt the will" of the
> developers of those applications. I am, on the other hand,
> a different animal (and, looking around me, I notice my part
> of the zoo expanding...): a developer who would *like to help*
> my end user to run those applications under Linux. However,
> I can not possibly justify a complete re-write. Since wine is
> (and will remain forever) less than "100% windoze" (we can argue
> the numbers, but not the principle) the more I can be given a
> "helping hand" to deal with those residual differences, the
> more I'll be able to make my Win32 apps available to Linux users.
> 
> (int WinelibVersion(); that returns yyyynn - Please, please...)

While clearly the best approach is to fix Wine, I think we can all
agree that this isn't always an option. This does *not* mean that you
need a WinelibVersion() function, or even a Wine check at all. What
you should be doing is find a way to check for the bug itself, not
blindly assume that because it's Wine such-and-such version it has the
bug.

If you look at the Wine code we have quite a number of workarounds for
glibc bugs; not a single one of them checks the glibc version, they
all check for the actual bug. As a result we do the right thing
whether or not the bug is here, no matter what games distros play with
glibc versions and patches.

A version number is even more meaningless in the free software world,
since anybody can release modified versions. There simply isn't a
linear progression of versions that can be numbered. For instance, the
current Crossover release is based on Wine 20040716, this is what a
wine -v will report. Does it mean it contains a certain bug or not?
You have no way to tell. Some fixes have been merged, others have not.
Of course we could make Crossover report a different version, but then
it means your app will need to be updated everytime someone releases a
modified Wine.

So yes, it's a bit more work to do this right and test for bugs
instead of versions, but in the end everybody is better off: you
because your app is more robust and won't break as soon as someone
changes something in Wine, and us because we can fix the bug without
having to worry about breaking apps that assume the bug is here just
because they are running on Wine.

-- 
Alexandre Julliard
julliard at winehq.org