On Thu, Mar 03, 2022 at 11:25:02AM +0100, Eric Pouech wrote:

Le 03/03/2022 à 10:58, Huw Davies a écrit :
     On Wed, Mar 02, 2022 at 09:03:33AM +0100, Eric Pouech wrote:
          Signed-off-by: Eric Pouech <eric.pouech@gmail.com>

          ---
           dlls/nsi/tests/Makefile.in |    1
           dlls/nsi/tests/nsi.c       |  202 ++++++++++++++++++++++--
          --------------------
           2 files changed, 101 insertions(+), 102 deletions(-)
     Let's hold off on this one until we[1] decide what to do
     about nsiproxy and potentially include/wine/nsi.h

     Huw.
     [1] The ball's in my court on this.
Hi Huw
yes makes sense
[1] and on Alexandre's too... it's not decided yet which strategy to adopt on
unixlib part

Right, but in this case, since we can change the header file,
one solution is to change the DWORDs to unsigned int / UINT32
and then the problem goes away and doesn't require Alexandre
to think about it ;-)

Huw.

yes but

1) we're looking for a solution that could be applied to all unixlib:s

2) in nsiproxy case, it boils down to changing all DWORD -> UINT into, yes, include/wine/nsi.h, but also in most of unixlib code, and also the protocol between the two

just for fun (picking up randomly <g>):

(from dlls/winealsa.drv/unixlib.h)

struct is_format_supported_params
{
    const char *alsa_name;
    EDataFlow flow;
    AUDCLNT_SHAREMODE share;
    const WAVEFORMATEX *fmt_in;
    WAVEFORMATEXTENSIBLE *fmt_out;
    HRESULT result;
};
most of those internal structures shoulb be converted

doable, but requires lots of changes

A+