- wine-devel - winehq.org

Re: [2/7] webservices: Add an index to the static dictionary.
by Alexandre Julliard 29 Jun '17

29 Jun '17

Hans Leidekker <hans(a)codeweavers.com> writes: > +static const ULONG dict_sorted[] = > +{ > + 81, 91, 129, 314, 185, 164, 346, 66, 235, 305, 14, 6, 114, 97, 96, 94, 11, 95, 110, 451, > + 443, 121, 213, 7, 71, 82, 431, 343, 74, 75, 73, 59, 447, 445, 467, 163, 472, 463, 453, 409, Why is it so large? Shouldn't it be the same size as the strings array? -- Alexandre Julliard julliard(a)winehq.org

2 1

What are the -l options I should be using to assure I am using the Wine Staging 2.10 versions of the standard system libraries?
by Alan W. Irwin 28 Jun '17

28 Jun '17

In the past (in the Wine 1.6 era) I used an old snapshot (4.7.2) of MinGW/MSYS on wine to build applications with success, and I would like to stick with that snapshot for Wine Staging 2.10 since I have found in the past later versions of MinGW/MSYS were not as reliable as 4.7.2. However, since that snapshot was initially installed with Wine 1.6 (or maybe even earlier) I assume its default header locations and library locations refer to some old wine version, and the general question is how do I override those to refer to the equivalent Wine Staging 2.10 locations. I have a simple test programme (attached) that illustrates the problem: bash.exe-3.1$ g++ /z/home/wine/wine_staging/test_rand_s.cxx z:/home/wine/wine_staging/test_rand_s.cxx: In function 'int main()': z:/home/wine/wine_staging/test_rand_s.cxx:18:5: error: 'errno_t' was not declared in this scope z:/home/wine/wine_staging/test_rand_s.cxx:18:21: error: expected ';' before 'err' z:/home/wine/wine_staging/test_rand_s.cxx:23:9: error: 'err' was not declared in this scope z:/home/wine/wine_staging/test_rand_s.cxx:23:31: error: 'rand_s' was not declared in this scope z:/home/wine/wine_staging/test_rand_s.cxx:26:53: error: 'printf_s' was not declared in this scope z:/home/wine/wine_staging/test_rand_s.cxx:29:60: error: 'printf_s' was not declared in this scope z:/home/wine/wine_staging/test_rand_s.cxx:32:18: error: 'printf_s' was not declared in this scope z:/home/wine/wine_staging/test_rand_s.cxx:37:9: error: 'err' was not declared in this scope z:/home/wine/wine_staging/test_rand_s.cxx:37:31: error: 'rand_s' was not declared in this scope (I presume those errors are due to those functions not being defined by Wine way back when). That compile issue is solved as follows: bash.exe-3.1$ g++ /z/home/wine/wine_staging/test_rand_s.cxx -I/z/opt/wine-staging/include/wine/msvcrt -I/z/opt/wine-staging/in clude/wine/windows C:\users\wine\Temp\cckTYgsp.o:test_rand_s.cxx:(.text+0x35): undefined reference to `rand_s' C:\users\wine\Temp\cckTYgsp.o:test_rand_s.cxx:(.text+0x4c): undefined reference to `printf_s' C:\users\wine\Temp\cckTYgsp.o:test_rand_s.cxx:(.text+0xa6): undefined reference to `printf_s' C:\users\wine\Temp\cckTYgsp.o:test_rand_s.cxx:(.text+0xc6): undefined reference to `printf_s' C:\users\wine\Temp\cckTYgsp.o:test_rand_s.cxx:(.text+0xdc): undefined reference to `rand_s' C:\users\wine\Temp\cckTYgsp.o:test_rand_s.cxx:(.text+0xf3): undefined reference to `printf_s' C:\users\wine\Temp\cckTYgsp.o:test_rand_s.cxx:(.text+0x124): undefined reference to `printf_s' z:/home/wine/wine_staging/mingw-4.7.2/bin/../lib/gcc/mingw32/4.7.2/../../../../mingw32/bin/ld.exe: C:\users\wine\Temp\cckTYgsp .o: bad reloc address 0x13 in section `.eh_frame' z:/home/wine/wine_staging/mingw-4.7.2/bin/../lib/gcc/mingw32/4.7.2/../../../../mingw32/bin/ld.exe: final link failed: Invalid operation collect2.exe: error: ld returned 1 exit status However, that compile fix obviously leaves the above link issue which I attempted to solve by appending the options -L/z/opt/wine-staging/lib/wine -lmsvcrt which worked (in the sense that that library was found) but apparently that particular library does not implement rand_s and printf_s since the same link errors occurred as above. So what are the -l options I should be using to assure I am using the Wine Staging 2.10 versions of the standard system libraries? N.B. I realize this issue would likely be taken care of automatically if I installed the latest version of MinGW/MSYS on the Wine Staging 2.10 platform. But I have my reasons explained above why I would prefer to use the 4.7.2 snapshot of MinGW/MSYS instead. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________

1 0

Re: [6/6] wsdapi/tests: Add tests for WSDXMLGetValueFromAny.
by Marvin 28 Jun '17

28 Jun '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=31935 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [4/6] wsdapi: Implement IWSDUdpAddress_Get/SetSockAddr.
by Marvin 28 Jun '17

28 Jun '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=31934 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [3/6] wsdapi: Implement IWSDUdpAddress_Get/SetMessageType.
by Marvin 28 Jun '17

28 Jun '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=31933 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [2/6] wsdapi: Implement IWSDUdpAddress_Get/SetPort.
by Marvin 28 Jun '17

28 Jun '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=31932 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [1/6] wsdapi: Implement IWSDUdpAddress_GetTransportAddress[Ex].
by Marvin 28 Jun '17

28 Jun '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=31931 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 3/3] gdiplus: Add partial support for GdipDrawImagePointsRect on metafile
by Vincent Povirk 28 Jun '17

28 Jun '17

Can we keep the code for generating an EmfplusImage structure separate from this? We'll want to reuse it for EmfPlusDrawImage and EmfPlusTextureBrushOptionalData.

2 1

Re: [PATCH v2] gdiplus: Scale widened dashes to the pen width.
by Vincent Povirk 28 Jun '17

28 Jun '17

I don't understand this part. On Tue, Jun 27, 2017 at 5:27 PM, Zebediah Figura <z.figura12(a)gmail.com> wrote: > @@ -2175,8 +2182,7 @@ static void widen_dashed_figure(GpPath *path, GpPen *pen, int start, int end, > if (dash_index % 2 == 0 && num_tmp_points != 0) > { > /* last dash overflows last segment */ > - tmp_points[num_tmp_points] = path->pathdata.Points[end]; > - widen_open_figure(tmp_points, pen, 0, num_tmp_points, > + widen_open_figure(tmp_points, pen, 0, num_tmp_points-1, > draw_start_cap ? pen->startcap : LineCapFlat, pen->customstart, > closed ? LineCapFlat : pen->endcap, pen->customend, last_point); > }

2 1

WineConf RSVP
by Jacek Caban 28 Jun '17

28 Jun '17

Hi all, Jeremy has set up RSVP page for this year conference: https://www.winehq.org/wineconf/rsvp Please fill the form if you're planning to attend. The pool of rooms for participants is reserved until middle of October. However, some rooms will be released in the end of July unless we know that we need them. That said, an information about number of participants is important for organization reasons. Thanks, Piotr and Jacek

1 0

Re: [v2 PATCH] dmime: Query the Sound buffer for supported interfaces
by Michael Stefaniuc 28 Jun '17

28 Jun '17

Hello Alistair, On 06/28/2017 08:46 AM, Alistair Leslie-Hughes wrote: > v2: Fix compile warning. > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/dmime/audiopath.c | 18 +++++++----------- > dlls/dmime/tests/dmime.c | 23 +++++++++++++++++++++++ > 2 files changed, 30 insertions(+), 11 deletions(-) > > diff --git a/dlls/dmime/audiopath.c b/dlls/dmime/audiopath.c > index 04f0af03d0..211f2156f2 100644 > --- a/dlls/dmime/audiopath.c > +++ b/dlls/dmime/audiopath.c > @@ -137,17 +137,13 @@ static HRESULT WINAPI IDirectMusicAudioPathImpl_GetObjectInPath (IDirectMusicAud > case DMUS_PATH_BUFFER: > if (This->pDSBuffer) > { > - if (IsEqualIID (iidInterface, &IID_IDirectSoundBuffer8)) { > - IDirectSoundBuffer8_QueryInterface (This->pDSBuffer, &IID_IDirectSoundBuffer8, ppObject); > - TRACE("returning %p\n",*ppObject); > - return S_OK; > - } else if (IsEqualIID (iidInterface, &IID_IDirectSound3DBuffer)) { > - IDirectSoundBuffer8_QueryInterface (This->pDSBuffer, &IID_IDirectSound3DBuffer, ppObject); > - TRACE("returning %p\n",*ppObject); > - return S_OK; > - } else { > - FIXME("Bad iid\n"); > - } you need to add tests for all the interfaces supported by the DirectSoundBuffer object too: IID_IDirectSoundNotify, IID_IDirectSound3DBuffer, IID_IKsPropertySet. But if native supports the query for those too this can be simplified even further to a return IDirectSoundBuffer8_QueryInterface(This->pDSBuffer, iidInterface, ppObject); The extra tracing isn't really needed as IDirectSoundBuffer8_QueryInterface() already does that. And any serious dmusic tracing needs to include the dsound debug channels anyway. > + if(IDirectSoundBuffer8_QueryInterface (This->pDSBuffer, iidInterface, ppObject) == S_OK) { Just in case you insist on keeping the extra tracing: "if" is not a function so please have a space between it and the "(". And no space between the function name and "(". > + TRACE("returning %p\n",*ppObject); Please add a space after the "," thanks bye michael > + return S_OK; > + } > + > + WARN("Unsupported iid %s\n", debugstr_guid(iidInterface)); > + return E_NOINTERFACE; > } > break; > > diff --git a/dlls/dmime/tests/dmime.c b/dlls/dmime/tests/dmime.c > index a154eac50b..13c6afbfec 100644 > --- a/dlls/dmime/tests/dmime.c > +++ b/dlls/dmime/tests/dmime.c > @@ -23,6 +23,7 @@ > #include <wine/test.h> > #include <dmusici.h> > #include <audioclient.h> > +#include <guiddef.h> > > #define ARRAY_SIZE(a) (sizeof(a)/sizeof((a)[0])) > > @@ -45,8 +46,11 @@ static void test_COM_audiopath(void) > IDirectMusicAudioPath *dmap; > IUnknown *unk; > IDirectMusicPerformance8 *performance; > + IDirectSoundBuffer *dsound; > + IDirectSoundBuffer8 *dsound8; > ULONG refcount; > HRESULT hr; > + DWORD buffer = 0; > > hr = CoCreateInstance(&CLSID_DirectMusicPerformance, NULL, CLSCTX_INPROC_SERVER, > &IID_IDirectMusicPerformance8, (void**)&performance); > @@ -89,6 +93,25 @@ static void test_COM_audiopath(void) > ok(refcount == 5, "refcount == %u, expected 5\n", refcount); > refcount = IUnknown_Release(unk); > > + hr = IDirectMusicAudioPath_GetObjectInPath(dmap, DMUS_PCHANNEL_ALL, DMUS_PATH_BUFFER, buffer, &GUID_NULL, > + 0, &IID_IDirectSoundBuffer, (void**)&dsound); > + ok(hr == S_OK, "Failed: %08x\n", hr); > + IDirectSoundBuffer_Release(dsound); > + > + hr = IDirectMusicAudioPath_GetObjectInPath(dmap, DMUS_PCHANNEL_ALL, DMUS_PATH_BUFFER, buffer, &GUID_NULL, > + 0, &IID_IDirectSoundBuffer8, (void**)&dsound8); > + ok(hr == S_OK, "Failed: %08x\n", hr); > + IDirectSoundBuffer8_Release(dsound8); > + > + hr = IDirectMusicAudioPath_GetObjectInPath(dmap, DMUS_PCHANNEL_ALL, DMUS_PATH_BUFFER, buffer, &GUID_NULL, > + 0, &IID_IUnknown, (void**)&unk); > + ok(hr == S_OK, "Failed: %08x\n", hr); > + IUnknown_Release(unk); > + > + hr = IDirectMusicAudioPath_GetObjectInPath(dmap, DMUS_PCHANNEL_ALL, DMUS_PATH_BUFFER, buffer, &GUID_NULL, > + 0, &GUID_NULL, (void**)&dsound8); > + ok(hr == E_NOINTERFACE, "Failed: %08x\n", hr); > + > while (IDirectMusicAudioPath_Release(dmap) > 1); /* performance has a reference too */ > IDirectMusicPerformance8_CloseDown(performance); > IDirectMusicPerformance8_Release(performance); >

1 0

Rerun TestBot tasks that timeout?
by Francois Gouget 28 Jun '17

28 Jun '17

The hope would be that the timeout was due to an external factor and that the task won't time out on the second try. But it's also quite likely that that the timeout is caused by an issue with the test itself and then it would time out again, and again. So with the default 3 tries this would result in tripling the time it takes to get the results (so 6 minutes and 3 reverts). Furthermore timeouts are not that common (particularly spurious ones) so it may not be worth changing anything. If we do want to do something the patch would be simple. I believe something like the patch below would do the trick. We could also have a single retry in such a case but this would require to special-case the code. diff --git a/testbot/bin/WineRunTask.pl b/testbot/bin/WineRunTask.pl index 1663c105..0cb0ea18 100755 --- a/testbot/bin/WineRunTask.pl +++ b/testbot/bin/WineRunTask.pl @@ -765,4 +765,5 @@ FatalTAError(undef, $TAError, $PossibleCrash) if (defined $TAError); # Wrap up # -WrapUpAndExit($NewStatus, $TaskFailures); +# Don't retry running a timed out test if it has failures anyway +WrapUpAndExit($NewStatus, $TaskFailures, ($TaskTimedOut and $TaskFailures == 1)); -- 2.11.0

1 0

Re: [v2 PATCH] oledb32: Support DBTYPE_DBTIMESTAMP to DBTYPE_WSTR in DataConvert
by Marvin 28 Jun '17

28 Jun '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=31909 Your paranoid android. === wxppro (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w2003std (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === wvistau64 (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w2008s64 (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w7u (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w7pro64 (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w8 (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w864 (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w1064 (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4

1 0

Re: [PATCH] oledb32: Support DBTYPE_DBTIMESTAMP to DBTYPE_WSTR in DataConvert
by Marvin 28 Jun '17

28 Jun '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=31908 Your paranoid android. === wxppro (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w2003std (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === wvistau64 (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w2008s64 (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w7u (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w7pro64 (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w8 (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w864 (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w1064 (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4

1 0

Re: [PATCH] gdiplus: Scale widened dashes to the pen width.
by Vincent Povirk 27 Jun '17

27 Jun '17

If the dash_pos variable is relative to pen width, we need to fix the other references to it. It doesn't make sense to compare it directly with segment_length and segment_pos. Or we could scale the whole dash_pattern array by pen width at the start.

2 2

Fwd: Improvements to the heap allocator
by Andrea Canciani 27 Jun '17

27 Jun '17

The original message was apparently blocked by the mailing list rules/filter. Now I am subscribed to wine-devel, sorry if you get the message twice. Andrea ---------- Forwarded message ---------- From: Andrea Canciani <ranma42(a)gmail.com> Date: Fri, Jun 23, 2017 at 9:29 AM Subject: Improvements to the heap allocator To: wine-devel(a)winehq.org Yesterday I opened a bug report about a performance issue in the wine heap allocator: https://bugs.winehq.org/show_bug.cgi?id=43224 Since I was also asking for some suggestions about what the preferred fix would be, Sebastian Lackner pointed to this mailing list. The bug report contains the source code for a program that has an allocation pattern that is very bad (for the current wine allocator). This appears to be a known problem, but I was unable to find any test/benchmark that shows such degenerate behavior. So far none of the attempts at fixing it seem to have landed. Some possible approaches are: 1. ensure that the freelist sizes cover all (alignment rounded) sizes up to a certain value; 2. when looking up for a free block, start from the freelist whose smallest element is at least as big as the desired block; 3. implement more complex free block management. #1 would fix the issue for some allocations sizes, but for bigger allocations the problem would stay the same. #2 would fix the performance problem at the cost of increased memory usage: for some sizes it would be possible that after a block is allocated and freed, the following allocation for that size does not re-use that memory (if the free block is stored in a freelist together with smaller blocks). #3 would increase the complexity of the code; to keep it under control, it might be possible to re-use the red-black tree implementation already available in wine. To avoid regressing performance, the smallest blocks might still be handled with simple freelists (fixed as in #1), while larger blocks are managed in a tree. Some of the current/previous attempts at tackling this issue are: - https://github.com/wine-compholio/wine-staging/blob/ master/patches/ntdll-Heap_FreeLists/0001-ntdll-Improve- heap-allocation-performance-by-using-m.patch (implements #1) - https://github.com/laino/wine-patches (IIUC, a combination of #1 and #3, in which the code tries to keep the freelist length under control, but AFAICT there is no guaranteed bound) I would like to try and work on fixing this, but there are some decision to make that might depend on constraints I am not aware of. Would the solution I propose (#3, rbtree based, with some tuning for small allocation sizes) be acceptable? Are there any benchmarks that a new implementation should strive to improve or at least avoid regressing? Suggestions and alternative solutions are welcome :) Sorry for the long message, thank you for your patience Andrea

1 0

Re: [v5 2/3] d3dx9: Get rid of constant's length checking for matrix in set_constants().
by Matteo Bruni 27 Jun '17

27 Jun '17

2017-06-22 15:11 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > When count in const_upload_info is calculated precisely (considering actual > constant set length), boolean matrix setting fall in direct copy path, unless > transpose is required. The case of incomplete last row for matrix should be > handled in set_constants() for transposed boolean constant only. > > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > v5: > - added check for constant size not exceeding parameter size. The check for > non array, non struct constants should be sufficient as the dimensions of > arrays and structs are derived from const_set data and register counts > from constant description is not used for them. I don't understand what you mean here. > @@ -1417,6 +1433,16 @@ static HRESULT init_set_constants_param(struct d3dx_const_tab *const_tab, ID3DXC > && !info.transpose && info.minor == info.major_stride > && info.count == get_offset_reg(const_set.table, const_set.register_count) > && info.count * sizeof(unsigned int) <= param->bytes; > + if (info.minor_remainder && !const_set.direct_copy && !info.transpose) > + FIXME("Incomplete last row for not transposed matrix which cannot be directly copied, parameter %s.\n", > + debugstr_a(param->name)); > + > + if (info.major_count > info.major > + || (info.major_count == info.major && info.minor_remainder)) > + { > + WARN("Constant dimensions exceed parameter size.\n"); > + return D3DERR_INVALIDCALL; > + } It seems to me that this catches all the problematic cases.

2 2

Re: [v5 1/3] d3dx9: Remove redundant parameter size check in set_constants().
by Matteo Bruni 27 Jun '17

27 Jun '17

2017-06-22 15:11 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > v5: > - Removed assert for parameter data length. The check for constant size not exceeding parameter size > is in the next patch. Otherwise the code would be changed right in the next patch after modifying > get_const_upload_info(), while before that the check is redundant. Yeah, it would have been slightly preferable with the check in a separate patch before this one. The check would have been redundant in practice but that's a bit of an "implementation detail". Certainly not a big deal though.

1 0

Re: [PATCH 2/2] d3drm: Store animation options
by Henri Verbeet 27 Jun '17

27 Jun '17

On 27 June 2017 at 10:17, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > +static HRESULT WINAPI d3drm_animation2_SetOptions(IDirect3DRMAnimation2 *iface, D3DRMANIMATIONOPTIONS options) > +{ > + struct d3drm_animation *animation = impl_from_IDirect3DRMAnimation2(iface); > + static const DWORD supported_options = D3DRMANIMATION_OPEN | D3DRMANIMATION_CLOSED | D3DRMANIMATION_LINEARPOSITION > + | D3DRMANIMATION_SPLINEPOSITION | D3DRMANIMATION_SCALEANDROTATION | D3DRMANIMATION_POSITION; > + > + TRACE("iface %p, options %#x.\n", iface, options); > + > + if (options && !(options & supported_options)) > + return D3DRMERR_BADVALUE; Should that be "if (options & ~supported_options)"? The test is ambiguous about that. > @@ -6776,6 +6777,42 @@ static void test_animation(void) > IDirect3DRMFrame3_Release(frame3); > IDirect3DRMFrame_Release(frame); > > + /* Animation options. */ > + options = IDirect3DRMAnimation_GetOptions(animation); > + ok(options == (D3DRMANIMATION_CLOSED | D3DRMANIMATION_LINEARPOSITION), > + "Unexpected default options %#x.\n", options); > + > + /* Undefined mask value */ > + hr = IDirect3DRMAnimation_SetOptions(animation, 0xdeadbeef); > + ok(hr == D3DRMERR_BADVALUE, "Unexpected hr %#x.\n", hr); 0xdeadbeef is a bit of a poor test value here, since it will trigger both the "D3DRMANIMATION_OPEN | D3DRMANIMATION_CLOSED" and "D3DRMANIMATION_LINEARPOSITION | D3DRMANIMATION_SPLINEPOSITION" paths as well. Is it valid to set 0 as an option? Is it valid to set e.g. D3DRMANIMATION_OPEN, but not one of D3DRMANIMATION_LINEARPOSITION and D3DRMANIMATION_SPLINEPOSITION? I.e., is it just invalid to set conflicting options, or should always exactly one of OPEN/CLOSED and LINEARPOSITION/SPLINEPOSITION be set?

2 3

Re: [PATCH 1/2] d3drm: Store animated frame pointer in animation object
by Henri Verbeet 27 Jun '17

27 Jun '17

On 27 June 2017 at 10:17, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > static HRESULT WINAPI d3drm_animation1_SetFrame(IDirect3DRMAnimation *iface, IDirect3DRMFrame *frame) > { > - FIXME("iface %p, frame %p.\n", iface, frame); > + struct d3drm_animation *animation = impl_from_IDirect3DRMAnimation(iface); > + HRESULT hr = D3DRM_OK; > > - return E_NOTIMPL; > + TRACE("iface %p, frame %p.\n", iface, frame); > + > + if (frame) > + { > + hr = IDirect3DRMFrame_QueryInterface(frame, &IID_IDirect3DRMFrame3, (void **)&animation->frame); > + if (SUCCEEDED(hr)) > + IDirect3DRMFrame3_Release(animation->frame); > + } > + else > + animation->frame = NULL; > + > + return hr; > } There's nothing necessarily wrong with this, but I feel the following alternative is worth pointing out: struct d3drm_frame *f = unsafe_impl_from_IDirect3DRMFrame(frame); ... animation->frame = f ? &f->IDirect3DRMFrame3_iface : NULL; return D3DRM_OK; or even ... return d3drm_animation2_SetFrame(&animation->IDirect3DRMAnimation2_iface, f ? &f->IDirect3DRMFrame3_iface : NULL); which is a pattern that's used in ddraw for this kind of thing.

2 1

Re: [PATCH] gdiplus: Write API doc for GdipAddPathEllipse and GdipAddPathEllipseI
by Clemens Tamme 27 Jun '17

27 Jun '17

ok, i will rewrite so the same terms are used in the docs of GdipAddPathLine and GdipAddPathEllipse 2017-06-26 22:18 GMT+02:00 Marvin <testbot(a)winehq.org>: > Thank you for your contribution to Wine! > > This is an automated notification to let you know that your patch has > been reviewed and its status set to "Assigned". > > This means that the patch has been assigned to a reviewer. If the > reviewer signs off on the patch, it will be committed, otherwise > you'll receive advice on how to improve it. If you don't hear anything > after a couple of weeks, please resend the patch. >

1 0

Re: [PATCH v3 1/4] msi/tests: Add tests for external UI callback.
by Marvin 27 Jun '17

27 Jun '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=31868 Your paranoid android. === wvistau64 (32 bit package) === package.c:9397: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ" === wvistau64 (64 bit package) === package.c:9397: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ"

1 0

Re: [PATCH v2 3/4] msi: Implement INSTALLMESSAGE_INITIALIZE and INSTALLMESSAGE_TERMINATE.
by Marvin 27 Jun '17

27 Jun '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=31865 Your paranoid android. === wvistau64 (32 bit package) === package.c:9397: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ" === wvistau64 (64 bit package) === package.c:9397: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ"

1 0

Re: [PATCH v2 2/4] msi: Send the correct UI messages upon calling MsiDoAction().
by Marvin 27 Jun '17

27 Jun '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=31864 Your paranoid android. === wvistau64 (32 bit package) === package.c:9397: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ" === wvistau64 (64 bit package) === package.c:9397: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ"

1 0

Re: [PATCH v2 1/4] msi/tests: Add tests for external UI callback.
by Marvin 27 Jun '17

27 Jun '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=31863 Your paranoid android. === wvistau64 (32 bit package) === package.c:9397: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ" === wvistau64 (64 bit package) === package.c:9397: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ"

1 0

Re: [v3 2/2] user32/tests: Add test for GetWindowDisplayAffinity.
by Marvin 26 Jun '17

26 Jun '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=31853 Your paranoid android. === w7u (32 bit win) === win.c:9860: Test failed: SetWindowDisplayAffinity returned with 8 win.c:9864: Test failed: GetWindowDisplayAffinity returned unexpected affinity 0 win.c:9867: Test failed: SetWindowDisplayAffinity returned with 8 === w7pro64 (32 bit win) === win.c:9860: Test failed: SetWindowDisplayAffinity returned with 8 win.c:9864: Test failed: GetWindowDisplayAffinity returned unexpected affinity 0 win.c:9867: Test failed: SetWindowDisplayAffinity returned with 8 === w7pro64 (64 bit win) === win.c:9860: Test failed: SetWindowDisplayAffinity returned with 8 win.c:9864: Test failed: GetWindowDisplayAffinity returned unexpected affinity 0 win.c:9867: Test failed: SetWindowDisplayAffinity returned with 8

2 1

Re: [PATCH] gdiplus: Write API doc for GdipAddPathEllipse and GdipAddPathEllipseI
by Vincent Povirk 26 Jun '17

26 Jun '17

This description is probably more complicated than it needs to be. If we want consistency with the GdipAddPathLine description, we can state it in terms of the newfigure value, which is ignored on input and TRUE on output. On Sat, Jun 24, 2017 at 11:26 AM, Clemens Tamme <clemens.tamme(a)gmail.com> wrote: > + * As an ellipse is always a new subpath the current subpath of the given path > + * cannot be continued afterwards. Additionally, the next thing added to the > + * path will be the start of the next subpath.

1 0

Re: [1/3] server: Add field for window display affinity.
by Alexandre Julliard 26 Jun '17

26 Jun '17

Andrew Wesie <awesie(a)gmail.com> writes: > Signed-off-by: Andrew Wesie <awesie(a)gmail.com> > --- > include/wine/server_protocol.h | 9 ++++++--- > server/protocol.def | 3 +++ > server/request.h | 4 +++- > server/window.c | 4 ++++ > 4 files changed, 16 insertions(+), 4 deletions(-) > > diff --git a/include/wine/server_protocol.h b/include/wine/server_protocol.h > index d31579c..f442a94 100644 > --- a/include/wine/server_protocol.h > +++ b/include/wine/server_protocol.h > @@ -47,7 +47,7 @@ struct reply_header > > struct request_max_size > { > - int pad[16]; > + int pad[18]; > }; You can't change the request size. Also note that this is a generated file, updated by tools/make_requests. Do you have an app that uses this across processes? Otherwise you can probably simply store a local flag for now. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH 1/5] msi/tests: Add tests for external UI callback.
by Hans Leidekker 26 Jun '17

26 Jun '17

On Sun, 2017-06-25 at 21:13 -0500, Zebediah Figura wrote: > @@ -822,6 +823,8 @@ static UINT package_from_db(MSIHANDLE hdb, MSIHANDLE *handle) > CHAR szPackage[12]; > MSIHANDLE hPackage; > > + CoInitialize(NULL); > + > sprintf(szPackage, "#%u", hdb); > res = MsiOpenPackageA(szPackage, &hPackage); > if (res != ERROR_SUCCESS) > @@ -837,22 +840,39 @@ static UINT package_from_db(MSIHANDLE hdb, MSIHANDLE *handle) > return res; > } > > + CoUninitialize(); > + Why do you need this? > -static void create_test_file(const CHAR *name) > +static void create_file_data(LPCSTR name, LPCSTR data, DWORD size) > { > HANDLE file; > DWORD written; > > file = CreateFileA(name, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, 0, NULL); > ok(file != INVALID_HANDLE_VALUE, "Failure to open file %s\n", name); > - WriteFile(file, name, strlen(name), &written, NULL); > + if (file == INVALID_HANDLE_VALUE) > + return; > + > + WriteFile(file, data, strlen(data), &written, NULL); > WriteFile(file, "\n", strlen("\n"), &written, NULL); > + > + if (size) > + { > + SetFilePointer(file, size, NULL, FILE_BEGIN); > + SetEndOfFile(file); > + } > + > CloseHandle(file); > } You're not using this in this patch set.

3 3

Re: [PATCH 4/5] msi: Implement INSTALLMESSAGE_INITIALIZE and INSTALLMESSAGE_TERMINATE.
by Marvin 26 Jun '17

26 Jun '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=31839 Your paranoid android. === wvistau64 (32 bit package) === package.c:9405: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ" === wvistau64 (64 bit package) === package.c:9405: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ"

1 0

Re: [PATCH 3/5] msi: Send the correct UI messages upon calling MsiDoAction().
by Marvin 26 Jun '17

26 Jun '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=31838 Your paranoid android. === wvistau64 (32 bit package) === package.c:9405: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ" === wvistau64 (64 bit package) === package.c:9405: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ"

1 0

Re: [PATCH 1/5] msi/tests: Add tests for external UI callback.
by Marvin 26 Jun '17

26 Jun '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=31836 Your paranoid android. === wvistau64 (32 bit package) === package.c:9405: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ" === wvistau64 (64 bit package) === package.c:9405: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ"

1 0

Re: [PATCH v3] configure: Avoid clobbering x18 on arm64 within wine
by André Hentschel 26 Jun '17

26 Jun '17

1 0

Re: [v2 PATCH 1/2] d3drm: Added IDirect3DRMWrap stub
by Henri Verbeet 26 Jun '17

26 Jun '17

On 26 June 2017 at 01:16, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > +static HRESULT WINAPI d3drm_wrap_QueryInterface(IDirect3DRMWrap *iface, REFIID riid, void **out) > +{ > + TRACE("iface %p, riid %s, out %p.\n", iface, debugstr_guid(riid), out); > + > + if (IsEqualGUID(riid, &IID_IDirect3DRMWrap) > + || IsEqualGUID(riid, &IID_IDirect3DRMObject) > + || IsEqualGUID(riid, &IID_IUnknown)) > + { > + IDirect3DRMWrap_AddRef(iface); > + *out = iface; > + return S_OK; > + } > + > + WARN("%s not implemented, returning E_NOINTERFACE.\n", debugstr_guid(riid)); That's a little misleading. > + > + *out = NULL; > + return CLASS_E_CLASSNOTAVAILABLE; > +}

1 0

Re: [PATCH 5/5] msi: Implement UI messages in MsiOpenPackage().
by Hans Leidekker 26 Jun '17

26 Jun '17

> @@ -1610,6 +1617,35 @@ UINT MSI_OpenPackageW(LPCWSTR szPackage, MSIPACKAGE **pPackage) > if (gszLogFile) > package->log_file = CreateFileW( gszLogFile, GENERIC_WRITE, FILE_SHARE_WRITE, NULL, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL ); > + > + /* FIXME: when should these messages be sent? */ > + data_row = MSI_CreateRecord(3); > + /* FIXME: field 0 should be NULL */ > + MSI_RecordSetInteger(data_row, 1, 0); > + MSI_RecordSetInteger(data_row, 2, package->num_langids ? package->langids[0] : 0); > + MSI_RecordSetInteger(data_row, 3, msi_get_string_table_codepage(package->db->strings)); > + MSI_ProcessMessage(package, INSTALLMESSAGE_COMMONDATA, data_row); > + > + info_row = MSI_CreateRecord(0); > + GetTimeFormatW(LOCALE_USER_DEFAULT, 0, NULL, time_format, timet, 100); > + GetDateFormatW(LOCALE_USER_DEFAULT, 0, NULL, date_format, datet, 100); > + LoadStringW(msi_hInstance, IDS_INFO_LOGGINGSTART, info_template, 1024); > + sprintfW(info_message, info_template, datet, timet); > + MSI_RecordSetStringW(info_row, 0, info_message); > + MSI_ProcessMessage(package, INSTALLMESSAGE_INFO|MB_ICONHAND, info_row); > + > + MSI_ProcessMessage(package, INSTALLMESSAGE_COMMONDATA, data_row); > + > + productname = msi_dup_property(package->db, INSTALLPROPERTY_PRODUCTNAMEW); > + MSI_RecordSetInteger(data_row, 1, 1); > + MSI_RecordSetStringW(data_row, 2, productname); > + MSI_RecordSetStringW(data_row, 3, NULL); > + MSI_ProcessMessage(package, INSTALLMESSAGE_COMMONDATA, data_row); Error handling.

1 0

Re: [PATCH 3/5] msi: Send the correct UI messages upon calling MsiDoAction().
by Hans Leidekker 26 Jun '17

26 Jun '17

On Sun, 2017-06-25 at 21:13 -0500, Zebediah Figura wrote: > @@ -156,18 +158,12 @@ static const WCHAR szValidateProductID[] = > static const WCHAR szWriteEnvironmentStrings[] = > {'W','r','i','t','e','E','n','v','i','r','o','n','m','e','n','t','S','t','r','i','n','g','s',0}; > > -static void ui_actionstart(MSIPACKAGE *package, LPCWSTR action) > +static void ui_actionstart(MSIPACKAGE *package, LPCWSTR action, LPCWSTR description, LPCWSTR template) > { > - static const WCHAR Query_t[] = > - {'S','E','L','E','C','T',' ','*',' ','F','R','O','M',' ', > - '`','A','c','t','i','o', 'n','T','e','x','t','`',' ', > - 'W','H','E','R','E', ' ','`','A','c','t','i','o','n','`',' ','=', > - ' ','\'','%','s','\'',0}; > - MSIRECORD * row; > - > - row = MSI_QueryGetRecord( package->db, Query_t, action ); > - if (!row) > - return; > + MSIRECORD *row = MSI_CreateRecord(3); > + MSI_RecordSetStringW(row, 1, action); > + MSI_RecordSetStringW(row, 2, description); > + MSI_RecordSetStringW(row, 3, template); Please check the result of the MSI_CreateRecord call. > @@ -175,28 +171,21 @@ static void ui_actionstart(MSIPACKAGE *package, LPCWSTR action) > static void ui_actioninfo(MSIPACKAGE *package, LPCWSTR action, BOOL start, > UINT rc) > { > - MSIRECORD * row; > - static const WCHAR template_s[]= > - {'A','c','t','i','o','n',' ','s','t','a','r','t',' ','%','s',':',' ', > - '%','s', '.',0}; > - static const WCHAR template_e[]= > - {'A','c','t','i','o','n',' ','e','n','d','e','d',' ','%','s',':',' ', > - '%','s', '.',' ','R','e','t','u','r','n',' ','v','a','l','u','e',' ', > - '%','i','.',0}; > + MSIRECORD *row; > + WCHAR template[1024]; > static const WCHAR format[] = > {'H','H','\'',':','\'','m','m','\'',':','\'','s','s',0}; > WCHAR message[1024]; > WCHAR timet[0x100]; > > GetTimeFormatW(LOCALE_USER_DEFAULT, 0, NULL, format, timet, 0x100); > - if (start) > - sprintfW(message,template_s,timet,action); > - else > - sprintfW(message,template_e,timet,action,rc); > - > - row = MSI_CreateRecord(1); > - MSI_RecordSetStringW(row,1,message); > - > + LoadStringW(msi_hInstance, start ? IDS_INFO_ACTIONSTART : IDS_INFO_ACTIONENDED, template, 1024); > + sprintfW(message, template, timet); > + > + row = MSI_CreateRecord(2); > + MSI_RecordSetStringW(row, 0, message); > + MSI_RecordSetStringW(row, 1, action); > + MSI_RecordSetInteger(row, 2, !rc); Same here.

1 0

Re: [PATCH 1/2] tools/winedbg: Add support for printing floating point registers.
by Alexandre Julliard 26 Jun '17

26 Jun '17

Zebediah Figura <z.figura12(a)gmail.com> writes: > @@ -237,6 +237,14 @@ static struct dbg_internal_var be_x86_64_ctx[] = > {CV_AMD64_R13, "R13", (DWORD_PTR*)FIELD_OFFSET(CONTEXT, R13), dbg_itype_unsigned_long_int}, > {CV_AMD64_R14, "R14", (DWORD_PTR*)FIELD_OFFSET(CONTEXT, R14), dbg_itype_unsigned_long_int}, > {CV_AMD64_R15, "R15", (DWORD_PTR*)FIELD_OFFSET(CONTEXT, R15), dbg_itype_unsigned_long_int}, > + {CV_AMD64_ST0, "ST0", (DWORD_PTR*)FIELD_OFFSET(CONTEXT, FloatSave.RegisterArea[ 0]), dbg_itype_long_real}, > + {CV_AMD64_ST0+1, "ST1", (DWORD_PTR*)FIELD_OFFSET(CONTEXT, FloatSave.RegisterArea[10]), dbg_itype_long_real}, > + {CV_AMD64_ST0+2, "ST2", (DWORD_PTR*)FIELD_OFFSET(CONTEXT, FloatSave.RegisterArea[20]), dbg_itype_long_real}, > + {CV_AMD64_ST0+3, "ST3", (DWORD_PTR*)FIELD_OFFSET(CONTEXT, FloatSave.RegisterArea[30]), dbg_itype_long_real}, > + {CV_AMD64_ST0+4, "ST4", (DWORD_PTR*)FIELD_OFFSET(CONTEXT, FloatSave.RegisterArea[40]), dbg_itype_long_real}, > + {CV_AMD64_ST0+5, "ST5", (DWORD_PTR*)FIELD_OFFSET(CONTEXT, FloatSave.RegisterArea[50]), dbg_itype_long_real}, > + {CV_AMD64_ST0+6, "ST6", (DWORD_PTR*)FIELD_OFFSET(CONTEXT, FloatSave.RegisterArea[60]), dbg_itype_long_real}, > + {CV_AMD64_ST0+7, "ST7", (DWORD_PTR*)FIELD_OFFSET(CONTEXT, FloatSave.RegisterArea[70]), dbg_itype_long_real}, This doesn't build: ../../../wine/include/winnt.h:757:42: error: ‘CONTEXT {aka struct _CONTEXT}’ has no member named ‘FloatSave’ ../../../wine/programs/winedbg/be_x86_64.c:240:53: note: in expansion of macro ‘FIELD_OFFSET’ -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/2] tools/winedbg: Add support for printing SSE (XMM) registers.
by Alexandre Julliard 26 Jun '17

26 Jun '17

Zebediah Figura <z.figura12(a)gmail.com> writes: > + for (cnt = 0; cnt < 8; cnt++) > + { > + dbg_printf( " xmm%u: uint=%016llx%016llx", cnt, > + xmm_area->XmmRegisters[cnt].High, xmm_area->XmmRegisters[cnt].Low ); Please avoid %ll formats. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: advpack: Improve DelNode and tests
by Alexandre Julliard 26 Jun '17

26 Jun '17

"katahiromz ." <katayama.hirofumi.mz(a)gmail.com> writes: > @@ -327,6 +328,149 @@ done: > return HRESULT_FROM_WIN32(dwLastError); > } > > +static HRESULT DELNODE_delete_file(LPWSTR fname) > +{ > + if (GetFileAttributesW(fname) != INVALID_FILE_ATTRIBUTES) > + { > + SetFileAttributesW(fname, FILE_ATTRIBUTE_NORMAL); > + if (DeleteFileW(fname)) > + { > + return S_OK; > + } > + } There shouldn't be any reason to retrieve attributes first. > + /* generate a path with wildcard suitable for iterating */ > + fname_len = lstrlenW(fname); > + if (fname_len && fname[fname_len - 1] != L'\\') > + { > + fname[fname_len++] = L'\\'; Please don't use wide character constants. > C_SRCS = \ > advpack.c \ > + delnode.c \ > files.c \ > install.c Please don't create a new file, the tests should go into files.c. > +static const NODEW s_nodesW[] = > +{ > + { L"dir1", TRUE }, /* 0 */ > + { L"dir1\\dir2", TRUE }, /* 1 */ > + { L"dir1\\dir2\\file1", FALSE }, /* 2 */ You can't use wide character strings in Wine. > +START_TEST(delnode) > +{ > + s_hAdvPack = LoadLibraryA("advpack.dll"); > + if (s_hAdvPack == NULL) > + { > + skip("unable to load advpack.dll\n"); > + return; > + } This shouldn't be necessary. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH v2] configure: Avoid clobbering x18 on arm64 when building with clang
by Martin Storsjö 26 Jun '17

26 Jun '17

On Sat, 24 Jun 2017, André Hentschel wrote: > Am 21.06.2017 um 12:39 schrieb Martin Storsjo: >> On aarch64/arm64, clang/LLVM feels free to use x18 for normal code >> generation on linux (while the register is reserved on iOS/darwin). >> For windows/arm64, this register must not be clobbered. >> >> If targeting arm64, check for the clang cflags that allows this >> register to be left untouched. >> >> This makes sure that wine for aarch64 built with clang doesn't >> crash immediately on startup. >> >> Signed-off-by: Martin Storsjo <martin(a)martin.st> >> --- >> Now with the sign-off included, which was forgotten in v1. >> --- >> configure.ac | 5 +++++ >> 1 file changed, 5 insertions(+) >> >> diff --git a/configure.ac b/configure.ac >> index 7ae29f7..5b5a1d8 100644 >> --- a/configure.ac >> +++ b/configure.ac >> @@ -179,6 +179,11 @@ case $host in >> CFLAGS="$CFLAGS -marm" >> AC_SUBST(TARGETFLAGS,"-marm") >> ;; >> + aarch64*) >> + # Clang needs these flags in order not to clobber the x18 register >> + WINE_TRY_CFLAGS([-Xclang -target-feature -Xclang +reserve-x18], >> + [CFLAGS="$CFLAGS -Xclang -target-feature -Xclang +reserve-x18"]) >> + ;; >> i[[3456789]]86*) >> enable_win16=${enable_win16:-yes} >> ;; >> > > I think it's worthwhile adding it > > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> FWIW, in case Alexandre also reconsiders merging it since you think it's worthwhile adding it - I reposted a v3, using the gcc compatible flag syntax and with an improved commit message. // Martin

1 0

Re: [4/6] windowscodecs: Add initial implementation of IWICMetadataQueryReader::GetMetadataByName. (v2)
by Dmitry Timoshkov 25 Jun '17

25 Jun '17

Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > +static const WCHAR *map_shortname_to_schema(const GUID *format, const WCHAR *name) > +{ > + UINT i; > + > + /* It appears that the only metadata formats > + * that support schemas are xmp and xmpstruct. > ++ */ Oops. I hope that a typo in the comment won't require another resend. Alexandre, could you please remove extra '+' in the comment above if the patch gets accepted? Thanks. -- Dmitry.

1 0

Re: [6/7] windowscodecs: Add some tests for IWICMetadataQueryReader.
by Vincent Povirk 25 Jun '17

25 Jun '17

> + if (CompareStringW(LOCALE_NEUTRAL, NORM_IGNORECASE, queryW, len-1, name, len-1) == CSTR_EQUAL && decoder_data[j].query[len - 1] != 0) > + { > + if (winetest_debug > 1) > + trace("query: %s\n", wine_dbgstr_w(queryW + len - 1)); > + PropVariantInit(&value); Shouldn't this be PropVariantClear?

2 1

Re: [5/7] windowscodecs: Add initial implementation of IWICMetadataQueryReader::GetMetadataByName.
by Vincent Povirk 25 Jun '17

25 Jun '17

> + if (vt == VT_CLSID) > + { > + id->u.puuid = CoTaskMemAlloc(sizeof(GUID)); > + if (!id->u.puuid) return E_OUTOFMEMORY; > + > + hr = UuidFromStringW(next_token.u.bstrVal, id->u.puuid); > + } > + else > + hr = PropVariantChangeType(id, &next_token, 0, vt); > + PropVariantClear(&next_token); > + if (hr != S_OK) > + { > + PropVariantClear(id); > + PropVariantClear(schema); > + return hr; > + } > + > + id->vt = vt; Assigning the vt at the end of this is a bit strange. I don't know any situation here where PropVariantChangeType will succeed without giving you the requested vt, and if it did, changing it would be unsafe. I can see you need it in the VT_CLSID case, but then it would make more sense to set it there. In fact, this version will leak memory if UuidFromStringW fails. + if (!elem.len) break; When can this happen? + new_value.vt = VT_UNKNOWN; + hr = MetadataQueryReader_CreateInstance(This->block, root, (IWICMetadataQueryReader **)&new_value.u.punkVal); I think you need to clear new_value first here?

2 1

Re: [PATCH v2] configure: Avoid clobbering x18 on arm64 when building with clang
by Alexandre Julliard 24 Jun '17

24 Jun '17

Martin Storsjo <martin(a)martin.st> writes: > On aarch64/arm64, clang/LLVM feels free to use x18 for normal code > generation on linux (while the register is reserved on iOS/darwin). > For windows/arm64, this register must not be clobbered. This would have to be made the default system-wide, fixing it on the Wine side isn't good enough since we call system libraries. -- Alexandre Julliard julliard(a)winehq.org

3 7

Re: [PATCH] gdiplus: Write API doc for GdipAddPathEllipse and GdipAddPathEllipseI
by Vincent Povirk 24 Jun '17

24 Jun '17

+ * GenericError If conversion from arc to bezier curve fails When would this happen? Best I can tell, it isn't supposed to be possible, and the check is just coding defensively. + * Ok If ecerything works out as expected Typo.

2 1

Re: [3/3] user32/tests: Add test for GetWindowDisplayAffinity.
by Marvin 23 Jun '17

23 Jun '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=31812 Your paranoid android. === w7u (32 bit win) === win.c:9858: Test failed: SetWindowDisplayAffinity returned with 8 win.c:9862: Test failed: GetWindowDisplayAffinity returned unexpected affinity 0 win.c:9865: Test failed: SetWindowDisplayAffinity returned with 8 === w7pro64 (32 bit win) === win.c:9858: Test failed: SetWindowDisplayAffinity returned with 8 win.c:9862: Test failed: GetWindowDisplayAffinity returned unexpected affinity 0 win.c:9865: Test failed: SetWindowDisplayAffinity returned with 8 === w7pro64 (64 bit win) === win.c:9858: Test failed: SetWindowDisplayAffinity returned with 8 win.c:9862: Test failed: GetWindowDisplayAffinity returned unexpected affinity 0 win.c:9865: Test failed: SetWindowDisplayAffinity returned with 8

2 1

Re: [PATCH 2/2] d3drm: Added IDirect3DRMWrap stub
by Henri Verbeet 23 Jun '17

23 Jun '17

On 23 June 2017 at 15:15, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > +static HRESULT WINAPI d3drm_wrap_QueryInterface(IDirect3DRMWrap *iface, REFIID riid, void **out) > +{ > + TRACE("iface %p, riid %s, out %p.\n", iface, debugstr_guid(riid), out); > + > + if (IsEqualGUID(riid, &IID_IDirect3DRMWrap) > + || IsEqualGUID(riid, &IID_IDirect3DRMObject) > + || IsEqualGUID(riid, &IID_IUnknown)) > + { > + IDirect3DRMWrap_AddRef(iface); > + *out = iface; > + return S_OK; > + } > + > + WARN("%s not implemented, returning E_NOINTERFACE.\n", debugstr_guid(riid)); > + > + *out = NULL; > + return E_NOINTERFACE; > +} Likewise, while E_NOINTERFACE would normally be the expected value, that's not a given with d3drm. > +static ULONG WINAPI d3drm_wrap_Release(IDirect3DRMWrap *iface) > +{ > + struct d3drm_wrap *wrap = impl_from_IDirect3DRMWrap(iface); > + ULONG refcount = InterlockedDecrement(&wrap->ref); > + > + TRACE("%p decreasing refcount to %u.\n", iface, refcount); > + > + if (!refcount) > + { > + d3drm_object_cleanup((IDirect3DRMObject *)iface, &wrap->obj); > + //IDirect3DRM_Release(mesh->d3drm); C99 comment. > @@ -109,10 +109,10 @@ static void test_class_name_(unsigned int line, IDirect3DRMObject *object, const > ok_(__FILE__, line)(hr == D3DRM_OK, "Failed to get classname size, hr %#x.\n", hr); > ok_(__FILE__, line)(size == strlen(name) + 1, "wrong size: %u\n", size); > > - size = 1; > + size = size2 = *name ? 1 : 0; I think "!!*name" would be more obvious, but don't care strongly.

1 0

Re: [PATCH 1/2] d3drm: Added IDirect3DRMAnimation stub
by Henri Verbeet 23 Jun '17

23 Jun '17

On 23 June 2017 at 15:15, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > +static HRESULT WINAPI d3drm_animation2_QueryInterface(IDirect3DRMAnimation2 *iface, REFIID riid, void **out) > +{ > + struct d3drm_animation *animation = impl_from_IDirect3DRMAnimation2(iface); > + > + TRACE("iface %p, riid %s, out %p.\n", iface, debugstr_guid(riid), out); > + > + if (IsEqualGUID(riid, &IID_IDirect3DRMAnimation) > + || IsEqualGUID(riid, &IID_IDirect3DRMObject) > + || IsEqualGUID(riid, &IID_IUnknown)) > + { > + *out = &animation->IDirect3DRMAnimation_iface; > + } > + else if (IsEqualGUID(riid, &IID_IDirect3DRMAnimation2)) > + { > + *out = &animation->IDirect3DRMAnimation2_iface; > + } > + else > + { > + *out = NULL; > + WARN("%s not implemented, returning CLASS_E_CLASSNOTAVAILABLE.\n", debugstr_guid(riid)); > + return CLASS_E_CLASSNOTAVAILABLE; I suspect CLASS_E_CLASSNOTAVAILABLE is correct, since other d3drm interfaces are unusual like that as well, but it would be good to have that backed up by the tests.

1 0

Re: [PATCH 1/4] d3drm: Make it possible to create material objects with CreateObject().
by Henri Verbeet 22 Jun '17

22 Jun '17

On 21 June 2017 at 14:39, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > diff --git a/dlls/d3drm/tests/d3drm.c b/dlls/d3drm/tests/d3drm.c > index fc19b97b8b..6c2903226a 100644 > --- a/dlls/d3drm/tests/d3drm.c > +++ b/dlls/d3drm/tests/d3drm.c > @@ -1404,6 +1404,8 @@ static void test_object(void) > { &CLSID_CDirect3DRMFrame, &IID_IDirect3DRMFrame2 }, > { &CLSID_CDirect3DRMFrame, &IID_IDirect3DRMFrame3 }, > { &CLSID_CDirect3DRMLight, &IID_IDirect3DRMLight }, > + { &CLSID_CDirect3DRMMaterial, &IID_IDirect3DRMMaterial }, > + { &CLSID_CDirect3DRMMaterial, &IID_IDirect3DRMMaterial2 }, > }; > IDirect3DRM *d3drm1; > IDirect3DRM2 *d3drm2; > @@ -1429,7 +1431,8 @@ static void test_object(void) > { > BOOL takes_ref = IsEqualGUID(tests[i].clsid, &CLSID_CDirect3DRMMeshBuilder) || > IsEqualGUID(tests[i].clsid, &CLSID_CDirect3DRMFrame) || > - IsEqualGUID(tests[i].clsid, &CLSID_CDirect3DRMLight); > + IsEqualGUID(tests[i].clsid, &CLSID_CDirect3DRMLight) || > + IsEqualGUID(tests[i].clsid, &CLSID_CDirect3DRMMaterial); If there are going to be more of these, it probably makes sense to just include the information as a field in tests[].

2 1

Re: winhttp: Reset content length when a redirect creates a new connection.
by Alistair Leslie-Hughes 22 Jun '17

22 Jun '17

Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>

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