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).