Mike Hearn mh@codeweavers.com writes:
Paul Davis of Ardour has raised a good point: currently despite the fact that the symbols in libwine are versioned, we change them at will and don't change the symbol version, for instance in the patch that made environ passed through to wine_init from main to hack around the general suckage of MacOS X.
Unless this versioning system is meant to be dormant until Wine 1.0 is out (and we should definitely document this if so), perhaps we should be changing the symbol versions?
No, the interfaces are not considered frozen, they will be frozen in 1.0; until then it is possible that things will still need to change. For the specific wine_init case, I suppose we could back out the change if it causes trouble.
well, the problem is that until the mono guys and us audio freaks came along, wine was a "self-contained" project. wine was the only thing that used the wine APIs. but now the situation has changed, even if only by the smallest amount. you've got at least 2 projects using wine API's outside of wine.
in our case, the specific problem is the addition of the "environment" ptr arg in wine_init(). there appears to be no way to check on whether this needed, hence:
Also, there is no easy way to find out the version of Wine you got from dlopen at runtime. Should we export a wine_version symbol?
No, I don't think we should encourage this kind of version checks.
how can anyone know which version of wine_init() to use, then?
--p