[PATCH v4 3/3] mfplat: Add MFCreateFile stub.

Sven Baars sven.wine at gmail.com
Fri Nov 2 18:10:03 CDT 2018


On 02-11-18 23:48, Zebediah Figura wrote:
>
>
> On 11/2/18 5:34 PM, Sven Baars wrote:
>> On 02-11-18 21:55, Zebediah Figura wrote:
>>> On 11/2/18 3:27 PM, Sven Baars wrote:
>>>> Signed-off-by: Sven Baars <sven.wine at gmail.com>
>>>> ---
>>>> v3: Actually read the file and handle all flags.
>>>> v4: Rebased on the previous patch.
>>>>
>>>>    dlls/mfplat/main.c            |  78 ++++++++++++++++++++++-
>>>>    dlls/mfplat/mfplat.spec       |   2 +-
>>>>    dlls/mfplat/tests/Makefile.in |   2 +
>>>>    dlls/mfplat/tests/mfplat.c    | 114
>>>> ++++++++++++++++++++++++++++++++++
>>>>    dlls/mfplat/tests/resource.rc |  24 +++++++
>>>>    dlls/mfplat/tests/test.mp4    | Bin 0 -> 1554 bytes
>>>>    include/mfapi.h               |   2 +
>>>>    7 files changed, 220 insertions(+), 2 deletions(-)
>>>>    create mode 100644 dlls/mfplat/tests/resource.rc
>>>>    create mode 100644 dlls/mfplat/tests/test.mp4
>>>>
>>>> diff --git a/dlls/mfplat/main.c b/dlls/mfplat/main.c
>>>> index 7865a8935f..130597e8e7 100644
>>>> --- a/dlls/mfplat/main.c
>>>> +++ b/dlls/mfplat/main.c
>>>> @@ -850,6 +850,8 @@ typedef struct _mfbytestream
>>>>        mfattributes attributes;
>>>>        IMFByteStream IMFByteStream_iface;
>>>>        IMFAttributes IMFAttributes_iface;
>>>> +
>>>> +    HANDLE file;
>>>>    } mfbytestream;
>>>>      static inline mfbytestream *impl_from_IMFByteStream(IMFByteStream
>>>> *iface)
>>>
>>> This strikes me as a little janky. Arguably it could make sense, but
>>> I'd like to get a sense of how MFCreateMFByteStreamOnStream would fit
>>> in with this (plus any other APIs that create byte stream objects).
>>> Taking a less cursory look at the API of IMFByteStream, my intuition
>>> leads me to think it would make more sense just to create separate
>>> objects; there doesn't seem to be a lot of room for shared code.
>>>
>>>
>> Hi Zebediah,
>>
>> I thought the same, but a lot may be shared (at least the IMFAttributes
>> interface that I added), and for now, not doing this would mean I have
>> to duplicate another 500 lines of code. Maybe it would be better if the
>> person who actually implements MFCreateMFByteStreamOnStream duplicates
>> this code? I'm happy to copy-paste everything if you think that's
>> better.
>>
>> Sven
>>
>>
>
> Even if there's a lot of shared code, it may be better just to use
> common helper functions. Anyway, besides possibly
> IMFAsyncCallback/IMFAsyncResult handling, it looks like most of
> IMFByteStream is a thin veneer over specific I/O methods.
>
> Besides, with regard to IMFAttributes, as I think over it a bit
> more—since here the interface in question doesn't actually derive from
> IMFAttributes, I think we could simplify the code considerably by
> using existing mfattributes methods in the vtbl directly, with the
> exception of IUnknown methods.
>
Hmm, when I tried earlier this I got warnings of the form

 warning: initialization from incompatible pointer type
[-Wincompatible-pointer-types]

...or at least I thought so. But when I try it now, this does not
happen. I suppose I accidentally tried to use methods from the wrong
interface. Thanks for catching this.

I will make two separate interfaces. I'm scared of the even longer names
this gives though :)

Sven




More information about the wine-devel mailing list