April 2008 - Wine-Devel - list.winehq.org

Re: winmm/tests: waveOutGetDevCaps called with invalid size

by Peter Åstrand

On Tue, 29 Apr 2008, Robert Reif wrote: > First of all, requesting 4 bytes is not invalid but a perfectly > reasonable thing to do. It is just reading the manufactures id and > product id. However this behavior is not documented in MSDN so at best > it's just unspecified behavior. The reason most hardware drivers get > this right is because Microsoft does check this behavior in their > hardware compatibility test so manufactures can get certification that > their hardware and drivers are working properly. Now the two drivers ... Ok, you have convinced me. > The tests in wine are valid but incomplete because they don't check for > the possible buffer overrun that could occur if the driver just ignores > the requested size. A black list should be added for Terminal Server > and your product because they behave differently than most hardware > drivers. This would ensure that regressions don't slip into wine when > drivers are added or changed and that wine behaves like Microsoft > expects a hardware driver to behave. Adding a black list for WTS sounds good to me; much better than just accepting MMSYSERR_INVALPARAM. GetSystemMetrics(SM_REMOTESESSION) can be used to detect WTS. Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.se Wallenbergs gata 4 583 30 Linköping Phone: +46-13-21 46 00

April 30, 2008

Re: [Resend] user32: Post the WM_KEY{DOWN|UP} message whenWM_IME_KEY{DOWN|UP} message is generated by IME.

by Dmitry Timoshkov

"ByeongSik Jeon" <bsjeon(a)hanmail.net> wrote: > I have added the test code. Your test doesn't confirm that the message is posted and not sent. You need to use SendMessage and examine the resulting messages, then run the message loop and see what messages got posted. -- Dmitry.

April 30, 2008

Re: wined3d: Fix for buggy programs using ortho matrix with no z range

by Jens Albretsen

On Tuesday 29 April 2008 22:25:48 Stefan Dösinger wrote: > Am Dienstag, 29. April 2008 19:04:55 schrieb Jens Albretsen: > > Changelog: > > Fix for old games that sets a Ortho matrix with z range from 0-0 or in > > other word with no range, which does'nt make any sense but they do it > > anyway. > > I think a test case for this would be good. A quick one is Lego Island, just forget to put in the disc a there is black screen, with this patch is shows a message to put the cdrom in the drive. Is it something like this? create (1,1) rendertarget clear rendertarget with black setup ortho with no range draw something with white check rendertarget for any pixel drawn, if black test fails or what? -------------------------------------------------------

April 30, 2008

Re: wined3d: Fix for buggy programs using ortho matrix with no z range

by Jens Albretsen

On Tuesday 29 April 2008 22:25:48 Stefan Dösinger wrote: > Am Dienstag, 29. April 2008 19:04:55 schrieb Jens Albretsen: > > Changelog: > > Fix for old games that sets a Ortho matrix with z range from 0-0 or in > > other word with no range, which does'nt make any sense but they do it > > anyway. > > I think a test case for this would be good. A quick one is Lego Island, just forget to put in the disc a there is black screen, with this patch is shows a message to put the cdrom in the drive. Is it something like this? create (1,1) rendertarget clear rendertarget with black setup ortho with no range draw something with white check rendertarget for any pixel drawn, if black test fails or what?

April 30, 2008

Re: RFC: detecting wine drivers in the audio tests

by Maarten Lankhorst

Hello Robert, 2008/4/29 Robert Reif <reif(a)earthlink.net>: > The returned result of some audio functions on windows may be inconsistent > because a driver may actually supply the returned value. > > This presents a problem for the wine regression tests because a buggy > driver may return an unexpected result which causes the test to fail. One > way around this is to accept known failures as OK but that reduces the > usefulness of the test for wine because it may allow wine bugs to slip in. > I'm proposing the we determine if we are running on wine by defining a wine > manufactures id and checking for that id in the test. If a wine driver is > found, don't accept a failure as OK. The returned result should be well > defined and any failure is unacceptable. However, if the driver is not a > wine driver and there are known buggy windows drivers that return specific > errors, we can check for that and not fail the test. This should be easier > than maintaining a database of known broken drivers and black listing them. > > I am concerned that requiring 100% wine regression test success on windows > is not practical when there are broken windows drivers out there. Accepting > the failures as success is not good for wine because it may allow buggy wine > drivers to also pass. I think we should hold wine audio drivers to higher > standards than the typical audio card manufacture. > > I am suppling a minimal patch to the alsa driver and a single wave test to > illustrate this concept. I hope this allows valid tests to remain in spite > of buggy windows drivers. I don't know, the general idea is that whatever windows lets you do is fine for wine, so I'm not 100% sure that testing for this is a good idea, because it means in border cases windows programs can't rely on those to return a correct or incorrect value either. By the way you also used a C++ style comment, wine doesn't allow that. Cheers, Maarten

April 30, 2008

Re: RFC: detecting wine drivers in the audio tests

by Vitaliy Margolen

Robert Reif wrote: > The returned result of some audio functions on windows may be > inconsistent because a driver may actually supply the returned value. > > This presents a problem for the wine regression tests because a buggy > driver may return an unexpected result which causes the test to fail. > One way around this is to accept known failures as OK but that reduces > the usefulness of the test for wine because it may allow wine bugs to > slip in. I'm proposing the we determine if we are running on wine by > defining a wine manufactures id and checking for that id in the test. > If a wine driver is found, don't accept a failure as OK. The returned > result should be well defined and any failure is unacceptable. However, > if the driver is not a wine driver and there are known buggy windows > drivers that return specific errors, we can check for that and not fail > the test. This should be easier than maintaining a database of known > broken drivers and black listing them. > > I am concerned that requiring 100% wine regression test success on > windows is not practical when there are broken windows drivers out > there. Accepting the failures as success is not good for wine because > it may allow buggy wine drivers to also pass. I think we should hold > wine audio drivers to higher standards than the typical audio card > manufacture. > I think this was discussed before in regards to d3d. Except not in the sense of bugs but differences between how d3d behaves for Wine and for some applications. AKA workarounds for applications. In some way that can be considered bugs. I'm not sure how much of that is going on with sound drivers. And there are might not be an easy way to find out. I think in this particular case where it's clear what it is a bug (most other drivers do the right thing and in agreement with MSDN) then it might be time for "todo_windows". Vitaliy. There agreement was that drivers have specific workarounds for specific programs.

April 30, 2008

RFC: detecting wine drivers in the audio tests

by Robert Reif

The returned result of some audio functions on windows may be inconsistent because a driver may actually supply the returned value. This presents a problem for the wine regression tests because a buggy driver may return an unexpected result which causes the test to fail. One way around this is to accept known failures as OK but that reduces the usefulness of the test for wine because it may allow wine bugs to slip in. I'm proposing the we determine if we are running on wine by defining a wine manufactures id and checking for that id in the test. If a wine driver is found, don't accept a failure as OK. The returned result should be well defined and any failure is unacceptable. However, if the driver is not a wine driver and there are known buggy windows drivers that return specific errors, we can check for that and not fail the test. This should be easier than maintaining a database of known broken drivers and black listing them. I am concerned that requiring 100% wine regression test success on windows is not practical when there are broken windows drivers out there. Accepting the failures as success is not good for wine because it may allow buggy wine drivers to also pass. I think we should hold wine audio drivers to higher standards than the typical audio card manufacture. I am suppling a minimal patch to the alsa driver and a single wave test to illustrate this concept. I hope this allows valid tests to remain in spite of buggy windows drivers. diff --git a/dlls/winealsa.drv/alsa.h b/dlls/winealsa.drv/alsa.h index 4cd2cf5..8433c12 100644 --- a/dlls/winealsa.drv/alsa.h +++ b/dlls/winealsa.drv/alsa.h @@ -51,6 +51,8 @@ #include "ks.h" #include "ksmedia.h" #include "ksguid.h" +#define MM_WINE_ALSA_VERSION 0x0100 // driver version + /* state diagram for waveOut writing: * * +---------+-------------+---------------+---------------------------------+ diff --git a/dlls/winealsa.drv/midi.c b/dlls/winealsa.drv/midi.c index 3e791d5..8ac0363 100644 --- a/dlls/winealsa.drv/midi.c +++ b/dlls/winealsa.drv/midi.c @@ -1134,10 +1134,10 @@ static void ALSA_AddMidiPort(snd_seq_cli * Does not seem to be a problem, because in mmsystem.h only * Microsoft's ID is listed. */ - MidiOutDev[MODM_NumDevs].caps.wMid = 0x00FF; - MidiOutDev[MODM_NumDevs].caps.wPid = 0x0001; /* FIXME Product ID */ - /* Product Version. We simply say "1" */ - MidiOutDev[MODM_NumDevs].caps.vDriverVersion = 0x001; + MidiOutDev[MODM_NumDevs].caps.wMid = MM_WINE; + MidiOutDev[MODM_NumDevs].caps.wPid = MM_WINE_ALSA; /* Product ID */ + /* Product Version. */ + MidiOutDev[MODM_NumDevs].caps.vDriverVersion = MM_WINE_ALSA_VERSION; MidiOutDev[MODM_NumDevs].caps.wChannelMask = 0xFFFF; /* FIXME Do we have this information? @@ -1190,10 +1190,10 @@ static void ALSA_AddMidiPort(snd_seq_cli * Does not seem to be a problem, because in mmsystem.h only * Microsoft's ID is listed. */ - MidiInDev[MIDM_NumDevs].caps.wMid = 0x00FF; - MidiInDev[MIDM_NumDevs].caps.wPid = 0x0001; /* FIXME Product ID */ - /* Product Version. We simply say "1" */ - MidiInDev[MIDM_NumDevs].caps.vDriverVersion = 0x001; + MidiInDev[MIDM_NumDevs].caps.wMid = MM_WINE; + MidiInDev[MIDM_NumDevs].caps.wPid = MM_WINE_ALSA; /* Product ID */ + /* Product Version. */ + MidiInDev[MIDM_NumDevs].caps.vDriverVersion = MM_WINE_ALSA_VERSION; /* FIXME Do we have this information? * Assuming the soundcards can handle diff --git a/dlls/winealsa.drv/mixer.c b/dlls/winealsa.drv/mixer.c index cc38f8f..68d09c6 100644 --- a/dlls/winealsa.drv/mixer.c +++ b/dlls/winealsa.drv/mixer.c @@ -54,10 +54,6 @@ WINE_DEFAULT_DEBUG_CHANNEL(mixer); #ifdef HAVE_ALSA -#define WINE_MIXER_MANUF_ID 0xAA -#define WINE_MIXER_PRODUCT_ID 0x55 -#define WINE_MIXER_VERSION 0x0100 - /* Generic notes: * In windows it seems to be required for all controls to have a volume switch * In alsa that's optional @@ -797,9 +793,9 @@ static DWORD MIX_GetDevCaps(UINT wDevID, memset(&capsW, 0, sizeof(MIXERCAPS2W)); - capsW.wMid = WINE_MIXER_MANUF_ID; - capsW.wPid = WINE_MIXER_PRODUCT_ID; - capsW.vDriverVersion = WINE_MIXER_VERSION; + capsW.wMid = MM_WINE; + capsW.wPid = MM_WINE_ALSA; + capsW.vDriverVersion = MM_WINE_ALSA_VERSION; lstrcpynW(capsW.szPname, mmixer->mixername, sizeof(capsW.szPname)/sizeof(WCHAR)); capsW.cDestinations = mmixer->dests; @@ -1421,9 +1417,9 @@ static DWORD MIX_GetLineInfo(UINT wDevID else Ml->Target.dwType = MIXERLINE_TARGETTYPE_WAVEOUT; Ml->Target.dwDeviceID = 0xFFFFFFFF; - Ml->Target.wMid = WINE_MIXER_MANUF_ID; - Ml->Target.wPid = WINE_MIXER_PRODUCT_ID; - Ml->Target.vDriverVersion = WINE_MIXER_VERSION; + Ml->Target.wMid = MM_WINE; + Ml->Target.wPid = MM_WINE_ALSA; + Ml->Target.vDriverVersion = MM_WINE_ALSA_VERSION; lstrcpynW(Ml->Target.szPname, mmixer->mixername, sizeof(Ml->Target.szPname)/sizeof(WCHAR)); return MMSYSERR_NOERROR; } diff --git a/dlls/winealsa.drv/waveinit.c b/dlls/winealsa.drv/waveinit.c index 1516aa6..8663d47 100644 --- a/dlls/winealsa.drv/waveinit.c +++ b/dlls/winealsa.drv/waveinit.c @@ -494,9 +494,9 @@ static int ALSA_AddPlaybackDevice(snd_ct wwo.outcaps.szPname, sizeof(wwo.outcaps.szPname)/sizeof(WCHAR)); wwo.outcaps.szPname[sizeof(wwo.outcaps.szPname)/sizeof(WCHAR) - 1] = '\0'; - wwo.outcaps.wMid = MM_CREATIVE; - wwo.outcaps.wPid = MM_CREATIVE_SBP16_WAVEOUT; - wwo.outcaps.vDriverVersion = 0x0100; + wwo.outcaps.wMid = MM_WINE; + wwo.outcaps.wPid = MM_WINA_ALSA; + wwo.outcaps.vDriverVersion = MM_WINE_ALSA_VERSION; rc = ALSA_ComputeCaps(ctl, pcm, &wwo.outcaps.wChannels, &wwo.ds_caps.dwFlags, &wwo.outcaps.dwFormats, &wwo.outcaps.dwSupport); @@ -534,9 +534,9 @@ static int ALSA_AddCaptureDevice(snd_ctl wwi.incaps.szPname, sizeof(wwi.incaps.szPname) / sizeof(WCHAR)); wwi.incaps.szPname[sizeof(wwi.incaps.szPname)/sizeof(WCHAR) - 1] = '\0'; - wwi.incaps.wMid = MM_CREATIVE; - wwi.incaps.wPid = MM_CREATIVE_SBP16_WAVEOUT; - wwi.incaps.vDriverVersion = 0x0100; + wwi.incaps.wMid = MM_WINE; + wwi.incaps.wPid = MM_WINE_ALSA; + wwi.incaps.vDriverVersion = MM_WINE_ALSA_VERSION; rc = ALSA_ComputeCaps(ctl, pcm, &wwi.incaps.wChannels, &wwi.ds_caps.dwFlags, &wwi.incaps.dwFormats, &wwi.dwSupport); diff --git a/dlls/winmm/tests/wave.c b/dlls/winmm/tests/wave.c index 2844be4..d902a4a 100644 --- a/dlls/winmm/tests/wave.c +++ b/dlls/winmm/tests/wave.c @@ -812,6 +812,7 @@ static void wave_out_test_device(int dev SYSTEM_INFO sSysInfo; DWORD flOldProtect; BOOL res; + BOOL wine = FALSE; GetSystemInfo(&sSysInfo); dwPageSize = sSysInfo.dwPageSize; @@ -821,9 +822,13 @@ static void wave_out_test_device(int dev rc==MMSYSERR_NODRIVER, "waveOutGetDevCapsA(%s): failed to get capabilities: rc=%s\n", dev_name(device),wave_out_error(rc)); - if (rc==MMSYSERR_BADDEVICEID || rc==MMSYSERR_NODRIVER) + if (rc!=MMSYSERR_NOERROR) return; + /* check for wine manufactures id */ + if (capsA.wMid == MM_WINE) + wine = TRUE; + rc=waveOutGetDevCapsW(device,&capsW,sizeof(capsW)); ok(rc==MMSYSERR_NOERROR || rc==MMSYSERR_NOTSUPPORTED, "waveOutGetDevCapsW(%s): MMSYSERR_NOERROR or MMSYSERR_NOTSUPPORTED " @@ -854,14 +859,23 @@ static void wave_out_test_device(int dev } rc=waveOutGetDevCapsA(device,&capsA,4); - ok(rc==MMSYSERR_NOERROR || rc==MMSYSERR_INVALPARAM, - "waveOutGetDevCapsA(%s): MMSYSERR_NOERROR or MMSYSERR_INVALPARAM " - "expected, got %s\n", dev_name(device),wave_out_error(rc)); + if (wine) // we really care that wine drivers do the right thing + ok(rc==MMSYSERR_NOERROR, "waveOutGetDevCapsA(%s): MMSYSERR_NOERROR " + "expected, got %s\n", dev_name(device),wave_out_error(rc)); + else // broken Windows drivers may fail so accept known failures + ok(rc==MMSYSERR_NOERROR || rc==MMSYSERR_INVALPARAM, + "waveOutGetDevCapsA(%s): MMSYSERR_NOERROR or MMSYSERR_INVALPARAM " + "expected, got %s\n", dev_name(device),wave_out_error(rc)); rc=waveOutGetDevCapsW(device,&capsW,4); - ok(rc==MMSYSERR_NOERROR || rc==MMSYSERR_NOTSUPPORTED, - "waveOutGetDevCapsW(%s): MMSYSERR_NOERROR or MMSYSERR_NOTSUPPORTED " - "expected, got %s\n",dev_name(device),wave_out_error(rc)); + if (wine) // we really care that wine drivers do the right thing + ok(rc==MMSYSERR_NOERROR, "waveOutGetDevCapsW(%s): MMSYSERR_NOERROR " + "expected, got %s\n",dev_name(device),wave_out_error(rc)); + else // broken Windows drivers may fail so accept known failures + ok(rc==MMSYSERR_NOERROR || rc== MMSYSERR_INVALPARAM || + rc==MMSYSERR_NOTSUPPORTED, "waveOutGetDevCapsW(%s): " + "MMSYSERR_NOERROR or MMSYSERR_INVALPARAM or MMSYSERR_NOTSUPPORTED " + "expected, got %s\n",dev_name(device),wave_out_error(rc)); nameA=NULL; rc=waveOutMessage((HWAVEOUT)device, DRV_QUERYDEVICEINTERFACESIZE, diff --git a/include/mmsystem.h b/include/mmsystem.h index bb13cfd..e232856 100644 --- a/include/mmsystem.h +++ b/include/mmsystem.h @@ -243,6 +243,7 @@ typedef void (CALLBACK *LPDRVCALLBACK)(H #define MM_MICROSOFT 1 /* Microsoft Corp. */ #define MM_CREATIVE 2 /* Creative labs */ +#define MM_WINE 255 /* Wine */ #define MM_MIDI_MAPPER 1 /* MIDI Mapper */ #define MM_WAVE_MAPPER 2 /* Wave Mapper */ @@ -262,6 +263,14 @@ #define MM_PC_JOYSTICK 12 #define MM_CREATIVE_SBP16_WAVEOUT 104 +#define MM_WINE_ALSA 1 +#define MM_WINE_AUDIOIO 2 +#define MM_WINE_COREAUDIO 3 +#define MM_WINE_ESD 4 +#define MM_WINE_JACK 5 +#define MM_WINE_NAS 6 +#define MM_WINE_OSS 7 + UINT WINAPI mmsystemGetVersion(void); BOOL WINAPI sndPlaySoundA(LPCSTR lpszSound, UINT fuSound); BOOL WINAPI sndPlaySoundW(LPCWSTR lpszSound, UINT fuSound);

April 30, 2008

Re: [PATCH] usp10: Use passed hdc instead of cached one for ScriptTextOut with test to check

by Guy Albertelli

On Tue, 2008-04-29 at 11:12 +0200, Hans Leidekker wrote: > On Tuesday 29 April 2008 06:15:23 Guy Albertelli wrote: > > > Application does most of the Script... calls under one hdc then deletes it > > prior to calling the ScriptTextOut with the original hdc. > > Out of curiosity, which app is that? What are the symptoms? I tested > your patch on some of the apps I know that use usp10 (TomTom HOME, Firefox, > PAF5) and didn't see any obvious regressions. The application is HP's Service Center. It used to be Peregrine's Service Center until HP bought them. The symptom was that all the text boxes showing the text of problems and changes were blank until I found this. Apparently part of the application is Eclispe based (SWT_Window0) and those were the windows where the Scriptxxxx was being used to draw. > > > - if (!ExtTextOutW(get_cache_hdc(psc), x, y, fuOptions, lprc, pwGlyphs, cGlyphs, NULL)) > > + if (!ExtTextOutW(hdc, x, y, fuOptions, lprc, pwGlyphs, cGlyphs, NULL)) > > You should also get rid of the calls to get_script_cache and > un/select_cached_font; they are redundant now. This was not intuitively obvious to me. I will construct an additional patch to clean that up. It should apply on top of this one. > > -Hans

April 30, 2008

Abusing valgrind to find reference leaks

by Maarten Lankhorst

Hi all, I've managed to abuse valgrind to show backtraces of all places where an AddRef and Release is called when there is a memory, this is superior to wading through an endless pile of logs without even guarantee it will work. I thought I should share it for the following reasons: 1. Valgrind is an awesome tool 2. Reference leaks are usually impossible or very hard to find by using debug logs All I'm doing is leaking memory until the destructor is called, which gives quite useful results, I had to add a exit(1) after the leak occured because the samples get destroyed regardless when the interface controlling those samples is released. The log was created with: valgrind --trace-children=yes --leak-check=full --show-reachable=yes --leak-resolution=high -- wine quartz_test.exe.so filtergraph 2>&1 | tee valgrind.log And then I removed all the memory leaks and warnings not related to AddRef and Release. Ideally I could get it to automatically sort the outputted data based on the order of calling, but I'm not 100% sure how to do that yet. I could do 1,000,000 + GetTickCount(), but the results are usable now regardless. This was useful for me to get the backtraces of all _AddRef's and _Release's *ONLY* for the leaking interfaces, which saves a lot of time determining whether the specific interface is leaking and not, and when it starts leaking, and then determining who calls and where it is called, so I hope it is useful for you too! Cheers, Maarten.

April 29, 2008

Re: wined3d: Fix for buggy programs using ortho matrix with no z range

by Stefan Dösinger

Am Dienstag, 29. April 2008 19:04:55 schrieb Jens Albretsen: > Changelog: > Fix for old games that sets a Ortho matrix with z range from 0-0 or in > other word with no range, which does'nt make any sense but they do it > anyway. I think a test case for this would be good.

April 29, 2008