Ethan Lee elee@codeweavers.com writes:
I could add F3DAudioInitialize8 separately, but it would mean everybody has to update to 19.05.0x for that def to go away, so the packaging situation doesn’t improve much there. I could possibly do something like FAPOFX_Create7 (well, it could be 5 since it’s xapofx1_5, but it could also be 7 since it’s the XAudio 2.7 spec…?) but that just makes FAudio’s API really confusing, since we would have some of the spec targeting 2.7 with 2.8+ as extension methods and other parts targeting 2.8 with 2.7- as extension methods. The real killer is CommitChanges, which is for sure stuck since it was an entirely bogus function and the old version should not exist at all. I could _maybe_ write in something like...
/* For build compatibility. This function was a stub to begin with, so do nothing. */ #define FAudio_CommitChanges(x)
… but that only fixes compile compatibility. The ABI increment would thankfully catch it since, presumably, this would only be an issue if someone updated FAudio but not Wine, so the old Wine would still look for libFAudio.so.0, but that’s just moving the issue to a different spot. Same applies to FAPOFX_CreateFX.
It does make life a bit more complicated, but that's the price to pay for backwards compatibility. You can't increment the ABI every time you find a bug.