All of the changes are relatively easy to avoid until you get to CommitChanges, which was completely wrong to begin with. It was either wait and let more software become dependent on the incorrect function signature or break right away and get the unavoidable pains out of the way sooner than later. Either way, these ifdefs were going to happen. Breaking compatibility for one single function seemed really awful, so I tried my best to update the rest of the API to be more consistent across the board to justify the breakage a bit more (for example, properly making 2.8+ functions with the ‘8’ suffix). My hope is that this will keep us from having to break it again in the future.
Other than CommitChanges, the rest of the changes aren’t terribly interesting, except for F3DAudioInitialize8 which now returns an error code if the input parameters are invalid, which is accurate for 2.8 and higher.
-Ethan
On May 1, 2019, at 1:57 PM, Alexandre Julliard julliard@winehq.org wrote:
elee@codeweavers.com writes:
diff --git a/dlls/xaudio2_7/x3daudio.c b/dlls/xaudio2_7/x3daudio.c index ee3367e092..f08a425ca1 100644 --- a/dlls/xaudio2_7/x3daudio.c +++ b/dlls/xaudio2_7/x3daudio.c @@ -51,8 +51,12 @@ HRESULT CDECL X3DAudioInitialize(UINT32 chanmask, float speedofsound, X3DAUDIO_HANDLE handle) { TRACE("0x%x, %f, %p\n", chanmask, speedofsound, handle); +#if FAUDIO_ABI_VERSION >= 1
- return F3DAudioInitialize8(chanmask, speedofsound, handle);
+#else F3DAudioInitialize(chanmask, speedofsound, handle); return S_OK; +#endif
Was it really necessary to break binary compatibility so soon, and force us to maintain ugly ifdefs and multiple builds of the library? It looks like it wouldn't be hard to avoid it.
-- Alexandre Julliard julliard@winehq.org