- wine-devel - winehq.org

HID success
by Marcus Meissner 21 Feb '17

21 Feb '17

Hi, Small success story on HID ;) I just helped a colleague to enable the "Polar Loop 2" wristband for his wive. The device uses HID to synchronize settings and update firmware. While the device can be (later) configured used with Bluetooth and a Smartphone App, the basic initialization must be done with a Windows App. Wine worked nicely after the usual chmod og+rw /dev/hidraw0 (The reconnect after the firmware update had a bit of trouble, but the syncing of settings worked.) https://flow.polar.com/ Ciao, Marcus

2 1

Re: msxml3: Add __WINE_ALLOC_SIZE attributes to heap_xxx() functions.
by Nikolay Sivov 21 Feb '17

21 Feb '17

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>

1 0

Re: comctl32: Update the tooltip rectangle when a tool button is hidden
by Nikolay Sivov 21 Feb '17

21 Feb '17

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>

1 0

Re: [PATCH 3/4] d3d9/tests: AMD r500 needs dummy texture output from vertex shaders for point sprites to work.
by Marvin 21 Feb '17

21 Feb '17

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 https://testbot.winehq.org/JobDetails.pl?Key=28786 Your paranoid android. === w864 (64 bit visual) === visual.c:8093: Test failed: Got unexpected color 0x00ff00ff for no color attribute test.

1 0

Re: [PATCH 2/4] d3d9/tests: Work around a r500 Windows point sprite bug.
by Marvin 21 Feb '17

21 Feb '17

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 https://testbot.winehq.org/JobDetails.pl?Key=28785 Your paranoid android. === w1064 (64 bit visual) === visual.c:7989: Test failed: Got unexpected color 0x00007580 for quad 2 (different colors). visual.c:8093: Test failed: Got unexpected color 0x00000080 for no color attribute test.

1 0

Re: [PATCH 1/4] d3d8/tests: Work around a r500 Windows point sprite bug.
by Marvin 21 Feb '17

21 Feb '17

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 https://testbot.winehq.org/JobDetails.pl?Key=28784 Your paranoid android. === wvistau64 (64 bit visual) === d3d8:visual has no test summary line (early exit of the main process?) === w2008s64 (64 bit visual) === d3d8:visual has no test summary line (early exit of the main process?) === w7pro64 (64 bit visual) === d3d8:visual has no test summary line (early exit of the main process?) === w864 (64 bit visual) === d3d8:visual has no test summary line (early exit of the main process?) === w1064 (64 bit visual) === d3d8:visual has no test summary line (early exit of the main process?)

1 0

Re: [PATCH 3/4] d3d9/tests: AMD r500 needs dummy texture output from vertex shaders for point sprites to work.
by Henri Verbeet 20 Feb '17

20 Feb '17

On 20 February 2017 at 23:31, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > @@ -10445,6 +10445,8 @@ static void test_pointsize(void) > vertex_pointsize = {64.0f, 64.0f, 0.1f, 48.0f}, > vertex_pointsize_scaled = {64.0f, 64.0f, 0.1f, 24.0f}, > vertex_pointsize_zero = {64.0f, 64.0f, 0.1f, 0.0f}; > + /* Writing a texture coordinate from the shader is technically unnecessary, but is required > + * to make AMD drivers work. Without it, texture coordinates in the pixel shaders are 0. */ Could you make that comment a bit more specific and mention the affected hardware and driver version?

1 0

Re: comctl32: Update the tooltip rectangle when a tool button is hidden
by Nikolay Sivov 20 Feb '17

20 Feb '17

On 20.02.2017 22:17, Eric Kohl wrote: > Signed-off-by: Eric Kohl <eric.kohl(a)t-online.de> > --- > dlls/comctl32/toolbar.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/dlls/comctl32/toolbar.c b/dlls/comctl32/toolbar.c > index 784745c..bb53d66 100644 > --- a/dlls/comctl32/toolbar.c > +++ b/dlls/comctl32/toolbar.c > @@ -1690,6 +1690,7 @@ TOOLBAR_LayoutToolbar(TOOLBAR_INFO *infoPtr) > if (btnPtr->fsState & TBSTATE_HIDDEN) > { > SetRectEmpty (&btnPtr->rect); > + TOOLBAR_TooltipSetRect(infoPtr, btnPtr); > continue; > } > Hi, Eric. What are symptoms of that? I'd guess it's causing tooltips to appear when they shouldn't, or tooltips from one button to appear for another. Do you have an demo application for that or any easy way to reproduce?

2 1

Re: qcap: Define O_CLOEXEC when needed
by Bruno Jesus 20 Feb '17

20 Feb '17

On Mon, Feb 20, 2017 at 7:28 PM, André Hentschel <nerv(a)dawncrow.de> wrote: > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> > --- > > https://bugs.winehq.org/show_bug.cgi?id=42478 > > dlls/qcap/v4l.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/dlls/qcap/v4l.c b/dlls/qcap/v4l.c > index d67df73..19c6f2e 100644 > --- a/dlls/qcap/v4l.c > +++ b/dlls/qcap/v4l.c > @@ -71,6 +71,10 @@ WINE_DEFAULT_DEBUG_CHANNEL(qcap_v4l); > > #ifdef VIDIOCMCAPTURE > > +#ifndef O_CLOEXEC > +#define O_CLOEXEC 2000000 > +#endif Hi, comparing to my fcntl.h the value should be octal: #define O_CLOEXEC 02000000 /* set close_on_exec */ But FreeBSD 10 defines like: #define O_CLOEXEC 0x00100000 02000000 = 524288 0x00100000 = 1048576 So I guess it is better to define as zero or #ifdef it out.

1 1

Re: [PATCH 3/5] d3d9/tests: r500 GPUs only generate point sprite coords on texture coordinate 0.
by Henri Verbeet 20 Feb '17

20 Feb '17

On 19 February 2017 at 12:47, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > @@ -10746,7 +10746,8 @@ static void test_pointsize(void) > IDirect3DDevice9_Present(device, NULL, NULL, NULL, NULL); > > /* The following code tests point sprites with two textures, to see if each texture coordinate unit > - * generates texture coordinates for the point(result: Yes, it does) > + * generates texture coordinates for the point. Result: Yes, it does, except on some older hardware > + * (r500 and earlier, probably others). > * > * However, not all GL implementations support point sprites(they need GL_ARB_point_sprite), but there > * is no point sprite cap bit in d3d because native d3d software emulates point sprites. Until the > @@ -10802,6 +10803,11 @@ static void test_pointsize(void) > color = getPixelColor(device, 64-4, 64-4); > ok(color == 0x00ff0000, "pSprite: Pixel (64-4),(64-4) has color 0x%08x, expected 0x00ff0000\n", color); > color = getPixelColor(device, 64-4, 64+4); > + if (color == 0x00ff0000) > + { > + skip("Hardware generates point sprite coordinates on texture unit 0 only.\n"); > + goto cleanup_1tex; > + } > ok(color == 0x00000000, "pSprite: Pixel (64-4),(64+4) has color 0x%08x, expected 0x00000000\n", color); > color = getPixelColor(device, 64+4, 64+4); > ok(color == 0x0000ff00, "pSprite: Pixel (64+4),(64+4) has color 0x%08x, expected 0x0000ff00\n", color); This test has been around for a while, did it always fail? I also have the impression the hardware should be able to do this, does this fail on Linux, Windows, or both?

2 1

Re: [PATCH 1/2] ddraw/tests: Check pointer after CreateSurface without a descriptor.
by Stefan Dösinger 20 Feb '17

20 Feb '17

Am 2017-02-17 um 06:05 schrieb Alex Henrie: > dlls/ddraw/tests/dsurface.c | 10 ++++++++++ The rule is to not add new things to these old files, even if it is a minor obvious fix. If you want to change a test in there move it to tests/ddraw*.c (changing the code style, using the existing helper functions in the file, test all versions etc) and implement the change there. See e.g. http://source.winehq.org/patches/data/130355 . Yeah, it's a pesky work, but it needs to be done in the long run anyway.

3 3

Re: [PATCH 3/6] d3d8: Allocate WINED3DCAPS on stack.
by Henri Verbeet 20 Feb '17

20 Feb '17

On 20 February 2017 at 13:12, Józef Kucia <jkucia(a)codeweavers.com> wrote: > Signed-off-by: Józef Kucia <jkucia(a)codeweavers.com> > --- > dlls/d3d8/d3d8_private.h | 106 +++++++++++++++++++++++------------------------ > dlls/d3d8/device.c | 12 ++---- > dlls/d3d8/directx.c | 12 ++---- > 3 files changed, 61 insertions(+), 69 deletions(-) > Ideally we'd get rid of the macro as well.

1 0

Re: [PATCH 2/6] wined3d: Fix swizzle for ld_raw instruction.
by Henri Verbeet 20 Feb '17

20 Feb '17

On 20 February 2017 at 13:12, Józef Kucia <jkucia(a)codeweavers.com> wrote: > @@ -5063,9 +5071,9 @@ static void shader_glsl_ld_raw(const struct wined3d_shader_instruction *ins) > &dst, dst.reg.data_type))) > continue; > > - shader_glsl_swizzle_to_str(src->swizzle, FALSE, write_mask, dst_swizzle); > - shader_addline(buffer, "%s(%s_%s%u, %s / 4)%s);\n", > - function, prefix, resource, src->reg.idx[0].offset, offset.param_str, dst_swizzle); > + swizzle = shader_glsl_swizzle_get_component(src->swizzle, write_mask); That doesn't look right, should that use "i" instead of "write_mask"?

1 0

Re: Reproducible builds
by wylda＠volny.cz 20 Feb '17

20 Feb '17

> Od: Marcus Meissner <marcus(a)jet.franken.de> > > CC: <stefandoesinger(a)gmail.com, wine-devel(a)winehq.org> >On Sun, Feb 19, 2017 at 05:36:30PM +0100, wylda(a)volny.cz wrote: >> > Od: Stefan Dösinger <stefandoesinger(a)gmail.com> >> > >> >Am 2017-02-19 um 10:00 schrieb wylda(a)volny.cz: >> >> Anyway, there are 7 files out of 2750 which _always_ pickup some random >> >> value and use that consistently. Why are these libraries built >> >> inconsitently? Is that intentional? An example is attached. >> > >> >Have you looked at the .o files of those libraries? Finding the .c file >> >that introduces the difference might give some hints to pin down the >> >problem. >> > >> >> Thanks. These "random" value come from: >> >> * olepro_t.res >> * std_ole_v2_t.res >> * wuapi_tlb_t.res >> >> Anyway, all the other folders also have *.res files. Can these 3 be "fixed" >> so that they behave like the rest of dll-folders? Or can i pass some kind >> of parameter or switch? > >std_ole_v2_t.res always comes out the same for me, in 32 and 64bit builds >when I set WIDL_TIME_OVERRIDE="0". > >Same for olepro_t.res > >(current git state) When i do: export WIDL_TIME_OVERRIDE="0" rm dlls/olepro32/olepro_t.res make -k dlls/olepro32 md5sum -b dlls/olepro32/olepro_t.res then i always get different MD5 checksum. Marcus, could you send me your dlls/olepro32/Makefile please? What is your distro?

4 3

winetricks alldlls=builtin update based on wine-2.2
by wylda＠volny.cz 20 Feb '17

20 Feb '17

Hi, in case you find it useful... W.

2 1

Re: [PATCH] winemp3.acm: Fixes compilation for older mpg123 library versions
by Sebastian Lackner 19 Feb '17

19 Feb '17

On 19.02.2017 19:54, Bruno Jesus wrote: > From: Bruno Jesus <00cpxxx(a)gmail.com> > > Fixes bug https://bugs.winehq.org/show_bug.cgi?id=42483 > > Signed-off-by: Bruno Jesus <00cpxxx(a)gmail.com> > --- > dlls/winemp3.acm/mpegl3.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/dlls/winemp3.acm/mpegl3.c b/dlls/winemp3.acm/mpegl3.c > index 28a1998..100aa49 100644 > --- a/dlls/winemp3.acm/mpegl3.c > +++ b/dlls/winemp3.acm/mpegl3.c > @@ -249,12 +249,14 @@ static LRESULT MPEG3_StreamOpen(PACMDRVSTREAMINSTANCE adsi) > aad->mh = mpg123_new(NULL,&err); > mpg123_open_feed(aad->mh); > > +#ifdef MPG123_IGNORE_INFOFRAME Are you sure this works? On my system it is an enum, not a define. > /* mpg123 may find a XING header in the mp3 and use that information > * to ask for seeks in order to read specific frames in the file. > * We cannot allow that since the caller application is feeding us. > * This fixes problems for mp3 files encoded with LAME (bug 42361) > */ > mpg123_param(aad->mh, MPG123_ADD_FLAGS, MPG123_IGNORE_INFOFRAME, 0); > +#endif > } > /* no encoding yet > else if (adsi->pwfxSrc->wFormatTag == WAVE_FORMAT_PCM && >

2 5

Re: [v2 PATCH 2/2] comctl32/tests: Some tests for property page initialization
by Sebastian Lackner 19 Feb '17

19 Feb '17

On 19.02.2017 19:24, Nikolay Sivov wrote: > Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> > --- > > Resending, it depends on header change in 1/2. > > dlls/comctl32/tests/propsheet.c | 142 ++++++++++++++++++++++++++++++++++++++++ > include/prsht.h | 1 + > 2 files changed, 143 insertions(+) > > diff --git a/dlls/comctl32/tests/propsheet.c b/dlls/comctl32/tests/propsheet.c > index 7547e793e8..d11fac4bb0 100644 > --- a/dlls/comctl32/tests/propsheet.c > +++ b/dlls/comctl32/tests/propsheet.c > @@ -987,6 +987,147 @@ if (0) > DestroyWindow(hdlg); > } > > +struct custom_proppage > +{ > + union > + { > + PROPSHEETPAGEA pageA; > + PROPSHEETPAGEW pageW; > + } u; > + unsigned int addref_called; > + unsigned int release_called; > +}; > + > +static UINT CALLBACK proppage_callback_a(HWND hwnd, UINT msg, PROPSHEETPAGEA *psp) > +{ > + struct custom_proppage *cpage = (struct custom_proppage *)psp->lParam; > + PROPSHEETPAGEA *psp_orig = &cpage->u.pageA; > + > + ok(hwnd == NULL, "Expected NULL hwnd, got %p\n", hwnd); > + > + ok(psp->lParam && psp->lParam != (LPARAM)psp, "Expected newly allocated page description, got %lx, %p\n", > + psp->lParam, psp); > + ok(psp_orig->pszTitle == psp->pszTitle, "Expected same page title pointer\n"); > + ok(!lstrcmpA(psp_orig->pszTitle, psp->pszTitle), "Expected same page title string\n"); > + > + switch (msg) > + { > + case PSPCB_ADDREF: > + ok(psp->dwSize > PROPSHEETPAGEA_V1_SIZE, "Expected ADDREF for V2+ only, got size %u\n", psp->dwSize); > + cpage->addref_called++; > + break; > + case PSPCB_RELEASE: > + ok(psp->dwSize >= PROPSHEETPAGEA_V1_SIZE, "Unexpected RELEASE, got size %u\n", psp->dwSize); > + cpage->release_called++; > + break; > + default: > + ok(0, "Unexpected message %u\n", msg); > + } > + > + return 1; > +} > + > +static UINT CALLBACK proppage_callback_w(HWND hwnd, UINT msg, PROPSHEETPAGEW *psp) > +{ > + struct custom_proppage *cpage = (struct custom_proppage *)psp->lParam; > + PROPSHEETPAGEW *psp_orig = &cpage->u.pageW; > + > + ok(hwnd == NULL, "Expected NULL hwnd, got %p\n", hwnd); > + ok(psp->lParam && psp->lParam != (LPARAM)psp, "Expected newly allocated page description, got %lx, %p\n", > + psp->lParam, psp); > + ok(psp_orig->pszTitle == psp->pszTitle, "Expected same page title pointer\n"); > + ok(!lstrcmpW(psp_orig->pszTitle, psp->pszTitle), "Expected same page title string\n"); > + > + switch (msg) > + { > + case PSPCB_ADDREF: > + ok(psp->dwSize > PROPSHEETPAGEW_V1_SIZE, "Expected ADDREF for V2+ only, got size %u\n", psp->dwSize); > + cpage->addref_called++; > + break; > + case PSPCB_RELEASE: > + ok(psp->dwSize >= PROPSHEETPAGEW_V1_SIZE, "Unexpected RELEASE, got size %u\n", psp->dwSize); > + cpage->release_called++; > + break; > + default: > + ok(0, "Unexpected message %u\n", msg); > + } > + > + return 1; > +} > + > +static void test_CreatePropertySheetPage(void) > +{ > + static const WCHAR titleW[] = {'T','i','t','l','e',0}; > + struct custom_proppage page; > + HPROPSHEETPAGE hpsp; > + BOOL ret; > + > + memset(&page.u.pageA, 0, sizeof(page.u.pageA)); > + page.u.pageA.dwFlags = PSP_USECALLBACK; > + page.u.pageA.pfnDlgProc = page_dlg_proc_messages; > + page.u.pageA.pfnCallback = proppage_callback_a; > + page.u.pageA.lParam = (LPARAM)&page; > + page.u.pageA.pszTitle = "Title"; > + > + /* Only minimal size validation is performed */ > + for (page.u.pageA.dwSize = PROPSHEETPAGEA_V1_SIZE - 1; page.u.pageA.dwSize <= PROPSHEETPAGEA_V4_SIZE + 1; page.u.pageA.dwSize++) > + { > + page.addref_called = 0; > + hpsp = CreatePropertySheetPageA(&page.u.pageA); > + > + if (page.u.pageA.dwSize < PROPSHEETPAGEA_V1_SIZE) > + todo_wine > + ok(hpsp == NULL, "Expected failure, size %u\n", page.u.pageA.dwSize); > + else > + { > + ok(hpsp != NULL, "Failed to create a page, size %u\n", page.u.pageA.dwSize); > + todo_wine_if(page.u.pageA.dwSize > PROPSHEETPAGEA_V1_SIZE) > + ok(page.addref_called == (page.u.pageA.dwSize > PROPSHEETPAGEA_V1_SIZE) ? 1 : 0, "Expected ADDREF callback message\n"); > + } > + > + if (hpsp) > + { > + page.release_called = FALSE; It would be better to use 0 when its a counter. > + ret = DestroyPropertySheetPage(hpsp); > + ok(ret, "Failed to destroy a page\n"); > + todo_wine > + ok(page.release_called == 1, "Expected RELEASE callback message\n"); > + } > + } > + > + memset(&page.u.pageW, 0, sizeof(page.u.pageW)); > + page.u.pageW.dwFlags = PSP_USECALLBACK; > + page.u.pageW.pfnDlgProc = page_dlg_proc_messages; > + page.u.pageW.pfnCallback = proppage_callback_w; > + page.u.pageW.lParam = (LPARAM)&page; > + page.u.pageW.pszTitle = titleW; > + > + for (page.u.pageW.dwSize = PROPSHEETPAGEW_V1_SIZE - 1; page.u.pageW.dwSize <= PROPSHEETPAGEW_V4_SIZE + 1; page.u.pageW.dwSize++) > + { > + page.addref_called = 0; > + hpsp = CreatePropertySheetPageW(&page.u.pageW); > + > + if (page.u.pageW.dwSize < PROPSHEETPAGEW_V1_SIZE) > + todo_wine > + ok(hpsp == NULL, "Expected failure, size %u\n", page.u.pageW.dwSize); > + else > + { > + ok(hpsp != NULL, "Failed to create a page, size %u\n", page.u.pageW.dwSize); > + todo_wine_if(page.u.pageA.dwSize > PROPSHEETPAGEA_V1_SIZE) Shouldn't it be pageW here? > + ok(page.addref_called == (page.u.pageW.dwSize > PROPSHEETPAGEW_V1_SIZE) ? 1 : 0, "Expected ADDREF callback message\n"); > + } > + > + if (hpsp) > + { > + page.release_called = 0; > + ret = DestroyPropertySheetPage(hpsp); > + ok(ret, "Failed to destroy a page\n"); > + todo_wine > + ok(page.release_called == 1, "Expected RELEASE callback message\n"); > + } > + } > +} > + > START_TEST(propsheet) > { > test_title(); > @@ -998,4 +1139,5 @@ START_TEST(propsheet) > test_messages(); > test_PSM_ADDPAGE(); > test_PSM_INSERTPAGE(); > + test_CreatePropertySheetPage(); > } > diff --git a/include/prsht.h b/include/prsht.h > index f12f402afc..2b2a3e18f3 100644 > --- a/include/prsht.h > +++ b/include/prsht.h > @@ -293,6 +293,7 @@ DECL_PRSHT_TYPE_AW(LPCPROPSHEETPAGE, LATEST) > #define PSP_USEFUSIONCONTEXT 0x00004000 > #define PSP_COMMANDLINKS 0x00040000 > > +#define PSPCB_ADDREF 0 > #define PSPCB_RELEASE 1 > #define PSPCB_CREATE 2 > > -- 2.11.0 >

2 2

Re: Reproducible builds
by wylda＠volny.cz 19 Feb '17

19 Feb '17

> Od: Stefan Dösinger <stefandoesinger(a)gmail.com> > >Am 2017-02-19 um 10:00 schrieb wylda(a)volny.cz: >> Anyway, there are 7 files out of 2750 which _always_ pickup some random >> value and use that consistently. Why are these libraries built >> inconsitently? Is that intentional? An example is attached. > >Have you looked at the .o files of those libraries? Finding the .c file >that introduces the difference might give some hints to pin down the >problem. > Thanks. These "random" value come from: * olepro_t.res * std_ole_v2_t.res * wuapi_tlb_t.res Anyway, all the other folders also have *.res files. Can these 3 be "fixed" so that they behave like the rest of dll-folders? Or can i pass some kind of parameter or switch? Thank you! W.

2 1

Re: [PATCH 4/5] usp10: Iterate in visual order in GPOS_apply_feature().
by Henri Verbeet 19 Feb '17

19 Feb '17

On 19 February 2017 at 18:16, Henri Verbeet <hverbeet(a)codeweavers.com> wrote: > In particular, cursive attachment application depends on previous visual order > glyph offsets. Affects e.g. wordpad with Nastaliq fonts. > Actually, ignore this one for the moment, it depends on a few other patches.

1 0

Reproducible builds
by wylda＠volny.cz 19 Feb '17

19 Feb '17

Hi, i wanted to make a reproducible wine builds, so that striped files produce exactly same checksum. To achieve that, I run make that with: export WIDL_TIME_OVERRIDE="0" Anyway, there are 7 files out of 2750 which _always_ pickup some random value and use that consistently. Why are these libraries built inconsitently? Is that intentional? An example is attached. Thanks for hint. W.

2 1

Re: [PATCH 5/5] d3d9/tests: Allow a higher slop for test_updatetexture.
by Marvin 19 Feb '17

19 Feb '17

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 https://testbot.winehq.org/JobDetails.pl?Key=28758 Your paranoid android. === w8 (32 bit visual) === visual.c:8093: Test failed: Got unexpected color 0x00ff00ff for no color attribute test. === w1064 (32 bit visual) === visual.c:7941: Test failed: Input test: Quad 3(2crd-wrongidx) returned color 0x00ff00ff, expected 0x00ff0080 visual.c:7989: Test failed: Got unexpected color 0x00007580 for quad 2 (different colors). visual.c:8093: Test failed: Got unexpected color 0x00ff00ff for no color attribute test.

1 0

Re: [PATCH 3/5] d3d9/tests: r500 GPUs only generate point sprite coords on texture coordinate 0.
by Marvin 19 Feb '17

19 Feb '17

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 https://testbot.winehq.org/JobDetails.pl?Key=28756 Your paranoid android. === w1064 (64 bit visual) === visual.c:8093: Test failed: Got unexpected color 0x00ff00ff for no color attribute test.

1 0

Re: [PATCH 1/5] ddraw/tests: Rewrite SrcColorKey32BlitTest (v2).
by Marvin 19 Feb '17

19 Feb '17

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 https://testbot.winehq.org/JobDetails.pl?Key=28754 Your paranoid android. === w8 (32 bit ddraw1) === ddraw1.c:10154: Test failed: Got unexpected color 0x00ffffff.

1 0

Re: [PATCH] Some tests for lsa
by Sebastian Lackner 19 Feb '17

19 Feb '17

On 17.02.2017 00:29, Julius Schwartzenberg wrote: > --- > dlls/secur32/tests/Makefile.in | 1 + > dlls/secur32/tests/lsa.c | 206 +++++++++++++++++++++++++++++++++++++++++ > include/ntsecapi.h | 50 ++++++++++ > 3 files changed, 257 insertions(+) > create mode 100644 dlls/secur32/tests/lsa.c Thanks for providing the updated version. Unfortunately there are still various problems left, see the comments below. Patches should have a subject like "component: title". In this case something like "secur32/tests: Add some tests for lsa functions." might be appropriate. > > diff --git a/dlls/secur32/tests/Makefile.in b/dlls/secur32/tests/Makefile.in > index 089d1c3..d9f140a 100644 > --- a/dlls/secur32/tests/Makefile.in > +++ b/dlls/secur32/tests/Makefile.in > @@ -2,6 +2,7 @@ TESTDLL = secur32.dll > IMPORTS = secur32 crypt32 advapi32 ws2_32 > > C_SRCS = \ > + lsa.c \ > main.c \ > negotiate.c \ > ntlm.c \ > diff --git a/dlls/secur32/tests/lsa.c b/dlls/secur32/tests/lsa.c > new file mode 100644 > index 0000000..7668df1 > --- /dev/null > +++ b/dlls/secur32/tests/lsa.c It is preferred to add tests to existing files. You can still add your own copyright of course. Splitting in separate files is usually done when there are sufficient tests. > @@ -0,0 +1,206 @@ > +/* > + * Lsa tests > + * > + * Copyright 2017 Julius Schwartzenberg > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > + */ > + > +#define SECURITY_WIN32 > + > +#include <stdio.h> > +#include <ntstatus.h> > +#define WIN32_NO_STATUS > +#include <windows.h> > +#include <ntsecapi.h> > + > +#include "wine/test.h" > + > +static void test_LsaConnectUntrusted_null_handle(void) > +{ > + NTSTATUS status; > + > + status = LsaConnectUntrusted(NULL); > + > + todo_wine ok(status == STATUS_ACCESS_VIOLATION || status == RPC_NT_NULL_REF_POINTER, > + "LsaConnectUntrusted(NULL) returned 0x%x\n", status); > +} > + > +static void test_LsaConnectUntrusted_correct_handle(void) There is no need to add a separate function for each testcase. Its better to group them, for example all tests for LsaConnectUntrusted in one function, and so on. > +{ > + NTSTATUS status; > + HANDLE lsa_handle; > + There are still some lines (see for example above) with trailing whitespace in your patch. > + status = LsaConnectUntrusted(&lsa_handle); > + > + ok(status == STATUS_SUCCESS, "LsaConnectUntrusted(valid_handle) returned 0x%x\n", status); You should try to avoid leaks and always close handles at the end of each test - in this case with LsaDeregisterLogonProcess(). > +} > + > +static void test_LsaLookupAuthenticationPackage_null_handle(void) > +{ > + NTSTATUS status; > + LSA_STRING package_name; > + ULONG auth_package; > + char name[] = MICROSOFT_KERBEROS_NAME_A; > + package_name.Buffer = name; > + package_name.Length = sizeof(MICROSOFT_KERBEROS_NAME_A) - 1; > + > + status = LsaLookupAuthenticationPackage(NULL, &package_name, &auth_package); > + > + todo_wine ok(status == STATUS_INVALID_HANDLE || status == STATUS_INVALID_CONNECTION, Please always try to document where you observed which status value. Depending on what you consider more correct, you could mark the other value as broken() and a comment which Windows versions are affected. > + "LsaLookupAuthenticationPackage(NULL, \"Kerberos\", ...) returned 0x%x\n", status); > +} > + > +static void test_LsaLookupAuthenticationPackage_correct_handle(void) > +{ > + NTSTATUS status; > + HANDLE lsa_handle; > + LSA_STRING package_name; > + ULONG auth_package; > + char name[] = MICROSOFT_KERBEROS_NAME_A; > + package_name.Buffer = name; > + package_name.Length = sizeof(MICROSOFT_KERBEROS_NAME_A) - 1; > + > + LsaConnectUntrusted(&lsa_handle); > + status = LsaLookupAuthenticationPackage(lsa_handle, &package_name, &auth_package); > + LsaDeregisterLogonProcess(&lsa_handle); You should remove the & here. Also, you might want to check the result of each function, even if they are also tested separately. > + > + ok(status == STATUS_SUCCESS, > + "LsaLookupAuthenticationPackage(valid_handle, \"Kerberos\", ...) returned 0x%x\n", status); You might also want to test the auth_package output parameter here. > +} > + > +static void test_LsaLookupAuthenticationPackage_correct_handle_wrong_name(void) > +{ > + NTSTATUS status; > + HANDLE lsa_handle; > + LSA_STRING package_name; > + ULONG auth_package; > + package_name.Buffer = "this is probably not a valid authentication package name"; This triggers a compiler warning here: lsa.c:90:25: error: assignment discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers] package_name.Buffer = "this is probably not a valid authentication package name"; > + package_name.Length = (USHORT)strlen(package_name.Buffer); The explicit cast to USHORT should not be necessary here. > + > + LsaConnectUntrusted(&lsa_handle); > + status = LsaLookupAuthenticationPackage(lsa_handle, &package_name, &auth_package); > + LsaDeregisterLogonProcess(&lsa_handle); Similar to above, the & is wrong here. > + > + todo_wine ok(status == STATUS_NO_SUCH_PACKAGE, > + "LsaLookupAuthenticationPackage(valid_handle, invalid, ...) returned 0x%x\n", status); > +} > + > +static void test_LsaCallAuthenticationPackage_invalid_handle(void) > +{ > + NTSTATUS status; > + ULONG submit_buffer_length = 0; > + > + VOID *protocol_return_buffer = NULL; > + ULONG *return_buffer_length = 0; > + PNTSTATUS protocol_status = NULL; > + > + status = LsaCallAuthenticationPackage( > + NULL, 0xdeadbeef, NULL, submit_buffer_length, You do not really need a separate variable just to pass 0 to a function. > + protocol_return_buffer, return_buffer_length, protocol_status Those are supposed to be output pointers (&buffer, ...). Passing NULL is probably also fine, but no need for separate variables then. > + ); > + > + todo_wine ok(status == STATUS_INVALID_HANDLE || status == STATUS_INVALID_CONNECTION, > + "LsaCallAuthenticationPackage(NULL, ...) returned 0x%x\n", status); > +} > + > +static void test_LsaCallAuthenticationPackage_invalid_package(void) > +{ > + NTSTATUS status; > + HANDLE lsa_handle; > + ULONG submit_buffer_length = 0; > + > + VOID *protocol_return_buffer = NULL; > + ULONG *return_buffer_length = 0; > + PNTSTATUS protocol_status = NULL; > + > + LsaConnectUntrusted(&lsa_handle); > + status = LsaCallAuthenticationPackage( > + lsa_handle, 0xdeadbeef, NULL, submit_buffer_length, > + protocol_return_buffer, return_buffer_length, protocol_status > + ); > + LsaDeregisterLogonProcess(&lsa_handle); > + > + todo_wine ok(status == STATUS_NO_SUCH_PACKAGE, > + "LsaCallAuthenticationPackage(valid_handle, invalid, ...) returned 0x%x\n", status); > +} > + > +static void test_LsaCallAuthenticationPackage_null_submit_buffer(void) > +{ > + NTSTATUS status; > + HANDLE lsa_handle; > + LSA_STRING package_name; > + ULONG auth_package; > + ULONG submit_buffer_length = 0; > + VOID *protocol_return_buffer = NULL; > + ULONG *return_buffer_length = 0; > + PNTSTATUS protocol_status = NULL; > + char name[] = MICROSOFT_KERBEROS_NAME_A; > + package_name.Buffer = name; > + package_name.Length = sizeof(MICROSOFT_KERBEROS_NAME_A) - 1; > + > + LsaConnectUntrusted(&lsa_handle); > + LsaLookupAuthenticationPackage(lsa_handle, &package_name, &auth_package); > + status = LsaCallAuthenticationPackage( > + lsa_handle, auth_package, NULL, submit_buffer_length, > + protocol_return_buffer, return_buffer_length, protocol_status > + ); > + LsaDeregisterLogonProcess(&lsa_handle); > + > + todo_wine ok(status == STATUS_INVALID_PARAMETER, > + "LsaCallAuthenticationPackage(...) returned 0x%x\n", status); > +} > + > +static void test_LsaCallAuthenticationPackage_correct_submit_buffer(void) > +{ > + NTSTATUS status; > + HANDLE lsa_handle; > + LSA_STRING package_name; > + ULONG auth_package; > + PKERB_RETRIEVE_TKT_REQUEST protocol_submit_buffer; > + VOID *protocol_return_buffer = NULL; > + ULONG *return_buffer_length = 0; > + PNTSTATUS protocol_status = NULL; > + char name[] = MICROSOFT_KERBEROS_NAME_A; > + package_name.Buffer = name; > + package_name.Length = sizeof(MICROSOFT_KERBEROS_NAME_A) - 1; > + > + LsaConnectUntrusted(&lsa_handle); > + LsaLookupAuthenticationPackage(lsa_handle, &package_name, &auth_package); > + > + protocol_submit_buffer = LocalAlloc(LMEM_ZEROINIT, sizeof(KERB_RETRIEVE_TKT_REQUEST)); > + protocol_submit_buffer->MessageType = KerbRetrieveEncodedTicketMessage; If you use memory allocations, please also free them at the end of the function. Also, please note that it is usually preferred to use HeapAlloc(), unless the API requires to use a very specific one. In this case (fixed size struct) you could also consider allocating the memory directly on the stack. > + > + status = LsaCallAuthenticationPackage( > + lsa_handle, auth_package, protocol_submit_buffer, sizeof(KERB_RETRIEVE_TKT_REQUEST), > + protocol_return_buffer, return_buffer_length, protocol_status > + ); > + LsaDeregisterLogonProcess(&lsa_handle); > + > + ok(status == STATUS_SUCCESS, "LsaCallAuthenticationPackage(...) returned 0x%x\n", status); > +} > + > +START_TEST(lsa) > +{ > + test_LsaConnectUntrusted_null_handle(); > + test_LsaConnectUntrusted_correct_handle(); > + test_LsaLookupAuthenticationPackage_null_handle(); > + test_LsaLookupAuthenticationPackage_correct_handle(); > + test_LsaLookupAuthenticationPackage_correct_handle_wrong_name(); > + test_LsaCallAuthenticationPackage_invalid_handle(); > + test_LsaCallAuthenticationPackage_invalid_package(); > + test_LsaCallAuthenticationPackage_null_submit_buffer(); > + test_LsaCallAuthenticationPackage_correct_submit_buffer(); > +} > diff --git a/include/ntsecapi.h b/include/ntsecapi.h > index 2bb3d31..e8a2af4 100644 > --- a/include/ntsecapi.h > +++ b/include/ntsecapi.h > @@ -387,6 +387,56 @@ NTSTATUS WINAPI LsaSetTrustedDomainInformation(LSA_HANDLE,PSID,TRUSTED_INFORMATI > NTSTATUS WINAPI LsaStorePrivateData(LSA_HANDLE,PLSA_UNICODE_STRING,PLSA_UNICODE_STRING); > NTSTATUS WINAPI LsaUnregisterPolicyChangeNotification(POLICY_NOTIFICATION_INFORMATION_CLASS,HANDLE); > > +#ifndef MICROSOFT_KERBEROS_NAME_A > + > +#define MICROSOFT_KERBEROS_NAME_A "Kerberos" > +#define MICROSOFT_KERBEROS_NAME_W (const WCHAR []){'K','e','r','b','e','r','o','s',0} > +#define MICROSOFT_KERBEROS_NAME MICROSOFT_KERBEROS_NAME_W > +#endif > + > +typedef enum _KERB_PROTOCOL_MESSAGE_TYPE { > + KerbDebugRequestMessage = 0, You are using tabs here, but the file seems to use spaces. > + KerbQueryTicketCacheMessage, > + KerbChangeMachinePasswordMessage, > + KerbVerifyPacMessage, > + KerbRetrieveTicketMessage, > + KerbUpdateAddressesMessage, > + KerbPurgeTicketCacheMessage, > + KerbChangePasswordMessage, > + KerbRetrieveEncodedTicketMessage, > + KerbDecryptDataMessage, > + KerbAddBindingCacheEntryMessage, > + KerbSetPasswordMessage, > + KerbSetPasswordExMessage, > + KerbVerifyCredentialsMessage, > + KerbQueryTicketCacheExMessage, > + KerbPurgeTicketCacheExMessage, > + KerbRefreshSmartcardCredentialsMessage, > + KerbAddExtraCredentialsMessage, > + KerbQuerySupplementalCredentialsMessage, > + KerbTransferCredentialsMessage, > + KerbQueryTicketCacheEx2Message > +} KERB_PROTOCOL_MESSAGE_TYPE,*PKERB_PROTOCOL_MESSAGE_TYPE; > + > +#ifndef __SECHANDLE_DEFINED__ > + typedef struct _SecHandle { > + ULONG_PTR dwLower; > + ULONG_PTR dwUpper; > + } SecHandle,*PSecHandle; > + > +#define __SECHANDLE_DEFINED__ > +#endif > + > +typedef struct _KERB_RETRIEVE_TKT_REQUEST { > + KERB_PROTOCOL_MESSAGE_TYPE MessageType; > + LUID LogonId; > + UNICODE_STRING TargetName; > + ULONG TicketFlags; > + ULONG CacheOptions; > + LONG EncryptionType; > + SecHandle CredentialsHandle; > +} KERB_RETRIEVE_TKT_REQUEST,*PKERB_RETRIEVE_TKT_REQUEST; > + > #ifdef __cplusplus > } /* extern "C" */ > #endif /* defined(__cplusplus) */ > -- 1.9.1 >

2 1

[GSoC 2017]
by Saksham Bassi 18 Feb '17

18 Feb '17

Hello, I am Saksham. I am pursuing Bachelors of Engineering (Information Technology) at PICT, Pune. I would like to start contributing and GSoC can be stepping stone towards it. I am new to open source community. I went through the GSoC site. I really liked previous year projects and would love to be a part of GSoC this year. I would like to familiarise myself with the code. How can I start contributing?

3 2

Wine has been accepted into Outreachy (May-August 2017)
by Austin English 18 Feb '17

18 Feb '17

For more info, please see: https://wiki.gnome.org/Outreachy/2017/MayAugust https://wiki.winehq.org/Outreachy I am the administration coordinator, so please contact me with any questions. Please forward this to any students you know that may be eligible. -- -Austin GPG: 14FB D7EA A041 937B

3 4

Re: wine/test.h: Identify test result lines printed by child processes.
by Alexandre Julliard 18 Feb '17

18 Feb '17

Francois Gouget <fgouget(a)codeweavers.com> writes: > Currently the child process result lines are indistinguishable from the > main process one. This makes it impossible to automatically detect > when a process exits abruptly, i.e. without printing a result line, > if it has run a subprocess. By making the subprocess result lines > different analysis tools will detect that the main result line is > missing and automatically consider that the main process crashed, > thus marking the test as failed. > > Signed-off-by: Francois Gouget <fgouget(a)codeweavers.com> > --- > > This should fix bug 32354: > https://bugs.winehq.org/show_bug.cgi?id=32354 I don't think the test framework should be modifying the environment in all the tests. It already breaks some things: ../../../tools/runtest -q -P wine -T ../../.. -M msvcrt.dll -p msvcrt_test.exe.so environ && touch environ.ok environ.c:198: Test failed: Expected environment block pointer element to be non-NULL wine: Unhandled page fault on read access to 0x00000000 at address 0x7ed2a986 (thread 0074), starting debugger... -- Alexandre Julliard julliard(a)winehq.org

2 5

Re: [PATCH v5] compobj.dll16: Implement CoGetClassObject16().
by Sebastian Lackner 17 Feb '17

17 Feb '17

On 17.02.2017 22:32, Zebediah Figura wrote: > + SEGPTR seg_rclsid = MapLS(rclsid); > + SEGPTR seg_riid = MapLS(riid); > + SEGPTR seg_ppv = MapLS(ppv); You should also unmap them in case of an error. (Or alternatively, you could change the specfile, and pass through the SEGPTRs).

1 0

Re: [PATCH 2/5] wined3d: Handle CS op emission from CS op handlers.
by Sebastian Lackner 17 Feb '17

17 Feb '17

On 17.02.2017 14:08, Henri Verbeet wrote: > Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com> > --- > dlls/wined3d/cs.c | 37 +++++++++++++++++++++++++++++-------- > dlls/wined3d/wined3d_private.h | 2 +- > 2 files changed, 30 insertions(+), 9 deletions(-) > > diff --git a/dlls/wined3d/cs.c b/dlls/wined3d/cs.c > index 55706cd..10905c0 100644 > --- a/dlls/wined3d/cs.c > +++ b/dlls/wined3d/cs.c > @@ -1576,26 +1576,47 @@ static void (* const wined3d_cs_op_handlers[])(struct wined3d_cs *cs, const void > > static void *wined3d_cs_st_require_space(struct wined3d_cs *cs, size_t size) > { > - if (size > cs->data_size) > + if (size > (cs->data_size - cs->end)) > { > + size_t new_size; > void *new_data; > > - size = max( size, cs->data_size * 2 ); > - if (!(new_data = HeapReAlloc(GetProcessHeap(), 0, cs->data, size))) > + new_size = max(size, cs->data_size * 2); > + if (!cs->end) > + new_data = HeapReAlloc(GetProcessHeap(), 0, cs->data, new_size); > + else > + new_data = HeapAlloc(GetProcessHeap(), 0, new_size); > + if (!new_data) > return NULL; > > - cs->data_size = size; > + cs->data_size = new_size; > + cs->start = cs->end = 0; > cs->data = new_data; > } > > - return cs->data; > + cs->end += size; > + > + return (BYTE *)cs->data + cs->start; > } > > static void wined3d_cs_st_submit(struct wined3d_cs *cs) > { > - enum wined3d_cs_op opcode = *(const enum wined3d_cs_op *)cs->data; > - > - wined3d_cs_op_handlers[opcode](cs, cs->data); > + enum wined3d_cs_op opcode; > + size_t start; > + BYTE *data; > + > + data = cs->data; > + start = cs->start; > + cs->start = cs->end; > + opcode = *(const enum wined3d_cs_op *)&data[start]; > + wined3d_cs_op_handlers[opcode](cs, &data[start]); > + if (!start) > + { > + if (cs->data != data) > + HeapFree(GetProcessHeap(), 0, data); > + else > + cs->start = cs->end = 0; > + } Is it intentional that you are not updating cs->start and cs->end in any other situation? This might lead to unnecessary memory allocations because start / end is not set back before the block is fully empty. Here an example what happens if wined3d_device_delete_opengl_contexts_cs is called with lots of resources (with this patch http://ix.io/dP5): fixme:d3d:wined3d_device_delete_opengl_contexts_cs -> unloading resources fixme:d3d:wined3d_cs_st_require_space start = 12 fixme:d3d:wined3d_cs_st_require_space start = 20 fixme:d3d:wined3d_cs_st_require_space start = 28 [...] fixme:d3d:wined3d_cs_st_require_space start = 4068 fixme:d3d:wined3d_cs_st_require_space start = 4076 fixme:d3d:wined3d_cs_st_require_space start = 4084 fixme:d3d:wined3d_cs_st_require_space allocated new block 0x579fdb70 fixme:d3d:wined3d_cs_st_require_space start = 0 fixme:d3d:wined3d_cs_st_require_space start = 0 fixme:d3d:wined3d_cs_st_require_space start = 0 [..] In this case, with the buffer basically almost empty, there shouldn't be any need to do memory allocations. > } > > static void wined3d_cs_st_push_constants(struct wined3d_cs *cs, enum wined3d_push_constants p, > diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h > index 54adf26..49fba06 100644 > --- a/dlls/wined3d/wined3d_private.h > +++ b/dlls/wined3d/wined3d_private.h > @@ -3170,7 +3170,7 @@ struct wined3d_cs > struct wined3d_fb_state fb; > struct wined3d_state state; > > - size_t data_size; > + size_t data_size, start, end; > void *data; > }; > >

3 5

Re: [PATCH v4 1/5] compobj.dll16: Implement CoLoadLibrary16 and CoFreeLibrary16.
by Alexandre Julliard 17 Feb '17

17 Feb '17

Zebediah Figura <z.figura12(a)gmail.com> writes: > +/* --- loaded dll list implementation */ > +struct open_dll > +{ > + HMODULE16 library; > + FARPROC16 DllCanUnloadNow; > + struct list entry; > +}; > + > +static struct list open_dll_list = LIST_INIT(open_dll_list); > + > +static HRESULT dll_list_add(LPCSTR library_name, struct open_dll **ret) > +{ > + struct open_dll *dll; > + HMODULE16 library; > + FARPROC16 DllCanUnloadNow; > + > + library = LoadLibrary16(library_name); > + if (!library) > + { > + ERR("couldn't load in-process dll %s\n", debugstr_a(library_name)); > + return E_ACCESSDENIED; /* FIXME: or should this be CO_E_DLLNOTFOUND? */ > + } > + > + DllCanUnloadNow = GetProcAddress16(library, "DllCanUnloadNow"); > + /* Note: failing to find DllCanUnloadNow is not a failure */ > + > + dll = HeapAlloc(GetProcessHeap(), 0, sizeof(struct open_dll)); > + dll->library = library; > + dll->DllCanUnloadNow = DllCanUnloadNow; > + list_add_tail(&open_dll_list, &dll->entry); > + *ret = dll; > + TRACE("added new loaded dll %d\n", dll->library); > + > + return S_OK; > +} I'm not sure we even need the list at all. It would be needed for CoFreeAllLibraries16, but it's not clear that this is a useful function. > +void WINAPI CoFreeLibrary16( > + HINSTANCE16 hInst) > +{ > + struct open_dll *dll; > + > + LIST_FOR_EACH_ENTRY(dll, &open_dll_list, struct open_dll, entry) > + { > + if(hInst == dll->library) > + dll_list_free(dll); > + } That's freeing all the loaded instances, I don't think that's what you want. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH] programs/regedit: Sort each of top level branches separately
by Hugh McMaster 17 Feb '17

17 Feb '17

On Friday, 17 February 2017 9:42 AM, Nikolay Sivov wrote: > --- a/programs/regedit/treeview.c > +++ b/programs/regedit/treeview.c > @@ -477,12 +477,12 @@ BOOL RefreshTreeView(HWND hwndTV) > hItem = (HTREEITEM)SendMessageW(hwndTV, TVM_GETNEXTITEM, TVGN_CHILD, (LPARAM)hRoot); > while (hItem) { > RefreshTreeItem(hwndTV, hItem); > + SendMessageW(hwndTV, TVM_SORTCHILDREN, TRUE, (LPARAM)hItem); > hItem = (HTREEITEM)SendMessageW(hwndTV, TVM_GETNEXTITEM, TVGN_NEXT, (LPARAM)hItem); > } > > SendMessageW(hwndTV, WM_SETREDRAW, TRUE, 0); > InvalidateRect(hwndTV, NULL, FALSE); > - SendMessageW(hwndTV, TVM_SORTCHILDREN, TRUE, (LPARAM)hSelectedItem); > SetCursor(hcursorOld); This doesn't seem to work. None of the treeview nodes are sorted when you click Refresh or press F5, but immediate children were sorted before this patch. Can you please take another look? This is probably due to an incomplete TREEVIEW_SortChildren() function in comctl32. case TVM_SORTCHILDREN: return TREEVIEW_SortChildren(infoPtr, lParam); Note that we ignore the wParam, which MSDN says is a "Value that specifies whether the sorting is recursive. Set wParam to TRUE to sort all levels of child items below the parent item. Otherwise, only the parent's immediate children are sorted. " -- Hugh McMaster

2 1

Re: ntoskrnl.exe: add KeAcquireInStackQueuedSpinLock stub (try 2)
by Sebastian Lackner 17 Feb '17

17 Feb '17

On 09.02.2017 23:51, Austin English wrote: > CC: Sebastian Lackner <sebastian(a)fds-team.de> > > https://bugs.winehq.org/show_bug.cgi?id=41472 > > -- -Austin GPG: 14FB D7EA A041 937B > > > 0001-ntoskrnl.exe-add-KeAcquireInStackQueuedSpinLock-stub.patch > > > From ee6a34f4a0e558de27aa5d9f3c81a8ad45c24dbb Mon Sep 17 00:00:00 2001 > From: Austin English <austinenglish(a)gmail.com> > Date: Mon, 6 Feb 2017 17:11:15 -0600 > Subject: [PATCH] ntoskrnl.exe: add KeAcquireInStackQueuedSpinLock stub (try 2) > > Signed-off-by: Austin English <austinenglish(a)gmail.com> > --- > dlls/hal/hal.spec | 2 +- > dlls/ntoskrnl.exe/ntoskrnl.c | 13 +++++++++++++ > dlls/ntoskrnl.exe/ntoskrnl.exe.spec | 1 + > include/ddk/wdm.h | 10 ++++++++++ > tools/make_specfiles | 4 ++++ > 5 files changed, 29 insertions(+), 1 deletion(-) > > diff --git a/dlls/hal/hal.spec b/dlls/hal/hal.spec > index bd6bc35..f441ac5 100644 > --- a/dlls/hal/hal.spec > +++ b/dlls/hal/hal.spec > @@ -4,7 +4,7 @@ > @ stub HalClearSoftwareInterrupt > @ stub HalRequestSoftwareInterrupt > @ stub HalSystemVectorDispatchEntry > -@ stub KeAcquireInStackQueuedSpinLock > +@ stdcall -norelay KeAcquireInStackQueuedSpinLock(ptr ptr) ntoskrnl.exe.KeAcquireInStackQueuedSpinLock > @ stub KeAcquireInStackQueuedSpinLockRaiseToSynch > @ stub KeAcquireQueuedSpinLock > @ stub KeAcquireQueuedSpinLockRaiseToSynch > diff --git a/dlls/ntoskrnl.exe/ntoskrnl.c b/dlls/ntoskrnl.exe/ntoskrnl.c > index 06320d0..b8f6a25 100644 > --- a/dlls/ntoskrnl.exe/ntoskrnl.c > +++ b/dlls/ntoskrnl.exe/ntoskrnl.c > @@ -3188,3 +3188,16 @@ VOID WINAPI KeClearEvent(PRKEVENT event) > { > FIXME("stub: %p\n", event); > } > + > +/*********************************************************************** > + * KeAcquireInStackQueuedSpinLock (NTOSKRNL.EXE.@) > + */ > +#ifdef DEFINE_FASTCALL2_ENTRYPOINT > +DEFINE_FASTCALL2_ENTRYPOINT( KeAcquireInStackQueuedSpinLock ) > +void WINAPI __regs_KeAcquireInStackQueuedSpinLock(KSPIN_LOCK *spinlock, KLOCK_QUEUE_HANDLE *handle) > +#else > +void WINAPI KeAcquireInStackQueuedSpinLock(KSPIN_LOCK *spinlock, KLOCK_QUEUE_HANDLE *handle) > +#endif > +{ > + FIXME( "stub: %p %p\n", spinlock, handle); > +} > diff --git a/dlls/ntoskrnl.exe/ntoskrnl.exe.spec b/dlls/ntoskrnl.exe/ntoskrnl.exe.spec > index efa69fe..08644fb 100644 > --- a/dlls/ntoskrnl.exe/ntoskrnl.exe.spec > +++ b/dlls/ntoskrnl.exe/ntoskrnl.exe.spec > @@ -41,6 +41,7 @@ > @ stub IoWritePartitionTable > @ stdcall -norelay IofCallDriver(ptr ptr) > @ stdcall -norelay IofCompleteRequest(ptr long) > +@ stdcall -norelay KeAcquireInStackQueuedSpinLock(ptr ptr) Based on the information I have found, the location where this function is implemented differs between 32-bit and 64-bit Windows versions. On 32-bit its only in HAL, on 64-bit its only in ntoskrnl. Unfortunately I'm not sure what would be the best way to solve this. We probably don't want to implement it twice, but what would be the preferred location? Some shared file, or is it fine to keep the ntoskrnl export on 32-bit? > @ stub KeAcquireInStackQueuedSpinLockAtDpcLevel > @ stub KeReleaseInStackQueuedSpinLockFromDpcLevel > @ stub KeSetTimeUpdateNotifyRoutine > diff --git a/include/ddk/wdm.h b/include/ddk/wdm.h > index 4c696f7..3e1a8a7 100644 > --- a/include/ddk/wdm.h > +++ b/include/ddk/wdm.h > @@ -1210,6 +1210,16 @@ typedef struct _CALLBACK_OBJECT > UCHAR reserved[3]; > } CALLBACK_OBJECT, *PCALLBACK_OBJECT; > > +typedef struct _KSPIN_LOCK_QUEUE { > + struct _KSPIN_LOCK_QUEUE volatile *Next; > + volatile PKSPIN_LOCK Lock; Does this really match your Windows header files? In my Win10 header files the volatile is at a different place in both lines above. > +} KSPIN_LOCK_QUEUE, *PKSPIN_LOCK_QUEUE; > + > +typedef struct _KLOCK_QUEUE_HANDLE { > + KSPIN_LOCK_QUEUE LockQueue; > + KIRQL OldIrql; > +} KLOCK_QUEUE_HANDLE, *PKLOCK_QUEUE_HANDLE; > + > typedef NTSTATUS (NTAPI EX_CALLBACK_FUNCTION)(void *CallbackContext, void *Argument1, void *Argument2); > typedef EX_CALLBACK_FUNCTION *PEX_CALLBACK_FUNCTION; > > diff --git a/tools/make_specfiles b/tools/make_specfiles > index 1e2400e..505bdf1 100755 > --- a/tools/make_specfiles > +++ b/tools/make_specfiles > @@ -338,6 +338,10 @@ my @dll_groups = > "bcrypt", > "ncrypt", > ], > + [ > + "ntoskrnl.exe", > + "hal", > + ] > ); > > my $update_flags = 0; > -- 2.10.2 >

2 1

Re: [PATCH] dpnet: IDirectPlay8ThreadPool is a singleton interface.
by Sebastian Lackner 17 Feb '17

17 Feb '17

On 17.02.2017 07:43, Alistair Leslie-Hughes wrote: > - ok(pool1 != pool2, "same pointer returned.\n"); > + todo_wine ok(pool1 != pool2, "same pointer returned.\n"); Well, this test shows that its not implemented as a singleton interface on Windows. Just because part of the state is global doesn't necessarily mean you don't need any interface specific data.

2 1

Re: wined3d: Call wined3d_cs_emit_unload_resource outside of command stream.
by Henri Verbeet 17 Feb '17

17 Feb '17

On 17 February 2017 at 03:47, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > dlls/wined3d/device.c | 15 ++++++++------- > 1 file changed, 8 insertions(+), 7 deletions(-) > Why would you want to do that?

2 2

Re: wined3d: Remove duplicate assignment of NULL to map_ptr in wined3d_buffer_map.
by Henri Verbeet 17 Feb '17

17 Feb '17

On 17 February 2017 at 04:43, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > BTW: Is someone currently working on wined3d_buffer_map? To me it looks like > there are multiple issues related to location handling in there. > The code certainly has issues, at least in part that's because it mostly predates the current resource location management scheme. > * For mappings without !(flags & WINED3D_MAP_READONLY), shouldn't the code invalidate > the sysmem location, to force a download when it is required later? > If you're referring to the case I think you're referring to, no, because WINED3D_BUFFER_PIN_SYSMEM isn't set and the system memory location has been evicted. > * In the "Falling back to doublebuffered operation." case with > !(flags & WINED3D_MAP_READONLY) the buffer location is never invalidated, which > means no upload will happen. For testing purposes, this can be triggered by > replacing the if conditions and running d3d9 visual tests. Adding something like: > buffer->locations &= ~WINED3D_LOCATION_BUFFER; fixes it (using a function would > add the modified range twice). > That path should only be reachable for read-only maps, in which case there's nothing to upload. The general issue that the code is overly complicated and hard to reason about is certainly true though.

1 0

Re: [PATCH v2 5/5] crypt32: Fix wrong Base64 trailer WCHAR constants.
by Alexandre Julliard 16 Feb '17

16 Feb '17

Lauri Kenttä <lauri.kentta(a)gmail.com> writes: > The tests simply check that W and A give the same results. > That wouldn't always happen without this fix. > > v2: Fix buffer overflow. > Signed-off-by: Lauri Kenttä <lauri.kentta(a)gmail.com> It doesn't work here: ../../../tools/runtest -q -P wine -T ../../.. -M crypt32.dll -p crypt32_test.exe.so base64 && touch base64.ok base64.c:315: Test failed: base64 "V=" len 0: W and A differ base64.c:315: Test failed: base64 "VV=" len 0: W and A differ base64.c:315: Test failed: base64 "V==" len 0: W and A differ base64.c:315: Test failed: base64 "V=" len 2: W and A differ base64.c:315: Test failed: base64 "VV=" len 3: W and A differ base64.c:315: Test failed: base64 "V==" len 3: W and A differ Makefile:188: recipe for target 'base64.ok' failed make[1]: *** [base64.ok] Error 6 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] ddraw/tests: Rewrite SrcColorKey32BlitTest.
by Marvin 16 Feb '17

16 Feb '17

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 https://testbot.winehq.org/JobDetails.pl?Key=28707 Your paranoid android. === w8 (32 bit ddraw7) === ddraw7.c:12644: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw7.c:12644: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw7.c:12790: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw7.c:12807: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw7.c:12847: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw7.c:12878: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw7.c:12900: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw7.c:12980: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. === w864 (32 bit ddraw7) === ddraw7.c:12644: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw7.c:12644: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw7.c:12790: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw7.c:12807: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw7.c:12847: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw7.c:12878: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw7.c:12900: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw7.c:12980: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. === w1064 (32 bit ddraw7) === ddraw7.c:12644: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw7.c:12644: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw7.c:12790: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw7.c:12807: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw7.c:12847: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw7.c:12878: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw7.c:12900: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw7.c:12980: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. === w864 (64 bit ddraw7) === ddraw7.c:12644: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw7.c:12644: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw7.c:12790: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw7.c:12807: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw7.c:12847: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw7.c:12878: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw7.c:12900: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw7.c:12980: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. === w1064 (64 bit ddraw7) === ddraw7.c:12644: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw7.c:12644: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw7.c:12790: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw7.c:12807: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw7.c:12847: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw7.c:12878: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw7.c:12900: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw7.c:12980: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. === w8 (32 bit ddraw4) === ddraw4.c:12971: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw4.c:12971: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw4.c:13117: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw4.c:13134: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw4.c:13174: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw4.c:13205: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw4.c:13227: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw4.c:13307: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. === w864 (32 bit ddraw4) === ddraw4.c:12971: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw4.c:12971: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw4.c:13117: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw4.c:13134: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw4.c:13174: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw4.c:13205: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw4.c:13227: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw4.c:13307: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. === w1064 (32 bit ddraw4) === ddraw4.c:12971: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw4.c:12971: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw4.c:13117: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw4.c:13134: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw4.c:13174: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw4.c:13205: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw4.c:13227: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw4.c:13307: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. === w864 (64 bit ddraw4) === ddraw4.c:12971: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw4.c:12971: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw4.c:13117: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw4.c:13134: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw4.c:13174: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw4.c:13205: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw4.c:13227: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw4.c:13307: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. === w1064 (64 bit ddraw4) === ddraw4.c:12971: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw4.c:12971: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw4.c:13117: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw4.c:13134: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw4.c:13174: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw4.c:13205: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw4.c:13227: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw4.c:13307: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. === w8 (32 bit ddraw2) === ddraw2.c:11580: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw2.c:11580: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw2.c:11726: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw2.c:11743: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw2.c:11783: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw2.c:11814: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw2.c:11836: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw2.c:11916: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. === w864 (32 bit ddraw2) === ddraw2.c:11580: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw2.c:11580: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw2.c:11726: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw2.c:11743: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw2.c:11783: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw2.c:11814: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw2.c:11836: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw2.c:11916: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. === w1064 (32 bit ddraw2) === ddraw2.c:11580: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw2.c:11580: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw2.c:11726: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw2.c:11743: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw2.c:11783: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw2.c:11814: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw2.c:11836: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw2.c:11916: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. === w864 (64 bit ddraw2) === ddraw2.c:11580: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw2.c:11580: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw2.c:11726: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw2.c:11743: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw2.c:11783: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw2.c:11814: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw2.c:11836: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw2.c:11916: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. === w1064 (64 bit ddraw2) === ddraw2.c:11580: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw2.c:11580: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw2.c:11726: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw2.c:11743: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw2.c:11783: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw2.c:11814: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw2.c:11836: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw2.c:11916: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. === w8 (32 bit ddraw1) === ddraw1.c:10249: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw1.c:10249: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw1.c:10395: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw1.c:10412: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw1.c:10451: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw1.c:10482: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw1.c:10504: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw1.c:10584: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. === w864 (32 bit ddraw1) === ddraw1.c:10249: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw1.c:10249: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw1.c:10395: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw1.c:10412: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw1.c:10451: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw1.c:10482: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw1.c:10504: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw1.c:10584: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. === w1064 (32 bit ddraw1) === ddraw1.c:10249: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw1.c:10249: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw1.c:10395: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw1.c:10412: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw1.c:10451: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw1.c:10482: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw1.c:10504: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw1.c:10584: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. === w864 (64 bit ddraw1) === ddraw1.c:10249: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw1.c:10249: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw1.c:10395: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw1.c:10412: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw1.c:10451: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw1.c:10482: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw1.c:10504: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw1.c:10584: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. === w1064 (64 bit ddraw1) === ddraw1.c:10249: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw1.c:10249: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw1.c:10395: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw1.c:10412: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw1.c:10451: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw1.c:10482: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw1.c:10504: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw1.c:10584: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000.

1 0

Re: [PATCH 2/3] comctl32/propsheet: Implement PSM_SETHEADERTITLE
by Alexandre Julliard 16 Feb '17

16 Feb '17

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > case PSM_SETHEADERTITLEW: > - PROPSHEET_SetHeaderTitleW(hwnd, (int)wParam, (LPCWSTR)lParam); > - return TRUE; > + PROPSHEET_SetHeaderTitleW(hwnd, wParam, (LPCWSTR)lParam); > + return FALSE; > > case PSM_SETHEADERTITLEA: > - PROPSHEET_SetHeaderTitleA(hwnd, (int)wParam, (LPCSTR)lParam); > - return TRUE; > + PROPSHEET_SetHeaderTitleA(hwnd, wParam, (LPCSTR)lParam); > + return FALSE; Not that it makes much difference, but is there a reason for changing these to returning FALSE? -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH v2] winedevice: Use WINE_RB_FOR_EACH_ENTRY_DESTRUCTOR to free drivers in async_shutdown_drivers.
by Sebastian Lackner 16 Feb '17

16 Feb '17

On 15.02.2017 17:07, Jacek Caban wrote: > + wine_rb_clear( &wine_drivers, NULL, NULL ); This fixes the issue, but passing a non-NULL callback to clear() would crash because the rbtree is temporarily corrupted. In all other places clear() is called to clear the content, not as a replacement for init(). Wouldn't it make more sense to integrate the clearing directly into the macro somehow, if its only used for destructors? You could for example reset ->root immediately after initializating the cursor. Otherwise, if the macro is supposed to be a general purpose postorder iterator, it would make more sense to use a different name.

3 5

Re: [v5 1/2] ntdll: Implement FileIdInformation class support in NtQueryInformationFile.
by Sebastian Lackner 16 Feb '17

16 Feb '17

On 14.02.2017 19:21, Jonathan Doron wrote: > Signed-off-by: Jonathan Doron <jond(a)wizery.com> > --- > dlls/ntdll/file.c | 29 ++++++++++++++++++++++++- > dlls/ntdll/tests/file.c | 56 +++++++++++++++++++++++++++++++++++++++++++++++++ > include/winternl.h | 9 ++++++++ > 3 files changed, 93 insertions(+), 1 deletion(-) I have just sent a series (patch 130340 - 130343) based on your work which implements initial support for FileIdInformation. There are some tasks left, however I believe it is easier for all of us, when the basic stuff is already upstream, and we only have to discuss about the missing pieces. ;) > > diff --git a/dlls/ntdll/file.c b/dlls/ntdll/file.c > index a6c1098..182db56 100644 > --- a/dlls/ntdll/file.c > +++ b/dlls/ntdll/file.c > @@ -2377,7 +2377,7 @@ NTSTATUS WINAPI NtQueryInformationFile( HANDLE hFile, PIO_STATUS_BLOCK io, > 0, /* FileRenameInformationBypassAccessCheck */ > 0, /* FileLinkInformationBypassAccessCheck */ > 0, /* FileVolumeNameInformation */ > - 0, /* FileIdInformation */ > + sizeof(FILE_ID_INFORMATION), /* FileIdInformation */ > 0, /* FileIdExtdDirectoryInformation */ > 0, /* FileReplaceCompletionInformation */ > 0, /* FileHardLinkFullIdInformation */ > @@ -2619,6 +2619,33 @@ NTSTATUS WINAPI NtQueryInformationFile( HANDLE hFile, PIO_STATUS_BLOCK io, > } > } > break; > + case FileIdInformation: > + { > + if (fstat(fd, &st) == -1) > + { > + io->u.Status = FILE_GetNtStatus(); > + } > + else > + { > + FILE_ID_INFORMATION *info = ptr; > +#if defined(HAVE_FSTATFS) > + struct statfs volstats; > + if (fstatfs(fd, &volstats) == -1) > + { > + io->u.Status = FILE_GetNtStatus(); > + break; > + } > + > + memcpy(&info->VolumeSerialNumber, > + &volstats.f_fsid, > + min(sizeof(info->VolumeSerialNumber), sizeof(volstats.f_fsid))); > +#else > + memset(&info->VolumeSerialNumber, 0, sizeof(info->VolumeSerialNumber)); > +#endif It might be fine to implement the volume serial number like that, but I believe it is even more important that all functions return the same information. If its required for your application, please also update kernel32 and other places where it is returned. > + ((LARGE_INTEGER *)&info->FileId)->QuadPart = st.st_ino; > + } > + } > + break; > default: > FIXME("Unsupported class (%d)\n", class); > io->u.Status = STATUS_NOT_IMPLEMENTED; > diff --git a/dlls/ntdll/tests/file.c b/dlls/ntdll/tests/file.c > index 57d7df9..926b8f8 100644 > --- a/dlls/ntdll/tests/file.c > +++ b/dlls/ntdll/tests/file.c > @@ -1444,6 +1444,61 @@ static void test_file_basic_information(void) > CloseHandle( h ); > } > > +static void test_file_id_information(void) > +{ > + IO_STATUS_BLOCK io; > + FILE_ID_INFORMATION fid1, fid2; > + HANDLE h = INVALID_HANDLE_VALUE; > + NTSTATUS res; > + char path[MAX_PATH], buffer[MAX_PATH]; > + > + GetTempPathA(MAX_PATH, path); > + GetTempFileNameA(path, "foo", 0, buffer); > + > + h = CreateFileA(buffer, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, 0); > + ok(h != INVALID_HANDLE_VALUE, "CreateFile error %d\n", GetLastError()); > + > + /* Query the temp file unique id */ > + memset(&fid1, 0, sizeof(fid1)); The memsets with same value hide that some bytes of FileId are uninitialized. > + res = pNtQueryInformationFile(h, &io, &fid1, sizeof(fid1), FileIdInformation); > + if (res == STATUS_NOT_IMPLEMENTED || res == STATUS_INVALID_INFO_CLASS) > + { > + CloseHandle(h); > + DeleteFileA(buffer); > + win_skip("FileIdInformation not supported\n"); > + return; > + } > + > + ok(res == STATUS_SUCCESS, "can't get fid1, res %x\n", res); > + > + CloseHandle(h); > + > + h = CreateFileA(buffer, GENERIC_WRITE, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0); > + ok(h != INVALID_HANDLE_VALUE, "CreateFile error %d\n", GetLastError()); > + > + memset(&fid2, 0, sizeof(fid2)); > + res = pNtQueryInformationFile(h, &io, &fid2, sizeof(fid2), FileIdInformation); > + ok(res == STATUS_SUCCESS, "can't get fid2, res %x\n", res); > + > + /* Verify we got the same unique id for the file */ > + ok(memcmp(&fid1, &fid2, sizeof(fid1)) == 0, "file id is not unique\n"); > + > + CloseHandle(h); > + > + h = create_temp_file(0); > + ok(h != NULL, "error creating new file %d\n", GetLastError()); > + > + memset(&fid2, 0, sizeof(fid2)); > + res = pNtQueryInformationFile(h, &io, &fid2, sizeof(fid2), FileIdInformation); > + ok(res == STATUS_SUCCESS, "can't get new fid2, res %x\n", res); > + > + /* Verify we got the different unique id for the new file */ > + ok(memcmp(&fid1, &fid2, sizeof(fid1)) != 0, "file id is not unique\n"); > + Some of those patches can probably be added again if you want. For now I have only added a test to compare the result with GetFileInformationByHandle. > + CloseHandle(h); > + DeleteFileA(buffer); > +} > + > static void test_file_all_information(void) > { > IO_STATUS_BLOCK io; > @@ -4262,4 +4317,5 @@ START_TEST(file) > test_file_disposition_information(); > test_query_volume_information_file(); > test_query_attribute_information_file(); > + test_file_id_information(); > } > diff --git a/include/winternl.h b/include/winternl.h > index 891b6a7..2f2ea86 100644 > --- a/include/winternl.h > +++ b/include/winternl.h > @@ -571,6 +571,15 @@ typedef struct _FILE_INTERNAL_INFORMATION { > LARGE_INTEGER IndexNumber; > } FILE_INTERNAL_INFORMATION, *PFILE_INTERNAL_INFORMATION; > > +typedef struct _FILE_ID_128 { > + UCHAR Identifier[16]; > +} FILE_ID_128, *PFILE_ID_128; > + > +typedef struct _FILE_ID_INFORMATION { > + ULONGLONG VolumeSerialNumber; > + FILE_ID_128 FileId; > +} FILE_ID_INFORMATION, *PFILE_ID_INFORMATION; > + > typedef struct _FILE_EA_INFORMATION { > ULONG EaSize; > } FILE_EA_INFORMATION, *PFILE_EA_INFORMATION; >

1 0

Re: [PATCH v2 8/9] ddraw/tests: Test ddraw7 CreateSurface with a null descriptor.
by Henri Verbeet 16 Feb '17

16 Feb '17

On 16 February 2017 at 04:46, Alex Henrie <alexhenrie24(a)gmail.com> wrote: > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > dlls/ddraw/tests/ddraw7.c | 5 +++++ > 1 file changed, 5 insertions(+) > Actually, most of this is already covered by both CreateSurfaceBadCapsSizeTest() and create_surface_test() in dsurface.c. Could you cleanup and merge those instead?

1 0

Re: [PATCH v2 8/9] ddraw/tests: Test ddraw7 CreateSurface with a null descriptor.
by Marvin 16 Feb '17

16 Feb '17

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 https://testbot.winehq.org/JobDetails.pl?Key=28673 Your paranoid android. === w864 (32 bit ddraw7) === ddraw7.c:3767: Test failed: Lit quad with light has color 0x00000000. ddraw7.c:3767: Test failed: Lit quad with singular world matrix has color 0x00000000. ddraw7.c:3767: Test failed: Lit quad with transformation matrix has color 0x00000000.

1 0

wine-1.8.7-rc2 Available
by Michael Stefaniuc 15 Feb '17

15 Feb '17

Hello guys, wine-1.8.7-rc2 is now available, including the tag: https://github.com/mstefani/wine-stable https://static-winehq.rhcloud.com/stable/ Changes to rc1: - Removed commit "winex11.drv: Added ThreadDetach entry point and use it instead of DllMain." as it needs a dependency not suitable for Stable. - Added Turkish translations. Thanks to Can Taşan for dealing with the fallout of msgmerge'ing the tr.po from wine-2.0. bye michael

1 0

Re: [PATCH 3/7] ddraw: Fix IDirectDraw_CreateSurface's invalid descriptor error code.
by Henri Verbeet 15 Feb '17

15 Feb '17

On 15 February 2017 at 07:53, Alex Henrie <alexhenrie24(a)gmail.com> wrote: > @@ -3000,7 +3000,7 @@ static HRESULT WINAPI ddraw1_CreateSurface(IDirectDraw *iface, > { > WARN("Application supplied invalid surface descriptor\n"); > wined3d_mutex_unlock(); > - return DDERR_INVALIDPARAMS; > + return E_INVALIDARG; Did you verify the test fails without this change? How is DDERR_INVALIDPARAMS defined?

3 2

Re: winedevice: Use WINE_RB_FOR_EACH_ENTRY_DESTRUCTOR to free drivers in async_shutdown_drivers.
by Sebastian Lackner 15 Feb '17

15 Feb '17

On 15.02.2017 16:47, Jacek Caban wrote: > Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> > --- > programs/winedevice/device.c | 30 +++++++++++++++--------------- > 1 file changed, 15 insertions(+), 15 deletions(-) This isn't really a noop, the previous code also cleared tree->root.

2 1

Re: [PATCH 13/14] rbtree.h: Added WINE_RB_FOR_EACH_DESTRUCTOR and WINE_RB_FOR_EACH_ENTRY_DESTRUCTOR helpers for implementing tree destructors.
by Matteo Bruni 15 Feb '17

15 Feb '17

2017-02-13 21:12 GMT+01:00 Jacek Caban <jacek(a)codeweavers.com>: > Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> > --- > include/wine/rbtree.h | 20 ++++++++++++++------ > 1 file changed, 14 insertions(+), 6 deletions(-) These sound like the _SAFE variants of our list implementation. Any reason not to use the same naming here?

2 3

Re: [PATCH 1/7] ddraw/tests: Test IDirectDraw4_CreateSurface without cooperative level.
by Henri Verbeet 15 Feb '17

15 Feb '17

On 15 February 2017 at 07:53, Alex Henrie <alexhenrie24(a)gmail.com> wrote: > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > dlls/ddraw/tests/ddraw4.c | 6 ++++++ > 1 file changed, 6 insertions(+) > I think this belongs in test_coop_level_surf_create().

1 0

Re: [PATCH 2/8] wined3d: Honor buffer ranges for shader resource views.
by Matteo Bruni 15 Feb '17

15 Feb '17

2017-02-14 13:15 GMT+01:00 Józef Kucia <jkucia(a)codeweavers.com>: > > context_bind_texture(context, GL_TEXTURE_BUFFER, view->name); > - GL_EXTCALL(glTexBuffer(GL_TEXTURE_BUFFER, view_format->glInternal, buffer->buffer_object)); > + if (gl_info->supported[ARB_TEXTURE_BUFFER_RANGE]) > + { > + GL_EXTCALL(glTexBufferRange(GL_TEXTURE_BUFFER, view_format->glInternal, > + buffer->buffer_object, offset, size)); > + } > + else > + { > + if (!offset || size != buffer->resource.size) > + FIXME("OpenGL implementation does not support ARB_texture_buffer_range.\n"); > + GL_EXTCALL(glTexBuffer(GL_TEXTURE_BUFFER, view_format->glInternal, buffer->buffer_object)); > + } I think you want the FIXME if offset is non-zero.

2 1

Re: wine.inf: Add Dynamic DST/{First,Last}Entry registry keys
by Piotr Caban 15 Feb '17

15 Feb '17

On 02/14/17 22:54, Sebastian Lackner wrote: > Is it actually used by apps? If yes, I hope it doesn't cause problems > that we store them in "sparse" format (sometimes years are missing inbetween, > when they match the information in the parent registry key). It's used by mono. Without this patch it crashes in some timezone related functions. I've grepped mono source and the "Dynamic DST" keys are used in 3 places. None of them is correctly handling the missing entries (one returns error on missing entry, others define adjustment rules only for specified years). Thanks, Piotr

1 0

Re: [PATCH 6/7] ddraw: Fix IDirectDraw7_CreateSurface's invalid descriptor error code.
by Marvin 15 Feb '17

15 Feb '17

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 https://testbot.winehq.org/JobDetails.pl?Key=28636 Your paranoid android. === w864 (64 bit ddraw7) === The test timed out

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel