[PATCH] wmvcore/tests: Access IWMDRMReader(|2|3) interfaces on Windows.

Jefferson Carpenter jeffersoncarpenter2 at gmail.com
Tue Oct 24 02:08:36 CDT 2017


s/wmdrmstub/wmstubdrm/

On Tue, Oct 24, 2017 at 2:07 AM, Jefferson Carpenter <
jeffersoncarpenter2 at gmail.com> wrote:

> That code would almost certainly crash if run against Wine's wmvcore.dll.
> It is just to have a piece of physical evidence that there IS a way to
> access the DRM interfaces.  It would of course be removed, once the
> mechanism by which DRM interfaces are exposed is understood, and Wine
> implements the corresponding functionality.
>
> Applications normally access this by being linked with a lib called
> wmdrmstub.lib access to which is restricted by Microsoft, instead of with
> the wmvcore.lib that anybody can get.  I do not know what the differences
> are between those libs, e.g. how WMCreateReader comes to produce a reader
> that exposes a IWMDRMReader interface when you link with one but not the
> other.
>
> On Tue, Oct 24, 2017 at 1:52 AM, Nikolay Sivov <bunglehead at gmail.com>
> wrote:
>
>> On 24.10.2017 8:36, Jefferson Carpenter wrote:
>> > +#if defined(__MINGW32__) || defined(__MINGW64__)
>> > +#ifdef _WIN64
>> > +    flagPtrAddr = (unsigned long long)(reader) - 24;
>> > +    flagMem[556] = 1;
>> > +#elif _WIN32
>> > +    flagPtrAddr = (unsigned int)(reader) - 12;
>> > +    flagMem[288] = 1;
>> > +#endif
>> > +    *(unsigned char **)flagPtrAddr = flagMem;
>> > +#endif
>>
>> Why would you need something like that to match potential Wine's
>> implementation? How do applications access this thing?
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20171024/3ed104d0/attachment.html>


More information about the wine-devel mailing list