Re: [PATCH] wmvcore/tests: Access IWMDRMReader(|2|3) interfaces on Windows.
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?
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(a)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?
s/wmdrmstub/wmstubdrm/ On Tue, Oct 24, 2017 at 2:07 AM, Jefferson Carpenter < jeffersoncarpenter2(a)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(a)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?
Jefferson Carpenter <jeffersoncarpenter2(a)gmail.com> writes:
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.
How did you figure this out? -- Alexandre Julliard julliard(a)winehq.org
I knew it was possible to get DRM interfaces because I have an application that queries for an IWMDRMReader (I forget 1, 2, or 3) over and over and over until S_OK is returned. To begin finding out why the return value is sometimes S_OK and sometimes E_NOINTERFACE, I compiled an exe that runs WMCreateReader and queries for the IWMDRMReader2 interface, and then stepped through the assembly. Turns out, the value at that memory location is checked inside of QueryInterface. Also, Windows Server 2003 ships with an earlier version of wmvcore than my PC does, I'll bet that's why the test failed for IWMDRMReader3. On Tue, Oct 24, 2017 at 3:32 AM, Alexandre Julliard <julliard(a)winehq.org> wrote:
Jefferson Carpenter <jeffersoncarpenter2(a)gmail.com> writes:
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.
How did you figure this out?
-- Alexandre Julliard julliard(a)winehq.org
Jefferson Carpenter <jeffersoncarpenter2(a)gmail.com> writes:
I knew it was possible to get DRM interfaces because I have an application that queries for an IWMDRMReader (I forget 1, 2, or 3) over and over and over until S_OK is returned. To begin finding out why the return value is sometimes S_OK and sometimes E_NOINTERFACE, I compiled an exe that runs WMCreateReader and queries for the IWMDRMReader2 interface, and then stepped through the assembly. Turns out, the value at that memory location is checked inside of QueryInterface.
That's not an acceptable way of figuring things out. If you have an application that uses this, you can look at what the app is doing, and try to reproduce that behavior in a test case; but the Microsoft DLLs have to be treated as black boxes. You can call public APIs and see what they return, but you can't look inside the box. In particular, disassembling the code is strictly forbidden. I'm afraid this means I can no longer accept any patches of yours implementing this functionality. -- Alexandre Julliard julliard(a)winehq.org
;...( On Oct 24, 2017 4:41 AM, "Alexandre Julliard" <julliard(a)winehq.org> wrote: Jefferson Carpenter <jeffersoncarpenter2(a)gmail.com> writes:
I knew it was possible to get DRM interfaces because I have an application that queries for an IWMDRMReader (I forget 1, 2, or 3) over and over and over until S_OK is returned. To begin finding out why the return value is sometimes S_OK and sometimes E_NOINTERFACE, I compiled an exe that runs WMCreateReader and queries for the IWMDRMReader2 interface, and then stepped through the assembly. Turns out, the value at that memory location is checked inside of QueryInterface.
That's not an acceptable way of figuring things out. If you have an application that uses this, you can look at what the app is doing, and try to reproduce that behavior in a test case; but the Microsoft DLLs have to be treated as black boxes. You can call public APIs and see what they return, but you can't look inside the box. In particular, disassembling the code is strictly forbidden. I'm afraid this means I can no longer accept any patches of yours implementing this functionality. -- Alexandre Julliard julliard(a)winehq.org
I'm afraid this means I can no longer accept any patches of yours implementing this functionality.
How much is off-limits to me now? On Tue, Oct 24, 2017 at 5:10 AM, Jefferson Carpenter < jeffersoncarpenter2(a)gmail.com> wrote:
;...(
On Oct 24, 2017 4:41 AM, "Alexandre Julliard" <julliard(a)winehq.org> wrote:
Jefferson Carpenter <jeffersoncarpenter2(a)gmail.com> writes:
I knew it was possible to get DRM interfaces because I have an application that queries for an IWMDRMReader (I forget 1, 2, or 3) over and over and over until S_OK is returned. To begin finding out why the return value is sometimes S_OK and sometimes E_NOINTERFACE, I compiled an exe that runs WMCreateReader and queries for the IWMDRMReader2 interface, and then stepped through the assembly. Turns out, the value at that memory location is checked inside of QueryInterface.
That's not an acceptable way of figuring things out.
If you have an application that uses this, you can look at what the app is doing, and try to reproduce that behavior in a test case; but the Microsoft DLLs have to be treated as black boxes. You can call public APIs and see what they return, but you can't look inside the box. In particular, disassembling the code is strictly forbidden. I'm afraid this means I can no longer accept any patches of yours implementing this functionality.
-- Alexandre Julliard julliard(a)winehq.org
Jefferson Carpenter <jeffersoncarpenter2(a)gmail.com> writes:
I'm afraid this means I can no longer accept any patches of yours implementing this functionality.
How much is off-limits to me now?
To be safe you should probably stay away from wmvcore and from anything related to the DRM support. -- Alexandre Julliard julliard(a)winehq.org
Also, does this mean I can't have your job when you retire? On Thu, Oct 26, 2017 at 2:15 PM, Alexandre Julliard <julliard(a)winehq.org> wrote:
Jefferson Carpenter <jeffersoncarpenter2(a)gmail.com> writes:
I'm afraid this means I can no longer accept any patches of yours implementing this functionality.
How much is off-limits to me now?
To be safe you should probably stay away from wmvcore and from anything related to the DRM support.
-- Alexandre Julliard julliard(a)winehq.org
Jefferson Carpenter <jeffersoncarpenter2(a)gmail.com> writes:
Also, does this mean I can't have your job when you retire?
Be careful what you wish for ;-) -- Alexandre Julliard julliard(a)winehq.org
participants (3)
-
Alexandre Julliard -
Jefferson Carpenter -
Nikolay Sivov