[PATCH v3 1/5] winepulse.drv: Expose audio devices to the application.

[Gabriel Ivăncescu]

On 17/02/2022 17:23, Huw Davies wrote:
> On Thu, Feb 17, 2022 at 03:55:03PM +0200, Gabriel Ivăncescu wrote:
>> +struct get_endpoint_ids_params
>> +{
>> +    EDataFlow flow;
>> +    DWORD size;
>> +    WCHAR *device_strings;
>> +    HRESULT result;
>> +    unsigned int num;
>> +};
> 
> As already mentioned, it would be better to try to keep this
> as close as possible to the existing get_endpoint_ids_params
> in the coreaudio and alsa drivers.  i.e. pass a ptr to a
> (client allocated) struct endpoint array.  Sure, the endpoint
> struct will be slightly different, but once we have all of
> the drivers converted it'll make harmonising the interface
> rather easier.
> 
> Huw.
> 

Well I used a simple serialization approach where all the strings are 
concatenated. I have to admit, at least the coreaudio part is a bit 
confusing. The array holds pointers to the name (I would need two 
strings per endpoint), but those pointers are never allocated per se.

If I understand it correctly, they're made to point to data beyond the 
array by the unixlib? I guess it's slightly easier on the PE side but 
will be a lot more complicated on the unixlib side...

I also have some concerns about Wow64 unixlib, as I tried to avoid 
output pointers (or VARIANT or other types that are different) as much 
as possible, because it's different between 32-bit and 64-bit. IIRC Zeb 
said it's not safe to return pointers.

I know that these pointers just point to the existing array already, but 
they'd still be larger than what 32-bit PE side expects. Honestly I 
don't know how *input* pointers would be handled either, since they're 
used all over the place.

Is there some guidelines for writing unixlib params? I don't even know 
how the future wow64 is supposed to work, but I certainly don't want to 
add more weight to whoever ends up converting it (if it does).