[PATCH 1/2] xaudio2: Fix support for FAudio 19.06 and newer

[Ztirfe Elgnid]

On Thu, May 2, 2019 at 12:29 PM Ethan Lee <elee at codeweavers.com> wrote:
>
> Those names definitely look messy, but not quite messy enough… I’ll keep thinking of a good name, but for now (at least for demonstration purposes) I’ve gone ahead and used ‘BADABI’ to lay out how this is going to go down:
>
> https://github.com/FNA-XNA/FAudio/blob/16d1dfeb92a4ae18eacb67c3dcf3f75de5135fc4/include/FAudio.h#L662
>
> https://github.com/FNA-XNA/FAudio/blob/16d1dfeb92a4ae18eacb67c3dcf3f75de5135fc4/include/FAPOFX.h#L159
>
> So I’ve added the fixed functions and that’ll work for the rest of 2019 - this can safely be used for all of Wine 4.x and 5.0, and the function used by 4.3 through 4.7 (or 8 or 9, depending on when you want to move to the corrected function) can still build against the old function. It won’t work (and absolutely positively never will and never could have worked, just to emphasize one more time), but it’s at least there for compilation purposes. By the time 5.0 is out the proper function will be available and the 5.x series can use the new function, while 5.0.x maintenance releases can continue to use the BADABI function safely without having to worry about it getting lost before 6.0 is out. Once 6.0 is out, both the stable/unstable branches of Wine will be on the right function and the old functions won’t apply at that point.
>
> If someone really _really_ needs to do a multi-year bisect, they can pass --disable-faudio and save themselves the build time. If the XAudio2 subsystem is what’s being examined, they’re most likely looking at FAudio and not Wine.
>
> -Ethan
>

Labeling the newer function as BADAPI strikes me as even worse. I'd
expect something labeled BADAPI to be proscribed rather than
prescribed.

I think this approach is a matter of looking at compatibility the
wrong way. I think it doesn't make sense to treat the erroneous
function as so wrong that it needs to be completely removed from the
public library, nor I do see why it's absolutely necessary that the
correct implementation of CommitChanges actually have the exact name
CommitChanges(). API compatibility isn't something you keep as a
temporary measure until you think that everyone has updated your
library; it's something you keep for as long as possible, until the
combined weight of design mistakes and errors makes it more worthwhile
just to scrap the whole interface and recreate it. Incrementing the
major version shouldn't be something you do every year just because
time passes, but rather something you do only when you have to.
(That's not to say you shouldn't call it 20.x and 21.x etc. after the
year, but the library major version should remain the same.) An
incorrect parameter signature doesn't make that necessary, inasmuch as
FAudio isn't an ABI-compatible drop-in replacement for XAudio but
rather a tool to recreate its logic and to allow easy porting. Anyone
who's interested in porting can rely on documentation to tell them
that CommitChanges() is deprecated in favor of CommitChangesBySet(),
if the missing parameter isn't already enough of a clue.