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

Re: ole32: Fix a failed call to DllGetClassObject while retrieving class object interface pointer.
by Robert Shearman June 17, 2008

June 17, 2008

Huang, Zhangrong wrote: > See dlls/ole32/compobj.c, > > static HRESULT apartment_getclassobject(struct apartment *apt, LPCWSTR dllpath, > BOOL apartment_threaded, > REFCLSID rclsid, REFIID riid, > void **ppv) > { > ................... > if (SUCCEEDED(hr)) > { > .................. > TRACE("calling DllGetClassObject %p\n", > apartment_loaded_dll->dll->DllGetClassObject); > /* OK: get the ClassObject */ > hr = apartment_loaded_dll->dll->DllGetClassObject(rclsid, riid, ppv); > ^^^^ > if (hr != S_OK) > ERR("DllGetClassObject returned error 0x%08x\n", hr); > } > .............. > } > > Reference to http://msdn2.microsoft.com/en-us/library/ms680760.aspx, > > riid > > [in] Reference to the identifier of the interface that the caller > is to use to communicate with the class object. Usually, this is > IID_IClassFactory (defined in the OLE headers as the interface > identifier for IClassFactory). > This doesn't mean anything other than CoCreateInstance is usually used instead of CoGetClassObject (and CoCreateInstance always passes in IID_IClassFactory for the IID). > We can't pass riid to DllGetClassObject directly sometimes, causes some dlls' > DllGetClassObject (like native adsldp.dll) can only return reference-counted > pointer to class factory via IID_IClassFactory, for retrieving the > pointer to the > class object interface requested in riid, we must try another way. > Thank you for your patch, but this behaviour seems a little strange and needs a little more investigation before I am happy that it is correct. What parameters are being passed in to CoGetClassObject to cause the call to fail for you? -- Rob Shearman

5 12

Removinig CVS/GIT version from bugzilla
by Vitaliy Margolen May 25, 2008

May 25, 2008

I'm copying my response here to continue the conversation. Please don't remove cvs/git version. What should be done is: 1. Leave old bugs alone or modify them case-by-case 2. All bugs with "cvs/git" version from now on can be filed on the development branch between releases only. 3. After the next release, if the bug is still present, modify version to that release. Of course no modifying of old bugs. Vitaliy.

4 5

Re: dinput: Convert keyboard buffer from internal data format to user data format
by Vitaliy Margolen May 14, 2008

May 14, 2008

Sergey Khodych wrote: > > > Any particular reason for this? Do you have a program that sets different data format? The reason I ask - copying 256 bytes is much faster then iterating over the whole data format and copying one byte at a time. Vitaliy.

2 5

wineserver socket file and DOS attacks
by Steven Elliott May 5, 2008

May 5, 2008

I have some concerns about the location of the socket file that wineserver uses. Since by default the current location is in /tmp my concern is that anyone can stop anyone else from using wine just by creating a directory named /tmp/.wine-500. As far as I know the only risk is denial of service in nature since wine seems to be smart enough to make sure the /tmp/.wine-500 is owned by the user invoking the wine application: > notepad wineserver: /tmp/.wine-500 is not owned by you Previously the socket file was under ~/.wine. I found this which briefly documents the change here: http://www.winehq.org/site/docs/winedev-guide/x2584 under section "7.3.2. The Wine server" it says: "In earlier versions of Wine the master socket mentioned above was actually created in the configuration directory; either your home directory's /wine subdirectory or wherever the WINEPREFIX environment variable points. Since that might not be possible the socket is actually created within the /tmp directory with a name that reflects the configuration directory." /tmp/.wine-<user Id> is hard coded in libs/wine/config.c, so that aspect of the socket file location is not configurable. Anyway, have alternatives such as the following been considered?: 1) Create the socket file in ~/.wine (or wherever WINEPREFIX points) like wine used to if the user's home directory exists and is writable. Use /tmp/.wine-<user Id> as a fallback. 2) Append some additional integer to /tmp/.wine-<user Id> that is incremented if that directory already exists and is owned by someone else. For example, if /tmp/.wine-500 already exists for user 500 but is owned by someone else then both wineserver and the wine application would append "-1" and then keep incrementing: /tmp/.wine-500 /tmp/.wine-500-1 /tmp/.wine-500-2 until they each found a directory owned by the current user (or until they are able to create one). Hopefully they would pick the same directory. I need to think more about how robust this would be. -- ----------------------------------------------------------------------- | Steven Elliott | selliott4(a)austin.rr.com | -----------------------------------------------------------------------

6 10

Re: widl: Add a framework for automated testing of IDL files that should succeed or fail to be parsed.
by Dan Hipschman May 2, 2008

May 2, 2008

On Mon, Apr 28, 2008 at 08:37:26PM +0100, Robert Shearman wrote: > > This should aid in testing more-obscure parts of the parser that aren't > necessarily valid when using RPC (and hence don't make sense being put > in dlls/rpcrt4/tests/server.idl). Obviously this is a good idea. I tried doing something similar a while ago, but it didn't get accepted on the first try and I never asked why, so I'll ask why now. See here: http://winehq.org/pipermail/wine-patches/2006-September/030438.html It has some benefits over the approach you're proposing so it's worth bringing up. One is that it can run the tests against MIDL, so we know the tests themselves are correct (ok, MIDL has been known to do things differently than the spec, but we may want to copy MIDL's behaviour anyway, and in any case it's easier to automatically validate the tests on MIDL than to do so by hand or by inspection). Another is versatility in what it can test. Since the tests are shell scripts, not only can it test the success/failure of a parse, but it can check that all the correct files were created, and it can perform further tests on the output (e.g., if we have an import in the IDL file, we can grep the output to make sure a #include was generated for the import). It already supports "todo"s, and the test scripts look similar to the usual Wine tests written in C. On the other hand your method has some advantages over mine. You already provide a "make test" framework, and including the expected result of the compilation in the IDL file is cleaner. Alexandre may very well disagree with what I see as valid points (like testing on MIDL), but these are my suggestions anyway. Hope they're useful.

3 3

Re: hhctrl.ocx: Fix for memory release problem in ReleaseWebBrowser (fixes bug #12767)
by Tefnet Developers May 1, 2008

May 1, 2008

Dnia 24-04-2008, czw o godzinie 12:48 +0200, Tomasz Jezierski - Tefnet pisze: > For more information check bug report. > Hi.. what's the status of this patch? I haven't found any comments on wine-devel about it.

2 1

RFC: detecting wine drivers in the audio tests
by Robert Reif May 1, 2008

May 1, 2008

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);

8 8

Re: Dan Kegel : winecfg: Restrict dpi slider to sane values.
by Lei Zhang May 1, 2008

May 1, 2008

On Wed, Apr 23, 2008 at 5:59 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Module: wine > Branch: master > Commit: faaccca59be08be547ec4e1948b6306eff3808a2 > URL: http://source.winehq.org/git/wine.git/?a=commit;h=faaccca59be08be547ec4e194… > > Author: Dan Kegel <dank(a)kegel.com> > Date: Tue Apr 22 17:56:36 2008 -0700 > > winecfg: Restrict dpi slider to sane values. > > --- > > programs/winecfg/x11drvdlg.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/programs/winecfg/x11drvdlg.c b/programs/winecfg/x11drvdlg.c > index bfa6ec5..c0ec058 100644 > --- a/programs/winecfg/x11drvdlg.c > +++ b/programs/winecfg/x11drvdlg.c > @@ -35,9 +35,9 @@ > > WINE_DEFAULT_DEBUG_CHANNEL(winecfg); > > -#define RES_MAXLEN 5 /* the maximum number of characters in a screen dimension. 5 digits should be plenty, what kind of crazy person runs their screen >10,000 pixels across? */ > +#define RES_MAXLEN 5 /* max number of digits in a screen dimension. 5 digits should be plenty */ > #define MINDPI 96 > -#define MAXDPI 480 > +#define MAXDPI 144 /* making this too high surprises and hurts users */ > #define DEFDPI 96 > > #define IDT_DPIEDIT 0x1234 > > > > Dan, this basically reverted commit 0110512904d9c646abef416819a057c06d3f2c97, which bumped MAXDPI from 160 to 480 because some users specifically requested the ability for higher DPI settings. I think we need to decide what we want and stop the tug-o-war.

12 23

SOC 2008 Projects Announced
by Austin English April 30, 2008

April 30, 2008

For those of you who haven't heard yet, the Google SOC Projects were announced today: http://google-opensource.blogspot.com/2008/04/announcing-accepted-student-p… 5 Wine projects have been accepted: http://code.google.com/soc/2008/wine/about.html <http://code.google.com/soc/2008/wine/about.html#>Improving Wine MSXML implementation <http://code.google.com/soc/2008/wine/appinfo.html?csaid=A546A592C8ACDDD5> by Piotr Caban, mentored by James Hawkins Print Dialog <http://code.google.com/soc/2008/wine/appinfo.html?csaid=7CC6A70D0D7A1FDE> by Gal Topper, mentored by Detlef Riekenberg <http://code.google.com/soc/2008/wine/about.html#> Implementing proper Control Panel support for Wine <http://code.google.com/soc/2008/wine/appinfo.html?csaid=8B4254855F2BD854> by Owen Rudge, mentored by Juan Lang <http://code.google.com/soc/2008/wine/about.html#> DirectPlay implementation <http://code.google.com/soc/2008/wine/appinfo.html?csaid=984D708DA20ACA94> by Ismael Barros Barros, mentored by Kai Blin Wine - Richedit with Tables <http://code.google.com/soc/2008/wine/appinfo.html?csaid=7D1930729985958C> by Dylan Andrew Harper Smith, mentored by Huw D M Davies <http://code.google.com/soc/2008/wine/about.html#> Improve Gdi+ Implemenation <http://code.google.com/soc/2008/wine/appinfo.html?csaid=7BE88570BACC2046> by Adam Joel Petaccia, mentored by Lei Zhang Thanks to all those who applied and congrats to those who were accepted! Now get hacking ;-).

6 5

Re: richedit: add tests for EM_FINDTEXT in 1.0 emulation, make them pass under Wine
by Alex Villacís Lasso April 30, 2008

April 30, 2008

Alex Villacís Lasso escribió: > EM_FINDTEXT and EM_FINDTEXTEX have different rules for interpreting > ranges for 1.0 and 2.0 modes: > > In 1.0 emulation cpMin > cpMax is invalid and always fails. > In 1.0 emulation, search is always done between cpMin and cpMax, even > backwards search. > In 1.0 emulation, cpMax == -1 assumes FR_DOWN, even if not set. > > This goes a long way towards resolving richedit search problems in bug > #709. > > Changelog: > * Add tests for EM_FINDTEXT in 1.0 emulation, make them pass under Wine > My bad, it is bug #4144 that is being addressed with this patch. -- perl -e '$x=2.4;print sprintf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'

1 0