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

(no subject)
by Hongbo Ni 18 Aug '08

18 Aug '08

Sorry my previous email got wrong format. "Dan Kegel" wrote: > This guide seems rather well written: > http://ldn.linuxfoundation.org/how-participate-linux-community > Wine could probably use something similar. YES, the Wine development speed can be greatly improved if similar development process is adepted, specially the 'Chain of Commands'. I am sure that Alexandre has done a great job as the Wine maintainer, but he may be stressed out when he comes back from his holiday as there are pile of patches awaiting him to review and commit. Hongbo Ni _________________________________________________________________ Win a Nokia E51 with mobile Hotmail SMS alerts http://www.livelife.ninemsn.com.au/compIntro.aspx?compId=4589

1 0

.NET program crashes involving stubbed functions
by Adam Petaccia 17 Aug '08

17 Aug '08

Its customary to make a function return NotImplemented in Gdiplus, if its just a dummy function that does nothing and returns. But .NET seems to check for this and throw an exception, crashing the program anyway. See bug http://bugs.winehq.org/show_bug.cgi?id=12951 for details, but originally a program crashed because GdipNewPrivateFontCollection was just a stub. After the function was created, it still crashes because it returns "NotImplemented", rather than "Ok". IIRC, we return "NotImplemented" for some debugging reason, but if the goal of Wine is to run Windows applications, should we just go ahead and return "Ok" so that .NET apps don't freak out? Of course in a perfect world, we wouldn't have to fake a return code, but until that time comes do people have opinions one way or another?

3 3

Patchwatcher status
by Dan Kegel 17 Aug '08

17 Aug '08

Patchwatcher is online and giving reasonably good feedback on the patch stream. The bug that caused every patch to be marked 'failed tests' is fixed, and the blacklist is expanded enough that false regressions seem to be rare. There are still bugs: 1. the dashboard shows no status column for http://kegel.com/wine/patchwatcher/results/32.txt even though http://kegel.com/wine/patchwatcher/results/32.log exists and shows that there was some strange problem in applying the patch. 2. The most recent patch shows up as 'queued' but the link to the patch doesn't work. Results are at http://kegel.com/wine/patchwatcher/results/ and source code is at http://winezeug.googlecode.com Next steps: - add timeout to handle hanging tests (every day or two I have to kill some test or other). There's no portable way to do this from wine/test.h that works in Win9x, so I'll probably set WINETEST_WRAPPER to run the tests via a wrapper that implements the timeout. - distribute across multiple machines by splitting into master (which watches the patch stream) and slaves (which execute tests). I will probably use http and ftp for this so the slaves can be remote. - support multiple architectures (anybody want to run the slaves on MacOSX for me?) - improve the web page to have error counts and perhaps separate links to the build and test logs - merge the chroot support (though this will need porting to run on MacOSX) - add valgrind as the next step after running tests - improve the web page generator to show current status (e.g. show the results from "make test" before starting valgrind)

4 5

Re: kernel32: Tiny improvement to the GetVolumePathNameW stub (try 3)
by Michael Karcher 17 Aug '08

17 Aug '08

Am Samstag, den 16.08.2008, 23:56 +0000 schrieb Louis. Lenders: > Hi Michael, thanks again for the comment, i moved the check for the > stringlength to the front, and removed the wrong check for the > bufferlength (oops). Looks quite good now, but somehow the "return TRUE;" line got lost. Regards, Michael Karcher

1 0

re: kernel32: Tiny improvement to the GetVolumePathNameW stub (try 2)
by Dan Kegel 16 Aug '08

16 Aug '08

"Louis. Lenders" <xerox_xerox2000(a)yahoo.co.uk> wrote: > i'm sure that if this function ever gets implemented all these checks and tests are needed, but as i said, a bit of google for fixme:GetVolumePath shows the common way (the very few) apps call this function is with filename="c:\blabla\bla", so for now , in my opinion, i don't think it's worth the effort. A simple test would be very easy and would help convince Alexandre to apply your patch. IMHO you should go drink a little bit of the koolaid at http://en.wikipedia.org/wiki/Test-driven_development Check it out; It even *sounds* like Wine development philosophy: ... > By focusing on writing only the code necessary to pass tests, designs can be cleaner and clearer than is often achieved by other methods[3]. In Test-Driven Development by Example Kent Beck also suggests the principle "Fake it, till you make it". - Dan

1 0

Re: kernel32: Tiny improvement to the GetVolumePathNameW stub (try 2)
by Michael Karcher 16 Aug '08

16 Aug '08

Am Samstag, den 16.08.2008, 19:09 +0000 schrieb Louis. Lenders: > Hi Michael, thanks for your comments. I've added some simple sanity > checks from your first suggestions. It looks much better now, but you still access filename[1] before you even know that filename is not an empty string. In that case, filename[1] is past the end of the array, and you must not access it. Your check for strlenW comes too late. The minimal fix would be to put the strlenW call before the character comparisons, but it would be even smarter to either a) check that filename[0] is not 0, and check the next characters in order. So if any of these characters, short circuit evaluation prevents access of later characters, or b) just implement the special case for the empty string and catch this case before you access filename[1] and filename[2]. Please think about what "sizeof(volumepathname)" will return. The condition "sizeof(volumepathname) > 3" is *always* true. You should check buflen at that point. > As for the other suggestions, i'm sure that if this function ever gets > implemented all these checks and tests are needed, but as i said, a > bit of google for fixme:GetVolumePath shows the common way (the very > few) apps call this function is with filename="c:\blabla\bla", so for > now , in my opinion, i don't think it's worth the effort. As long as there are no junctions in wine, your implementation is correct for paths it can handle. So I would suggest to make the FIXME a TRACE and add a FIXME("Can't handle path %s\n",debugstr_w(filename)); below the case you handle. While googling for GetVolumeFileNameW, I stumbled across http://www.winehq.org/pipermail/wine-patches/2006-June/027228.html This patch obviously has not been applied. That is not really surprising, as it contains an extra hunk on an unrelated include file at the end, and also ignores buflen, but it does contain the correct logic for testing whether filename is a fully qualified local part, it contains the GetVolumeFileNameA implementation that forwards to GetVolumeFileNameW and contains at least one basic test. I would suggest to polish that patch a bit and submit the extra goodies from it also (you might use your GetPathNameW implementation after fixing the points raised above; these implementations are mostly equivalent). With polishing, I mean the following changes: - Test buflen in GetVolumeFileNameW (important) - The test "!filename[2]" is redundant (should be removed) (or just use your fixed version instead of the last two) - In the test: There is no need to allocate volumepath on the heap. char volumepath[16] (too bad you can't use constants in C for array dimensions!) would also do. Also, an ok(ret,"Error...") should precede the if(ret) block, the else part killed. If you expect something, always test it with an ok statement; do not sprinkle ok(FALSE) later in the code. Regards, Michael Karcher

1 0

Re: [winmm] Implement stub for midiConnect and midiDisconnect.
by Nikolay Sivov 16 Aug '08

16 Aug '08

Christian Costa wrote: > Hi, > > This fixes bug 11142 & 11182. > > Bye, > Christian > > Changelog: > Implement stub for midiConnect and midiDisconnect. > Usually some error code returned for plain stubs like these. Does it block these bugs?

2 1

Re: kernel32: Tiny improvement to the GetVolumePathNameW stub
by Michael Karcher 16 Aug '08

16 Aug '08

Am Samstag, den 16.08.2008, 17:12 +0000 schrieb Louis. Lenders: > Hi, this fixes Adobe Lightroom 2.0 start up bug, mentioned in > http://bugs.winehq.org/show_bug.cgi?id=8224#c4 > > as long wine doesn't handle with volume mount points, it's probably > safe to satisfy most apps. The idea of your patch looks right to me. But (1) please don't use memcmp to compare wide characters, especially, don't use memcmp with a count of one, as it only compares one half the the wide character. use filename[1] == ':' && filename[2] == '\\' instead. (2) Please check that filename really has at least 3 characters before accessing it. (3)Please check the size of the output buffer before copying anything into it. Finally, the chance of getting this patch accepted raises if you accompany the implementation with an API test. Another point to increase the chances of getting that patch committed is to implement the corner cases (at least the empty string) explained on MSDN, also backed up by an API test. Please also note the documented behaviour for the case of the output buffer being short by one byte. Regards, Michael Karcher

1 0

re: winmm: remove misleading message
by Dan Kegel 16 Aug '08

16 Aug '08

Jeff wrote: > Remove a message suggesting that Wine should be pointed at a windows installation. > > - FIXME("Couldn't load driver for type %s.\n" > - "If you don't have a windows installation accessible from Wine,\n" > - "you perhaps forgot to create a [mci] section in system.ini\n", > + FIXME("Couldn't load driver for type %s.\n", The [mci] section in system.ini advice is still valid and usful, I think. You probably just want to remove the middle line. - Dan

1 0

Re: [1/2] mshtml: Changed get_typeinfo to help support IDispatch
by leslie_alistair＠hotmail.com 16 Aug '08

16 Aug '08

-------------------------------------------------- From: "Jacek Caban" <jacek(a)codeweavers.com> Sent: Saturday, August 16, 2008 8:18 PM To: <wine-devel(a)winehq.org> Cc: "Alistair Leslie-Hughes" <leslie_alistair(a)hotmail.com> Subject: Re: [1/2] mshtml: Changed get_typeinfo to help support IDispatch > Alistair Leslie-Hughes wrote: >> Hi, >> >> Changelog: >> mshtml: Changed get_typeinfo to help support IDispatch > > Subject: [PATCH] Changed get_typeinfo to AddRef the COM pointer > > > get_typeinfo is an internal function so it's fine to not AddRef as long as > we guarantee that we hold the reference (and we do) so there is no point > to add unneeded AddRef here. > I based the msxml get_typeinfo on the mshtml implementation, and it was initial rejected due to the missing AddRef's. So before I started Implementing more of the IDispatch functions, I thought this was the right thing todo. Best Regards Alistair Leslie-Hughes

1 0