October 2013 - Wine-Devel - list.winehq.org

Re: Video Mixing Renderer 7

by Aric Stewart

Hi, On 10/16/13 3:22 AM, Michael Stefaniuc wrote: > Hello, > > On 10/15/2013 09:52 PM, Michael Müller wrote: >> I am wondering what would be the best way to handle programs which rely >> on the Video Mixing Renderer 7 (quartz.dll) as it's supposed to be >> available on XP and later, but Wine contains only an implementation of >> version 9. Being one of the guy who did the work on vmr9 and generally had a pretty good working knowledge of quartz I am willing to bet that the actual work to be done is fairly small. But there will be a lot of COM wrapping to be written. Not to hard but busy work. Looking briefly at the vmr7 interfaces, they seems basically the same as the vmr9 ones, but with different parameters. I bet you could even get away with renaming vmr9.c to vmr.c and implementing 7/9 both in the file pretty easily. -aric

Oct. 16, 2013

Re: notepad: Use BOOL type where appropriate (try 2)

by Alexandre Julliard

Frédéric Delanoy <frederic.delanoy(a)gmail.com> writes: > try 2: Avoid changing SendMessage calls Dialog procedures return booleans too. -- Alexandre Julliard julliard(a)winehq.org

Oct. 16, 2013

Re: notepad: Use BOOL type where appropriate

by Alexandre Julliard

Frédéric Delanoy <frederic.delanoy(a)gmail.com> writes: > @@ -298,7 +298,7 @@ static SAVE_STATUS DoSaveFile(LPCWSTR szFileName, ENCODING enc) > CloseHandle(hFile); > HeapFree(GetProcessHeap(), 0, pBytes); > > - SendMessageW(Globals.hEdit, EM_SETMODIFY, FALSE, 0); > + SendMessageW(Globals.hEdit, EM_SETMODIFY, 0, 0); Many messages use booleans, even if the actual type is a WPARAM. Please don't change them. -- Alexandre Julliard julliard(a)winehq.org

Oct. 16, 2013

Re: dispex/tests: Compile with -D__WINESRC__

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > >> + PeekMessageA(&msg, NULL, WM_USER, WM_USER, PM_NOREMOVE); > > IMHO it would be much better to use W version of APIs while doing this > cleanup. Same applies to all other your patches that prepare switching > compilation to using -D__WINESRC__. Considering that the A implementation is usually based on the W one, calling the A function enables to test both. When there are differences we would of course want to test both explicitly, but otherwise it's a good idea to have a healthy mix. We definitely don't want a rule that tests always have to call W functions. -- Alexandre Julliard julliard(a)winehq.org

Oct. 16, 2013

Re: Video Mixing Renderer 7

by Michael Stefaniuc

Hello, On 10/15/2013 09:52 PM, Michael Müller wrote: > I am wondering what would be the best way to handle programs which rely > on the Video Mixing Renderer 7 (quartz.dll) as it's supposed to be > available on XP and later, but Wine contains only an implementation of > version 9. > > The program I am speaking of is Silverlight which uses the VMR 7 > Interface to create a filter graph and then queries for the > IAMCertifiedOutputProtection interface. I am currently using a hack fix > to get around this by returning a VMR9 instance when a VMR7 is requested > and implementing the missing subinterfaces (which are only part of > VMR7). This solution is clearly not perfect and I am searching for a > better way to get around this issue. > > The most similar way to Windows would be to completely rewrite the > current implementation of the VMR9 as VMR7 using DirectDraw, which would > take a lot of time and most probably end up in having a lot of duplicate > code. I am wondering whether using d3d9 for VMR7 would also be an > acceptable solution. We could move all the d3d9 related stuff to a > separate file so that VMR7.c and VMR9.c only offer the version specific > interfaces and use the same code internally. This shouldn't be a big > problem since the differences between the VMR7 and VMR9 interfaces are > often only very small. Though it would not completely fit the behavior > of windows. if the differences are small then there are different options to reuse the common parts: - Use the same object (struct) for both VMR7 and 9. Just set the correct vtbl pointers during object creation. - Use a separate struct for the common parts and include it in both objects. Kind off like it is done at the moment with the BaseRenderer and the other Base* stuff. - If it is feasible to have VMR7 implemented in d3d9 you could even make VMR7 a small wrapper around VMR9. Aka COM aggregate the VMR9 object and just implement the parts you can't forward. > I am open for other ideas on how to solve the problem, but as > Silverlight does not even use the VMR7 object for playing the video but > only to check for the graphic driver certificate I don't think it would > justify to rewrite everything using Direct Draw if there are no other > programs needing this interface. I have an old kids education game that uses both ddraw and quartz that doesn't works. I'll check if it uses VMR7. If yes it is worthwhile to do it right as it is a whole class of such multimedia apps from the early days. bye michael

Oct. 16, 2013

Re: [10/10] gdi32/tests: Enable gdi32 tests compilation with __WINESRC__ defined.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2808 Your paranoid android. === wxppro (32 bit) === No test summary line found === wvista (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7pro64 (32 bit) === No test summary line found === w864 (32 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found === w7pro64 (64 bit) === No test summary line found === w864 (64 bit) === No test summary line found

Oct. 16, 2013

Re: [06/10] gdi32/tests: Fix font tests compilation with __WINESRC__ defined.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2804 Your paranoid android. === wxppro (32 bit font) === font.c:1545: Test failed: GetGlyphIndicesW should have returned a 20ac not 0080 === wvista (32 bit font) === font.c:1545: Test failed: GetGlyphIndicesW should have returned a 20ac not 0080 No test summary line found Failure running script in VM: network read timed out === w2008s64 (32 bit font) === font.c:1545: Test failed: GetGlyphIndicesW should have returned a 20ac not 0080 Timeout Failure running script in VM: network read timed out === w7pro64 (32 bit font) === font.c:1545: Test failed: GetGlyphIndicesW should have returned a 20ac not 0080 === w864 (32 bit font) === font.c:1545: Test failed: GetGlyphIndicesW should have returned a 20ac not 0080 === w2008s64 (64 bit font) === font.c:1545: Test failed: GetGlyphIndicesW should have returned a 20ac not 0080 === w7pro64 (64 bit font) === font.c:1545: Test failed: GetGlyphIndicesW should have returned a 20ac not 0080 === w864 (64 bit font) === font.c:1545: Test failed: GetGlyphIndicesW should have returned a 20ac not 0080

Oct. 16, 2013

Re: wined3d: Initialize map_desc in wined3d_surface_map

by Lasse Rasinen

Stefan Dösinger <stefandoesinger(a)gmail.com> writes: > Am 2013-10-15 20:34, schrieb Marvin: >> === w864 (32 bit device) === device.c:5409: Test failed: pBits not >> cleared on double lock. device.c:5410: Test failed: Pitch not >> cleared on double lock. device: unhandled exception c0000005 at >> 742814C8 > I'm surprised that the testbot executes those tests. Did you run those > tests on a real Windows machine? If you want I can test them for you > on a variety of windows versions and GPUs here. I can have access to a Windows machine earliest on Friday, and even then it won't be Win8. So yes please. -- Lasse Rasinen lrasinen(a)iki.fi

Oct. 16, 2013

Re: mmdevapi/tests: Compile with -D__WINESRC__.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2797 Your paranoid android. === w7pro64 (32 bit render) === render.c:662: Test failed: Wait(event) after Stop gave 102

Oct. 16, 2013

Re: winmm/tests: Use the explicit mciSendStringA() form.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2796 Your paranoid android. === w864 (32 bit midi) === midi.c:518: Test failed: midiOutPrepare old size rc=MMSYSERR_INVALPARAM midi.c:519: Test failed: MHDR.dwFlags when prepared 0 midi.c:523: Test failed: midiStreamOut old size rc=MIDIERR_UNPREPARED midi.c:547: Test failed: MHDR.dwFlags 0 no ISSTRM when out of queue midi.c:553: Test failed: MHDR.dwFlags 0 not DONE when out of queue midi.c:554: Test failed: Wait failed: 0102 -559038737 midi.c:554: Test failed: Expect message 3ca from midiStream callback midi.c:555: Test failed: Wait failed: 0102 -559038737 midi.c:555: Test failed: Expect message 3c9 from midiStreamOut midi.c:558: Test failed: play left MIDIHDR.dwOffset at 1234567890 midi.c:561: Test failed: midiOutUnprepare rc=MMSYSERR_INVALPARAM midi.c:563: Test failed: midiOutUnprepare #2 rc=MMSYSERR_INVALPARAM midi.c:566: Test failed: MHDR.dwFlags when done 0 midi.c:580: Test failed: stream set tempo 500000 midi.c:588: Test failed: midiOutPrepare used flags 8 rc=MMSYSERR_INVALPARAM midi.c:590: Test failed: midiOutUnprepare used flags 8 rc=MMSYSERR_INVALPARAM midi.c:518: Test failed: midiOutPrepare old size rc=MMSYSERR_INVALPARAM midi.c:519: Test failed: MHDR.dwFlags when prepared 0 midi.c:523: Test failed: midiStreamOut old size rc=MIDIERR_UNPREPARED midi.c:547: Test failed: MHDR.dwFlags 0 no ISSTRM when out of queue midi.c:553: Test failed: MHDR.dwFlags 0 not DONE when out of queue midi.c:554: Test failed: Wait failed: 0102 -559038737 midi.c:554: Test failed: Expect message 3ca from midiStream callback midi.c:555: Test failed: Wait failed: 0102 -559038737 midi.c:555: Test failed: Expect message 3c9 from midiStreamOut midi.c:558: Test failed: play left MIDIHDR.dwOffset at 1234567890 midi.c:561: Test failed: midiOutUnprepare rc=MMSYSERR_INVALPARAM midi.c:563: Test failed: midiOutUnprepare #2 rc=MMSYSERR_INVALPARAM midi.c:566: Test failed: MHDR.dwFlags when done 0 midi.c:580: Test failed: stream set tempo 500000 midi.c:588: Test failed: midiOutPrepare used flags 8 rc=MMSYSERR_INVALPARAM midi.c:590: Test failed: midiOutUnprepare used flags 8 rc=MMSYSERR_INVALPARAM === wxppro (32 bit mci) === mci.c:1209: Test failed: mci status "C:\Documents and Settings\winetest\My Documents\tempfile.wav" mode returned MCIERR_INVALID_DEVICE_NAME mci.c:1274: Test failed: mci re-auto-open status mode returned MCIERR_INVALID_DEVICE_NAME mci.c:1290: Test failed: mci auto-open pause returned MCIERR_INVALID_DEVICE_NAME === wvista (32 bit mci) === mci.c:986: Test failed: 397ms is not in the expected 400-600ms range mci.c:993: Test failed: 397ms is not even in the expected 400-1000ms range === w7pro64 (64 bit mci) === mci.c:1120: Test failed: got 0001 instead of MCI_NOTIFY_xyz 0004 from command play (aborted by close)

Oct. 16, 2013