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

Re: Definition (or not) of IDXGIResource methods

by Henri Verbeet

On 30 June 2017 at 19:54, Ben "Root" Anderson <roothorick(a)gmail.com> wrote: > I've been studying the DXGI code with an eye for implementing the > DirectX-side shared resource functionality so that an application > would hopefully be able to share Direct3D textures with a Vulkan > instance, and what I'm seeing has me rather confused. > > IDXGIResource appears to be declared, with a number of methods, in > include/dxgi.idl. I'm not clear on what exactly an IDL file is, but my > impression is it's similar to a specfile, except for headers of C++ > interfaces. In any case, none of the methods declared appear to have > any definition anywhere in Wine. The logical conclusion would be > they're automatically generated stubs. > > But that doesn't make sense, because the DXGI test at > dlls/dxgi/tests/device.c calls IDXGIResource_GetUsage and appears to > expect it to succeed, Actually, no, it doesn't. The IDXGISwapChain_GetBuffer() call in test_swapchain_parameters() that's supposed to return the IDXGIResource interface is marked todo_wine. I.e., it's expected to fail currently. The IDXGIResource interface is indeed currently unimplemented in Wine.

June 30, 2017

Re: [PATCH 03/10 v4] gdiplus: Add functions for managing metafile objects id

by Piotr Caban

> On 30 Jun 2017, at 22:24, Vincent Povirk <madewokherd(a)gmail.com> wrote: > > This seems like overkill to me? > > I don't see the need for per-object refcounting. Every drawing > operation that uses an object is just going to end with a series of > releases, and after it returns all refcounts should be 0. > > + /* TODO: object id should be released on object dispose */ > I don't think this approach is possible. It would require every object > to be aware of which metafiles are using it, and every operation that > modifies the object would have to release them. Bitmap objects can > refer to an application buffer that could be modified without any call > into gdiplus. (Or, Bitmaps could be modified by an ImageAttributes, in > which case we can't reuse them except with an identical > ImageAttributes.) > > If we wanted to reuse Bitmaps, we'd have to compare the data. For > other large types like Paths, maybe keeping an id to detect whether it > changed would make sense. For types of bounded size, it probably would > be easier to store a complete copy. Currently the implementation only overwrites ids in the same way as native does. It’s there to make sure we never run out of IDs. I think it’s nice that the functions are failsafe. It’s also closer to native behaviour. I think that everything else can be figured out later. The comment is based on observation of native dll behaviour. I’ve checked what happens when new bitmaps are created and drawn to metafile in a loop. All of the bitmaps contained exactly the same data. In this case the IDs were not freed unless we run out of free IDs. After adding GdiDisposeImage call to the loop the IDs got released. I think it makes the comment valid even if we never implement this behaviour. Thanks, Piotr

June 30, 2017

Re: [PATCH 03/10 v4] gdiplus: Add functions for managing metafile objects id

by Vincent Povirk

This seems like overkill to me? I don't see the need for per-object refcounting. Every drawing operation that uses an object is just going to end with a series of releases, and after it returns all refcounts should be 0. + /* TODO: object id should be released on object dispose */ I don't think this approach is possible. It would require every object to be aware of which metafiles are using it, and every operation that modifies the object would have to release them. Bitmap objects can refer to an application buffer that could be modified without any call into gdiplus. (Or, Bitmaps could be modified by an ImageAttributes, in which case we can't reuse them except with an identical ImageAttributes.) If we wanted to reuse Bitmaps, we'd have to compare the data. For other large types like Paths, maybe keeping an id to detect whether it changed would make sense. For types of bounded size, it probably would be easier to store a complete copy.

June 30, 2017

Definition (or not) of IDXGIResource methods

by Ben "Root" Anderson

I've been studying the DXGI code with an eye for implementing the DirectX-side shared resource functionality so that an application would hopefully be able to share Direct3D textures with a Vulkan instance, and what I'm seeing has me rather confused. IDXGIResource appears to be declared, with a number of methods, in include/dxgi.idl. I'm not clear on what exactly an IDL file is, but my impression is it's similar to a specfile, except for headers of C++ interfaces. In any case, none of the methods declared appear to have any definition anywhere in Wine. The logical conclusion would be they're automatically generated stubs. But that doesn't make sense, because the DXGI test at dlls/dxgi/tests/device.c calls IDXGIResource_GetUsage and appears to expect it to succeed, implying that it's implemented *somewhere*. What am I missing?

June 30, 2017

Re: winedump: Add initial support for handling EMF+ records

by Piotr Caban

On 06/30/17 17:50, Dmitry Timoshkov wrote: > Piotr Caban <piotr(a)codeweavers.com> wrote: > >> #define EMRCASE(x) case x: printf("%-20s %08x\n", #x, length); break >> +#define EMRPLUSCASE(x) case x: printf(" %-20s %04x %08x\n", #x, header->Flags, header->Size); break; > > ';' at the end is redundant. EMRCASE macro intentionally omits it. > >> + /* Hand EMF+ records */ >> + if (length >= 16 && !memcmp((char*)PRD(offset + 12, sizeof(unsigned int)), "EMF+", 4)) > > A typo in the comment. Thanks, I'll send a fixed version.

June 30, 2017

Re: winedump: Add initial support for handling EMF+ records

by Dmitry Timoshkov

Piotr Caban <piotr(a)codeweavers.com> wrote: > #define EMRCASE(x) case x: printf("%-20s %08x\n", #x, length); break > +#define EMRPLUSCASE(x) case x: printf(" %-20s %04x %08x\n", #x, header->Flags, header->Size); break; ';' at the end is redundant. EMRCASE macro intentionally omits it. > + /* Hand EMF+ records */ > + if (length >= 16 && !memcmp((char*)PRD(offset + 12, sizeof(unsigned int)), "EMF+", 4)) A typo in the comment. -- Dmitry.

June 30, 2017

Re: [PATCH 1/9 v3] gdiplus: Add partial support for GdipDrawImagePointsRect on metafile

by Piotr Caban

On 06/30/17 16:46, Dmitry Timoshkov wrote: > Piotr Caban <piotr.caban(a)gmail.com> wrote: > >>> Even internally gdiplus shouldn't do this kind of hacks IMO, if there is >>> a need for a shortcut for a particular encoder class id it's better to >>> add a helper. Have a look at the encoder/decoder tests how it's supposed >>> to look like. >> I've done it this way because I don't think we should go through >> enumerating all supported formats internally. > > Why not? Mainly because it unnecessarily complicates the code. Also I don't see any advantages from doing it this way.

June 30, 2017

Re: [PATCH 1/9 v3] gdiplus: Add partial support for GdipDrawImagePointsRect on metafile

by Dmitry Timoshkov

Piotr Caban <piotr.caban(a)gmail.com> wrote: > > Even internally gdiplus shouldn't do this kind of hacks IMO, if there is > > a need for a shortcut for a particular encoder class id it's better to > > add a helper. Have a look at the encoder/decoder tests how it's supposed > > to look like. > I've done it this way because I don't think we should go through > enumerating all supported formats internally. Why not? > How about using > encode_image_png function directly? I personally don't like it, this is not a performance critical code. While looking at this I noticed that 'clsid' parameter in encode_image_func() is unused, that's probably a leftover from previous implementation. -- Dmitry.

June 30, 2017

Re: [PATCH 1/9 v3] gdiplus: Add partial support for GdipDrawImagePointsRect on metafile

by Piotr Caban

On 06/30/17 16:14, Dmitry Timoshkov wrote: > Piotr Caban <piotr(a)codeweavers.com> wrote: > >> +static GpStatus METAFILE_CreateCompressedImageStream(GpImage *image, IStream **stream, DWORD *size) >> +{ >> + static const CLSID png_clsid = { 0x557cf406, 0x1a04, 0x11d3, >> + { 0x9a, 0x73, 0x0, 0x0, 0xf8, 0x1e, 0xf3, 0x2e } }; >> + LARGE_INTEGER zero; >> + STATSTG statstg; >> + GpStatus stat; >> + HRESULT hr; >> + >> + *size = 0; >> + >> + hr = CreateStreamOnHGlobal(NULL, TRUE, stream); >> + if (FAILED(hr)) return hresult_to_status(hr); >> + >> + stat = GdipSaveImageToStream(image, *stream, &png_clsid, NULL); > > Even internally gdiplus shouldn't do this kind of hacks IMO, if there is > a need for a shortcut for a particular encoder class id it's better to > add a helper. Have a look at the encoder/decoder tests how it's supposed > to look like. I've done it this way because I don't think we should go through enumerating all supported formats internally. How about using encode_image_png function directly? Thanks, Piotr

June 30, 2017

Re: [PATCH 3/9 v3] gdiplus: Add support for ImageAttributes when drawing image to metafile

by Piotr Caban

On 06/30/17 16:11, Dmitry Timoshkov wrote: > Piotr Caban <piotr(a)codeweavers.com> wrote: > >> @@ -259,7 +278,7 @@ static DWORD METAFILE_AddObjectId(GpMetafile *metafile) >> id = 0; >> for (i=1; i<sizeof(metafile->objects_table)/sizeof(metafile->objects_table[0]); i++) >> { >> - if (metafile->objects_table[id] < metafile->objects_table[i]) >> + if (metafile->objects_table[id] > metafile->objects_table[i]) > > This looks strange to change this right in the next patch. I've made a mistake while rebasing the patches. Thanks for catching it. Thanks, Piotr

June 30, 2017

Re: [PATCH 1/9 v3] gdiplus: Add partial support for GdipDrawImagePointsRect on metafile

by Dmitry Timoshkov

Piotr Caban <piotr(a)codeweavers.com> wrote: > +static GpStatus METAFILE_CreateCompressedImageStream(GpImage *image, IStream **stream, DWORD *size) > +{ > + static const CLSID png_clsid = { 0x557cf406, 0x1a04, 0x11d3, > + { 0x9a, 0x73, 0x0, 0x0, 0xf8, 0x1e, 0xf3, 0x2e } }; > + LARGE_INTEGER zero; > + STATSTG statstg; > + GpStatus stat; > + HRESULT hr; > + > + *size = 0; > + > + hr = CreateStreamOnHGlobal(NULL, TRUE, stream); > + if (FAILED(hr)) return hresult_to_status(hr); > + > + stat = GdipSaveImageToStream(image, *stream, &png_clsid, NULL); Even internally gdiplus shouldn't do this kind of hacks IMO, if there is a need for a shortcut for a particular encoder class id it's better to add a helper. Have a look at the encoder/decoder tests how it's supposed to look like. -- Dmitry.

June 30, 2017

Re: [PATCH 3/9 v3] gdiplus: Add support for ImageAttributes when drawing image to metafile

by Dmitry Timoshkov

Piotr Caban <piotr(a)codeweavers.com> wrote: > @@ -259,7 +278,7 @@ static DWORD METAFILE_AddObjectId(GpMetafile *metafile) > id = 0; > for (i=1; i<sizeof(metafile->objects_table)/sizeof(metafile->objects_table[0]); i++) > { > - if (metafile->objects_table[id] < metafile->objects_table[i]) > + if (metafile->objects_table[id] > metafile->objects_table[i]) This looks strange to change this right in the next patch. -- Dmitry.

June 30, 2017

Re: [PATCH 3/4 v2] gdiplus: Add partial support for GdipDrawImagePointsRect on metafile

by Vincent Povirk

+ draw_image_record->SrcRect.Width = units_to_pixels(srcwidth, srcUnit, metafile->image.xres);; + draw_image_record->SrcRect.Height = units_to_pixels(srcheight, srcUnit, metafile->image.yres);; One semicolon is probably enough. I think we should put a little more effort into object management up front. I would start it by having the Add*Object functions return an id to the caller, and adding a ReleaseObjects function to indicate that the current objects are no longer needed. For now, we could just implement this as a counter that we reset to 0.

June 29, 2017

Re: [PATCH 3/4] gdiplus: Add partial support for GdipDrawImagePointsRect on metafile

by Piotr Caban

On 06/29/17 18:21, Vincent Povirk wrote: > On Thu, Jun 29, 2017 at 5:49 AM, Piotr Caban <piotr.caban(a)gmail.com> wrote: >> I've done some basic tests and EmfPlusImage record is used for texture >> brushes. In my brush test image was stored in PNG format. I've moved the >> code to separate functions so it can be reused later. > > OK, I must be missing something in the spec that makes this possible, > or the spec is wrong. In that case, I'll review the earlier version. > I guess you misunderstood me - the PNG is stored in EmfPlusImage that is not stored inside EmfPlusObject. This means that the code can be reused for brush texture implementation. I think this makes v2 attempt better. Thanks, Piotr

June 29, 2017

Re: [PATCH] libs/wine: Use Windows collation when sorting and comparing strings

by Alexandre Julliard

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > This patch fixes bugs 10767 and 32490, amongst other bugs. > It also fixes subkey sorting issues in regedit's treeview control. > > From: Dmitry Timoshkov <dtimoshkov(a)codeweavers.com> > > Signed-off-by: Hugh McMaster <hugh.mcmaster(a)outlook.com> > --- > dlls/kernel32/tests/locale.c | 9 +++---- > libs/wine/collation.c | 60 ++++++++++++++++++++++---------------------- > 2 files changed, 34 insertions(+), 35 deletions(-) That's a generated file, changes would have to be made in the generating script instead (tools/make_unicode). -- Alexandre Julliard julliard(a)winehq.org

June 29, 2017

Re: [PATCH] msi: Fix a buffer overrun.

by Austin English

On Thu, Jun 29, 2017 at 12:09 AM, Zebediah Figura <z.figura12(a)gmail.com> wrote: > Fixes https://bugs.winehq.org/show_bug.cgi?id=43257 > > Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com> > --- > dlls/msi/package.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/dlls/msi/package.c b/dlls/msi/package.c > index bf6ae10..3a75a1c 100644 > --- a/dlls/msi/package.c > +++ b/dlls/msi/package.c > @@ -1812,17 +1812,17 @@ INT MSI_ProcessMessage( MSIPACKAGE *package, INSTALLMESSAGE eMessageType, MSIREC > { > WCHAR template_s[1024]; > WCHAR *template_rec, *template; > - DWORD length; > > LoadStringW(msi_hInstance, IDS_INFO, template_s, 1024); > > - res = MSI_RecordGetStringW(record, 0, NULL, &length); > + res = MSI_RecordGetStringW(record, 0, NULL, &len); > if (res != ERROR_SUCCESS && res != ERROR_MORE_DATA) > return res; > len++; > template_rec = msi_alloc(len * sizeof(WCHAR)); > if (!template_rec) return ERROR_OUTOFMEMORY; > - MSI_RecordGetStringW(record, 0, template_rec, &length); > + MSI_RecordGetStringW(record, 0, template_rec, &len); > + len++; > > template = msi_alloc((len + strlenW(template_s)) * sizeof(WCHAR)); > if (!template) return ERROR_OUTOFMEMORY; > -- > 2.7.4 > > > Works for me, thanks. -- -Austin GPG: 14FB D7EA A041 937B

June 29, 2017

Re: [PATCH 3/4] gdiplus: Add partial support for GdipDrawImagePointsRect on metafile

by Vincent Povirk

On Thu, Jun 29, 2017 at 5:49 AM, Piotr Caban <piotr.caban(a)gmail.com> wrote: > I've done some basic tests and EmfPlusImage record is used for texture > brushes. In my brush test image was stored in PNG format. I've moved the > code to separate functions so it can be reused later. OK, I must be missing something in the spec that makes this possible, or the spec is wrong. In that case, I'll review the earlier version.

June 29, 2017

Re: [PATCH 3/4] gdiplus: Add partial support for GdipDrawImagePointsRect on metafile

by Piotr Caban

On 06/28/17 21:07, Vincent Povirk wrote: > I don't fully understand the spec, so I could be wrong about this, but > I think for texture brushes we'll need the ability to create an > EmfPlusImage structure without an EmfPlusObject record. I've done some basic tests and EmfPlusImage record is used for texture brushes. In my brush test image was stored in PNG format. I've moved the code to separate functions so it can be reused later. Thanks, Piotr

June 29, 2017

Re: [PATCH 1/6] include: Support wine_dbgstr_longlong in tests

by Michael Stefaniuc

Hello Alistair, On 06/29/2017 02:43 AM, Alistair Leslie-Hughes wrote: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > include/wine/test.h | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/include/wine/test.h b/include/wine/test.h > index af602c0..d8e5490 100644 > --- a/include/wine/test.h > +++ b/include/wine/test.h > @@ -68,6 +68,7 @@ extern const char *wine_dbgstr_wn( const WCHAR *str, int n ); > extern const char *wine_dbgstr_guid( const GUID *guid ); > extern const char *wine_dbgstr_rect( const RECT *rect ); > static inline const char *wine_dbgstr_w( const WCHAR *s ) { return wine_dbgstr_wn( s, -1 ); } > +extern const char *wine_dbgstr_longlong( ULONGLONG ll ); > > /* strcmpW is available for tests compiled under Wine, but not in standalone > * builds under Windows, so we reimplement it under a different name. */ > @@ -541,6 +542,17 @@ const char *wine_dbgstr_rect( const RECT *rect ) > return res; > } > > +const char *wine_dbgstr_longlong( ULONGLONG ll ) > +{ > + char *res; The other functions have an empty line after the variable declarations. > + res = get_temp_buffer( 17 ); > + if (sizeof(ll) > sizeof(unsigned long) && ll >> 32) > + sprintf(res, "%lx%08lx", (unsigned long)(ll >> 32), (unsigned long)ll); Either place a space after the opening parenthesis and before the closing one or don't but please stay consistent inside a function. The file prefers the variant with the spaces. > + else > + sprintf(res, "%lx", (unsigned long)ll); > + return res; The other debug functions with variable length output release the unused part of the temp buffer. You can waste up to 15 bytes here. > +} > + > /* Find a test by name */ > static const struct test *find_test( const char *name ) > { > thanks bye michael

June 29, 2017

Re: [PATCH] libs/wine: Use Windows collation when sorting and comparing strings

by Marvin

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=31953 Your paranoid android. === w7u (32 bit locale) === locale.c:2927: Test failed: qsort using lstrcmpA failed for element 6 locale.c:2927: Test failed: qsort using lstrcmpA failed for element 7 locale.c:2927: Test failed: qsort using lstrcmpA failed for element 8 locale.c:2927: Test failed: qsort using lstrcmpA failed for element 9 locale.c:2927: Test failed: qsort using lstrcmpA failed for element 10 locale.c:2935: Test failed: qsort using CompareStringA failed for element 6 locale.c:2935: Test failed: qsort using CompareStringA failed for element 7 locale.c:2935: Test failed: qsort using CompareStringA failed for element 8 locale.c:2935: Test failed: qsort using CompareStringA failed for element 9 locale.c:2935: Test failed: qsort using CompareStringA failed for element 10 locale.c:2943: Test failed: qsort using sort keys failed for element 6 locale.c:2943: Test failed: qsort using sort keys failed for element 7 locale.c:2943: Test failed: qsort using sort keys failed for element 8 locale.c:2943: Test failed: qsort using sort keys failed for element 9 locale.c:2943: Test failed: qsort using sort keys failed for element 10

June 29, 2017

Re: [2/7] webservices: Add an index to the static dictionary.

by Hans Leidekker

On Wed, 2017-06-28 at 16:22 +0200, Alexandre Julliard wrote: > 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? Thanks for catching that. It was a bug in the script used to generate the index.

June 29, 2017

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

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 __________________________

June 28, 2017

Re: [6/6] wsdapi/tests: Add tests for WSDXMLGetValueFromAny.

by Marvin

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

June 28, 2017

Re: [4/6] wsdapi: Implement IWSDUdpAddress_Get/SetSockAddr.

by Marvin

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

June 28, 2017

Re: [3/6] wsdapi: Implement IWSDUdpAddress_Get/SetMessageType.

by Marvin

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

June 28, 2017