Versioning and internal APIs

Paul Davis paul at linuxaudiosystems.com
Sun Jun 13 15:31:41 CDT 2004


>Mike Hearn <mh at 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



More information about the wine-devel mailing list