February 2010 - Wine-Devel - list.winehq.org

Re: [PATCH] ole32: ignore HighPart in the Seek method HGLOBAL streams. [try 2]

by Alexandre Julliard

Reece Dunn <msclrhd(a)googlemail.com> writes: > NOTE: A check for integer overflow would be `position.low + move.low < > position.low`, but there are no current tests to say if integer > overflow is handled (and how it is handled) here in the tests. > Therefore, the simplest implementation is just to remove the previous > check. It may be the simplest, but the right way is to add such a test and figure out the appropriate behavior. -- Alexandre Julliard julliard(a)winehq.org

Feb. 24, 2010

Re: PeekMsg/MsgWaitForMultipleObjects question

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Alexandre wrote: >Message waiting functions only return for new input. You need to make >sure the queue is empty before waiting. Actually, now that I believe I understand the issue, I'd rephrase it differently: The queue need not be empty (a message might have arrived 1 microsecond before the call to MsgWaitFor*). The key issue is that once you start to call PeekMessage or GetMessage, you must empty the queue with these functions before calling Wait again, because all messages present in the queue at Get/PeekMessage time will be marked "not new" (my understanding now of MSDN). for(;;) { PeekMessage(REMOVE)/*=pick 1*/; Wait(); } will timeout/hang because of this when 2 messages arrive. Exactly that happened to my code. Regards, Jörg Höhle

Feb. 24, 2010

Re: msvcrt: Implement _mbctombb.

by Reece Dunn

On 24 February 2010 08:51, David Hedberg <david.hedberg(a)gmail.com> wrote: > Well, I should add that it only makes sense for cp 932 as far as I > know, but then I'm only familiar with Japanese. More important perhaps > is that I also ran some tests on Win XP and Win 7 trying to get it to > return anything for other code pages (basically looped through them > all with _setmbcp), but only with cp 932 did it return anything other > than what was given to it. > > I'm no expert on the win32 API though, so it is possible that I have > missed something. :-) Could you add that to your test case, and then run it on the winetestbot with a range of OSs? This will help show that it is only CP 932 that is affected by that function. Thanks, - Reece

Feb. 24, 2010

Re: msvcrt: Implement _mbctombb.

by David Hedberg

Hi again, On Wed, Feb 24, 2010 at 8:27 AM, Maarten Lankhorst <m.b.lankhorst(a)gmail.com> wrote: > Hi David, > > David Hedberg wrote: >> >> On Wed, Feb 24, 2010 at 7:12 AM, Maarten Lankhorst >> <m.b.lankhorst(a)gmail.com> wrote: >> >>> >>> Hi David, >>> >> >> Hi Maarten, >> >> >>> >>> David Hedberg wrote: >>> >>>> >>>> +/* Maps multibyte cp932 punctuation marks to single byte equivalents */ >>>> +static unsigned int mbctombb_932_punct[] = { >>>> + >>>> >>>> 0x20,0xa4,0xa1,0x2c,0x2e,0xa5,0x3a,0x3b,0x3f,0x21,0xde,0xdf,0x00,0x00,0x00,0x5e, >>>> + >>>> >>>> 0x7e,0x5f,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xb0,0x00,0x00,0x2f,0x00, >>>> + >>>> >>>> 0x00,0x00,0x7c,0x00,0x00,0x60,0x27,0x00,0x22,0x28,0x29,0x00,0x00,0x5b,0x5d,0x7b, >>>> + >>>> >>>> 0x7d,0x00,0x00,0x00,0x00,0xa2,0xa3,0x00,0x00,0x00,0x00,0x2b,0x2d,0x00,0x00,0x00, >>>> + >>>> >>>> 0x00,0x3d,0x00,0x3c,0x3e,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x5c, >>>> + 0x24,0x00,0x00,0x25,0x23,0x26,0x2a,0x40}; >>>> + >>>> +/* Maps multibyte cp932 hiragana/katakana to single-byte equivalents */ >>>> +static unsigned int mbctombb_932_kana[] = { >>>> + >>>> >>>> 0xa7,0xb1,0xa8,0xb2,0xa9,0xb3,0xaa,0xb4,0xab,0xb5,0xb6,0xb6,0xb7,0xb7,0xb8,0xb8, >>>> + >>>> >>>> 0xb9,0xb9,0xba,0xba,0xbb,0xbb,0xbc,0xbc,0xbd,0xbd,0xbe,0xbe,0xbf,0xbf,0xc0,0xc0, >>>> + >>>> >>>> 0xc1,0xc1,0xaf,0xc2,0xc2,0xc3,0xc3,0xc4,0xc4,0xc5,0xc6,0xc7,0xc8,0xc9,0xca,0xca, >>>> + >>>> >>>> 0xca,0xcb,0xcb,0xcb,0xcc,0xcc,0xcc,0xcd,0xcd,0xcd,0xce,0xce,0xce,0xcf,0xd0,0xd1, >>>> + >>>> >>>> 0xd2,0xd3,0xac,0xd4,0xad,0xd5,0xae,0xd6,0xd7,0xd8,0xd9,0xda,0xdb,0xdc,0xdc,0xb2, >>>> + 0xb4,0xa6,0xdd,0xb3,0xb6,0xb9}; >>>> >>>> >>> >>> You're hardcoding this for a single code page? Are you sure you cannot >>> use a >>> more generic function instead of hardcoding a table? >>> >>> >> >> I haven't found anything that might handle it. The function in >> question maps the characters in a somewhat "irregular fashion", and >> only makes sense for code page 932. There's a static function >> "han2zen" in dlls/mlang/mlang.c that appears to be the "inverse" (to >> the extent this function is reversible), that one too is implemented >> with a couple of tables. >> > > Well, it seems msdn says the function used to be called zentohan, so if the > function only makes sense for cp 932 then adding the table is harmless, I > was afraid that more locales would need that function, in which case a more > generic solution would have been preferred. Well, I should add that it only makes sense for cp 932 as far as I know, but then I'm only familiar with Japanese. More important perhaps is that I also ran some tests on Win XP and Win 7 trying to get it to return anything for other code pages (basically looped through them all with _setmbcp), but only with cp 932 did it return anything other than what was given to it. I'm no expert on the win32 API though, so it is possible that I have missed something. :-) > > Cheers, > Maarten. > > PS: Use 'reply all' so wine-devel gets cc'd. Woops, sorry! > Thanks, David

Feb. 24, 2010

Re: msvcrt: Implement _mbctombb.

by Maarten Lankhorst

Hi David, David Hedberg wrote: > On Wed, Feb 24, 2010 at 7:12 AM, Maarten Lankhorst > <m.b.lankhorst(a)gmail.com> wrote: > >> Hi David, >> > > Hi Maarten, > > >> David Hedberg wrote: >> >>> +/* Maps multibyte cp932 punctuation marks to single byte equivalents */ >>> +static unsigned int mbctombb_932_punct[] = { >>> + >>> 0x20,0xa4,0xa1,0x2c,0x2e,0xa5,0x3a,0x3b,0x3f,0x21,0xde,0xdf,0x00,0x00,0x00,0x5e, >>> + >>> 0x7e,0x5f,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xb0,0x00,0x00,0x2f,0x00, >>> + >>> 0x00,0x00,0x7c,0x00,0x00,0x60,0x27,0x00,0x22,0x28,0x29,0x00,0x00,0x5b,0x5d,0x7b, >>> + >>> 0x7d,0x00,0x00,0x00,0x00,0xa2,0xa3,0x00,0x00,0x00,0x00,0x2b,0x2d,0x00,0x00,0x00, >>> + >>> 0x00,0x3d,0x00,0x3c,0x3e,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x5c, >>> + 0x24,0x00,0x00,0x25,0x23,0x26,0x2a,0x40}; >>> + >>> +/* Maps multibyte cp932 hiragana/katakana to single-byte equivalents */ >>> +static unsigned int mbctombb_932_kana[] = { >>> + >>> 0xa7,0xb1,0xa8,0xb2,0xa9,0xb3,0xaa,0xb4,0xab,0xb5,0xb6,0xb6,0xb7,0xb7,0xb8,0xb8, >>> + >>> 0xb9,0xb9,0xba,0xba,0xbb,0xbb,0xbc,0xbc,0xbd,0xbd,0xbe,0xbe,0xbf,0xbf,0xc0,0xc0, >>> + >>> 0xc1,0xc1,0xaf,0xc2,0xc2,0xc3,0xc3,0xc4,0xc4,0xc5,0xc6,0xc7,0xc8,0xc9,0xca,0xca, >>> + >>> 0xca,0xcb,0xcb,0xcb,0xcc,0xcc,0xcc,0xcd,0xcd,0xcd,0xce,0xce,0xce,0xcf,0xd0,0xd1, >>> + >>> 0xd2,0xd3,0xac,0xd4,0xad,0xd5,0xae,0xd6,0xd7,0xd8,0xd9,0xda,0xdb,0xdc,0xdc,0xb2, >>> + 0xb4,0xa6,0xdd,0xb3,0xb6,0xb9}; >>> >>> >> You're hardcoding this for a single code page? Are you sure you cannot use a >> more generic function instead of hardcoding a table? >> >> > > I haven't found anything that might handle it. The function in > question maps the characters in a somewhat "irregular fashion", and > only makes sense for code page 932. There's a static function > "han2zen" in dlls/mlang/mlang.c that appears to be the "inverse" (to > the extent this function is reversible), that one too is implemented > with a couple of tables. > Well, it seems msdn says the function used to be called zentohan, so if the function only makes sense for cp 932 then adding the table is harmless, I was afraid that more locales would need that function, in which case a more generic solution would have been preferred. Cheers, Maarten. PS: Use 'reply all' so wine-devel gets cc'd.

Feb. 24, 2010

Re: msvcrt: Implement _mbctombb.

by Maarten Lankhorst

Hi David, David Hedberg wrote: > +/* Maps multibyte cp932 punctuation marks to single byte equivalents */ > +static unsigned int mbctombb_932_punct[] = { > + 0x20,0xa4,0xa1,0x2c,0x2e,0xa5,0x3a,0x3b,0x3f,0x21,0xde,0xdf,0x00,0x00,0x00,0x5e, > + 0x7e,0x5f,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xb0,0x00,0x00,0x2f,0x00, > + 0x00,0x00,0x7c,0x00,0x00,0x60,0x27,0x00,0x22,0x28,0x29,0x00,0x00,0x5b,0x5d,0x7b, > + 0x7d,0x00,0x00,0x00,0x00,0xa2,0xa3,0x00,0x00,0x00,0x00,0x2b,0x2d,0x00,0x00,0x00, > + 0x00,0x3d,0x00,0x3c,0x3e,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x5c, > + 0x24,0x00,0x00,0x25,0x23,0x26,0x2a,0x40}; > + > +/* Maps multibyte cp932 hiragana/katakana to single-byte equivalents */ > +static unsigned int mbctombb_932_kana[] = { > + 0xa7,0xb1,0xa8,0xb2,0xa9,0xb3,0xaa,0xb4,0xab,0xb5,0xb6,0xb6,0xb7,0xb7,0xb8,0xb8, > + 0xb9,0xb9,0xba,0xba,0xbb,0xbb,0xbc,0xbc,0xbd,0xbd,0xbe,0xbe,0xbf,0xbf,0xc0,0xc0, > + 0xc1,0xc1,0xaf,0xc2,0xc2,0xc3,0xc3,0xc4,0xc4,0xc5,0xc6,0xc7,0xc8,0xc9,0xca,0xca, > + 0xca,0xcb,0xcb,0xcb,0xcc,0xcc,0xcc,0xcd,0xcd,0xcd,0xce,0xce,0xce,0xcf,0xd0,0xd1, > + 0xd2,0xd3,0xac,0xd4,0xad,0xd5,0xae,0xd6,0xd7,0xd8,0xd9,0xda,0xdb,0xdc,0xdc,0xb2, > + 0xb4,0xa6,0xdd,0xb3,0xb6,0xb9}; > You're hardcoding this for a single code page? Are you sure you cannot use a more generic function instead of hardcoding a table? Cheers, Maarten.

Feb. 24, 2010

Re: "make distclean" failing?

by Austin English

On Tue, Feb 23, 2010 at 10:54 PM, Dan Kegel <dank(a)kegel.com> wrote: > James McKenzie <jjmckenzie51(a)earthlink.net> wrote: >> Dan Kegel wrote: >>> "make distclean" failed for me today... >> >> I usually use just plain make clean. Is this before/after today's commits? > > After. > > And I saw a similar error today in the valgrind continuous build, > which only does clean and testclean. Works fine here...ubuntu karmic x86_64/gcc 4.4.1/GNU make 3.8.1 -- -Austin

Feb. 24, 2010

Re: "make distclean" failing?

by Dan Kegel

James McKenzie <jjmckenzie51(a)earthlink.net> wrote: > Dan Kegel wrote: >> "make distclean" failed for me today... > > I usually use just plain make clean. Is this before/after today's commits? After. And I saw a similar error today in the valgrind continuous build, which only does clean and testclean.

Feb. 24, 2010

Re: [PATCH 1/2] gdiplus/test: Add GdipGetNearestColor test [try 2]

by Vincent Povirk

You should probably use a Bitmap object rather than the display for this, since the pixel format is important. That should make it possible to test other depths, even though they can't yet be implemented properly in Wine. Also, you should mark tests that fail in wine with todo_wine and remove the todo_wine in any subsequent patches that fix them. On Tue, Feb 23, 2010 at 8:56 PM, Justin Chevrier <jchevrier(a)gmail.com> wrote: > --- > dlls/gdiplus/tests/graphics.c | 45 +++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 45 insertions(+), 0 deletions(-) > > diff --git a/dlls/gdiplus/tests/graphics.c b/dlls/gdiplus/tests/graphics.c > index 45bd9f7..97c520d 100644 > --- a/dlls/gdiplus/tests/graphics.c > +++ b/dlls/gdiplus/tests/graphics.c > @@ -21,6 +21,7 @@ > #include "windows.h" > #include "gdiplus.h" > #include "wingdi.h" > +#include "winuser.h" > #include "wine/test.h" > #include <math.h> > > @@ -2270,6 +2271,49 @@ static void test_GdipIsVisibleRect(void) > ReleaseDC(0, hdc); > } > > +static void test_GdipGetNearestColor(void) > +{ > + GpStatus status; > + GpGraphics *graphics = NULL; > + ARGB color = 0xdeadbeef; > + HDC hdc = GetDC(0); > + DEVMODEA dmA; > + BOOL ret; > + > + /* create a graphics object */ > + ok(hdc != NULL, "Expected HDC to be initialized\n"); > + > + status = GdipCreateFromHDC(hdc, &graphics); > + expect(Ok, status); > + ok(graphics != NULL, "Expected graphics to be initialized\n"); > + > + status = GdipGetNearestColor(graphics, NULL); > + expect(InvalidParameter, status); > + > + status = GdipGetNearestColor(NULL, &color); > + expect(InvalidParameter, status); > + > + ret = EnumDisplaySettingsA(NULL, ENUM_CURRENT_SETTINGS, &dmA); > + if (!ret) > + { > + skip("Could not determine color depth\n"); > + goto end; > + } > + > + if (dmA.dmBitsPerPel >= 24) > + { > + status = GdipGetNearestColor(graphics, &color); > + expect(Ok, status); > + ok(color == 0xdeadbeef, "expected 0xdeadbeef, got: 0x%08x\n", color); > + } > + else > + skip("Color depth less than 24bpp.\n"); > + > + end: > + GdipDeleteGraphics(graphics); > + ReleaseDC(0, hdc); > +} > + > START_TEST(graphics) > { > struct GdiplusStartupInput gdiplusStartupInput; > @@ -2296,6 +2340,7 @@ START_TEST(graphics) > test_GdipDrawLineI(); > test_GdipDrawLinesI(); > test_GdipDrawString(); > + test_GdipGetNearestColor(); > test_GdipGetVisibleClipBounds(); > test_GdipIsVisiblePoint(); > test_GdipIsVisibleRect(); > -- > 1.6.5.rc1 > > > >

Feb. 24, 2010

"make distclean" failing?

by Dan Kegel

"make distclean" failed for me today... after cleaning lots of stuff, it started trying to *build* something: ... make[1]: Leaving directory `/home/dank/wine-git/tools' config.status: creating tools/widl/Makefile make[1]: Entering directory `/home/dank/wine-git/tools/widl' ../../tools/makedep -C. -S../.. -T../.. client.c expr.c hash.c header.c proxy.c server.c typegen.c typelib.c typetree.c utils.c widl.c write_msft.c parser.y parser.l make[1]: ../../tools/makedep: Command not found make[1]: *** [depend] Error 127 make[1]: Leaving directory `/home/dank/wine-git/tools/widl' make: *** [tools/widl/Makefile] Error 2 Alexandre changed the build system today a bit, I wonder if that did it.

Feb. 23, 2010