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

[Ethan Lee]

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/FAudio.h#L662>

https://github.com/FNA-XNA/FAudio/blob/16d1dfeb92a4ae18eacb67c3dcf3f75de5135fc4/include/FAPOFX.h#L159 <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

> The idea of backwards compatibility is that a program should still be
> able to compile and run with any respective combination of old and new
> versions of the library. Renaming the old function breaks this. It also
> means that you want to load the new function at runtime rather than
> assuming it'll be present if compile-time support is there.
> 
> As for naming convention, a few suggestions are:
> 
> * FAudio_CommitChanges_a (e.g. libdwarf), or FAudio_CommitChangesA if
> you insist on title case
> * FAudio_CommitChangesBySet
> * FAudio_CommitChanges_v2
> * FAudio_CommitChanges_ex (or FAudio_CommitChangesEx, but this has the
> risk of colliding with a future function Microsoft adds)
> 
> Personally I'm a fan of a descriptive name like CommitChangesBySet(),
> but ultimately it's your choice.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20190502/6b3a5f06/attachment.html>