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

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

Re: [2/6] wsdapi: Implement IWSDUdpAddress_Get/SetPort.

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

June 28, 2017

Re: [1/6] wsdapi: Implement IWSDUdpAddress_GetTransportAddress[Ex].

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

June 28, 2017

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

by Vincent Povirk

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.

June 28, 2017

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

by Piotr Caban

On 06/28/17 20:29, Vincent Povirk wrote: > Can we keep the code for generating an EmfplusImage structure separate > from this? We'll want to reuse it for EmfPlusDrawImage and > EmfPlusTextureBrushOptionalData. Sure, I've sent an updated version of patch. Thanks, Piotr

June 28, 2017

Re: [PATCH v2] gdiplus: Scale widened dashes to the pen width.

by Zebediah Figura

On 06/28/2017 01:43 PM, Vincent Povirk wrote: > 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); >> } > > The code is redundant and ends up creating an extra point at the end of the path. The loop already ensures that the last point will be on the end of a segment.

June 28, 2017