[PATCH (try 3) 2/2] dpvoice: Turn GetCompressionTypes into a semi-stub.

[Alex Henrie]

 2015-01-16 9:59 GMT-07:00 Stefan Dösinger <stefandoesinger at gmail.com>:
> Am 2015-01-16 um 08:44 schrieb Alex Henrie:
>> Star Trek Armada II needs GetCompressionTypes to return at least
>> one value, see https://bugs.winehq.org/show_bug.cgi?id=29238
> Is the game happy if you return DV_OK and set *pdwNumElements = 0?

No. *pdwNumElements has to be at least 1 or the game crashes.

>> MS-PCM is guaranteed to be present on Windows XP, and it's already
>> implemented in Wine, so advertising this codec shouldn't cause any
>> trouble.
> Even though we have the codec we probably don't have the dpvoice
> infrastructure to hook up a dpvoice client to the codec, right? That's
> not necessarily a reason to reject the semi-stub though.

Right. Very little of dpvoice is implemented right now, but this
semi-stub gives us a starting point for building the rest.

>> +extern HRESULT DPVOICE_GetCompressionTypes(DVCOMPRESSIONINFO
>> *pData, DWORD *pdwDataSize, DWORD *pdwNumElements, DWORD dwFlags)
>> DECLSPEC_HIDDEN;
> Please avoid hungarian notation names (dwThisIsAdWord, *pThisIsAPointer).

I copied and pasted the variable names from
dpvclient_GetCompressionTypes and dpvserver_GetCompressionTypes, so I
am merely matching the variable conventions already present in this
DLL.

>> +        string_loc = (LPWSTR)((char*)pData + sizeof(pcm_type)); +
>>  memcpy(pData, &pcm_type, sizeof(pcm_type)); + memcpy(string_loc,
>> pcm_name, sizeof(pcm_name)); + pData->lpszName = string_loc;
> I think there should be a nicer way to do this. I didn't test this with
> the compiler, but I guess you can do something like this:
>
> struct
> {
> DVCOMPRESSIONINFO info;
> const WCHAR name[];
> }
> codec =
> {
> {80, {0x8de12fd4,0x7cb3,0x48ce
> {0xa7,0xe8,0x9c,0x47,0xa2,0x2e,0x8a,0xc5}}, &codec.name,
> NULL, 0, 64000}},
> {'M','S','-','P','C','M',' ','6','4',' ','k','b','i','t','/','s',0};
> };

There are a couple of problems with this suggestion:

1. C only allows one flexible array per struct. We would have to
switch to fixed, manually hardcoded array sizes in order to add more
codecs to the list. Also, ANSI C does not allow flexible arrays in
structs at all, so this syntax could be a problem for some compilers.

2. In Windows, the codec names are localized and stored in resource
files in other DLLs. For PCM, the codec name is obtained by combining
a resource in msacm32.dll with a resource in dpvacm.dll. These
resources are translated into German and possibly other languages. A
complete implementation of GetCompressionTypes would not have static
variables for codec names at all because it would use LoadStringW to
get the localized codec names, and it would have to keep track of the
string length of each codec name in the current language. Thus, using
a struct would be out of the question. See
https://github.com/wine-compholio/wine-staging/issues/251#issuecomment-69478988
for more information.

So long story short, yes a struct might be a little easier as long as
we only have one codec, but sooner or later we'd have to get rid of
the struct and switch to something else.

-Alex