[PATCH] x3daudio: fix lib exports

[Rafał Mużyło]

x3daudio: fix lib exports

1. in case of x3daudio1_{0,1,2}, two exported functions are for some
reason decorated
2. tests show these functions should be stdcall, not cdecl

Signed-off-by: Rafał Mużyło

[Nikolay Sivov]

Hi, Rafał.

Thanks for the patch. I think there is at least two issues with it - on
Windows only 32-bit modules use decorated names, 64-bit ones do not. We
need to do the same. Another issue is that you change to stdcall for all
versions, and according to recent SDK at least version 1.7 is using cdecl.
I suspect you should switch to stdcall only for 0,1,2 versions (if testing
confirms that).

[Rafał Mużyło]

On Fri, Sep 27, 2019 at 09:54:44AM +0300, Nikolay Sivov wrote:
> Hi, Rafał.
>
> Thanks for the patch. I think there is at least two issues with it - on
> Windows only 32-bit modules use decorated names, 64-bit ones do not. We
> need to do the same. Another issue is that you change to stdcall for all
> versions, and according to recent SDK at least version 1.7 is using cdecl.
> I suspect you should switch to stdcall only for 0,1,2 versions (if testing
> confirms that).

OK.
First is might be a significant problem - I'm not sure if spec file
syntax allows for diferent values for x86 and x64. Where is it
documented anyway ?

As for the second, are you sure ? I haven't located those SDKs, but I
did google 1.1 and 1.7 versions of that header and *both* were stdcals.

[Nikolay Sivov]

On Fri, Sep 27, 2019 at 10:48 AM Rafał Mużyło  wrote:
> On Fri, Sep 27, 2019 at 09:54:44AM +0300, Nikolay Sivov wrote:
> > Hi, Rafał.
> >
> > Thanks for the patch. I think there is at least two issues with it - on
> > Windows only 32-bit modules use decorated names, 64-bit ones do not. We
> > need to do the same. Another issue is that you change to stdcall for all
> > versions, and according to recent SDK at least version 1.7 is using
>
> cdecl.
> > I suspect you should switch to stdcall only for 0,1,2 versions (if
>
> testing
> > confirms that).
>
> OK.
> First is might be a significant problem - I'm not sure if spec file
> syntax allows for diferent values for x86 and x64. Where is it
> documented anyway ?

It allows that, msvcp* is a good example where names are arch-dependent. I
don't know if it's documented.
> As for the second, are you sure ? I haven't located those SDKs, but I
> did google 1.1 and 1.7 versions of that header and *both* were stdcals.

Headers I have from 10.0.17763.0 have those as STDAPIVCALLTYPE, which is
cdecl.

[Rafał Mużyło]

On Fri, Sep 27, 2019 at 01:41:51PM +0300, Nikolay Sivov wrote:
> On Fri, Sep 27, 2019 at 10:48 AM Rafał Mużyło  wrote:
> > On Fri, Sep 27, 2019 at 09:54:44AM +0300, Nikolay Sivov wrote:
> > > Hi, Rafał.
> >
> > As for the second, are you sure ? I haven't located those SDKs, but I
> > did google 1.1 and 1.7 versions of that header and *both* were stdcals.
>
> Headers I have from 10.0.17763.0 have those as STDAPIVCALLTYPE, which is
> cdecl.

..aw, shucks, I've misread the header, you're correct: 1.1 is stdcall,
1.7 is cdecl. Yet that might be an even bigger problem than the spec
files. Not wrt. x3daudio.c, cause there the version defines could be
used (not sure if x3daudio already has those, but xaudio does, so it
would only be a matter of adapting), but (AFAICT) the public header is a
different matter...

...or is it ?