July 2012 - Wine-Devel - list.winehq.org

Re: [PATCH 9/9] mshtml: Added test of calling IDispatchEx properties
by Marvin July 13, 2012

July 13, 2012

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=19995 Your paranoid android. === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: Comdlg32: Select initial text in edit control (try 2)
by Dmitry Timoshkov July 13, 2012

July 13, 2012

Suresh Murty <murtys.wine(a)gmail.com> wrote: > Sends a EM_SETSEL message after the initial text has been set. This is wrong place for both a test and a fix. The text should be selected on focus by a dialog control itself. -- Dmitry.

1 0

Re: Comdlg32: Select initial text in edit control (try 2)
by Marvin July 13, 2012

July 13, 2012

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=19988 Your paranoid android. === W7PROX64 (32 bit filedlg) === filedlg: unhandled exception c0000005 at 75B94C19

1 0

Re: joy.cpl: Correct joystick testing thread behavior
by Alexandre Julliard July 12, 2012

July 12, 2012

Lucas Zawacki <lfzawacki(a)gmail.com> writes: > @@ -419,14 +421,19 @@ static INT_PTR CALLBACK test_dlgproc(HWND hwnd, UINT msg, WPARAM wparam, LPARAM > SendDlgItemMessageW(hwnd, IDC_TESTSELECTCOMBO, CB_SETCURSEL, 0, 0); > test_handle_joychange(hwnd, data); > > - thread = CreateThread(NULL, 0, input_thread, (void*) data, 0, &tid); > + ResumeThread(thread); > } > } > break; > > + case PSN_KILLACTIVE: > + SuspendThread(thread); > + break; You never want to use SuspendThread, it can't possibly work reliably. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [2/2] scrrun: Added IDispatch support for IFileSystem3
by Alistair Leslie-Hughes July 12, 2012

July 12, 2012

On 12/07/2012 5:02 PM, Nikolay Sivov wrote: > For http://bugs.winehq.org/show_bug.cgi?id=9638 and similar cases > I have already submitted a patch for this http://source.winehq.org/patches/data/87925 Best Regards Alistair Leslie-Hughes

2 2

Re: [PATCH 4/5] winex11: Release memory on xrandr cleanup.
by Alexandre Julliard July 12, 2012

July 12, 2012

Henri Verbeet <hverbeet(a)codeweavers.com> writes: > diff --git a/dlls/winex11.drv/xrandr.c b/dlls/winex11.drv/xrandr.c > index 83137a4..a8dccd4 100644 > --- a/dlls/winex11.drv/xrandr.c > +++ b/dlls/winex11.drv/xrandr.c > @@ -289,6 +289,12 @@ done: > wine_tsx11_unlock(); > } > > +void X11DRV_XRandR_Cleanup(void) > +{ > + HeapFree( GetProcessHeap(), 0, real_xrandr_rates_count ); > + HeapFree( GetProcessHeap(), 0, real_xrandr_rates ); > +} It's not worth adding complexity to free memory, in practice the graphics driver is never going to be unloaded except at process exit. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: msi: fix incorrect decoding of msi stream-names
by Hans Leidekker July 12, 2012

July 12, 2012

On Wed, 2012-07-11 at 15:03 +0000, Oleg Jakobsen wrote: > @@ -203,6 +203,7 @@ BOOL decode_streamname(LPCWSTR in, LPWSTR out) > *out++ = mime2utf(ch&0x3f); > count++; > ch = mime2utf((ch>>6)&0x3f); > + continue; > } > } > *out++ = ch; Why is it incorrect? It seems to me that the upper bits should be written as the next character but now you are discarding them.

2 1

Re: [2/2] windowscodecs: Add a test for palette associated with black&white TIFF image.
by Marvin July 12, 2012

July 12, 2012

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=19971 Your paranoid android. === WXPPROSP3 (32 bit tiffformat) === tiffformat.c:115: Test failed: CreateDecoderFromStream error 0x88982f8e tiffformat: unhandled exception c0000005 at 00413EB2 === WVISTAADM (32 bit tiffformat) === tiffformat.c:115: Test failed: CreateDecoderFromStream error 0x88982f8e tiffformat: unhandled exception c0000005 at 00413EB2

1 0

Re: msi: fix incorrect decoding of msi stream-names
by Nikolay Sivov July 12, 2012

July 12, 2012

On 7/11/2012 18:03, Oleg Jakobsen wrote: > Looked at how you decode msi-stream names, and spotted a minor error > whith the decoding. > > regards > Oleg > > Why do you think it's an error? Looks like in this case it decodes one input WCHAR to two output WCHARs in a single pass.

1 0

Re: [3/5] windowscodecs: Create a predefined black&white palette if 1 bpp TIFF image doesn't have one.
by Vincent Povirk July 11, 2012

July 11, 2012

Are you sure about this? My understanding is that the result of CopyPalette is unspecified when your pixel format is not an indexed color format (in this case, a grayscale format). So, while it's not really a problem to do that (unless a program relies on the exact behavior of this decoder, which seems unlikely), for correctness you shouldn't ever be relying on this change.

2 5

Re: msvcrt: Add bsearch_s implementation by reusing code and tests from ntdll (resend)
by Alexandre Julliard July 11, 2012

July 11, 2012

André Hentschel <nerv(a)dawncrow.de> writes: > @@ -39,10 +44,19 @@ static void init(void) > pmemcpy_s = (void*)GetProcAddress(hmod, "memcpy_s"); > pI10_OUTPUT = (void*)GetProcAddress(hmod, "$I10_OUTPUT"); > pstrerror_s = (void *)GetProcAddress(hmod, "strerror_s"); > + pbsearch_s = (void *)GetProcAddress(hmod, "bsearch_s"); > p_get_doserrno = (void *)GetProcAddress(hmod, "_get_doserrno"); > p_get_errno = (void *)GetProcAddress(hmod, "_get_errno"); > p_set_doserrno = (void *)GetProcAddress(hmod, "_set_doserrno"); > p_set_errno = (void *)GetProcAddress(hmod, "_set_errno"); > + p_set_invalid_parameter_handler = (void *)GetProcAddress(hmod, "_set_invalid_parameter_handler"); set_invalid_parameter_handler is not exported in native so this won't test anything. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [5/5] gdiplus: Add some tests for GdipBitmapLockBits/GdipBitmapUnlockBits.
by Vincent Povirk July 11, 2012

July 11, 2012

Shouldn't your second LockBits in this loop always use PixelFormat24bppRGB and ImageLockModeRead? As it is, if the LockBits/UnlockBits is writing but not reading, you won't be able to tell. Also, you might want to try flags == 0 in some pixel format other than 24bppRGB. As I understand it, all modes without ImageLockModeUserInputBuf are treated as read+write regardless of flags when the bitmap is locked in its native format, as an optimization. You may simply be running into that optimization. On Wed, Jul 11, 2012 at 2:49 AM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > With additional tests for flags set to ImageLockModeUserInputBuf only. > --- > dlls/gdiplus/tests/image.c | 184 +++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 184 insertions(+) > > diff --git a/dlls/gdiplus/tests/image.c b/dlls/gdiplus/tests/image.c > index 29182aa..6ce100d 100644 > --- a/dlls/gdiplus/tests/image.c > +++ b/dlls/gdiplus/tests/image.c > @@ -3342,6 +3342,189 @@ todo_wine > GdipDisposeImage(image); > } > > +static void test_bitmapbits(void) > +{ > + > + static const BYTE pixels_24[24] = {0xff,0xff,0xff, 0,0,0, 0xff,0xff,0xff, 0,0,0, > + 0xff,0xff,0xff, 0,0,0, 0xff,0xff,0xff, 0,0,0}; > + static const BYTE pixels_24_00[24] = {0,0,0, 0,0,0, 0,0,0, 0,0,0, > + 0,0,0, 0,0,0, 0,0,0, 0,0,0}; > + static const BYTE pixels_24_77[32] = {0xff,0xff,0xff, 0,0,0, 0xff,0xff,0xff, 0,0,0,0x77,0x77,0x77,0x77, > + 0xff,0xff,0xff, 0,0,0, 0xff,0xff,0xff, 0,0,0,0x77,0x77,0x77,0x77}; > + static const BYTE pixels_24_88[32] = {0xff,0xff,0xff, 0,0,0, 0xff,0xff,0xff, 0,0,0,0x88,0x88,0x88,0x88, > + 0xff,0xff,0xff, 0,0,0, 0xff,0xff,0xff, 0,0,0,0x88,0x88,0x88,0x88}; > +#if 0 /* FIXME: these tests crash gdiplus in Wine */ > + static const BYTE pixels_8[8] = {0x01,0,0x01,0,0x01,0,0x01,0}; > + static const BYTE pixels_8_00[8] = {0,0,0,0,0,0,0,0}; > + static const BYTE pixels_8_77[32] = {0x01,0,0x01,0,0x77,0x77,0x77,0x77, > + 0x77,0x77,0x77,0x77,0x77,0x77,0x77,0x77, > + 0x01,0,0x01,0,0x77,0x77,0x77,0x77, > + 0x77,0x77,0x77,0x77,0x77,0x77,0x77,0x77}; > + static const BYTE pixels_8_88[32] = {0x01,0,0x01,0,0x88,0x88,0x88,0x88, > + 0x88,0x88,0x88,0x88,0x88,0x88,0x88,0x88, > + 0x01,0,0x01,0,0x88,0x88,0x88,0x88, > + 0x88,0x88,0x88,0x88,0x88,0x88,0x88,0x88}; > + static const BYTE pixels_a7[32] = {0xa7,0x77,0x77,0x77,0x77,0x77,0x77,0x77, > + 0x77,0x77,0x77,0x77,0x77,0x77,0x77,0x77, > + 0xa7,0x77,0x77,0x77,0x77,0x77,0x77,0x77, > + 0x77,0x77,0x77,0x77,0x77,0x77,0x77,0x77}; > + static const BYTE pixels_1[8] = {0xa0,0,0,0,0xa0,0,0,0}; > +#endif > + static const BYTE pixels_77[32] = {0x77,0x77,0x77,0x77,0x77,0x77,0x77,0x77, > + 0x77,0x77,0x77,0x77,0x77,0x77,0x77,0x77, > + 0x77,0x77,0x77,0x77,0x77,0x77,0x77,0x77, > + 0x77,0x77,0x77,0x77,0x77,0x77,0x77,0x77}; > + static const BYTE pixels_88[32] = {0x88,0x88,0x88,0x88,0x88,0x88,0x88,0x88, > + 0x88,0x88,0x88,0x88,0x88,0x88,0x88,0x88, > + 0x88,0x88,0x88,0x88,0x88,0x88,0x88,0x88, > + 0x88,0x88,0x88,0x88,0x88,0x88,0x88,0x88}; > + static const struct test_data > + { > + PixelFormat format; > + ImageLockMode mode; > + UINT width, height, stride, size; > + const BYTE *pixels; > + const BYTE *pixels_unlocked; > + } td[] = > + { > + { PixelFormat24bppRGB, 0xfff0, 4, 2, 12, 24, pixels_24, pixels_24_00 }, > + { PixelFormat24bppRGB, 0, 4, 2, 12, 24, pixels_24, pixels_24_00 }, > + > + { PixelFormat24bppRGB, ImageLockModeRead, 4, 2, 12, 24, pixels_24, pixels_24_00 }, > + { PixelFormat24bppRGB, ImageLockModeWrite, 4, 2, 12, 24, pixels_24, pixels_24_00 }, > + { PixelFormat24bppRGB, ImageLockModeRead|ImageLockModeWrite, 4, 2, 12, 24, pixels_24, pixels_24_00 }, > + { PixelFormat24bppRGB, ImageLockModeRead|ImageLockModeUserInputBuf, 4, 2, 16, 32, pixels_24_77, pixels_24_88 }, > + { PixelFormat24bppRGB, ImageLockModeWrite|ImageLockModeUserInputBuf, 4, 2, 16, 32, pixels_77, pixels_88 }, > + { PixelFormat24bppRGB, ImageLockModeUserInputBuf, 4, 2, 16, 32, pixels_77, pixels_88 }, > +#if 0 /* FIXME: these tests crash gdiplus in Wine */ > + { PixelFormat8bppIndexed, ImageLockModeRead, 4, 2, 4, 8, pixels_8, pixels_8 }, > + { PixelFormat8bppIndexed, ImageLockModeWrite, 4, 2, 4, 8, pixels_8, pixels_8 }, > + { PixelFormat8bppIndexed, ImageLockModeRead|ImageLockModeWrite, 4, 2, 4, 8, pixels_8, pixels_8_00 }, > + { PixelFormat8bppIndexed, ImageLockModeRead|ImageLockModeUserInputBuf, 4, 2, 16, 32, pixels_8_77, pixels_8_88 }, > + { PixelFormat8bppIndexed, ImageLockModeWrite|ImageLockModeUserInputBuf, 4, 2, 16, 32, pixels_77, pixels_88 }, > + { PixelFormat8bppIndexed, ImageLockModeUserInputBuf, 4, 2, 16, 32, pixels_77, pixels_88 }, > + > + { PixelFormat1bppIndexed, ImageLockModeRead, 4, 2, 4, 8, pixels_1, pixels_1 }, > + { PixelFormat1bppIndexed, ImageLockModeWrite, 4, 2, 4, 8, pixels_1, pixels_1 }, > + { PixelFormat1bppIndexed, ImageLockModeRead|ImageLockModeWrite, 4, 2, 4, 8, pixels_1, pixels_1 }, > + { PixelFormat1bppIndexed, ImageLockModeRead|ImageLockModeUserInputBuf, 4, 2, 16, 32, pixels_a7, pixels_a7 }, > +#endif > + }; > + BYTE buf[32]; > + GpStatus status; > + GpBitmap *bitmap; > + UINT i; > + BitmapData data; > + struct > + { > + ColorPalette pal; > + ARGB entries[1]; > + } palette; > + > + for (i = 0; i < sizeof(td)/sizeof(td[0]); i++) > + { > + BYTE pixels[sizeof(pixels_24)]; > + memcpy(pixels, pixels_24, sizeof(pixels_24)); > + status = GdipCreateBitmapFromScan0(4, 2, 12, PixelFormat24bppRGB, pixels, &bitmap); > + expect(Ok, status); > + > + /* associate known palette with pixel data */ > + palette.pal.Flags = PaletteFlagsGrayScale; > + palette.pal.Count = 2; > + palette.pal.Entries[0] = 0; > + palette.pal.Entries[1] = 0xffffffff; > + status = GdipSetImagePalette((GpImage *)bitmap, &palette.pal); > + expect(Ok, status); > + > + memset(&data, 0xfe, sizeof(data)); > + if (td[i].mode & ImageLockModeUserInputBuf) > + { > + memset(buf, 0x77, sizeof(buf)); > + data.Scan0 = buf; > + data.Stride = 16; > + } > + status = GdipBitmapLockBits(bitmap, NULL, td[i].mode, td[i].format, &data); > + ok(status == Ok || broken(status == InvalidParameter) /* XP */, "%u: GdipBitmapLockBits error %d\n", i, status); > + if (status != Ok) > + { > + GdipDisposeImage((GpImage *)bitmap); > + continue; > + } > + ok(td[i].width == data.Width, "%u: expected %d, got %d\n", i, td[i].width, data.Width); > + ok(td[i].height == data.Height, "%u: expected %d, got %d\n", i, td[i].height, data.Height); > + ok(td[i].stride == data.Stride, "%u: expected %d, got %d\n", i, td[i].stride, data.Stride); > + ok(td[i].format == data.PixelFormat, "%u: expected %d, got %d\n", i, td[i].format, data.PixelFormat); > + ok(td[i].size == data.Height * data.Stride, "%u: expected %d, got %d\n", i, td[i].size, data.Height * data.Stride); > + if (td[i].mode & ImageLockModeUserInputBuf) > + ok(data.Scan0 == buf, "%u: got wrong buffer\n", i); > + if (td[i].size == data.Height * data.Stride) > + { > + int match = memcmp(data.Scan0, td[i].pixels, td[i].size) == 0; > + if ((td[i].mode & (ImageLockModeRead|ImageLockModeWrite|ImageLockModeUserInputBuf)) == ImageLockModeWrite && td[i].format != PixelFormat24bppRGB) > + ok(!match, "%u: data shouldn't match\n", i); > + else > + { > + /* copying to user buffer is very buggy even in win7 */ > + ok(match || broken(!match && (td[i].mode & ImageLockModeUserInputBuf)), > + "%u: data should match\n", i); > + if (!match) > + { > + UINT j; > + BYTE *bits = data.Scan0; > + printf("%u: data mismatch for format %#x:", i, td[i].format); > + for (j = 0; j < td[i].size; j++) > + printf(" %02x", bits[j]); > + printf("\n"); > + } > + } > + > + memset(data.Scan0, 0, td[i].size); > + } > + > + status = GdipBitmapUnlockBits(bitmap, &data); > + ok(status == Ok, "%u: GdipBitmapUnlockBits error %d\n", i, status); > + > + memset(&data, 0xfe, sizeof(data)); > + if (td[i].mode & ImageLockModeUserInputBuf) > + { > + memset(buf, 0x88, sizeof(buf)); > + data.Scan0 = buf; > + data.Stride = 16; > + } > + status = GdipBitmapLockBits(bitmap, NULL, td[i].mode, td[i].format, &data); > + ok(status == Ok, "%u: GdipBitmapLockBits error %d\n", i, status); > + ok(td[i].width == data.Width, "%u: expected %d, got %d\n", i, td[i].width, data.Width); > + ok(td[i].height == data.Height, "%u: expected %d, got %d\n", i, td[i].height, data.Height); > + ok(td[i].stride == data.Stride, "%u: expected %d, got %d\n", i, td[i].stride, data.Stride); > + ok(td[i].format == data.PixelFormat, "%u: expected %d, got %d\n", i, td[i].format, data.PixelFormat); > + ok(td[i].size == data.Height * data.Stride, "%u: expected %d, got %d\n", i, td[i].size, data.Height * data.Stride); > + if (td[i].mode & ImageLockModeUserInputBuf) > + ok(data.Scan0 == buf, "%u: got wrong buffer\n", i); > + /* copying indexed data without associated palette from BitmapData leads > + to funny effects, that's a design flaw with lock/unlock pixel data */ > + if (td[i].size == data.Height * data.Stride && !(td[i].format & PixelFormatIndexed)) > + { > + int match = memcmp(data.Scan0, td[i].pixels_unlocked, td[i].size) == 0; > + ok(match, "%u: data should match\n", i); > + if (!match) > + { > + UINT j; > + BYTE *bits = data.Scan0; > + printf("%u: data mismatch for format %#x:", i, td[i].format); > + for (j = 0; j < td[i].size; j++) > + printf(" %02x", bits[j]); > + printf("\n"); > + } > + } > + > + status = GdipBitmapUnlockBits(bitmap, &data); > + ok(status == Ok, "%u: GdipBitmapUnlockBits error %d\n", i, status); > + > + status = GdipDisposeImage((GpImage *)bitmap); > + expect(Ok, status); > + } > +} > + > START_TEST(image) > { > struct GdiplusStartupInput gdiplusStartupInput; > @@ -3354,6 +3537,7 @@ START_TEST(image) > > GdiplusStartup(&gdiplusToken, &gdiplusStartupInput, NULL); > > + test_bitmapbits(); > test_tiff_palette(); > test_GdipGetAllPropertyItems(); > test_tiff_properties(); > -- > 1.7.11.1 > > >

2 1

Re: [PATCH 4/5] winex11: Simplify X11DRV_XRandR_Init() error handling a bit.
by Alexandre Julliard July 11, 2012

July 11, 2012

Henri Verbeet <hverbeet(a)codeweavers.com> writes: > @@ -276,18 +274,15 @@ void X11DRV_XRandR_Init(void) > > /* see if Xrandr is available */ > wine_tsx11_lock(); > - ok = pXRRQueryExtension(gdi_display, &xrandr_event, &xrandr_error); > - if (ok) > - { > - X11DRV_expect_error(gdi_display, XRandRErrorHandler, NULL); > - ok = pXRRQueryVersion(gdi_display, &xrandr_major, &xrandr_minor); > - if (X11DRV_check_error()) ok = FALSE; > - } > - if (ok) > - { > - TRACE("Found XRandR - major: %d, minor: %d\n", xrandr_major, xrandr_minor); > - xrandr_init_modes(); > - } > + if (!pXRRQueryExtension( gdi_display, &xrandr_event, &xrandr_error )) goto done; > + X11DRV_expect_error( gdi_display, XRandRErrorHandler, NULL ); > + if (!pXRRQueryVersion( gdi_display, &xrandr_major, &xrandr_minor )) goto done; > + if (X11DRV_check_error()) goto done; You have to call X11DRV_check_error after X11DRV_expect_error in all cases. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/2] vbscript: Added UCase implementation
by Marvin July 11, 2012

July 11, 2012

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=19930 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: [PATCH 2/2 try2] advapi32: Pass service name as argv[0] to ServiceMain
by Marvin July 11, 2012

July 11, 2012

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=19931 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: kernel32: implement IsValidLocaleName (as a wrapper around IsValidLocale) (2/2) (try 2)
by Alexandre Julliard July 10, 2012

July 10, 2012

Austin English <austinenglish(a)gmail.com> writes: > @@ -2202,6 +2202,19 @@ BOOL WINAPI IsValidLocale( LCID lcid, DWORD flags ) > (LPCWSTR)LOCALE_ILANGUAGE, LANGIDFROMLCID(lcid)) != 0; > } > > +/****************************************************************************** > + * IsValidLocaleName (KERNEL32.@) > + * > + * See IsValidLocale(). > + */ > +BOOL WINAPI IsValidLocaleName( LPCWSTR locale ) > +{ > + LCID lcid; > + > + TRACE( "(%s)\n", debugstr_w(locale) ); > + lcid = LocaleNameToLCID( locale, 0 ); > + return IsValidLocale( lcid, 0 ); > +} That's probably not going to do the right thing for invalid names. Some tests would be a good idea. -- Alexandre Julliard julliard(a)winehq.org

1 0

re: Re-enable editing on the forum?
by Dan Kegel July 10, 2012

July 10, 2012

No objection here. Seems like an obvious thing to do. I'll do it later today if nobody objects.

3 2

Re: [1/2] gdiplus: GdipBitmapLockBits should treat flags == 0 as ImageLockModeRead.
by Vincent Povirk July 10, 2012

July 10, 2012

I think you might want (!(flags & (ImageLockModeRead|ImageLockModeWrite))), in case someone passes ImageLockModeUserInputBuf On Tue, Jul 10, 2012 at 7:45 AM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > --- > dlls/gdiplus/image.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/dlls/gdiplus/image.c b/dlls/gdiplus/image.c > index db79eca..45520fd 100644 > --- a/dlls/gdiplus/image.c > +++ b/dlls/gdiplus/image.c > @@ -942,6 +942,8 @@ GpStatus WINGDIPAPI GdipBitmapLockBits(GpBitmap* bitmap, GDIPCONST GpRect* rect, > return WrongState; > } > > + if (!flags) flags = ImageLockModeRead; > + > if (bitmap->bits && bitmap->format == format && !(flags & ImageLockModeUserInputBuf)) > { > /* no conversion is necessary; just use the bits directly */ > -- > 1.7.11.1 > > >

2 1

Re: kernel32: implement IsValidLocaleName (as a wrapper around IsValidLocale)
by Dmitry Timoshkov July 10, 2012

July 10, 2012

Austin English <austinenglish(a)gmail.com> wrote: > +BOOL WINAPI IsValidLocaleName( LPCWSTR locale ) > +{ > + LCID lcid; > + BOOL ret; > + > + TRACE( "locale: %s\n", debugstr_w(locale) ); > + lcid = LocaleNameToLCID( locale, 0 ); > + ret = IsValidLocale( lcid, 0 ); > + return ret; > +} Avoiding (useless) intermediate variables along with the word 'locale' in the trace would be better IMO. -- Dmitry.

2 1

Re: some patches to read files faster (especially for baldur's gate and infinity engine games)
by Austin English July 10, 2012

July 10, 2012

On Mon, Jul 9, 2012 at 2:06 PM, Emmanuel Anne <emmanuel.anne(a)gmail.com> wrote: > Hello, I installed baldur's gate lately and noticed it was still slow in > wine, especially if I install a few mods. > See the description of the bug here : > http://bugs.winehq.org/show_bug.cgi?id=17956 > > So after reading the page about case insensitive filesystems there > http://wiki.winehq.org/CaseInsensitiveFilenames > I decided that one possible solution was to have everything in lower case. > So I made a 1st patch (see attachement). > After this, installing a weidu mod in baldur's gate becomes faster, but > loading a savegame is still very slow compared to windows. > > After some more investigation using strace, it's because the program uses > NtQueryDirectoryFile to check if a file is present in the override directory > instead of trying to open it directly, which produces a getdents call in > linux, which is extremely unefficient. So I just added a short cut for this > function : if the filename argument has no wildcard, then just use stat to > return wether the file exists or not. This is in the 2nd patch. > After this, loading savegames was extremely fast, comparable to windows > speed, finally, and there are no more slowdowns in game, it runs smoothly > all the time ! > > Well I am sure you'll find I didn't make them the right way, but I hope the > ideas will be useful to you and that you'll merge them in one form or > another into wine. > Oh yes, after applying them, all the new files created by wine will be in > lower case, but you'll eventually have to convert all the files to lower > case in the wine directories (it's required at least in the baldur's gate 2 > directory). > Also having a wineprefix with mixed lower and upper case characters would > create problems. > But except that, it works excessively well ! :) > So maybe you'll want this enabled only if the user explecitely chooses to > enable it. > For me I know I'll keep it ! > I attach the simple perl script I used to convert everything to lower case. It would be great to document this patch at http://wiki.winehq.org/InterestingPatches. -- -Austin

1 0

Re-enable editing on the forum? - Excuse me!
by newsletter [at] Schiermeier-Software July 10, 2012

July 10, 2012

Hello list, sorry for my multiple posting in the subject "Re-enable editing on the forum?" I had a mail account problem. Thanks for your appreciation! -- Gruss von Joerg Schiermeier

1 0

Re: "winetricks dotnet40" fails verifier because System.EnterpriseServices.Wrapper.dll missing?
by Dan Kegel July 9, 2012

July 9, 2012

On Mon, Jul 9, 2012 at 1:42 PM, Hans Leidekker <hans(a)codeweavers.com> wrote: >> That file does seem to be on disc, but somewhere else: >> c:/windows/Microsoft.NET/Framework/v4.0.30319/System.EnterpriseServices.Wra… >> >> Not sure how serious it is that that's misplaced. Have other folks seen this? > > This should be fixed by 45473a65a0a1fe2e61809d80f6d09bb96f923126. Indeed it is. Thanks! - Dan

1 0

Re-enable editing on the forum?
by Schiermeier Software July 9, 2012

July 9, 2012

Guten Abend Rosanne, > but someone (Jeremy?) needs to correct the other page. maybe you want to send a patch to: WineHQ - patch <wine-patches(a)winehq.org> subject: [website] <your subject> This works easier. -- Gruss von Joerg Schiermeier

2 1

Re: [PATCH 3/4] d3dx9/tests: Add effect parameter value GetMatrixPointerArray() test.
by Matteo Bruni July 9, 2012

July 9, 2012

2012/7/8 Rico Schüller <kgbricola(a)web.de>: > --- > dlls/d3dx9_36/tests/effect.c | 90 > ++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 90 insertions(+), 0 deletions(-) > Hi Rico, maybe it's just me misunderstanding this, but: + FLOAT fvalue[EFFECT_PARAMETER_VALUE_ARRAY_SIZE]; + D3DXMATRIX *matrix_pointer_array[sizeof(fvalue)/sizeof(D3DXMATRIX)]; + UINT l, k, m, element; + + for (element = 0; element <= res_desc->Elements + 1; ++element) + { + memset(fvalue, 0xab, sizeof(fvalue)); + for (l = 0; l < element; ++l) + { + matrix_pointer_array[l] = (D3DXMATRIX *)&fvalue[l * sizeof(**matrix_pointer_array) / sizeof(*matrix_pointer_array)]; + } I don't quite understand what you're trying to achieve with "sizeof(**matrix_pointer_array) / sizeof(*matrix_pointer_array)". As far as I can see, that depends on the size of the pointer (32/64 bits) and I'm not sure that the offset should change in that case. Maybe you meant to use sizeof(float) as divisor?

2 1

Re-enable editing on the forum?
by Joerg Schiermeier July 9, 2012

July 9, 2012

Guten Abend Rosanne, > but someone (Jeremy?) needs to correct the other page. maybe you want to send a patch to: WineHQ - patch <wine-patches(a)winehq.org> subject: [website] <your subject> This works easier. -- Gruss von Joerg Schiermeier

1 0

Re-enable editing on the forum?
by newsletter [at] Schiermeier-Software July 9, 2012

July 9, 2012

Guten Abend Rosanne, > but someone (Jeremy?) needs to correct the other page. maybe you want to send a patch to: WineHQ - patch <wine-patches(a)winehq.org> subject: [website] <your subject> This works easier. -- Gruss von Joerg Schiermeier

1 0

Re: [PATCH 3/4] ieframe: Added init_test helper
by Marvin July 9, 2012

July 9, 2012

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=19864 Your paranoid android. === WNT4WSSP6 (32 bit webbrowser) === webbrowser.c:3325: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3325: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3325: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3476: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3325: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3441: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3419: Test failed: Could not get WebBrowserV1 instance: 80040154 webbrowser: unhandled exception c0000005 at 0040AF8E === W2KPROSP4 (32 bit webbrowser) === webbrowser.c:2627: Test failed: expected GetOverridesKeyPath webbrowser.c:2632: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2633: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:3052: Test failed: doc_disp == NULL webbrowser: unhandled exception c0000005 at 00402FCA

1 0

Re: [PATCH 4/4] vbscript: Added support for exit for stateemnt in 'for in' loops
by Marvin July 9, 2012

July 9, 2012

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=19865 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [PATCH 2/4] ieframe: Added more DoVerb tests
by Marvin July 9, 2012

July 9, 2012

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=19863 Your paranoid android. === WNT4WSSP6 (32 bit webbrowser) === webbrowser.c:3313: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3313: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3313: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3472: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3313: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3435: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3410: Test failed: Could not get WebBrowserV1 instance: 80040154 webbrowser: unhandled exception c0000005 at 0040AF8E === W2KPROSP4 (32 bit webbrowser) === webbrowser.c:2627: Test failed: expected GetOverridesKeyPath webbrowser.c:2632: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2633: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:3052: Test failed: doc_disp == NULL webbrowser: unhandled exception c0000005 at 00402FCA

1 0

Re: [PATCH 1/8] hhctrl.ocx: Implement HH_CLOSE_ALL.
by Jacek Caban July 9, 2012

July 9, 2012

Hi Erich, On 07/04/12 20:32, Erich E. Hoover wrote: > This series of patches is intended to fix the problems with HTML Help > associated with Bug #11303 (HtmlHelp causes problems in Elster). This > patch implements some of the framework required by the other patches > through implementing the HH_CLOSE_ALL functionality needed by the > application to safely shutdown the HTML Help windows on exit. The > framework provided in this patch is the ability to register specific > HTML Help windows (needed later to set and get window properties on > the fly). While it's not about this particular patch, I can see that you're changing hhctrl.ocx to the point where it has an useful API (as opposed to simple hh.exe-like help viewer). It is really nice to see, thanks. It would be great to have some tests for this. Please consider adding them (I'm sure you already have some code for testing, so I imagine it would be mostly integrating it with Wine test suite). Thanks, Jacek

2 2

App bundle patches for OS X
by Per Johansson July 8, 2012

July 8, 2012

Hi, I think I've reached a committable stage for the application bundle code I took over from Steven Edwards last summer. But there are some controversial parts so I figured I'd ask the list first. The patch extracts all XDG specific parts of winemenubuilder into a separate file, and there is also a new file for app bundles. Which one is used is controlled by a dispatch table and is choosable in the registry. The new code reacts to the same events but instead of a .desktop file an app bundle is created, start menu is replicated at ~/Applications/Wine/. Associations are handled by modifying start.exe to make it able to receive the file to open using AppleEvent, and an app bundle execing start.exe is put in ~/Library/Wine/Associations/. The actual file name contains the associated extension but the display name is modified to be the application that will be launched. It should work out of the box, after you've installed this patch and run winemenubuilder -a you should be able to right click a text file and choose "Open with notepad" (there's a cache involved as well so you might also need to remove the wine fileassociations key in the registry). Commits can be found at https://github.com/morth/wine/commits/appbundle-proper (original commits are on the master branch). The major controversity is in the start.exe code (commit < https://github.com/morth/wine/commit/ec68ac2b2abc0a1d4559eb5490b1f12b21000e…>). It uses a private API to access the AppleEvent containing the file to open. I choose this way because: 1. The only official way to access this information is by using Objective-C, building a proper Mac application. 2. Another option was to use the deprecated Carbon, but would also take a lot of code to finish. IMO neither of the two are good options, which leaves either doing it this way or to ask Apple to open up the API. Unfortunately I don't think Apple will respond quickly to such a request. Now that 10.8 is close (maybe even GMed) it's very unlikely to happen before 10.9, and perhaps not even then without backing from a major developer (I suppose the wine project might count as a such). I've made sure to check with configure if the functions exist before calling, but it is of course not safe in case they change the signature. OTOH, I don't think that is overly likely to happen. Another thing to note is that the app bundle script will copy some environment variables when created (commit https://github.com/morth/wine/commit/58773927eb7da431ba47923d66768cd129e4da… function). The ones copied are: PATH, DYLD_FALLBACK_LIBRARY_PATH and WINEPREFIX. DYLD_FALLBACK_LIBRARY_PATH is needed or wine won't work much at all. PATH is copied because the default one is only /bin and /usr/bin, and on OS X wine is rarely in one of those locations but rather installed with MacPorts of fink or similar, which use non-default paths. Anyway, if I don't hear anything from the list I'll likely send in the commits. I suppose that will be a second chance to review them. Once again I'd like to mention that Steven Edwards did a major part of this code, thanks goes to him and also to the wine project as a whole, I really enjoy using it. Finally, I only work on this code once every few months or so, so if it's deemed that there's too many problems, anyone should feel free to pick up this code and make it done (it'd be nice if you notified me though). Regards, -- Per Johansson

1 0

Re-enable editing on the forum?
by Rosanne DiMesio July 8, 2012

July 8, 2012

The main reason for disabling editing on the forum was the confusion it caused for mailing list users. Since the two are no longer connected, that is no longer an issue. Are there any objections to re-enabling editing on the forum? -- Rosanne DiMesio <dimesio(a)earthlink.net>

1 0

Re: [2/2] msxml3: Support xmlns[:*] attribute nodes intelligently.
by Nikolay Sivov July 8, 2012

July 8, 2012

On 6/12/2012 11:55, Ulrik Dickow wrote: > Patch 2 of 2 from http://bugs.winehq.org/show_bug.cgi?id=26226 . > > > > + /* Emit appropriate fixme or warning in case of unsupported or invalid namespace. > + * The W3C spec would like us to exit earlier for attempts to redefine the namespace for > + * the reserved "xmlns" attribute or prefix (http://www.w3.org/TR/xml-names/#ns-decl) > + * likehttp://gdome2.cs.unibo.it/gtk-doc/gdome2-gdomeelement.html#GDOME-EL-SETATTRIBUTENS, > + * but since native msxml3 accepts anything here, it's safest to just continue with warning. > + */ The question is more like what libxml2 thinks about that. If it follows w3c here which is likely the question will be - won't it break somewhere internally in libxml2 code if we hack it that way? > + if(namespaceURI && namespaceURI[0] && node_type != NODE_ELEMENT) > + { > + if(node_type == NODE_ATTRIBUTE) > + switch((!strcmpW(name, xmlnsW) || > + !strncmpW(name, xmlnscW, sizeof(xmlnscW)/sizeof(WCHAR))) + > + !strcmpW(namespaceURI, w3xmlns)) Could you please simplify that, it's a bit hard to read. > + * Note: We would be more in line with the native msxml if we only detected a > + * redundancy/conflict for prefixes existing on the element itself (in element->ns > + * or in the linked list element->nsDef). But as long as our *_get_xml() doesn't > + * eliminate redundant namespace definitions in children, this behaviour may be > + * an advantage in some cases. As disadvantage is that we incorrectly regard the > + * redefinition in element 'b' in '<a xmlns="x"><b xmlns="y"/></a>' as a conflict. > + * Libxml2 currently doesn't have a function or option to only search for namespaces > + * on the current node; but it would be easy to make a reduced version of xmlSearchNs > + * (currently defined inhttp://git.gnome.org/browse/libxml2/tree/tree.c#n5871) > + * However, most apps probably set the ns to y on node b creation, so no conflict here. > + * I don't think it's better to potentially break one thing while fixing the other. And I guess I like a thought on making xmlSearchNs version that will do what we want from it. Just to clarify - is that right that libxml2 problem here is a lack of some checks that lead to duplication and conflicts later? (that are visible in doc dumps too) > +/* Convenient helper function for creating an attribute node in a given namespace. > + * Note: CHECK_HR() should not be here, but in caller, to give optimal line number info. > + */ You mean EXPECT_HR here I guess. > +static HRESULT create_attribute_ns( > + IXMLDOMDocument *doc, > + const char *attr_name, > + const char *nsURI, > + IXMLDOMAttribute **attr_ptr) > +{ > + HRESULT hr; > + VARIANT var; > + IXMLDOMNode *node; > + > + V_VT(&var) = VT_I1; > + V_I1(&var) = NODE_ATTRIBUTE; > + > + hr = IXMLDOMDocument_createNode(doc, var,_bstr_(attr_name),_bstr_(nsURI), &node); > + if (hr == S_OK) > + { > + IXMLDOMNode_QueryInterface(node, &IID_IXMLDOMAttribute, (void**) attr_ptr); > + IXMLDOMNode_Release(node); > + } > + return hr; > +} Please null out pointer in case of failure, or better always before createNode().

2 4

winebuild port to ARM?
by Roger Cruz July 7, 2012

July 7, 2012

Has anyone worked or is currently working on porting the x86 specific code in Winebuild to ARM? Specifically the relay.c file? Thanks Roger R. Cruz

2 9

Re: [PATCH] ntdll: Add stubs for WinSqmStartSession / WinSqmEndSession
by André Hentschel July 7, 2012

July 7, 2012

Am 07.07.2012 01:08, schrieb Detlef Riekenberg: > It was to simple for a stub. > I added more parameter, until the 32-Bit app stopped crashing. > > -- > By by ... Detlef > --- > dlls/ntdll/rtl.c | 18 ++++++++++++++++++ > 1 files changed, 18 insertions(+), 0 deletions(-) > > diff --git a/dlls/ntdll/rtl.c b/dlls/ntdll/rtl.c > index 34869e7..ec35a23 100644 > --- a/dlls/ntdll/rtl.c > +++ b/dlls/ntdll/rtl.c > @@ -1310,3 +1310,21 @@ BOOL WINAPI RtlSetCurrentTransaction(HANDLE new_transaction) > FIXME("(%p) :stub\n", new_transaction); > return FALSE; > } > + > +/****************************************************************************** > + * WinSqmEndSession [NTDLL.@] > + */ > +NTSTATUS WINAPI WinSqmEndSession(void *unknown1) > +{ > + FIXME("(%p) :stub\n", unknown1); > + return STATUS_NOT_IMPLEMENTED; > +} > + > +/****************************************************************************** > + * WinSqmStartSession [NTDLL.@] > + */ > +NTSTATUS WINAPI WinSqmStartSession(void *unknown1, void *unknown2, void *unknown3) > +{ > + FIXME("(%p, %p, %p) :stub\n", unknown1, unknown2, unknown3); > + return STATUS_NOT_IMPLEMENTED; > +} > You forgot the spec update. -- Best Regards, André Hentschel

1 0

Debugging wine/windows applications
by John Yani July 7, 2012

July 7, 2012

I tried to run wine under gdb and failed. Using multiprocess gdb I endup with weird trace: 0xf7ffd430 0x7bc846f9 0x7bc8480f 0x7bc84855 0x7bc42a94 0x7bc433b1 0x7b8772f7 0x7ebab89b 0x7bc80014 0x7bc8005d Where 0x7****** addresses are not connected to any module. And 0xf****** addresses are from /lib/ld-linux.so.2, debug symbols for which I can't find. Can somebody explain what's hapenning? Running wine with winedbg under gdb fails with message "err:module:LdrInitializeThunk Main exe initialization for L"C:\\windows\\system32\\notepad.exe" failed, status c0000022" Is there any tutorial on how to run wine with applications under gdb?

2 10

Policy for the Wiki?
by Kyle Auble July 7, 2012

July 7, 2012

Hello all, I've been working on the wiki recently and noticed that a lot of out-of-date or redundant information is retained. For example, completed tasks on to-do lists are checked off and never removed. Isthere an unofficial policy of not deleting info, even if it may exist elsewhere (in the git repo history, wikipage revision history, etc)? Other instances might be stubs dedicated to features in development years ago, or pages on bugs that have already been fixed or triaged in Bugzilla.I know even page deletions can still be reverted, but I wanted to check first before cleaning things out more aggressively. If there are a few unwritten rules everyone likes the wiki to follow, I could add them somewhere as editing guidelines. While the topic's up, I was also wondering how moinmoin was chosen as the wiki engine. I couldn't really find a discussion on the mailing lists so I figured it was the best option when the wiki was first started. I can appreciate that it doesn't require a database and it's written in python instead of php. Allowing only inline CSS in tables causes some headaches, but mainly it can be really slow sometimes, especially when editing, and unless using wikilinks or going directly to a page, navigation is tricky. Has the possibility of migrating the wiki to a different engine ever come up? Or does the Wine wiki code just need some tweaking and maybe some tools? To be honest, I don't know if there is a better alternative (MediaWiki is designed for a very different use case and has really messy code). It just seems like something is discouraging even basic upkeep on the wiki, which kind of defeats its whole purpose. -Kyle

2 2

Building Wine on amd64 FreeBSD?
by Hilko Bengen July 6, 2012

July 6, 2012

Following Marcus Meissner's advice how to build a WoW64 setup (thanks!), I have succeeded in building a set of co-installable i386/amd64 Debian packages. Those won't make it into the "wheezy" release as I was just a bit late for the freeze, but I have uploaded packages to experimental. What didn't work was building the 64-bits of wine on Debian/kfreebsd-amd64 (Debian userland including GNU libc on a FreeBSD kernel): <https://buildd.debian.org/status/fetch.php%3Fpkg%3Dwine%26arch%3Dkfreebsd-a…> Apparently the reason is that the uc_mcontext structure does not store the DS, ES, FS, and GS registers. After I made the changes below, everything compiled, but how useful is the result? Are those registers contained in uc_mcontext on "plain" FreeBSD? Cheers, -Hilko

2 1

Re: kernel32: add a stub for WerSetFlags
by Dmitry Timoshkov July 5, 2012

July 5, 2012

Austin English <austinenglish(a)gmail.com> wrote: > +HRESULT WINAPI WerSetFlags(DWORD flags) > +{ > + FIXME("(%d) stub!\n", flags); > + return E_NOTIMPL; > +} 1. 'flags' is unsigned 2. if it's supposed to be bit flags then printing it in decimal is not helpful. -- Dmitry.

1 0

"winetricks dotnet40" fails verifier because System.EnterpriseServices.Wrapper.dll missing?
by Dan Kegel July 5, 2012

July 5, 2012

With current git, when I try rm -rf .wine sh winetricks -q dotnet40 sh winetricks -q dotnet_verifier wine netfx_setupverifier.exe the verifier reports failure: ... [07/04/12,21:45:13] ****ERROR**** File C:\windows\Microsoft.NET\assembly\GAC_32\System.EnterpriseServices\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.EnterpriseServices.Wrapper.dll is not installed on the system ... [07/04/12,21:45:15] ****ERROR**** Verification failed for product .NET Framework 4 Client That file does seem to be on disc, but somewhere else: c:/windows/Microsoft.NET/Framework/v4.0.30319/System.EnterpriseServices.Wra… Not sure how serious it is that that's misplaced. Have other folks seen this? - Dan

1 0

[PATCH] winepulse.drv: Add PulseAudio driver
by Joerg-Cyril.Hoehle＠t-systems.com July 4, 2012

July 4, 2012

Hi, >If you don't paste all the mmdevapi tests with the fix in my git tree, it's a >regression. I don't want to see held_Frames because it's a shadow buffer. >If winmm and dsound don't work without it, they're wrong, fix those. I won't comment on the two individual pulseaudio drivers. Unfortunately, none of the two authors bothered to point me to a verbose log of the mmdevapi tests for my scrutiny. The tests should pass like they do on native. Regarding latency, I'm not aware of a flaw in Wine's winmm. HOWEVER, Wine's DSound needs a patch. Here the reason. To recap, latency is somehow related to the "distance" between what one hears and the PCM frames sent to the device. GetPosition is the only API call in that area in both winmm and mmdevapi. Buffer size is a completely different thing. I find it useful to have in mind a cascade of audio filters performing some buffering each. Then it's obvious that an app only sees the frontmost buffer size and knows nothing about the others. High latencies imply that there must be some large buffer space(s), somewhere. Period is an artificial entity related to how often the frontmost buffer is drained to feed the next buffer in the chain, in case that happens regularly. This is not guaranteed nor necessarily documented. You get the idea: regardless of arbitrary (front) buffer sizes and periods not worth this name, try and send a stable flow of data to play music without glitches and let explosions be heard ASAP. So far the situation, now the issue. It appears easier to write code that provides (frontmost) buffer space behaviour similar to native than one that provides similar latency. Alas, behaviour observable on MS-Windows differs from what we get with PulseAudio and some ALSA devices. Tests seem to indicate a latency of around 30-70ms from mmdevapi with MS-Windows. That good enough for games. OTOH if ALSA or PA gives us 2 seconds on Linux, that's a big cause of trouble. The authors of MS apps could never test them in an environment with such high latency. What happens with software not tested? It happens not to work. Two solutions: - Reduce actual latency or - lie about latency. Lying about latency causes apps to loose the ability to sync audio and video. However, given a choice between loss of lip sync and possible crashes or other weird behaviour because an app is executed in a environment that its developers never experienced, I consider the loss of lip sync to be less worrying. We designed the winealsa driver to accomodate an arbitrary latency and accept a large variation of periods. (Some bug report from Jack users seem to imply that it should accept even larger periods, e.g. 150ms, yet still pretend to use 10ms on the mmdevapi side). We choose to have the winealsa driver not lie about latency. That should be left to high level APIs. DirectSound is built around the "Direct" HW (lack of) abstraction: a circular buffer of samples is played by a DAC. The converted signal is immediately sent to the speaker. Hence: 1. GetPosition information in the DSound abstraction translates to a "playpos" -- well known. 2. No provision is made for additional buffering. The playpos must lie within the circular buffer. The reported free (writable) space shall never cross the playpos -- with subtle consequences. Wine's DSound needs a patch to ensure this second property. Given a 80ms primary buffer, Wine's DSound must not pretend its playpos is 2 seconds late! I think Wine should try and reduce latency but lie if that does not suffice. What's needed? 1. Have DSound always use a buffer large enough for typical situations (I believe 100-200ms). 2. Clamp the reported position such that it won't leave the (virtual) primary buffer. As a result, DSound must pretend to play even when Wine is solely pumping the huge 2s of cascading SW audio buffers. 3. Work on reducing the latency of the cascading audio filters. That device-level work is independent on the DSound one. Native's 30-70ms has the benefit that it nicely fits within typical DSound primary buffer sizes. PulseAudio's 2s does not (yet). I believe a total 80ms latency would be acceptable with games. Further areas of investigation and effort: - Maybe clamp latency in the mmdevapi drivers after all? After all, huge latencies are known to cause dead-locks in apps and we don't know what all apps or libraries built atop mmdevapi or winmm expect. (If yes, to what value? 150% buffer size?) - Try and find MS setups with huge latencies. USB headphones are said to be candidates, but I've yet to see an excellent and trustworthy report about what happens in that case. - Work on reducing the cascades of audio buffers - Work on further decoupling mmdevapi periods from UNIX audio API ones - Research the trade-off between glitch free playback and buffering in UNIX. The current settings in Wine's audio are IMHO not good enough yet. Regards, Jörg Höhle

2 1

Re: [1/4] gdiplus: Add a test for font and graphics using different base units. Resend.
by Vincent Povirk July 4, 2012

July 4, 2012

> +todo_wine > + expectf(102.499985, bounds.Width); Please don't hard-code string widths in your tests. It's not likely or desirable to get them exactly right.

2 1

New Wine Gecko 1.7-beta1
by Jacek Caban July 4, 2012

July 4, 2012

Hi all, It's a bit sooner for another Gecko update than usually. This is caused by the fact, that many existing bugs in our MSHTML are blocked by another bugs, which require Gecko changes for proper fix. These changes enable using Gecko's cycle collector to understand our objects. This solves quite a few problems. The update also contains merged Firefox 14 beta changes. To test it, download Wine Gecko [1] and install it as usually [2]. You will also need the attached patch. The patch contains not only Gecko API changes, but also partial (but substantial enough for test to be meaningful) support for cycle collector in MSHTML. You may find some bugs already fixed by this patch. Any help with testing will be appreciated. Thanks, Jacek [1] http://sourceforge.net/projects/wine/files/Wine%20Gecko/1.7-beta1/ [2] http://wiki.winehq.org/Gecko

1 0

Re: League of Legends patches
by Dan Kegel July 4, 2012

July 4, 2012

On Tue, Jul 3, 2012 at 1:08 AM, Andrea Canciani <ranma42(a)gmail.com> wrote: > I tried to follow the http://wiki.winehq.org/SubmittingPatches > guidelines, but this is my first submission to wine, so I guess the > patches might need further improvement. > Please point out any issues that need fixing. On an administrivial note, you should send one patch per email to wine-patches. Do you think you could write a test that (semi-)reliably causes the deadlock you're fixing? > The patches have been tested by Dan Kegel (in CC) and are currently > being used by many MacOSX and Linux users to run LoL. Our emails may have crossed - with these patches applied, dlls/ieframe/tests/webbrowser.ok seems to crash here: Unhandled exception: privileged instruction in 32-bit code (0x02786624). Backtrace: =>0 0x02786624 (0x0032fcd8) 1 0x688e22db func_webbrowser+0x3ca() [dlls/ieframe/tests/webbrowser.c:3382] Otherwise the tests seem to pass. Thanks, Dan

3 3

Re: [3/4] gdiplus: Add some tests for GdipGetPropertyItemSize and GdipGetPropertyItem. Take 2.
by Marvin July 4, 2012

July 4, 2012

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=19764 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

2 1

Re: [4/4] gdiplus: Add a bunch of tests for TIFF image properties. Resend.
by Marvin July 4, 2012

July 4, 2012

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=19765 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [PATCH 3/4] vbscript: Fixed function return crossing for loop
by Marvin July 3, 2012

July 3, 2012

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=19753 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: [PATCH 4/4] jscript: Added more apply and call tests
by Marvin July 3, 2012

July 3, 2012

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=19754 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [PATCH 2/4] vbscript: Fixed 'exit do' statements crossing for in loops
by Marvin July 3, 2012

July 3, 2012

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=19752 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Wine on the front page of Reddit
by Caleb Hearon July 3, 2012

July 3, 2012

Hi all, In a conversation between myself (MaggotBrain on the forums) and Jarrex, I expressed some frustration that Blizzard had been banning Diablo III users who used Wine. He posted some of the excerpts I sent him from WineHQ, and it quickly got to 17 pages on Blizzard's forums. http://us.battle.net/d3/en/forum/topic/5978861022 Then it made the front page of Reddit with 25k votes! http://www.reddit.com/r/gaming/comments/vyc4z/linux_users_permanently_banne… It's likely a mistake on Blizzard's part. But I thought this might be interesting to some people here. It's amazing that this conversation I had while at work led to more widespread awareness of Wine (one of the top comments on Reddit asks what Wine is). And Wine hackers- great work, I've just finished playing 2 hours of Diablo III and it runs great. -Caleb

2 1