- wine-devel - winehq.org

Re: [PATCH 09/10] dxgi/tests: Add missing DestroyWindow() call in test_createswapchain().
by Marvin 14 Sep '15

14 Sep '15

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=16695 Your paranoid android. === w1064 (32 bit device) === device.c:1134: Test failed: Got unexpected hr 0, test 16. device.c:1134: Test failed: Got unexpected hr 0x87a0001, test 39. === w1064 (64 bit device) === device.c:1134: Test failed: Got unexpected hr 0, test 16. device.c:1188: Test failed: Got usage 160, expected 60, test 28, buffer 1. device.c:1188: Test failed: Got usage 160, expected 60, test 29, buffer 2. device.c:1188: Test failed: Got usage 160, expected 60, test 35, buffer 1. device.c:1188: Test failed: Got usage 160, expected 60, test 36, buffer 2. device.c:1134: Test failed: Got unexpected hr 0, test 39. device.c:1188: Test failed: Got usage 160, expected 60, test 41, buffer 15. device.c:1188: Test failed: Got usage 160, expected 60, test 42, buffer 15.

1 0

Re: [PATCH 08/10] dxgi/tests: Check that DXGI surface implements ID3D11Texture2D.
by Marvin 14 Sep '15

14 Sep '15

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=16694 Your paranoid android. === w1064 (32 bit device) === device.c:1133: Test failed: Got unexpected hr 0, test 16. device.c:1133: Test failed: Got unexpected hr 0x87a0001, test 39. === w1064 (64 bit device) === device.c:1133: Test failed: Got unexpected hr 0, test 16. device.c:1187: Test failed: Got usage 160, expected 60, test 28, buffer 1. device.c:1187: Test failed: Got usage 160, expected 60, test 29, buffer 2. device.c:1187: Test failed: Got usage 160, expected 60, test 35, buffer 1. device.c:1187: Test failed: Got usage 160, expected 60, test 36, buffer 2. device.c:1133: Test failed: Got unexpected hr 0, test 39. device.c:1187: Test failed: Got usage 160, expected 60, test 41, buffer 15. device.c:1187: Test failed: Got usage 160, expected 60, test 42, buffer 15.

1 0

Re: [06/10] msvcirt: Implement strstreambuf::setbuf
by Marvin 13 Sep '15

13 Sep '15

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=16671 Your paranoid android. === w2000pro (32 bit msvcirt) === msvcirt.c:1521: Test failed: wrong buffer end, expected 0022FC70 + 0x7fffffff got FFFFFFFF msvcirt.c:1527: Test failed: wrong put end, expected 0022FC70 + 0x7fffffff got FFFFFFFF === wxppro (32 bit msvcirt) === msvcirt.c:1521: Test failed: wrong buffer end, expected 0022FC70 + 0x7fffffff got FFFFFFFF msvcirt.c:1527: Test failed: wrong put end, expected 0022FC70 + 0x7fffffff got FFFFFFFF === w2003std (32 bit msvcirt) === msvcirt.c:1521: Test failed: wrong buffer end, expected 0022FC70 + 0x7fffffff got FFFFFFFF msvcirt.c:1527: Test failed: wrong put end, expected 0022FC70 + 0x7fffffff got FFFFFFFF

1 0

Re: [05/10] msvcirt: Implement strstreambuf::doallocate
by Marvin 13 Sep '15

13 Sep '15

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=16670 Your paranoid android. === w2000pro (32 bit msvcirt) === msvcirt.c:1517: Test failed: wrong buffer end, expected 0022FC70 + 0x7fffffff got FFFFFFFF msvcirt.c:1523: Test failed: wrong put end, expected 0022FC70 + 0x7fffffff got FFFFFFFF === wxppro (32 bit msvcirt) === msvcirt.c:1517: Test failed: wrong buffer end, expected 0022FC70 + 0x7fffffff got FFFFFFFF msvcirt.c:1523: Test failed: wrong put end, expected 0022FC70 + 0x7fffffff got FFFFFFFF === w2003std (32 bit msvcirt) === msvcirt.c:1517: Test failed: wrong buffer end, expected 0022FC70 + 0x7fffffff got FFFFFFFF msvcirt.c:1523: Test failed: wrong put end, expected 0022FC70 + 0x7fffffff got FFFFFFFF

1 0

Re: [03/10] msvcirt: Implement strstreambuf::freeze
by Marvin 13 Sep '15

13 Sep '15

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=16669 Your paranoid android. === w2000pro (32 bit msvcirt) === msvcirt.c:1513: Test failed: wrong buffer end, expected 0022FC70 + 0x7fffffff got FFFFFFFF msvcirt.c:1519: Test failed: wrong put end, expected 0022FC70 + 0x7fffffff got FFFFFFFF === wxppro (32 bit msvcirt) === msvcirt.c:1513: Test failed: wrong buffer end, expected 0022FC70 + 0x7fffffff got FFFFFFFF msvcirt.c:1519: Test failed: wrong put end, expected 0022FC70 + 0x7fffffff got FFFFFFFF === w2003std (32 bit msvcirt) === msvcirt.c:1513: Test failed: wrong buffer end, expected 0022FC70 + 0x7fffffff got FFFFFFFF msvcirt.c:1519: Test failed: wrong put end, expected 0022FC70 + 0x7fffffff got FFFFFFFF

1 0

Re: [02/10] msvcirt: Implement strstreambuf constructors and destructor
by Marvin 13 Sep '15

13 Sep '15

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=16668 Your paranoid android. === w2000pro (32 bit msvcirt) === msvcirt.c:1510: Test failed: wrong buffer end, expected 0022FC70 + 0x7fffffff got FFFFFFFF msvcirt.c:1516: Test failed: wrong put end, expected 0022FC70 + 0x7fffffff got FFFFFFFF === wxppro (32 bit msvcirt) === msvcirt.c:1510: Test failed: wrong buffer end, expected 0022FC70 + 0x7fffffff got FFFFFFFF msvcirt.c:1516: Test failed: wrong put end, expected 0022FC70 + 0x7fffffff got FFFFFFFF === w2003std (32 bit msvcirt) === msvcirt.c:1510: Test failed: wrong buffer end, expected 0022FC70 + 0x7fffffff got FFFFFFFF msvcirt.c:1516: Test failed: wrong put end, expected 0022FC70 + 0x7fffffff got FFFFFFFF

1 0

Re: po: German translation: Fix hyphenation
by Julian Rüger 13 Sep '15

13 Sep '15

Sorry for being late, had a busy week. I realize they are already in, but I have some remarks anyway. I fully agree with most of these. There are some examples of ugly translations in there, though. (Not your fault of course) It would be great if you/we could fix some of these, while we're at it. > #: crypt32.rc:105 > msgid "Unsigned CMC Request" > -msgstr "Unsignierte CMC Antwort" > +msgstr "Unsignierte-CMC-Antwort" First hyphen is wrong, that's an adjective and a noun. #: crypt32.rc:110 msgid "PKCS 7 Signed" -msgstr "PKCS 7 signiert" +msgstr "PKCS-7-signiert" #: crypt32.rc:111 msgid "PKCS 7 Enveloped" -msgstr "PKCS 7 umhüllt" +msgstr "PKCS-7-umhüllt" [... and similar] These feel wrong. I'm not sure what would be correct, but I suspect "PKCS-7, signiert" or "[Umhülltes/Signiertes] PKCS-7" would be correct. (These are descriptions of file types to open, right?) #: crypt32.rc:150 cryptui.rc:134 msgid "Windows System Component Verification" -msgstr "Windows System Komponenten Verifizierung" +msgstr "Windows-System-Komponenten-Verifizierung" [... and 2 similar] "Windows-Systemkomponentenverifizierung" would be grammatically correct, I think. It's a freaking long word though... #: crypt32.rc:160 msgid "IP security IKE intermediate" -msgstr "Dazwischenliegende IP Sicherheits-IKE" +msgstr "Dazwischenliegende IP-Sicherheits-IKE" Something like "temporäre" or "Übergangs-..." would better reflect the meaning. Dazwischenliegend is just wrong. I remember not having anything better, so I left these alone. Ideas? #: winerror.mc:3536 msgid "Security package error.\n" -msgstr "Sicherheitspaket Fehler.\n" +msgstr "Sicherheitspaket-Fehler.\n" "Sicherheitspakets-Fehler"? "Fehler im Sicherheitspaket"? #: winerror.mc:3701 msgid "Not all objects could be exported.\n" @@ -6844,9 +6844,9 @@ msgstr "" "Protokollierung und Benutzeroberfläche für die oberen Befehle anpassen:\n" "\t/l[*][i|w|e|a|r|u|c|m|o|p|v|][+|!] Protokolldatei\n" "\t/q{|n|b|r|f|n+|b+|b-}\n" -"MSI Service registrieren:\n" +"MSI-Service registrieren:\n" "\t/y\n" -"Registrierung des MSI Service aufheben:\n" +"Registrierung des MSI-Service aufheben:\n" While we're at it, this should be "MSI-Dienst", imho. #: msvidc32.rc:29 msgid "Wine Video 1 video codec" -msgstr "Wine Video 1 Video Codec" +msgstr "Wine-Video-1-Video-Codec" "Videocodec" seems to be a word (https://de.wikipedia.org/wiki/Videocodec ), but I would just say "Wine-Video-1-Codec". Still feels clumsy somehow... #: shdoclc.rc:28 msgid "Wine Internet Explorer" -msgstr "Wine Internet Explorer" +msgstr "Wine-Internet-Explorer" While technically right, this looks "wrong" somehow. Stichwort: Eigenname? -"$d aktuelles Datum $e Escape $g > Zeichen\n" -"$l < Zeichen $n aktuelles Laufwerk $p aktueller Pfad\n" +"$d aktuelles Datum $e Escape $g Größerzeichen (>)\n" +"$l Kleinerzeichen (<) $n aktuelles Laufwerk $p aktueller Pfad\n" Nice one! #: ipconfig.rc:49 msgid "Default gateway" -msgstr "Standard Gateway" +msgstr "Standard-Gateway" "Standardgateway"? #: net.rc:37 msgid "The %1 service is starting.\n" -msgstr "Der %1 Dienst startet.\n" +msgstr "Der Dienst %1 startet.\n" Why go half-way? ;) "Der Dienst '%1' startet.\n" #: taskmgr.rc:322 msgid "System Idle Process" -msgstr "Leerlauf Prozess" +msgstr "Leerlauf-Prozess" "Leerlaufprozess" (I think it's OK to copy Windows here) #: winecfg.rc:143 msgid "Windows registration information" -msgstr "Windows Registrierungs-Informationen" +msgstr "Windows-Registrierungs-Informationen" "Registrierungsinformationen"

3 7

Re: [website] Update Debian downloads info
by Jeremy Newman 12 Sep '15

12 Sep '15

Patch looks good. We will also need to update all the other languages and put in a redirect for the /downloads/debian page to the regular downloads page. -N On 07/22/2015 01:43 PM, Rosanne DiMesio wrote: > Updates the Debian links on the Downloads page to point to packages.debian.org and deletes the obsolete WineHQ Debian downloads page. > > > >

8 18

Re: [3/5] comdlg32: Return success from IFileDialog2::AddPlace.
by Marvin 11 Sep '15

11 Sep '15

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=16659 Your paranoid android. === w7u (32 bit itemdlg) === itemdlg: unhandled exception c0000005 at 76A81EA3

1 0

Re: TestBot job 16658 results: [PATCH 3/3] xaudio2: Support looping buffers
by Andrew Eikum 11 Sep '15

11 Sep '15

On Fri, Sep 11, 2015 at 11:48:29AM -0500, Marvin wrote: > xaudio2_7:xaudio2 start - - > xaudio2.c:244: this is the last test seen before the exception > xaudio2: unhandled exception c0000005 at 00007FFB69944B7D > xaudio2_7:xaudio2 done (3221225477) This isn't caused by this patch. It's a crash only on the 64-bit tests. I'm looking into it. Andrew

1 0

Re: [PATCH 3/3] xaudio2: Support looping buffers
by Marvin 11 Sep '15

11 Sep '15

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=16658 Your paranoid android. === w864 (64 bit xaudio2) === xaudio2: unhandled exception c0000005 at 00007FFB69944B7D

1 0

Re: msi: Fix MsiProvideQualifiedComponent test failure
by Marvin 11 Sep '15

11 Sep '15

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=16657 Your paranoid android. === w7u (32 bit action) === The test timed out

1 0

Re: [PATCH] ddraw/tests: add test for surface preload (v4)
by Marvin 11 Sep '15

11 Sep '15

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=16651 Your paranoid android. === w864 (64 bit ddraw7) === ddraw7: unhandled exception c0000005 at 0000000000000000

1 0

Re: [PATCH 2/2] ddraw/tests: add test for surface preload (v3)
by Stefan Dösinger 11 Sep '15

11 Sep '15

> Am 10.09.2015 um 13:48 schrieb Riccardo Bortolato <rikyz619(a)gmail.com>: > > + memset(&ddsd, 0, sizeof(ddsd)); > + ddsd.dwSize = sizeof(ddsd); > + ddsd.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT; > + ddsd.dwWidth = 64; > + ddsd.dwHeight = 64; > + ddsd.ddsCaps.dwCaps = DDSCAPS_OFFSCREENPLAIN | DDSCAPS_3DDEVICE; > + hr = IDirectDraw7_CreateSurface(ddraw, &ddsd, &surface, NULL); > + ok(SUCCEEDED(hr), "Failed to create surface, hr %#x.\n", hr); > + > + hr = IDirect3DDevice7_GetCaps(device, &device_desc); > + ok(SUCCEEDED(hr), "Failed to get device caps, hr %#x.\n", hr); > + cubemap_supported = !!(device_desc.dpcTriCaps.dwTextureCaps & D3DPTEXTURECAPS_CUBEMAP); > + > + IDirectDrawSurface7_Release(surface); This surface isn't used anywhere. I'd prefer if you add a comment that says that surfaces other than textures cause a segfault if they're passed to PreLoad. I think the best place is to put this somewhere near the test table.

1 0

Re: [1/2] d3dx9_36: Implement D3DXGetShaderInputSemantics (try 2)
by Matteo Bruni 11 Sep '15

11 Sep '15

2015-09-10 10:53 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > patch by Christian Costa > > Change to use 1u << 31 > > > Changelog: > d3dx9_36: Implement D3DXGetShaderInputSemantics > > > Best Regards > Alistair Leslie-Hughes Petty bickering aside, in general sending patches with git send-email makes so that I can easily inline my comments in the code. Sending your own patches yourself makes so that I'm replying to the actual patch author, which usually is the one who should update the patch according to my review. You're free to ignore those points but that doesn't help with my will to put the effort required to review the patches. Anyway, this patch requires some cleanup (most obviously, using the appropriate defines like D3DSP_REGTYPE_SHIFT instead of all those magic numbers). Also I'm interested in seeing tests with pixel shaders, especially shader model 1 and 2 pixel shaders.

3 3

Re: [PATCH 1/2] oledlg: Improve menu items localization for OleUIAddVerbMenuW()
by Akihiro Sagawa 11 Sep '15

11 Sep '15

On Tue, 08 Sep 2015 16:45:18 +0300, Nikolay Sivov wrote: > --- a/dlls/oledlg/oledlg.rc > +++ b/dlls/oledlg/oledlg.rc > @@ -30,7 +30,9 @@ STRINGTABLE > IDS_NOTOLEMOD "File does not appear to be a valid OLE module. Unable to register OLE control." > IDS_NOTOLEMODCAPTION "Add Control" > IDS_VERBMENU_OBJECT "&Object" > + IDS_VERBMENU_OBJECT_WITH_NAME "%s &Object" > IDS_VERBMENU_CONVERT "&Convert..." > + IDS_VERBMENU_SINGLEVERB_OBJECT "%1 %2 &Object" This patch has been commited, but you may want to use %1, instead of %s, for IDS_VERBMENU_OBJECT_WITH_NAME. Akihiro Sagawa

2 3

Re: [PATCH 2/2] ddraw/tests: add test for surface preload (v3)
by Marvin 11 Sep '15

11 Sep '15

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=16632 Your paranoid android. === w864 (64 bit ddraw7) === ddraw7: unhandled exception c0000005 at 0000000000000000

1 0

Re: [PATCH 1/2] ddraw/tests: add test for surface preload (v2)
by Marvin 11 Sep '15

11 Sep '15

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=16628 Your paranoid android. === w864 (64 bit ddraw7) === ddraw7: unhandled exception c0000005 at 0000000000000000

1 0

Re: [2/2] d3dx9_36: Implement D3DXGetShaderOutputSemantics (try 2)
by Matteo Bruni 10 Sep '15

10 Sep '15

2015-09-10 10:53 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > Hi, > > > Changelog: > d3dx9_36: Implement D3DXGetShaderInputSemantics > > > Best Regards > Alistair Leslie-Hughes Is it correct that this is your patch and not Christian's? Just doublechecking.

2 1

Re: [4/4] oleaut32/tests: Add a test to show that support for coercion to arrays of variants is specific to vararg methods.
by Marvin 10 Sep '15

10 Sep '15

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=16613 Your paranoid android. === w2000pro (32 bit tmarshal) === tmarshal.c:1629: Test failed: IDispatch_Invoke failed with error 0x80020008 === wxppro (32 bit tmarshal) === tmarshal.c:1629: Test failed: IDispatch_Invoke failed with error 0x80020008 === w2003std (32 bit tmarshal) === tmarshal.c:1629: Test failed: IDispatch_Invoke failed with error 0x80020008 === wvistau64 (32 bit tmarshal) === tmarshal.c:1629: Test failed: IDispatch_Invoke failed with error 0x80020008 === w2008s64 (32 bit tmarshal) === tmarshal.c:1629: Test failed: IDispatch_Invoke failed with error 0x80020008 === w7u (32 bit tmarshal) === tmarshal.c:1629: Test failed: IDispatch_Invoke failed with error 0x80020008 === w8 (32 bit tmarshal) === tmarshal.c:1629: Test failed: IDispatch_Invoke failed with error 0x80020008 === wvistau64 (64 bit tmarshal) === tmarshal.c:1629: Test failed: IDispatch_Invoke failed with error 0x80020008 === w2008s64 (64 bit tmarshal) === tmarshal.c:1629: Test failed: IDispatch_Invoke failed with error 0x80020008

1 0

Re: [3/4] oleaut32: Add support for handling VT_VARIANT|VT_ARRAY|VT_BYREF argument type. Resend.
by Marvin 10 Sep '15

10 Sep '15

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=16612 Your paranoid android. === w2000pro (32 bit tmarshal) === tmarshal.c:1605: Test failed: IDispatch_Invoke failed with error 0x80020008 === wxppro (32 bit tmarshal) === tmarshal.c:1605: Test failed: IDispatch_Invoke failed with error 0x80020008 === w2003std (32 bit tmarshal) === tmarshal.c:1605: Test failed: IDispatch_Invoke failed with error 0x80020008 === wvistau64 (32 bit tmarshal) === tmarshal.c:1605: Test failed: IDispatch_Invoke failed with error 0x80020008 === w2008s64 (32 bit tmarshal) === tmarshal.c:1605: Test failed: IDispatch_Invoke failed with error 0x80020008 === w7u (32 bit tmarshal) === tmarshal.c:1605: Test failed: IDispatch_Invoke failed with error 0x80020008 === w8 (32 bit tmarshal) === tmarshal.c:1605: Test failed: IDispatch_Invoke failed with error 0x80020008 === wvistau64 (64 bit tmarshal) === tmarshal.c:1605: Test failed: IDispatch_Invoke failed with error 0x80020008 === w2008s64 (64 bit tmarshal) === tmarshal.c:1605: Test failed: IDispatch_Invoke failed with error 0x80020008

1 0

Re: [2/4] oleaut32/tests: Add another test for calling a varargs method. Resend.
by Marvin 10 Sep '15

10 Sep '15

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=16611 Your paranoid android. === w2000pro (32 bit tmarshal) === tmarshal.c:1606: Test failed: IDispatch_Invoke failed with error 0x80020008 === wxppro (32 bit tmarshal) === tmarshal.c:1606: Test failed: IDispatch_Invoke failed with error 0x80020008 === w2003std (32 bit tmarshal) === tmarshal.c:1606: Test failed: IDispatch_Invoke failed with error 0x80020008 === wvistau64 (32 bit tmarshal) === tmarshal.c:1606: Test failed: IDispatch_Invoke failed with error 0x80020008 === w2008s64 (32 bit tmarshal) === tmarshal.c:1606: Test failed: IDispatch_Invoke failed with error 0x80020008 === w7u (32 bit tmarshal) === tmarshal.c:1606: Test failed: IDispatch_Invoke failed with error 0x80020008 === w8 (32 bit tmarshal) === tmarshal.c:1606: Test failed: IDispatch_Invoke failed with error 0x80020008 === wvistau64 (64 bit tmarshal) === tmarshal.c:1606: Test failed: IDispatch_Invoke failed with error 0x80020008 === w2008s64 (64 bit tmarshal) === tmarshal.c:1606: Test failed: IDispatch_Invoke failed with error 0x80020008

1 0

Re: [1/2] d3dx9_36: Implement D3DXGetShaderInputSemantics (try 2)
by Nikolay Sivov 10 Sep '15

10 Sep '15

It's preferred to have original author submitting his own work. Christian, ping?

5 7

Re: gdi32/tests: Avoid excessive traces for fonts with OS/2 version 4 tables
by Marvin 10 Sep '15

10 Sep '15

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=16629 Your paranoid android. === build (build) === Make failed

1 0

Re: [PATCH 6/8] wined3d: replace wined3d_surface_preload with wined3d_texture_preload
by Henri Verbeet 10 Sep '15

10 Sep '15

On 9 September 2015 at 12:23, Riccardo Bortolato <rikyz619(a)gmail.com> wrote: > static void WINAPI d3d9_surface_PreLoad(IDirect3DSurface9 *iface) > { > struct d3d9_surface *surface = impl_from_IDirect3DSurface9(iface); > + struct d3d9_texture *texture = surface->texture; > > TRACE("iface %p.\n", iface); > > + /* Standalone surfaces can't be in D3DPOOL_MANAGED */ > + if (!texture) > + return; > + > wined3d_mutex_lock(); > - wined3d_surface_preload(surface->wined3d_surface); > + wined3d_texture_preload(texture->wined3d_texture); > wined3d_mutex_unlock(); > } > This isn't necessarily wrong, but it may be too complicated. In particular, at some point we'll have to do maps for e.g. off-screen plain surfaces as well, and then you can't avoid getting the wined3d texture from somewhere. That probably means either creating an implicit d3d9 texture for those surfaces, or just storing a pointer to the wined3d texture in the d3d9 surface. So I'd like to see map()/unmap() before preload().

2 1

Re: po: Update Lithuanian translation
by Nikolay Sivov 10 Sep '15

10 Sep '15

Not specific to Lithuanian, I just want to mention context this new translatable string is in, that could help translators: > #: oledlg.rc:36 > -#, fuzzy > -#| msgid "&Object" > msgid "%1 %2 &Object" > -msgstr "&Objektas" > +msgstr "%1 %2 &objektas" %1 here is a verb that application provides - an action performed on Object (e.g. Open), %2 is for application provided object name/type action is performed on. So for English it could be something like "Open Bitmap Object". Some locales use different word order, that's why I used indexed argument format, see for example Korean https://bugs.winehq.org/show_bug.cgi?id=39243: > "test \ac1c\ccb4 verb(&O)" 'test' is object type, and 'verb' is a string for verb.

1 0

Re: [PATCH 5/8] ddraw/tests: add test for surface preload
by Marvin 10 Sep '15

10 Sep '15

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=16604 Your paranoid android. === w8 (32 bit ddraw7) === ddraw7: unhandled exception c0000005 at 68084F1E

1 0

Re: [PATCH 4/8] d3d9/tests: add test for surface preload
by Marvin 10 Sep '15

10 Sep '15

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=16603 Your paranoid android. === w2000pro (32 bit device) === device: unhandled exception c0000005 at 0041DAE4 === wxppro (32 bit device) === device: unhandled exception c0000005 at 0041DAE4 === w2003std (32 bit device) === device: unhandled exception c0000005 at 0041DAE4 === wvistau64 (32 bit device) === device: unhandled exception c0000005 at 0041DAE4 === w2008s64 (32 bit device) === device: unhandled exception c0000005 at 0041DAE4 === w7u (32 bit device) === device: unhandled exception c0000005 at 0041DAE4 === wvistau64 (64 bit device) === device: unhandled exception c0000005 at 0000000000419CD8 === w2008s64 (64 bit device) === device: unhandled exception c0000005 at 0000000000419CD8

1 0

Re: msi: Check HKLM/Software/Classes/Installer/Components path while looking for components
by Marvin 09 Sep '15

09 Sep '15

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=16596 Your paranoid android. === w2008s64 (32 bit action) === action.c:5915: Test failed: MsiProvideQualifiedCompontent returned 1607

1 0

Re: [PATCH 4/8] d3d9/tests: add test for surface preload
by Stefan Dösinger 09 Sep '15

09 Sep '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I have some nitpicky style comments. I don't demand that they are addressed, I'm ok with the patch as it is if Henri accepts it. > + IDirect3DSurface9 *backbuffer, *stencilsurface, *offscreensurface, *rendertarget, *rendertarget2; You shouldn't need the two rendertarget variables. In fact, one common surface variable should do, and I don't think it would make the test more difficult to read. > + hr = IDirect3DDevice9_GetRenderTarget(device, 0, &rendertarget); > + ok(SUCCEEDED(hr), "GetRenderTarget failed, hr %#x.\n", hr); > + IDirect3DSurface9_PreLoad(rendertarget); > + IDirect3DSurface9_Release(rendertarget); We already know from other tests that on device creation backbuffer 0 is the render target. I don't think it's necessary to explicitly test render target 0. > + hr = IDirect3DDevice9_GetBackBuffer(device, 0, 0, 0, &backbuffer); "D3DBACKBUFFER_TYPE_MONO" would be better than "0". Yeah, I know many other tests use 0, and I just sent a patch that shows that this parameter is just ignored... Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV8JlBAAoJEN0/YqbEcdMwNCkP/2aqOA8gTfOb1kE4GkaiKRYk L6sks0mVbtu0nDG/futVUEFniYzQEJNNOabBi/2vcIWFKIOpGALlKGFxbXc3MRC/ +TEIMYq9p1iOsDL1T3tMx+tR39vfG3nFh+FNcZe0nDzT1PmWU5egAdp+IXzY/rR1 qPMQiyFF3ppbvgPi16WAWvnDqHao4+YGoAUFtiiZEBKF8+xA3LiUimuyJnaHYUWj 6caXL1e/DLE/6o7dlJr1YbDmA6IDUYAi029ANv45Upyhf8VCBknpQ1YShRJ+Wt6m g96I/lRtLCpYq8Y8lLTrE6ZD9/8eRkUIxt8jzw8s+gpGtg1wwaR4Y+pzUkrqSRfR OyTzXAFDTI7hNbHfeUHw1EkrT/Ef2H66g9eoMZYVgDJM9ZmfHvgwENPjClTRO2nZ 5jCt14lhZD3Cpdw8+K6AqgPZVtZGyVs4Z0pkO9w7pcfLHTtuWAKh7NfikzXqzyAE zBJ/PtOxdY5BooCZ7ZPuQ0Dblz7wt11m+t6Y7+Jkni0qeH+EetDXDaL4G+ZbmV4V 1gZu5QOaFwNDTIrOU8W94R66oCeAx2YryQgejk4PmHN3UHO3GuQ5irUQlfOGZi/z WO2YZcU3+wCAdZXopgE7kIkaBE+Y2VWKtBUgLGPeiglApaq5SfKncALa5iPACpzN bmSeigvhzA2FKICkLYil =9uRC -----END PGP SIGNATURE-----

1 0

Re: [PATCH 5/8] ddraw/tests: add test for surface preload
by Stefan Dösinger 09 Sep '15

09 Sep '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-09-09 um 19:02 schrieb Riccardo Bortolato: > + hr = IDirectDraw7_SetCooperativeLevel(ddraw, window, DDSCL_NORMAL); > + ok(SUCCEEDED(hr), "Failed to set cooperative level, hr %#x.\n", hr); > + > + if (FAILED(IDirectDraw7_QueryInterface(ddraw, &IID_IDirect3D7, (void **)&d3d))) > + { > + skip("D3D interface is not available, skipping test.\n"); > + goto done; > + } > + > + hr = IDirect3D7_EnumDevices(d3d, enum_devtype_cb, &hal_ok); > + ok(SUCCEEDED(hr), "Failed to enumerate devices, hr %#x.\n", hr); > + if (hal_ok) > + devtype = &IID_IDirect3DTnLHalDevice; > + > + memset(&z_fmt, 0, sizeof(z_fmt)); > + hr = IDirect3D7_EnumZBufferFormats(d3d, devtype, enum_z_fmt, &z_fmt); > + if (FAILED(hr) || !z_fmt.dwSize) > + { > + skip("No depth buffer formats available, skipping test.\n"); > + goto done; > + } > ... There is a helper function called create_device for this. > + IDirect3DDevice7_PreLoad(device, surface); This incarnation of PreLoad returns a value. It's probably always D3D_OK, but please test it for success / failure. Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV8JT4AAoJEN0/YqbEcdMw4zQP/23zlgm39IW26Wga1gKx4gmJ 2nCC01cpnjsr6TxOH/TYdWNxbXncmG45UlPbCe3H2TU57Aro/dcDAAG4epswuhNU 0rd7TMgkwhUJ+6PDgiYUGdhab30Oem0IvWdS+Z8RNZAdwarpcsbQgIvvpMDMiRgF sNkpCdr2aFVJbjUU9c0sgswumQxOCgok1Z4s6cSOHDK8UmRMRDob1E9U/3QQ77d2 JdsZYeAsTjxWzznX4S77+SklIUaF+ga2noTqOzUf4IHZhJc/2KgMW/r2ZmRYAHxH FyP6E02aVhnhD+PjH3lCBQXGvdQ+oE40Bvtt8ZMMvWP9JkS4ZtkLOC24UYD4jt03 4zPVt1WvqZ7LQFEKjKSfEZMG9wRkMYu/69YVxy5A+QgBiVPLyW2cNTk8FbKRG9mU C5ctjIwhgWVzldSv2kLNeuSDgFr+ybo9BuvBySjzHSabvXaJ8jAsj30zG5UwPOmV e/FjZUzhrK+oAFGPSeZvHauoE14gskPR2V0jNV7h3gXfwvy2thwYWOksS6QihpA1 Rx67RgS8uxre7VfxsqCQsFl8irE/wmKYsGIpqMGYiAFNETCigFuz8nmDBx0I4Oqo ZGmOYATtU09Ap8WVEtcwSLdHbVRy9UF/aStRI1dAeWcFcXxXdEZvop7jWaNMaEmZ V90SEh1KkRgOew5ZkDXp =RHsN -----END PGP SIGNATURE-----

1 0

Re: [PATCH] xaudio2: Use ffmpeg to convert non-PCM formats
by Henri Verbeet 09 Sep '15

09 Sep '15

On 9 September 2015 at 17:26, Andrew Eikum <aeikum(a)codeweavers.com> wrote: > I've discussed other options with people on IRC, including: > > Build and distribute our own Windows FFmpeg package, or ask the user to > install a Windows FFmpeg package in their wineprefix, instead of relying > on the system FFmpeg. Maybe a workable solution, but we'd have to build > and distribute yet another package, or rely on a 3rd party to do so. > There may also be optimization concerns with a package built for Windows > instead of natively on Linux/OSX. > > Find a different WMA decoding library. While one exists (libwmapro), it > is simply pulled out of FFmpeg and converted for use on iPods. It's > several years of out date with FFmpeg's WMA decoder. No other open > source WMA decoder exists that I'm aware of. > > Pull FFmpeg's WMA code out and use it in Wine directly. This would > require a significant amount of effort and ongoing work to pull in > updates. I'm not convinced this is worth the effort. > Mostly for completeness, I think "fix gstreamer" was also mentioned as an option at some point.

1 0

Re: dwrite/tests: Some tests for TranslateColorGlyphRun()
by Marvin 09 Sep '15

09 Sep '15

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=16598 Your paranoid android. === build (build) === Could not copy the patch to the VM: Timed out in create_socket while connecting to testnet.winehq.org:22001:10.42.42.130:4242

1 0

Re: [PATCH 2/3] wineps.drv: Add support for PostScript Format 2 standard glyph names (try 3).
by Huw Davies 09 Sep '15

09 Sep '15

On 8 Sep 2015, at 18:30, Erich E. Hoover wrote: > +WORD get_post2_name_index(BYTE *post2header, DWORD size, WORD index) > +{ > + USHORT numberOfGlyphs = GET_BE_WORD(post2header); > + DWORD offset = (1 + index) * sizeof(USHORT); > + > + if((1 + numberOfGlyphs) * sizeof(USHORT) > size) > + { > + FIXME("Total number of glyphs (%d) exceeds PostScript Format 2 table size (%d)\n", > + numberOfGlyphs, size); > + return 0; /* .notdef */ > + } Personally, I'd remove this check, you only added it because you misunderstood something I suggested. What we actually care about is covered by the check below. > + if(offset + sizeof(USHORT) > size || index >= numberOfGlyphs) > + { > + FIXME("Index '%d' exceeds PostScript Format 2 table size (%d)\n", index, numberOfGlyphs); > + return 0; /* .notdef */ > + } In the failure case we need to not return 0 (.notdef), but should end up using the existing "gxxxx" glyph name. This is because glyphs are shown using the glyphshow PostScript operator, so we need unique names for every glyph. Note though that zero should be returned if the glyph's name really is .notdef. I guess returning 0xffff on failure would work, or something like that. Otherwise, the rest of the series looks good to me. Huw.

1 0

Re: d3dx9_36: Implement D3DXGetShaderOutputSemantics
by Marvin 09 Sep '15

09 Sep '15

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

1 0

Re: [2/2] oleaut32/tests: Add a test to show that support for coercion to arrays of variants is specific to vararg methods.
by Marvin 08 Sep '15

08 Sep '15

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=16571 Your paranoid android. === w2000pro (32 bit tmarshal) === tmarshal.c:1522: Test failed: expected DISP_E_TYPEMISMATCH, got 0x80020008 === wxppro (32 bit tmarshal) === tmarshal.c:1522: Test failed: expected DISP_E_TYPEMISMATCH, got 0x80020008 === w2003std (32 bit tmarshal) === tmarshal.c:1522: Test failed: expected DISP_E_TYPEMISMATCH, got 0x80020008 === wvistau64 (32 bit tmarshal) === tmarshal.c:1522: Test failed: expected DISP_E_TYPEMISMATCH, got 0x80020008 === w2008s64 (32 bit tmarshal) === tmarshal.c:1522: Test failed: expected DISP_E_TYPEMISMATCH, got 0x80020008 === w7u (32 bit tmarshal) === tmarshal.c:1522: Test failed: expected DISP_E_TYPEMISMATCH, got 0x80020008 === w8 (32 bit tmarshal) === tmarshal.c:1522: Test failed: expected DISP_E_TYPEMISMATCH, got 0x80020008 === wvistau64 (64 bit tmarshal) === tmarshal.c:1522: Test failed: expected DISP_E_TYPEMISMATCH, got 0x80020008 === w2008s64 (64 bit tmarshal) === tmarshal.c:1522: Test failed: expected DISP_E_TYPEMISMATCH, got 0x80020008

1 0

Re: [PATCH 2/3] wineps.drv: Add support for PostScript Format 2 standard glyph names.
by Huw Davies 08 Sep '15

08 Sep '15

On 8 Sep 2015, at 17:09, Erich E. Hoover wrote: > This version adds an additional check that the number of glyphs > reported to be in the table fits within the size of the table data. By checking size is big enough for numberOfGlyphs, I meant that you need to check whether size is big enough to read the first two bytes of the extended (version 2) table. Huw.

1 0

FW: [PATCH] msxml3: treat namespace as attribute in IXMLDOMElement::getAttribute (try 2)
by Daniel Lehman 08 Sep '15

08 Sep '15

Anything I need to add or change on this? https://source.winehq.org/patches/data/114075 thanks Daniel -----Original Message----- From: wine-patches [mailto:wine-patches-bounces@winehq.org] On Behalf Of Daniel Lehman Sent: Friday, August 28, 2015 2:49 PM To: 'wine-patches(a)winehq.org' Subject: [PATCH] msxml3: treat namespace as attribute in IXMLDOMElement::getAttribute (try 2) Try 2: add tests for failures

1 0

RFC - msacm32: Quit on unsupported destination format in PCM_FormatSuggest
by Bruno Jesus 08 Sep '15

08 Sep '15

Since this DLL is far away from my comprehension I'm first sending this to wine-devel. Current code [1] suggest that only WAVE_FORMAT_PCM is supported so do not allow the function to succeed if the destination format is not PCM. Fixes bug https://bugs.winehq.org/show_bug.cgi?id=14193 [1] 858 if (!(adfs->fdwSuggest & ACM_FORMATSUGGESTF_WFORMATTAG)) { 859 if (adfs->pwfxSrc->wFormatTag != WAVE_FORMAT_PCM) { 860 WARN("not possible\n"); 861 return ACMERR_NOTPOSSIBLE; 862 } 863 adfs->pwfxDst->wFormatTag = adfs->pwfxSrc->wFormatTag; 864 }

2 1

Re: [3/3] oleaut32/tests: Add a test to show that support for coercion to arrays of variants is specific to vararg methods.
by Marvin 08 Sep '15

08 Sep '15

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=16567 Your paranoid android. === w2000pro (32 bit tmarshal) === tmarshal.c:1558: Test failed: expected DISP_E_TYPEMISMATCH, got 0x80020008 tmarshal.c:1629: Test failed: IDispatch_Invoke failed with error 0x80020008 === wxppro (32 bit tmarshal) === tmarshal.c:1558: Test failed: expected DISP_E_TYPEMISMATCH, got 0x80020008 tmarshal.c:1629: Test failed: IDispatch_Invoke failed with error 0x80020008 === w2003std (32 bit tmarshal) === tmarshal.c:1558: Test failed: expected DISP_E_TYPEMISMATCH, got 0x80020008 tmarshal.c:1629: Test failed: IDispatch_Invoke failed with error 0x80020008 === wvistau64 (32 bit tmarshal) === tmarshal.c:1558: Test failed: expected DISP_E_TYPEMISMATCH, got 0x80020008 tmarshal.c:1629: Test failed: IDispatch_Invoke failed with error 0x80020008 === w2008s64 (32 bit tmarshal) === tmarshal.c:1558: Test failed: expected DISP_E_TYPEMISMATCH, got 0x80020008 tmarshal.c:1629: Test failed: IDispatch_Invoke failed with error 0x80020008 === w7u (32 bit tmarshal) === tmarshal.c:1558: Test failed: expected DISP_E_TYPEMISMATCH, got 0x80020008 tmarshal.c:1629: Test failed: IDispatch_Invoke failed with error 0x80020008 === w8 (32 bit tmarshal) === tmarshal.c:1558: Test failed: expected DISP_E_TYPEMISMATCH, got 0x80020008 tmarshal.c:1629: Test failed: IDispatch_Invoke failed with error 0x80020008 === wvistau64 (64 bit tmarshal) === tmarshal.c:1558: Test failed: expected DISP_E_TYPEMISMATCH, got 0x80020008 tmarshal.c:1629: Test failed: IDispatch_Invoke failed with error 0x80020008 === w2008s64 (64 bit tmarshal) === tmarshal.c:1558: Test failed: expected DISP_E_TYPEMISMATCH, got 0x80020008 tmarshal.c:1629: Test failed: IDispatch_Invoke failed with error 0x80020008

1 0

Re: [2/3] oleaut32: Add support for handling VT_VARIANT|VT_ARRAY|VT_BYREF argument type.
by Marvin 08 Sep '15

08 Sep '15

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=16566 Your paranoid android. === w2000pro (32 bit tmarshal) === tmarshal.c:1605: Test failed: IDispatch_Invoke failed with error 0x80020008 === wxppro (32 bit tmarshal) === tmarshal.c:1605: Test failed: IDispatch_Invoke failed with error 0x80020008 === w2003std (32 bit tmarshal) === tmarshal.c:1605: Test failed: IDispatch_Invoke failed with error 0x80020008 === wvistau64 (32 bit tmarshal) === tmarshal.c:1605: Test failed: IDispatch_Invoke failed with error 0x80020008 === w2008s64 (32 bit tmarshal) === tmarshal.c:1605: Test failed: IDispatch_Invoke failed with error 0x80020008 === w7u (32 bit tmarshal) === tmarshal.c:1605: Test failed: IDispatch_Invoke failed with error 0x80020008 === w8 (32 bit tmarshal) === tmarshal.c:1605: Test failed: IDispatch_Invoke failed with error 0x80020008 === wvistau64 (64 bit tmarshal) === tmarshal.c:1605: Test failed: IDispatch_Invoke failed with error 0x80020008 === w2008s64 (64 bit tmarshal) === tmarshal.c:1605: Test failed: IDispatch_Invoke failed with error 0x80020008

1 0

Re: [1/3] oleaut32/tests: Add another test for calling a varargs method.
by Marvin 08 Sep '15

08 Sep '15

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=16565 Your paranoid android. === w2000pro (32 bit tmarshal) === tmarshal.c:1606: Test failed: IDispatch_Invoke failed with error 0x80020008 === wxppro (32 bit tmarshal) === tmarshal.c:1606: Test failed: IDispatch_Invoke failed with error 0x80020008 === w2003std (32 bit tmarshal) === tmarshal.c:1606: Test failed: IDispatch_Invoke failed with error 0x80020008 === wvistau64 (32 bit tmarshal) === tmarshal.c:1606: Test failed: IDispatch_Invoke failed with error 0x80020008 === w2008s64 (32 bit tmarshal) === tmarshal.c:1606: Test failed: IDispatch_Invoke failed with error 0x80020008 === w7u (32 bit tmarshal) === tmarshal.c:1606: Test failed: IDispatch_Invoke failed with error 0x80020008 === w8 (32 bit tmarshal) === tmarshal.c:1606: Test failed: IDispatch_Invoke failed with error 0x80020008 === wvistau64 (64 bit tmarshal) === tmarshal.c:1606: Test failed: IDispatch_Invoke failed with error 0x80020008 === w2008s64 (64 bit tmarshal) === tmarshal.c:1606: Test failed: IDispatch_Invoke failed with error 0x80020008

1 0

Re: PATCH: widl: implement move-if-changed logic
by Jacek Caban 08 Sep '15

08 Sep '15

Hi Marcus, On 09/03/15 13:07, Marcus Meissner wrote: > From d8df64a7261bc0febcdd48d4ed818dc1f36f3471 Mon Sep 17 00:00:00 2001 > From: Marcus Meissner <meissner(a)suse.de> > Date: Thu, 3 Sep 2015 12:11:13 +0200 > Subject: [PATCH] widl: implement a move-if-changed logic > > This avoids unnecessary rebuilds if the generated code by widl > does not change. While I like the idea and it would often save a bug chunk of build time, I don't think it would work well with make. If you don't touch output file, then following make invocation will execute widl again, which is undesired. Thanks, Jacek

2 1

Re: configure.ac: Fix breakage caused by -Werror=unused-variable
by Alexandre Julliard 08 Sep '15

08 Sep '15

Daniel Santos <daniel.santos(a)pobox.com> writes: > When configuring with CFLAGS="-Wunused-variable -Werror", the configure > test for HAVE_PNG_SET_EXPAND_GRAY_1_2_4_TO_8 fails with unused variable. Running configure with -Werror is not a good idea. Is there a particular reason why you need this? -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: ntdll: wrap getdirentries around getdents on NetBSD
by Ken Thomases 07 Sep '15

07 Sep '15

On Sep 7, 2015, at 2:40 AM, Austin English <austinenglish(a)gmail.com> wrote: > For https://bugs.winehq.org/show_bug.cgi?id=18166 getdirentries() is only used if USE_GETDENTS is not defined. USE_GETDENTS is defined at the top of the file in the #ifdef linux block that your patch is right after. So, why not just #define USE_GETDENTS for NetBSD, too? No need for a wrapper. -Ken

1 0

Re: [PATCH 1/3] wineps.drv: Add support for PostScript Format 1 glyph names.
by Huw Davies 07 Sep '15

07 Sep '15

On Fri, Sep 04, 2015 at 10:28:50PM -0600, Erich E. Hoover wrote: > + size = GetFontData(hdc, MS_MAKE_TAG('p','o','s','t'), 0, NULL, 0); > + if(size == 0 || size == GDI_ERROR) > + return; Here you'll want to check that size >= sizeof(*post_header). In the 2nd patch you don't check that this size includes numberOfGlyphs. In the 3rd patch the size checks are repeated three times, it should be possible to simplify that. Huw.

1 0

Re: WS2_32: Proper WSACleanup implementation using wineserver help (try 2)
by Bruno Jesus 06 Sep '15

06 Sep '15

On Sun, Aug 30, 2015 at 11:04 PM, Matt Durgavich <mattdurgavich(a)gmail.com> wrote: > Fixes some tests and also bug 32910 > > From 6b34d1b9f6cfa491a26b9c36e395c3b180b5ceea Mon Sep 17 00:00:00 2001 > From: Matt <matt(a)wymzee.com> > Date: Thu, 27 Aug 2015 23:43:59 -0400 > Subject: [PATCH] WS2_32: Proper WSACleanup implementation using wineserver > help I see the patch is pending and I can think of a few new issues. First two minor issues that are not related which are the DLL name in uppercase in the email subject and the patch has 5 whitespace issues (whitespace after the end of a line). The main issue is that it does not seem to work as we expect it does. And that is proved by the need of adding those new todo lines in the send() and closesocket() calls. For example in the closesocket call: 2977 fd = get_sock_fd(s, FILE_READ_DATA, NULL); 2978 if (fd >= 0) 2979 { ... Despite being closed in the server the get_sock_fd still succeeds in the DLL returning a no longer valid handle. It looks like some out of sync problem with the ntdll cache. Need someone else to help with that because I have no idea how to improve the patch. Best wishes, Bruno

1 0

Re: Who decides what are good translations war: Update German translation.
by Hin-Tak Leung 06 Sep '15

06 Sep '15

------------------------------ On Sat, Sep 5, 2015 7:10 AM BST Alex Henrie wrote: >2015-09-02 7:47 GMT-06:00 Thomas Kaltenbrunner <tkaltenbrunner(a)opc.de>: >> BTW. Who decides what are good translations? > >My German is terrible, so I will not attempt to comment on specific >German translations. However, I'd like to point out that I used >Windows as a reference to translate Wine into Catalan. I did not copy >translations word-for-word, but I noticed that Windows consistently >used some very specific terminology that is less common in Linux. The >list I came up with was: > >byte -> byte >default -> per defecte >font size -> cos de lletra >front (of window stack) -> primer terme >graph -> gràfic >handle -> identificador >item -> element >move -> desplaçar >pool -> agrupació >prompt -> indicador >set -> definir >settings -> opcions, configuració >suppress -> reprimir >use -> utilitzar > >Windows also had some grossly horrible translations, like "tancar" for >"shut down". I ignored those. My point though is that if you are >having a hard time deciding which German word is appropriate for Wine, >I would give a lot of consideration to which German word Windows uses. > >-Alex > > That's perhaps the most relevant response in this thread - remember, the stated aim of wine is to be bug-for-bug compatible with windows. Wine does not try to be a 'better' windows. There is no 'good' translations, but just what localised windows does. Different from localised windows is a flaw, even if it is arguably 'better'. one might choose to have a flaw occasionally, but a flaw it is, if it is different from localised windows.

5 5

Re: [PATCH] shell32: Fix SHFileOperation(FO_MOVE) on non-exist files.
by Marvin 06 Sep '15

06 Sep '15

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=16527 Your paranoid android. === wvistau64 (32 bit shlfileop) === shlfileop.c:818: Test failed: Expected ERROR_CANCELLED or DE_DIFFDIR === wvistau64 (64 bit shlfileop) === shlfileop.c:818: Test failed: Expected ERROR_CANCELLED or DE_DIFFDIR

1 0

Re: po: Update German translation.
by Florian Pelz 05 Sep '15

05 Sep '15

Sorry for sending to the wrong list. On 08/28/2015 03:03 PM, Florian Pelz wrote: > On 08/28/2015 02:35 PM, Julian Rüger wrote: >> +"Wine Anwendungsentferner\n" > > This needs a hyphen ("Wine-Anwendungsentferner\n"). >

4 10

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