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

Re: [resend] gdi32/tests: Add a test for GdiGetCodePage().
by Paul Vriens 14 Dec '08

14 Dec '08

ByeongSik Jeon wrote: > http://bugs.winehq.org/show_bug.cgi?id=16325 > --- > dlls/gdi32/tests/Makefile.in | 2 +- > dlls/gdi32/tests/font.c | 152 ++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 153 insertions(+), 1 deletions(-) > > > ------------------------------------------------------------------------ > > Hi, Could you turn the skip in this piece of code: + if (!pGdiGetCodePage) + { + skip("GdiGetCodePage not available on this platform\n"); + return; + } into a win_skip? That way we fail if the function is not available in Wine. Another thing I'm not sure about though is that in the for() loop you don't do a DeleteObject( hfont ). Is that only needed at the end? -- Cheers, Paul.

1 0

No response to updated patch for gdi32/StretchDIBits
by Mathias Kosch 13 Dec '08

13 Dec '08

Hallo! About two weeks ago I tried to hand in a (corrected version of my) patch for "StretchDIBits" [1]. However it isn't accepted until now and I didn't yet notice any response. Would someone please tell me what's wrong or if it was just missed out accidentally? [1] http://www.winehq.org/pipermail/wine-patches/2008-September/062221.html -- Mathias Kosch <info(a)mkosch.de> | http://www.mkosch.de/ RSA Public Key: http://www.mkosch.de/pubkey Roboter zum selber bauen: http://www.heise.de/ct/projekte/ct-bot/

2 2

Re: Bugfix-patches for dlls/comdlg32/filedlg.c
by Paul Vriens 13 Dec '08

13 Dec '08

Elias wrote: > - Fix for bugzilla bug 16332 > crash in file dialog if the previous selected folder is deleted > > No checking was done on the selected initial directory for the > open-file dialog, which resulted in a stack overflow if the directory > was not present. > > - Prevent free on NULL values > A typo made the CommDlg32 leak memory and potenially free NULL values. > Checks added/changed in two places. > > > > ------------------------------------------------------------------------ > > Hi, Apart from the remark that Austin made about the 'only one patch per e-mail" I think the part about the 'free on NULL values' can be improved. MemFree is a wrapper around HeapFree and there is no need to check for NULL when calling HeapFree. So it's better to get rid of the whole if() altogether (and correctly indent the MemFree of course). -- Cheers, Paul.

1 0

Re : RFC: Wine Icons
by Hervÿffffe9 Chanal 13 Dec '08

13 Dec '08

> On Friday 14 November 2008 19:13:32 Juan Lang wrote: > > > > I find that a bit alarming. I'm sure he's working very hard, and doing > > > good stuff, but I don't think Wine should be redrawing anything. Not > > > when we have Tango around - it's designed to try create some consistency > > > through standardisation. IMO standards are really good! - we use them if > > > we possibly can. > > > > The trouble is that the Tango icon set doesn't cover all the icons > > Wine needs. There's no Tango icon for regedit, for instance. > > IIRC there's Tango icon sets for specific applications. If we're doing our own > icons anyway, we could try to keep them coherent with the rest of the Tango > look and get the icons upstream to Tango. > > This seems like the most reasonable approach. Of course the only things I > usually paint are walls so I'd have no idea how easy it is to match the Tango > specs when designing icons. > > Cheers, > Kai First of all, sorry to not have answered before and for my poor English, but I was quite busy these past months and I didn't see all these messages since today. I realize that the two patch I sent an hour ago are not the best answer to all these issues (I think these two newer icons look nicer in the open dialog boxes anyway) and that all theses points have to be discussed. When remaking icons, I tried to add a bit of consistency while improving a bit the icons. Obviously, I missed something. Reading all theses remarks, I agree that a better way to handle these icons are to use the Tango ones when they are available. As it was stated, including them is not straightforward and I haven't the skill to work on including these libraries into the wine tree. I hope somebody will work on these issues. In the meanwhile, maybe I'll try to improve the others shell32 icons as the bin or the computer which I found awful in this size but I don't know if it's a good idea. Cheers, Hervé

4 5

Re: Bugfix-patches for dlls/comdlg32/filedlg.c
by Austin English 13 Dec '08

13 Dec '08

On Fri, Dec 12, 2008 at 12:42 PM, Elias <elno0959(a)student.su.se> wrote: > > - Fix for bugzilla bug 16332 > crash in file dialog if the previous selected folder is deleted > > No checking was done on the selected initial directory for the > open-file dialog, which resulted in a stack overflow if the directory > was not present. > > - Prevent free on NULL values > A typo made the CommDlg32 leak memory and potenially free NULL values. > Checks added/changed in two places. > > -- > Fortune-of-the-Mail: > Lady, lady, should you meet > One whose ways are all discreet, > One who murmurs that his wife > Is the lodestar of his life, > One who keeps assuring you > That he never was untrue, > Never loved another one... > Lady, lady, better run! > -- Dorothy Parker, "Social Note" > > > > Please only patch per e-mail. -- -Austin

1 1

Re: Add DIB Test for Polyline
by Austin English 13 Dec '08

13 Dec '08

2008/12/12 Sergey Novosyolov <chi(a)etersoft.ru>: > > > > > You need to add this file to the list of tests in dlls/gdi32/tests/Makefile.in. -- -Austin

1 0

Where to put new (vfw32) compatibility tests that wine fails?
by Hoehle, Joerg-Cyril 13 Dec '08

13 Dec '08

Hi, I have attached to http://bugs.winehq.org/show_bug.cgi?id=15915#c3 ("Cinepak reportedly not installed") the skeleton of a test that wine fails but win2k passes. I could turn this into a format that git and wine-patches understands, if I knew the answer to these questions: o Is it "right" to add compatibility tests that wine is known to fail now (people are already complaining that a wine build does not pass all tests), or are the tests considered more like regression aids and should be added only when they succeed for the first time? o What directory to add this test specific to vfw32 (or rather iccvid) ? winmm seems to test sound only, although in principle, it could be there as well. o Which files to change (beside Makefile.in and testlist.c) so that the patch builds and becomes fully integrated into the wine source tree if it were located in a new file, instead of e.g. being added to tests/mmio.c? Thank you, Jörg Höhle

2 1

Serial Fixes
by Uwe Bonnes 12 Dec '08

12 Dec '08

Hello Wolfgang, nice findings and fixes around the serial driver! What application do you test against? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

RE: winmm: Sign-compare warning fix (Resend)
by James Mckenzie 12 Dec '08

12 Dec '08

Michael Karcher <wine(a)mkarcher.dialup.fu-berlin.de> at: Dec 12, 2008 9:23 AM (MST) wrote about: RE: winmm: Sign-compare warning fix (Resend) > >Am Freitag, den 12.12.2008, 09:07 -0700 schrieb James Mckenzie: >> > unsigned int i; >> > >> > ... >> > >> > for (i = sizeof(foo) / sizeof(foo[0]) - 1; ~i; --i) >> > >> >Tested? No. >> >Readable? Don't ask me... :-) >> I understood it, but is not the goal to avoid the use of C++ constructs in WINE code? >There is no C++ construct in that code. Still i-- would do the same and >is more idiomatic C. > >> The real question is why convert a for loop to a while loop? >After the last iteration, the --i (or i--) overflows. In a for loop, the >step statement (the third statement in the loop head) is always executed >before the test (the second statement in the loop head), so there is no >way to prevent the overflow. While this is not a problem per se, as >overflow of unsigned variables is well-defined, testing for "overflow >just happended" tends to be more confusing to the readers than testing >for "is at the end". > >If you use a while loop instead, you can arrange the test to be executed >*before* the step is performed, so you have to abort on "i == 0 just >finished" insted of "i == ~0U is next", the former being easier to >understand. > This is a definite improvement. Glad you caught it and thank you for the lesson in the use of structures vice arrays. I'll take a close look at the code and your change this weekend. I was caught by the use of sizeof(array[0]) vice sizeof(struct[0]), which do yeild different results. James McKenzie

1 0

RE: winmm: Sign-compare warning fix (Resend)
by James Mckenzie 12 Dec '08

12 Dec '08

Peter Rosin <peda(a)axentia.se> at: Dec 12, 2008 4:27 AM wrote about: RE: winmm: Sign-compare warning fix (Resend) > >> But how would you then fix the sign-compare violation, or >> would you just let this one go? > >If you want it to be more compact: > > unsigned int i; > > ... > > for (i = sizeof(foo) / sizeof(foo[0]) - 1; ~i; --i) > >Tested? No. >Readable? Don't ask me... :-) I understood it, but is not the goal to avoid the use of C++ constructs in WINE code? The real question is why convert a for loop to a while loop? My guess is to avoid a possible empty or zero length foo. Of course, there should be a check before this for an empty or misformed foo[0] avoiding a divide by zero error. James McKenzie

2 1