May 2008 - Wine-devel - list.winehq.org

New winetricks 20080402: new verbs dotnet20, win2k, flash, msls31; updated mono, liberation
by Dan Kegel 03 Jul '08

03 Jul '08

Big news: as of today or so, wine doesn't need any patches to install the .net 2.0 runtime or run trivial .net 2.0 apps, so I've added a dotnet20 verb. No more futzing with recipes to try out simple .net 2 apps, huzzah! There are lots of other little changes, too: 20080402 r21 Added dotnet20, removed one kludge from dotnet11, added win2k verb, plus shorthand for winver=foo r20 Updated liberation fonts. 20080328 r19 Added flash. 20080326 r18 Fix i18n problem reported by Ricardo Cabral 20080321 r17 Added msls31 (seems to be needed by e-Sword) 20080317 r16 update mono12 to 1.2.9 ... As always, winetricks is downloadable from http://kegel.com/wine/winetricks and change history is at http://code.google.com/p/winezeug Thanks to the folks who keep feeding me improvements and suggestions! - Dan

4 3

today's valgrind results online
by Dan Kegel 23 Jun '08

23 Jun '08

Online at http://kegel.com/wine/valgrind/20071002/ (I now include more info about memory leaks, but I still only report anything if there was an invalid memory reference.) The following tests were fixed in git yesterday, and no longer have any valgrind warnings: comctl32/rebar comctl32/status crypt32/chain crypt32/crl crypt32/msg cryptnet/cryptnet user32/msg wintrust/softpub Juan thinks nearly all of the remaining crypt32 errors can be suppressed (some are intentional). Here are the directories that still have warnings: advapi32 advpack cabinet comctl32 crypt32 d3d8 d3d9 d3dx8 dplayx dsound gdi32 gdiplus hlink kernel32 mlang msacm32 mscms mshtml msi msvcrt msxml3 netapi32 ntdll ole32 oleaut32 quartz riched20 riched32 rpcrt4 rsaenh setupapi shdocvw shell32 urlmon user32 usp10 wininet winmm wintrust - Dan

3 4

Re: ole32: Fix a failed call to DllGetClassObject while retrieving class object interface pointer.
by Robert Shearman 17 Jun '08

17 Jun '08

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

re: Bugs in Wine research
by Dan Kegel 14 Jun '08

14 Jun '08

tomecek wrote: > we are students from Department of computer science at Aalborg > university. During this semester we were working on project on static > analysis using the Coccinelle tool > (http://www.emn.fr/x-info/coccinelle/) and Flawfinder > (http://en.wikipedia.org/wiki/Flawfinder) We decided to search for > bugs in Wine source code. Great, thanks! We didn't have a wiki page about static analysis and Wine yet, so I created one, http://wiki.winehq.org/StaticAnalysis At least a couple of the memory leaks you found seem like they might be worth fixing. If you could put your full results up somewhere, and link to them from that wiki page, we'll take a look.

3 4

Re: Bugs in Wine research
by tomecek＠cs.aau.dk 14 Jun '08

14 Jun '08

> Dan Kegel wrote: >> James McKenzie <jjmckenzie51(a)sprintpcs.com> wrote: >>>>> we are students from Department of computer science at Aalborg >>>>> university. During this semester we were working on project on static >>>>> analysis using the Coccinelle tool >>>> http://wiki.winehq.org/StaticAnalysis >>> I was wondering if results from Wine 0.9.57 would continue to be valid? >>> Maybe the effort could shift to RC1? >> >> Sure, lots of the unused vars bugs in particular are probably >> already fixed. But the other issues have a pretty good >> chance of still being valid. >> > > Are there any volunteers to do this? > > My experience with Wine C code is fairly minimal, but it shouldn't be > too hard to look at one of their changes and see if it applies to > current git, and if it does just forward-port it. > > Thanks, > Scott Ritchie > > > > Hi, the complete results are available at http://www.cs.aau.dk/~dechouxb/results/complete/, the scripts used at http://www.cs.aau.dk/~dechouxb/cocci_scripts/done/. It is valid for Wine 0.9.57. Sorry for the delay, we were very busy. Unfortunately we cannot rerun the tests because we are leaving Aalborg University in 3 weeks. If you are interested I should be able to rerun these tests (with some improvements) at my home university during late August and September. Jaroslav Tomecek ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

3 2

Re: user32: Allow a NULL foreground window in the tests
by Dmitry Timoshkov 14 Jun '08

14 Jun '08

"James Hawkins" <jhawkins(a)codeweavers.com> wrote: > According to msdn, "The foreground window can be NULL in certain > circumstances, such as when a window is losing activation. " which is > exactly when these failures occur. > > Changelog: > * Allow a NULL foreground window in the tests. NULL foreground window is already allowed, you just need to fix the callers of check_wnd_state() to pass 0 for foreground. -- Dmitry.

2 11

Fixing crashes in Tests (OS version check)
by Alistair Leslie-Hughes 04 Jun '08

04 Jun '08

Hi, I've being investigating crashes that occur on Win98 when the tests run. I have fixed a couple already which where trivial. When I attempted to fix the snmpapi tests, I have found that i will end up removing alot of tests (~ 17). If I add a check for the windows version, I can skip the tests that will crash, also there is already tests with if(0) around them. What is the policy about checking the version of the OS before running certain tests? Best Regards Alistair Leslie-Hughes

8 11

Winetest grrr...
by Juan Lang 02 Jun '08

02 Jun '08

Since my tiny little menu patch didn't go in, I figured Alexandre wanted a test. So I tried to compile and run the existing one on Windows XP. It failed for me: lots of menu size tests failed. I checked the test.winehq.org data, and I don't see lots of failures on XP, so... I thought I'd run winetest.exe from Paul Millar's site, just in case the compilation environment had something to do with it. That locks up my laptop somewhere in the d3d/ddraw tests. I know some video drivers are so broken we don't want to run on them. I have an ATI Radeon Mobility 250. I thought this was a fairly common card. Is locking up the machine really acceptable here? How the ^$*@ am I supposed to produce a test when the existing ones fail/crash/burn for me? Grrr... --Juan

5 9

Re: [2/2] ddraw: Rename IDirectDraw functions (try 2)
by Christian Costa 01 Jun '08

01 Jun '08

Hi Michael, I think it would be better to fix function names in IDirectDraw7. Christian Michael Karcher a écrit : > The functions implementing IDirectDraw are called IDirectDrawImpl_Foo, > the ones implementing IDirectDraw7 are called alike. As they are > static functions in different files, the compiler has no problems > distinguishing them, but it confuses the reader of TRACE messages. > --- > dlls/ddraw/ddraw_thunks.c | 92 ++++++++++++++++++++++---------------------- > 1 files changed, 46 insertions(+), 46 deletions(-) > > ------------------------------------------------------------------------ > >

3 3

Re: ddraw: Don't release ddraw if a surface is still using it.
by Michael Karcher 31 May '08

31 May '08

Am Samstag, den 31.05.2008, 12:08 +0200 schrieb Jens Albretsen: The patch looks like it would work as advertised, but the following snippet in the testcase smells fishy: > +static unsigned long getRefcount(IUnknown *iface) > +{ > + IUnknown_AddRef(iface); > + return IUnknown_Release(iface); > +} [...] > + IDirectDraw_Release(lpDD); > + > + ref = getRefcount(lpDD); > + ok(ref == 0, "Got refcount %ld, expected 0\n", ref); > + > + IUnknown_Release(surface); The IDirectDraw_Release seems to be dropping the reference count of the DirectDraw object to zero. This is OK, of course, as you might well drop the last reference. But this might put the DirectDraw object into a state where AddRef crashes, as parts of the object might get destroyed when the reference count drops down to zero. On wine, there is obviously no problem, as wine keeps the DirectDraw object itself alive for longer. On Windows, it is not clear to me that the DirectDraw object is not destroyed at the IDirectDraw_Release, the only thing we know is, that Direct Draw still is working (perhaps implemented by a subobject of the DirectDraw object which keeps living). I suggest to alternatively write the second part as + ref = IDirectDraw_Release(lpDD); + ok(ref == 0, "Got refcount %ld, expected 0\n", ref); + + IUnknown_Release(surface); Regards, Michael Karcher

3 3