cdr cedar@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.