January 2017 - Wine-Devel - list.winehq.org

Re: [PATCH 3/3] windowscodecs: Use source palette if it wasn't specified earlier for PNG frame
by Dmitry Timoshkov Jan. 27, 2017

Jan. 27, 2017

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > @@ -1765,6 +1765,18 @@ static HRESULT WINAPI PngFrameEncode_WriteSource(IWICBitmapFrameEncode *iface, > > if (SUCCEEDED(hr)) > { > + if (This->colors == 0) > + { > + IWICPalette *palette; > + > + if (SUCCEEDED(PaletteImpl_Create(&palette))) > + { > + if (SUCCEEDED(IWICBitmapSource_CopyPalette(pIBitmapSource, palette))) > + IWICBitmapFrameEncode_SetPalette(iface, palette); > + IWICPalette_Release(palette); > + } > + } > + > hr = write_source(iface, pIBitmapSource, prc, > This->format->guid, This->format->bpp, This->width, This->height); > } What is this for? It looks like a workaround for a WIC converter bug. I'd like to see a test case for this behaviour. -- Dmitry.

1 0

Re: [PATCH 1/3] windowscodecs: Implement IWICBitmapFrameEncode::SetPalette in PNG encoder.
by Dmitry Timoshkov Jan. 27, 2017

Jan. 27, 2017

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > From: Dmitry Timoshkov <dmitry(a)baikal.ru> ... > diff --git a/dlls/windowscodecs/tests/converter.c b/dlls/windowscodecs/tests/converter.c > index 2af985785c..9da82f1665 100644 > --- a/dlls/windowscodecs/tests/converter.c > +++ b/dlls/windowscodecs/tests/converter.c > @@ -25,6 +25,7 @@ > #include "windef.h" > #include "objbase.h" > #include "wincodec.h" > +#include "wincodecsdk.h" > #include "wine/test.h" > > typedef struct bitmap_data { > @@ -577,6 +578,50 @@ struct setting { > void *value; > }; > > +#define EXPECT_REF(obj,ref) _expect_ref((IUnknown*)obj, ref, __LINE__) > +static void _expect_ref(IUnknown* obj, ULONG ref, int line) I'd prefer to avoid getting a credit for the code I never had written. -- Dmitry.

1 0

Re: [v3 PATCH 05/10] x86/insn-kernel: Add support to resolve 16-bit addressing encodings (fwd)
by Julia Lawall Jan. 27, 2017

Jan. 27, 2017

Check the type of seg on line 267. julia ---------- Forwarded message ---------- Date: Thu, 26 Jan 2017 05:24:40 +0800 From: kbuild test robot <fengguang.wu(a)intel.com> To: kbuild(a)01.org Cc: Julia Lawall <julia.lawall(a)lip6.fr> Subject: Re: [v3 PATCH 05/10] x86/insn-kernel: Add support to resolve 16-bit addressing encodings In-Reply-To: <20170125202353.101059-6-ricardo.neri-calderon(a)linux.intel.com> Hi Ricardo, [auto build test WARNING on tip/auto-latest] [also build test WARNING on v4.10-rc5 next-20170125] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Ricardo-Neri/x86-Enable-User-Mode-… :::::: branch date: 51 minutes ago :::::: commit date: 51 minutes ago >> arch/x86/lib/insn-kernel.c:267:6-9: WARNING: Unsigned expression compared with zero: seg < 0 git remote add linux-review https://github.com/0day-ci/linux git remote update linux-review git checkout 574de0de238ef30c816985006f02f7a1dbba92aa vim +267 arch/x86/lib/insn-kernel.c 574de0de Ricardo Neri 2017-01-25 251 addr = (seg << 4) + regs_get_register(regs, addr_offset1); 574de0de Ricardo Neri 2017-01-25 252 } else { 574de0de Ricardo Neri 2017-01-25 253 ret = get_reg_offset_16(insn, regs, &addr_offset1, 574de0de Ricardo Neri 2017-01-25 254 &addr_offset2); 574de0de Ricardo Neri 2017-01-25 255 if (ret < 0) 574de0de Ricardo Neri 2017-01-25 256 goto out_err; 574de0de Ricardo Neri 2017-01-25 257 /* 574de0de Ricardo Neri 2017-01-25 258 * Don't fail on invalid offset values. They might be invalid 574de0de Ricardo Neri 2017-01-25 259 * because they are not supported. Instead, use them in the 574de0de Ricardo Neri 2017-01-25 260 * calculation only if they contain a valid value. 574de0de Ricardo Neri 2017-01-25 261 */ 574de0de Ricardo Neri 2017-01-25 262 if (addr_offset1 >= 0) 574de0de Ricardo Neri 2017-01-25 263 addr1 = regs_get_register(regs, addr_offset1); 574de0de Ricardo Neri 2017-01-25 264 if (addr_offset2 >= 0) 574de0de Ricardo Neri 2017-01-25 265 addr2 = regs_get_register(regs, addr_offset2); 574de0de Ricardo Neri 2017-01-25 266 seg = __get_segment_selector_16(regs, insn, addr_offset1); 574de0de Ricardo Neri 2017-01-25 @267 if (seg < 0) 574de0de Ricardo Neri 2017-01-25 268 goto out_err; 574de0de Ricardo Neri 2017-01-25 269 addr = (seg << 4) + addr1 + addr2; 574de0de Ricardo Neri 2017-01-25 270 } 574de0de Ricardo Neri 2017-01-25 271 addr += insn->displacement.value; 574de0de Ricardo Neri 2017-01-25 272 574de0de Ricardo Neri 2017-01-25 273 return (void __user *)addr; 574de0de Ricardo Neri 2017-01-25 274 out_err: 574de0de Ricardo Neri 2017-01-25 275 return (void __user *)-1; --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation

2 1

Re: comctl32: Move prototype to header
by Sebastian Lackner Jan. 26, 2017

Jan. 26, 2017

On 27.01.2017 00:26, André Hentschel wrote: > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> > --- > dlls/comctl32/comctl32.h | 1 + > dlls/comctl32/syslink.c | 2 -- > 2 files changed, 1 insertion(+), 2 deletions(-) > Any specific reason that you don't use include/shlwapi.h ?

2 1

Re: msvideo.dll16: Implement DrawDibProfileDisplay
by Alexandre Julliard Jan. 26, 2017

Jan. 26, 2017

Bruno Jesus <00cpxxx(a)gmail.com> writes: > @@ -35,7 +35,7 @@ > 111 stub DRAWDIBCHANGEPALETTE > 112 pascal -ret16 DrawDibRealize(word word word) DrawDibRealize16 > 113 stub DRAWDIBTIME > -114 stub DRAWDIBPROFILEDISPLAY > +114 pascal -ret16 DrawDibProfileDisplay(segptr) DrawDibProfileDisplay16 segptr is not correct if you pass the pointer to 32-bit code. -- Alexandre Julliard julliard(a)winehq.org

3 3

Performance Testing Wine-1.2-rc4 vs Wine-1.8
by Stefan Dösinger Jan. 26, 2017

Jan. 26, 2017

Hi, After more than a year of break I ran my Wine benchmarking scripts again on one of my two test machines: The iMac5.1 box with a Radeon X1600 GPU. You can see the results and the comparison to the last regular run here: http://openbenchmarking.org/result/1701170-RI-UPDATETES12,1512236-GA-WINE18… The one game that jumps out is Trackmania Nations. It apparently regressed from approx. 32 fps to 24. I will run a bisect in the next days to pinpoint the patch that caused this. The game itself wasn't updated. Other than TMNations there is nothing too surprising. 3DMark2000 and 2001 are slightly slower, Half Life 2 (which surprisingly didn't seem to be changed by Valve since December 2015) is slightly faster. Unigine Heaven, UT2004 and World in Conflict are unchanged. As you can see in the results I updated the kernel, Mesa and Wine separately to see where changes come from (stable interfaces ftw!). The oldkernel_oldmesa_oldwine result differs from the 2015 one in the general update of the system (KDE Desktop, X server, DDX driver, etc). Unfortunately this old machine is the less interesting one of my two test boxes. I still don't have a monitor for my Radeon HD 5700 Desktop. I ordered one a while ago and it should arrive soon. If I have time I'll try to run the tests next week. Cheers, Stefan

2 4

Re: [PATCH] hidclass.sys: When processing reads fill all the buffers
by Sebastian Lackner Jan. 26, 2017

Jan. 26, 2017

On 26.01.2017 13:57, Aric Stewart wrote: > This is a follow-up fix for continuing work on bug 42225 > > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/hidclass.sys/buffer.c | 34 +++++++++++++++++++++++++++++++++- > dlls/hidclass.sys/device.c | 2 +- > dlls/hidclass.sys/hid.h | 3 ++- > 3 files changed, 36 insertions(+), 3 deletions(-) > > > > 0001-hidclass.sys-When-processing-reads-fill-all-the-buffer.txt > > > diff --git a/dlls/hidclass.sys/buffer.c b/dlls/hidclass.sys/buffer.c > index 0b29f97b69..41bbb8e241 100644 > --- a/dlls/hidclass.sys/buffer.c > +++ b/dlls/hidclass.sys/buffer.c > @@ -127,7 +127,7 @@ NTSTATUS RingBuffer_SetSize(struct ReportRingBuffer *ring, UINT size) > return STATUS_SUCCESS; > } > > -void RingBuffer_Read(struct ReportRingBuffer *ring, UINT index, void *output, UINT *size) > +void RingBuffer_ReadNew(struct ReportRingBuffer *ring, UINT index, void *output, UINT *size) > { > void *ret = NULL; > > @@ -155,6 +155,38 @@ void RingBuffer_Read(struct ReportRingBuffer *ring, UINT index, void *output, UI > } > } > > +void RingBuffer_Read(struct ReportRingBuffer *ring, UINT index, void *output, UINT *size) > +{ > + int pointer = ring->pointers[index]; > + void *ret = NULL; > + > + EnterCriticalSection(&ring->lock); > + if (index >= ring->pointer_alloc || ring->pointers[index] == POINTER_UNUSED > + || ring->end == ring->start) > + { > + LeaveCriticalSection(&ring->lock); > + *size = 0; > + return; > + } > + > + if (pointer == ring->end) > + pointer--; > + > + if (pointer < 0) > + pointer = ring->size - 1; > + > + ret = &ring->buffer[pointer * ring->buffer_size]; > + memcpy(output, ret, ring->buffer_size); > + if (pointer == ring->pointers[index]) > + { > + ring->pointers[index]++; > + if (ring->pointers[index] == ring->size) > + ring->pointers[index] = 0; > + } > + LeaveCriticalSection(&ring->lock); > + *size = ring->buffer_size; Have you been able to reproduce a similar behavior on Windows? The new code looks very suspicious and I'm not sure if this is the right approach to fix it. Also please note that this will effectively disable any asynchronous Read requests - HID_Device_read() will always use the first code path when there is at least one package in the ring buffer and never return STATUS_PENDING. > +} > + > UINT RingBuffer_AddPointer(struct ReportRingBuffer *ring) > { > UINT idx; > diff --git a/dlls/hidclass.sys/device.c b/dlls/hidclass.sys/device.c > index b241016e72..d6a0a358e3 100644 > --- a/dlls/hidclass.sys/device.c > +++ b/dlls/hidclass.sys/device.c > @@ -662,7 +662,7 @@ NTSTATUS WINAPI HID_Device_read(DEVICE_OBJECT *device, IRP *irp) > ptr = PtrToUlong( irp->Tail.Overlay.OriginalFileObject->FsContext ); > > irp->IoStatus.Information = 0; > - RingBuffer_Read(ext->ring_buffer, ptr, packet, &buffer_size); > + RingBuffer_ReadNew(ext->ring_buffer, ptr, packet, &buffer_size); > > if (buffer_size) > { > diff --git a/dlls/hidclass.sys/hid.h b/dlls/hidclass.sys/hid.h > index adc547cc43..1829319ccf 100644 > --- a/dlls/hidclass.sys/hid.h > +++ b/dlls/hidclass.sys/hid.h > @@ -62,7 +62,8 @@ typedef struct _BASE_DEVICE_EXTENSION { > void RingBuffer_Write(struct ReportRingBuffer *buffer, void *data) DECLSPEC_HIDDEN; > UINT RingBuffer_AddPointer(struct ReportRingBuffer *buffer) DECLSPEC_HIDDEN; > void RingBuffer_RemovePointer(struct ReportRingBuffer *ring, UINT index) DECLSPEC_HIDDEN; > -void RingBuffer_Read(struct ReportRingBuffer *buffer, UINT index, void *output, UINT *size) DECLSPEC_HIDDEN; > +void RingBuffer_Read(struct ReportRingBuffer *ring, UINT index, void *output, UINT *size) DECLSPEC_HIDDEN; > +void RingBuffer_ReadNew(struct ReportRingBuffer *buffer, UINT index, void *output, UINT *size) DECLSPEC_HIDDEN; > UINT RingBuffer_GetBufferSize(struct ReportRingBuffer *buffer) DECLSPEC_HIDDEN; > UINT RingBuffer_GetSize(struct ReportRingBuffer *buffer) DECLSPEC_HIDDEN; > void RingBuffer_Destroy(struct ReportRingBuffer *buffer) DECLSPEC_HIDDEN; > > >

2 1

DirectX 12 in Wine
by Gabríel Arthúr Pétursson Jan. 25, 2017

Jan. 25, 2017

Hi, I am interested on working on getting DirectX 12 support into Wine. Is there anyone currently working towards that goal that I can get in contact with? With that said, what would an appropriate implementation in Wine look like? DirectX 12 on top of Vulkan seems like an obvious choice. The two APIs are very similar, whereas the DirectX 12 programming model deviates significantly from both OpenGL and DirectX 11. Another approach is to leverage wined3d (i.e. OpenGL + extensions). I don't know to what extent wined3d can be used or needs to be changed in order to support DirectX 12, or if it'd be useful at all. Can anyone shed some light on whether this would be a feasible approach? Thanks.

3 3

A couple unrelated issues
by Rafał Mużyło Jan. 25, 2017

Jan. 25, 2017

Just as the title says, I've got a couple problems/questions that don't have much in common except for "happening in wine". 1. regedit and long REG_BINARY values: the edit control should either be made resizable or scrollable, cause long values just don't fit in the box; as a temporary solution, I've made a hackish patch, that changes the font the control uses (not sure if that's necesarry, but it's just feels more natural to use monospaced font here), makes sure all glyphs get the same space and once the value wraps, if it's a non-integer divide, the last line is correctly placed; 2. alsa/pulseaudio and stream recovery: as in the past, it's hard to tell if it's wine or the underlaying stuff that fails; the problem I'm hearing is that apps sometimes without any apparent reason (as CPU usage isn't all that different than the average) go into '(snd_pcm_recover) underrun occurred' mode and start playing the sounds on much higher rate and then just as randomly (as it's again seemingly not related to CPU usage) recover; it's the randomness that bothers me: both going into the state *and* not recovering for several minutes; would it be possible, if not outright fix that, then for example add a helper app, that the user could manually trigger to force recovery ? 3. err:ntdll:RtlpWaitForCriticalSection wait timed out in thread <nr>, blocked by <nr>, retrying (60 sec): this is an annoyance, sometimes a major one; namely, it happens that I terminate an app by pressing ^C; usually, that works just fine, but every now and then app goes into that unterminatable state and not for those 60 sec (which is horribly long anyway), but pretty much indefinitelly; it really shouldn't do that; this requires a taskmgr or wineboot intervention to close it 4. (somewhat related to the previous) taskmgr could use a little enhancement: when running several apps with the same executable name, it's very hard to tell (impossible ?) how a line from process tab relates to application tab; usually it's not much of a problem, but if point 3 strikes, there's no more entry in the app tab, but the process is still there and you need to guess, which will often be wrong; perhaps the entries in the process tab should print the app name or have an option in the context menu to retrieve it ?

4 6

Re: [PATCH 3/7] d3d11/tests: Add test for interleaved Draw() and Dispatch() calls.
by Henri Verbeet Jan. 25, 2017

Jan. 25, 2017

On 25 January 2017 at 11:17, Józef Kucia <jkucia(a)codeweavers.com> wrote: > Signed-off-by: Józef Kucia <jkucia(a)codeweavers.com> > --- > dlls/d3d11/tests/d3d11.c | 186 +++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 186 insertions(+) > This fails here: d3d11.c:1310: Feature level 0xb000. d3d11.c:6487: Tests skipped: Some AMD drivers have a bug affecting the test. d3d11.c:10104: Compute shader support via SM4 0x1. d3d11.c:11197: Optional format 0x59 - display supported, feature level 0xa100. d3d11.c:11197: Optional format 0x59 - display supported, feature level 0xa000. d3d11.c:12628: Test failed: Got 0x00000000, expected 0xffffffff at (0, 0), sub-resource 0. d3d11: 7402 tests executed (0 marked as todo, 1 failure), 1 skipped. It also takes a long time to run; it might be hanging the GPU.

2 1

Post-release
by Alexandre Julliard Jan. 25, 2017

Jan. 25, 2017

Congrats to everybody for the 2.0 release! I'm particularly pleased with the progress we've made on fixing regressions, I didn't expect we'd get that many. Thanks all! The master branch is now open for development again. I'll go through the patches that are still in the queue, but please resend any patch that had been marked Deferred. I'll also resume the biweekly development release cycle, starting with release 2.1 on February 3rd. Despite fierce competition, Michael Stefaniuc once again took the coveted job of Stable Branch Maintainer. He'll be making regular 2.0.x releases. I've also implemented the patch reviewer assignment scheme that we discussed at WineConf. From now on, patches that stay in the queue unreviewed for a week will be assigned a reviewer automatically. The algorithm is prioritizing people who said they have some knowledge about the area (the P: entries in the MAINTAINERS file), before grabbing someone at random from the wildcard entry. If you feel that there are areas where you could help reviewing patches, but don't feel comfortable putting yourself up as maintainer, please consider adding an entry for yourself as a knowledgeable person. If you are asked to review a patch, and you think it looks good but don't feel that you know enough to sign off on it, please just send a reply saying "looks OK to me" or something like that. I may then ask someone else to have a further look, or do it myself. Any review helps, even without a full signoff. Looking forward to 3.0 :-) -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: rstrtmgr: add RmShutdown stub (resend)
by Sebastian Lackner Jan. 25, 2017

Jan. 25, 2017

On 25.01.2017 06:28, Austin English wrote: > CC: Sebastian Lackner <sebastian(a)fds-team.de> > > Supersedes https://source.winehq.org/patches/data/128639 > > Fixes https://bugs.winehq.org/show_bug.cgi?id=42093 > > Staged, https://github.com/wine-compholio/wine-staging/commit/b013afa66065427110c02… > > -- -Austin GPG: 14FB D7EA A041 937B > > > 0001-rstrtmgr-add-RmShutdown-stub-resend.patch > > > From fab99f2f9e398978461af053b38aa9b06b7bdc1d Mon Sep 17 00:00:00 2001 > From: Austin English <austinenglish(a)gmail.com> > Date: Wed, 28 Dec 2016 02:18:13 -0600 > Subject: [PATCH] rstrtmgr: add RmShutdown stub (resend) > > Signed-off-by: Austin English <austinenglish(a)gmail.com> > --- > dlls/rstrtmgr/main.c | 9 +++++++++ > dlls/rstrtmgr/rstrtmgr.spec | 2 +- > include/restartmanager.h | 3 +++ > 3 files changed, 13 insertions(+), 1 deletion(-) > > diff --git a/dlls/rstrtmgr/main.c b/dlls/rstrtmgr/main.c > index 2d45639..5c9a8dc 100644 > --- a/dlls/rstrtmgr/main.c > +++ b/dlls/rstrtmgr/main.c > @@ -100,3 +100,12 @@ DWORD WINAPI RmEndSession(DWORD handle) > FIXME("%u stub!\n", handle); > return ERROR_CALL_NOT_IMPLEMENTED; > } > + > +/*********************************************************************** > + * RmShutdown (rstrtmgr.@) > + */ > +DWORD WINAPI RmShutdown(DWORD handle, ULONG flags, RM_WRITE_STATUS_CALLBACK status) > +{ > + FIXME("%u, 0x%08x, %p stub!\n", handle, flags, status); > + return ERROR_CALL_NOT_IMPLEMENTED; > +} > diff --git a/dlls/rstrtmgr/rstrtmgr.spec b/dlls/rstrtmgr/rstrtmgr.spec > index 0e1ba79..6c6a9c9 100644 > --- a/dlls/rstrtmgr/rstrtmgr.spec > +++ b/dlls/rstrtmgr/rstrtmgr.spec > @@ -8,5 +8,5 @@ > @ stub RmRemoveFilter > @ stub RmReserveHeap > @ stdcall RmRestart(long long ptr) > -@ stub RmShutdown > +@ stdcall RmShutdown(long long ptr) > @ stdcall RmStartSession(ptr long ptr) > diff --git a/include/restartmanager.h b/include/restartmanager.h > index 27c1a92..51867a3 100644 > --- a/include/restartmanager.h > +++ b/include/restartmanager.h > @@ -64,6 +64,9 @@ typedef struct { > BOOL bRestartable; > } RM_PROCESS_INFO, *PRM_PROCESS_INFO; > > + > +typedef void *RM_WRITE_STATUS_CALLBACK(UINT); The calling convention is missing here, please see the staged version how it should look like. > + > #ifdef __cplusplus > } > #endif > -- 2.10.2 >

1 0

Re: [resend 2/3] ntdll: Implement FileIdInformation class support in NtQueryInformationFile.
by Sebastian Lackner Jan. 25, 2017

Jan. 25, 2017

On 25.01.2017 04:57, Jonathan Doron wrote: > + ((PLARGE_INTEGER)&info->VolumeSerialNumber)->LowPart = (ULONG)volstats.f_fsid.__val[0]; > + ((PLARGE_INTEGER)&info->VolumeSerialNumber)->HighPart = (ULONG)volstats.f_fsid.__val[1]; Accessing members of f_fsid is not cross-platform compatible - you will either have to find a better way to get this information, or at least add corresponding checks to configure.ac. For more information see: https://linux.die.net/man/2/fstatfs """Nobody knows what f_fsid is supposed to contain (but see below).""" """Solaris, Irix and POSIX have a system call statvfs(2) that returns a struct statvfs (defined in <sys/statvfs.h>) containing an unsigned long f_fsid. Linux, SunOS, HP-UX, 4.4BSD have a system call statfs() that returns a struct statfs (defined in <sys/vfs.h>) containing a fsid_t f_fsid, where fsid_t is defined as struct { int val[2]; }."""

1 0

Re: [PATCH resend] user32: Also remove WM_CHAR from queue when a menu gets VK_ESCAPE and add tests
by Dmitry Timoshkov Jan. 25, 2017

Jan. 25, 2017

Fabian Maurer <dark.shadow4(a)web.de> wrote: > +/* Test handling of VK_ESCAPE to close the menu */ > +static LRESULT WINAPI esc_test_wnd_proc(HWND hwnd, UINT msg, WPARAM wparam, LPARAM lparam) > +{ > + if(msg == WM_SHOWWINDOW) > + { > + PostMessageW(hwnd, WM_KEYDOWN, VK_ESCAPE, 0); > + HMENU hPopupMenu = CreatePopupMenu(); > + InsertMenuA(hPopupMenu, 0, MF_STRING, 10, "test"); > + TrackPopupMenu(hPopupMenu, 0, 0, 0, 0, hwnd, NULL); > + PostQuitMessage(0); > + } > + > + if(msg == WM_CHAR || msg == WM_KEYDOWN) > + ok(0, "Wrong VK_ESCAPE press detected.\n"); > + > + return DefWindowProcA(hwnd, msg, wparam, lparam); > +} Please add a test to msg.c instead. This should be a normal TrackPopupMenu test not wrapped inside of a parent's WM_SHOWWINDOW message handler. Once there is a message test, and the underlying behaviour is well understood a patch with a fix could be sent separately. -- Dmitry.

1 0

Re: [PATCH] gdi32: Add traces for painting functions
by Huw Davies Jan. 25, 2017

Jan. 25, 2017

On Sat, Jan 21, 2017 at 06:45:31PM +0100, Fabian Maurer wrote: > Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de> > --- > dlls/gdi32/painting.c | 56 +++++++++++++++++++++++++++++++++++++++++++++++---- > 1 file changed, 52 insertions(+), 4 deletions(-) I would suggest printing the point-like terms in the same way as wine_dbgstr_point() and the rect-like terms in the same way as wine_dbgstr_rect(). > @@ -237,6 +237,8 @@ BOOL WINAPI LineTo( HDC hdc, INT x, INT y ) > PHYSDEV physdev; > BOOL ret; > > + TRACE( "%p, %d, %d\n", hdc, x, y ); So this would be: TRACE( "%p, (%d,%d)\n", hdc, x, y ); > @@ -288,6 +292,8 @@ BOOL WINAPI Arc( HDC hdc, INT left, INT top, INT right, > BOOL ret; > DC * dc = get_dc_ptr( hdc ); > > + TRACE( "%p, %d, %d, %d, %d, %d, %d, %d, %d\n", hdc, left, top, right, bottom, xstart, ystart, xend, yend ); And this would be: TRACE( "%p, (%d,%d)-(%d,%d), (%d,%d), (%d,%d)\n", hdc, left, top, right, bottom, xstart, ystart, xend, yend ); > @@ -421,6 +437,8 @@ BOOL WINAPI RoundRect( HDC hdc, INT left, INT top, INT right, > BOOL ret; > DC *dc = get_dc_ptr( hdc ); > > + TRACE( "%p, %d, %d, %d, %d, %d, %d\n", hdc, left, top, right, bottom, ell_width, ell_height ); A size-like term could be: TRACE( "%p, (%d,%d)-(%d,%d), %dx%d\n", hdc, left, top, right, bottom, ell_width, ell_height ); > @@ -702,6 +738,8 @@ BOOL WINAPI ExtFloodFill( HDC hdc, INT x, INT y, COLORREF color, > BOOL ret; > DC * dc = get_dc_ptr( hdc ); > > + TRACE( "%p, %d, %d, %x, %x\n", hdc, x, y, color, fillType ); color should be %08x Huw.

2 1

Code freeze
by Fabian Maurer Jan. 25, 2017

Jan. 25, 2017

Hello, Now that wine 2.0 is released, does this mark the end of code-freeze or should we still wait before sending in patches like normally? Regards, Fabian

2 1

Re: [PATCH] shell32: Implement knownfolder_GetRedirectionCapabilities somewhat
by Nikolay Sivov Jan. 24, 2017

Jan. 24, 2017

On 23.01.2017 23:10, Enrico Horn wrote: > This is the one thing missing to get the config app for Temple+, a > Temple of Elemental Evil Mod, starting. > --- > dlls/shell32/shellpath.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/dlls/shell32/shellpath.c b/dlls/shell32/shellpath.c > index 92306239db7..3c44ecb393a 100644 > --- a/dlls/shell32/shellpath.c > +++ b/dlls/shell32/shellpath.c > @@ -5396,8 +5396,9 @@ static HRESULT WINAPI knownfolder_GetRedirectionCapabilities( > IKnownFolder *iface, > KF_REDIRECTION_CAPABILITIES *pCapabilities) > { > - FIXME("%p\n", pCapabilities); > - return E_NOTIMPL; > + FIXME("%p - always denied\n", pCapabilities); > + *pCapabilities = KF_REDIRECTION_CAPABILITIES_DENY_ALL; > + return S_OK; > } > > static HRESULT WINAPI knownfolder_GetFolderDefinition( > Do we have an open bug for that? If it's just a matter of returning static data, it's trivial to fix without any hacks.

2 1

RFC: Flushing the test reports
by Francois Gouget Jan. 24, 2017

Jan. 24, 2017

When a test causes Windows to crash the test output is often lost, even if it was redirected to a file : said file is often either 0-byte long or is missing a huge chunk. This is particularly annoying when the crash happens as part of WineTest as then one has to manually run a bunch of tests to try and find which one caused the issue. And it's not always which test caused the crash as shown by the rasapi32:rasapi case (bug 42185). So I have tested a couple of approaches to better pinpoint which test is causing trouble, and possibly even which chunk of code in that test causes the crash. The first approach is simple: flush the WineTest report to disk between each test (in Unix terms sync). It has little impact on performance and in case of a crash the last 'dll:test start' line would clearly identify the test responsible. diff --git a/programs/winetest/main.c b/programs/winetest/main.c index 50ebf4fd52a..df527734bb8 100644 --- a/programs/winetest/main.c +++ b/programs/winetest/main.c @@ -626,6 +626,11 @@ run_ex (char *cmd, HANDLE out_file, const char *tempdir, DWORD ms) PROCESS_INFORMATION pi; DWORD wait, status; + /* Flush to disk so we know which test caused Windows to crash if it does */ + if (out_file) + FlushFileBuffers(out_file); + FlushFileBuffers(GetStdHandle( STD_ERROR_HANDLE )); + GetStartupInfoA (&si); si.dwFlags = STARTF_USESTDHANDLES; si.hStdInput = GetStdHandle( STD_INPUT_HANDLE ); (the second flush is so WineTest's output too is flushed to disk in case stdout is redirected to a file though I did not really check that this part works) Another approach is to add these calls in wine/test.h. This narrows the location of the Windows crash down to an ok()/trace() interval, even more narrow if WINETEST_REPORT_SUCCESS is set. However this has quite an impact on performance: * WineTest normally takes about 19 minutes. * With the extra flushing this goes up to 29 minutes. * With no flushing but report success I get 45 minutes. * With both flushing and report success this shoots up to 315+ minutes. The report success cases can be ignored but even in the normal case the extra 10 minutes are probably not acceptable. So I set the flushing code behind a $WINETEST_FLUSH check. So once you've identified that, for instance, rasapi32:rasapi is causing trouble, you can run it on its own with report success and flushing to pinpoint where it goes wrong. Of course on the TestBot you still won't get the report (until the TestBot is changed appropriately), and you'll have to contend with the 2 minutes timeout but even with those options 88% of the tests completed within the time limit on my machine. That approach could be done with the patch below. commit ef211f6480fe84fd7660314c27bcaa5630dd0c16 Author: Francois Gouget <fgouget(a)codeweavers.com> Date: Sun Jan 22 02:57:23 2017 +0100 tests: Flush after each message if WINETEST_FLUSH is set. Signed-off-by: Francois Gouget <fgouget(a)codeweavers.com> diff --git a/include/wine/test.h b/include/wine/test.h index aa89c55ca07..149b0a9ae14 100644 --- a/include/wine/test.h +++ b/include/wine/test.h @@ -52,6 +52,9 @@ extern int winetest_debug; /* running in interactive mode? */ extern int winetest_interactive; +/* flush after each trace */ +extern int winetest_flush; + /* current platform */ extern const char *winetest_platform; @@ -199,6 +202,9 @@ int winetest_debug = 1; /* interactive mode? */ int winetest_interactive = 0; +/* flush to disk after every message? */ +int winetest_flush = 0; + /* current platform */ const char *winetest_platform = "windows"; @@ -291,6 +297,11 @@ int broken( int condition ) { return (strcmp(winetest_platform, "windows") == 0) && condition; } +static void winetest_do_flush( void ) +{ + if (winetest_flush) + FlushFileBuffers(GetStdHandle( STD_ERROR_HANDLE )); +} /* * Checks condition. @@ -313,6 +324,7 @@ int winetest_vok( int condition, const char *msg, __winetest_va_list args ) printf( "%s:%d: Test succeeded inside todo block: ", data->current_file, data->current_line ); vprintf(msg, args); + winetest_do_flush(); InterlockedIncrement(&todo_failures); return 0; } @@ -323,6 +335,7 @@ int winetest_vok( int condition, const char *msg, __winetest_va_list args ) printf( "%s:%d: Test marked todo: ", data->current_file, data->current_line ); vprintf(msg, args); + winetest_do_flush(); } InterlockedIncrement(&todo_successes); return 1; @@ -335,14 +348,18 @@ int winetest_vok( int condition, const char *msg, __winetest_va_list args ) printf( "%s:%d: Test failed: ", data->current_file, data->current_line ); vprintf(msg, args); + winetest_do_flush(); InterlockedIncrement(&failures); return 0; } else { if (report_success) + { printf( "%s:%d: Test succeeded\n", data->current_file, data->current_line); + winetest_do_flush(); + } InterlockedIncrement(&successes); return 1; } @@ -369,6 +386,7 @@ void __winetest_cdecl winetest_trace( const char *msg, ... ) __winetest_va_start(valist, msg); vprintf(msg, valist); __winetest_va_end(valist); + winetest_do_flush(); } } @@ -378,6 +396,7 @@ void winetest_vskip( const char *msg, __winetest_va_list args ) printf( "%s:%d: Tests skipped: ", data->current_file, data->current_line ); vprintf(msg, args); + winetest_do_flush(); skipped++; } @@ -443,7 +462,10 @@ void winetest_wait_child_process( HANDLE process ) DWORD exit_code = 1; if (WaitForSingleObject( process, 30000 )) + { printf( "%s: child process wait failed\n", current_test->name ); + winetest_do_flush(); + } else GetExitCodeProcess( process, &exit_code ); @@ -452,12 +474,14 @@ void winetest_wait_child_process( HANDLE process ) if (exit_code > 255) { printf( "%s: exception 0x%08x in child process\n", current_test->name, exit_code ); + winetest_do_flush(); InterlockedIncrement( &failures ); } else { printf( "%s: %u failures in child process\n", current_test->name, exit_code ); + winetest_do_flush(); while (exit_code-- > 0) InterlockedIncrement(&failures); } @@ -599,6 +623,7 @@ static int run_test( const char *name ) todo_successes, failures + todo_failures, (failures + todo_failures != 1) ? "failures" : "failure", skipped ); + winetest_do_flush(); } status = (failures + todo_failures < 255) ? failures + todo_failures : 255; return status; @@ -624,6 +649,7 @@ static LONG CALLBACK exc_filter( EXCEPTION_POINTERS *ptrs ) printf( "%s: unhandled exception %08x at %p\n", current_test->name, ptrs->ExceptionRecord->ExceptionCode, ptrs->ExceptionRecord->ExceptionAddress ); fflush( stdout ); + winetest_do_flush(); return EXCEPTION_EXECUTE_HANDLER; } @@ -660,6 +686,7 @@ int main( int argc, char **argv ) if (GetEnvironmentVariableA( "WINETEST_IS_CHILD", p, sizeof(p) )) winetest_is_child = atoi(p); /* Identify any future process as a child of this one */ SetEnvironmentVariableA( "WINETEST_IS_CHILD", "1" ); + if (GetEnvironmentVariableA( "WINETEST_FLUSH", p, sizeof(p) )) winetest_flush = atoi(p); if (!strcmp( winetest_platform, "windows" )) SetUnhandledExceptionFilter( exc_filter ); if (!winetest_interactive) SetErrorMode( SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX ); Both approaches could be combined. Comments? Suggestions? -- Francois Gouget <fgouget(a)codeweavers.com>

1 0

Re: [PATCH] winegstreamer: Avoid zero division in amt_from_gst_caps_video().
by Andrew Eikum Jan. 24, 2017

Jan. 24, 2017

Hi Masanori, Thank you for working on this! We're late in code freeze right now, can you please re-submit this patch after Wine 2.0 is released? Also, it would be better to use the MulDiv function to avoid integer overflow: vih->AvgTimePerFrame = (nom == 0) ? 0 : MulDiv(10000000, denom, nom); Andrew On Mon, Jan 23, 2017 at 10:29:19PM +0900, Masanori Kakura wrote: > Fixes https://bugs.winehq.org/show_bug.cgi?id=42212 > > Signed-off-by: Masanori Kakura <kakurasan(a)gmail.com> > --- > dlls/winegstreamer/gstdemux.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/dlls/winegstreamer/gstdemux.c b/dlls/winegstreamer/gstdemux.c > index c33ed9e..14ee584 100644 > --- a/dlls/winegstreamer/gstdemux.c > +++ b/dlls/winegstreamer/gstdemux.c > @@ -233,9 +233,7 @@ static gboolean amt_from_gst_caps_video(GstCaps *caps, AM_MEDIA_TYPE *amt) > bih->biCompression = amt->subtype.Data1; > } > bih->biSizeImage = width * height * bih->biBitCount / 8; > - vih->AvgTimePerFrame = 10000000; > - vih->AvgTimePerFrame *= denom; > - vih->AvgTimePerFrame /= nom; > + vih->AvgTimePerFrame = (nom == 0) ? 0 : 10000000 * denom / nom; > vih->rcSource.left = 0; > vih->rcSource.right = width; > vih->rcSource.top = height; > -- > 2.9.3 > > >

1 0

Re: dinput: Silence some effects feedback in linuxinput
by Andrew Eikum Jan. 24, 2017

Jan. 24, 2017

Instead of adding new cases, would you be opposed to just changing the FIXME into a TRACE or maybe a WARN? I think that would scale better, and users are likely only interested if they're doing dinput development anyway. Andrew

2 1

Re: [PATCH] Rename Mac OS X to macOS
by Nikolay Sivov Jan. 23, 2017

Jan. 23, 2017

On 23.01.2017 22:19, André Hentschel wrote: > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> > --- > en/winedev-multimedia.sgml | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/en/winedev-multimedia.sgml b/en/winedev-multimedia.sgml > index fa04b04..4c95349 100644 > --- a/en/winedev-multimedia.sgml > +++ b/en/winedev-multimedia.sgml > @@ -330,7 +330,7 @@ Kernel space | Client applications > </listitem> > <listitem> > <para> > - Core Audio as introduced in Mac OS X 10.3. Source code resides in > + Core Audio as introduced in macOS 10.3. Source code resides in > <filename class="libraryfile">dlls/winecoreaudio.drv</filename>. > </para> > </listitem> > 10.3 was before macOS renaming, so original sounds better to me.

2 1

Re: [PATCH] programs/winhlp32: Use noyywrap for macro.lex.l
by Fabian Maurer Jan. 23, 2017

Jan. 23, 2017

On Sunday, January 22, 2017 11:00:26 AM CET Mike Swanson wrote: > diff --git a/programs/winhlp32/macro.lex.l b/programs/winhlp32/macro.lex.l > index 8f6945ca98..ff8a4832d3 100644 > --- a/programs/winhlp32/macro.lex.l > +++ b/programs/winhlp32/macro.lex.l > @@ -20,7 +20,7 @@ > * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, > USA */ > %} > -%option noinput nounput never-interactive 8bit > +%option noinput nounput noyywrap never-interactive 8bit > %x quote > %{ > #include "config.h" > @@ -367,7 +367,3 @@ WINHELP_WINDOW* MACRO_CurrentWindow(void) > { > return lex_data ? lex_data->window : Globals.active_win; > } > - > -#ifndef yywrap > -int yywrap(void) { return 1; } > -#endif > -- > 2.11.0 Hello, I applied the patch and it compiles now, but I get a warning: > macro.lex.yy.c:398:0: warning: "yywrap" redefined > macro.lex.yy.c:74:0: note: this is the location of the previous definition You probably want to get rid of that, too. Regards, Fabian

4 5

Re: [PATCH] ws2_32/tests: Fix memcmp size in test_TransmitFile().
by Bruno Jesus Jan. 23, 2017

Jan. 23, 2017

On Fri, Jan 20, 2017 at 5:54 PM, Zebediah Figura <z.figura12(a)gmail.com> wrote: > Fixes https://bugs.winehq.org/show_bug.cgi?id=42221 > > Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com> > --- > dlls/ws2_32/tests/sock.c | 12 ++++++------ > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/dlls/ws2_32/tests/sock.c b/dlls/ws2_32/tests/sock.c > index 5856718..3c3e443 100644 > --- a/dlls/ws2_32/tests/sock.c > +++ b/dlls/ws2_32/tests/sock.c > @@ -8304,9 +8304,9 @@ static void test_TransmitFile(void) > iret = recv(dest, buf, sizeof(buf), 0); > ok(iret == sizeof(header_msg)+sizeof(footer_msg)+2, > "Returned an unexpected buffer from TransmitFile: %d\n", iret ); > - ok(memcmp(&buf[0], &header_msg[0], sizeof(header_msg)+1) == 0, > + ok(memcmp(&buf[0], &header_msg[0], sizeof(header_msg)) == 0, > "TransmitFile header buffer did not match!\n"); > - ok(memcmp(&buf[sizeof(header_msg)+1], &footer_msg[0], sizeof(footer_msg)+1) == 0, > + ok(memcmp(&buf[sizeof(header_msg)+1], &footer_msg[0], sizeof(footer_msg)) == 0, > "TransmitFile footer buffer did not match!\n"); Hi, you also have to change the sending lengths because it is also using +1. I believe this was a strlen/sizeof misfortune, right? Best wishes, Bruno

3 4

Re: server: Remove dead check in is_cpu_supported().
by Henri Verbeet Jan. 22, 2017

Jan. 22, 2017

For what it's worth, On 21 January 2017 at 16:25, Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > I am wondering about the following piece of code in server/thread.c: > > int is_cpu_supported( enum cpu_type cpu ) > { > unsigned int prefix_cpu_mask = get_prefix_cpu_mask(); > > if (CPU_FLAG(cpu) && (supported_cpus & prefix_cpu_mask & CPU_FLAG(cpu))) return 1; > > that was added as part of > > commit 1e78c99388c61d353cf60787eac6415328f54560 > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Fri Nov 22 12:32:48 2013 +0100 > > kernel32: Validate the architecture of newly created processes on the server side. > It's actually older than that, and seems to have been introduced by commit 279defe66e1265eeae3e2a72126c2b2f75e20c99 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Fri Apr 3 14:59:12 2009 +0200 server: Verify that the client is using a supported CPU type. > That means CPU_FLAG(...) is always positive and different from zero > -- unless its parameter is 32 or higher on a 32-bit architecture > (and the 1 shifts out). > But the definition of CPU_FLAG doesn't really matter for this. If "CPU_FLAG(cpu)" evaluates to zero, "supported_cpus & prefix_cpu_mask & CPU_FLAG(cpu)" evaluates to zero as well.

2 1

Re: [PATCH] ws2_32/tests: Fix memcmp size in test_TransmitFile().
by Marvin Jan. 22, 2017

Jan. 22, 2017

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=27913 Your paranoid android. === w8 (32 bit sock) === sock.c:7995: Test failed: bytesReturned isn't supposed to be 1 sock.c:8019: Test failed: GetOverlappedResult failed, error 0

1 0