Versioning and internal APIs

[Mike Hearn]

Hi Alexandre,

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?

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?

Finally, apparently Paul has had to duplicate a fair amount of Wine code
inside his libfst (library for loading Cubase VST plugins) because the
relevant functions are declared static in Wine. Paul, could you post a
list of exactly what you use?

It might be worth extending and starting to freeze some of these
semi-internal interfaces.

thanks -mike

[Paul Davis]

> Finally, apparently Paul has had to duplicate a fair amount of Wine code
> inside his libfst (library for loading Cubase VST plugins) because the
> relevant functions are declared static in Wine. Paul, could you post a
> list of exactly what you use?

actually, a "fair amount" is an overstatement. its not much, but what
there is rather critical:

* definition of SIGNAL_STACK_SIZE
* definition of MEM_SYSTEM (in winnt.h, but hard to make visible)
* alloc_teb()
* free_teb()
* server.h
* thread.h

--p

[Alexandre Julliard]

Mike Hearn  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.
> 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.

[Mike Hearn]

On Sun, 13 Jun 2004 09:22:37 -0700, Alexandre Julliard wrote:
> 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.

The problem then is that the WINE_1.0 symbol means the 1.0 frozen
interfaces *and* any that were used before then. What is the point of
symbol versioning if the linker can't meet the guarantees it's supposed to
provide?

[Alexandre Julliard]

Mike Hearn  writes:
> The problem then is that the WINE_1.0 symbol means the 1.0 frozen
> interfaces *and* any that were used before then. What is the point of
> symbol versioning if the linker can't meet the guarantees it's supposed to
> provide?

Symbol versioning is enabled right now to make sure it works, and to
make the transition easier since most symbols won't change before 1.0.
Backwards compatibility will only be guaranteed after 1.0 is released.

[Paul Davis]

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