September 2015 - Wine-Devel

Re: [PATCH 06/10] dxgi: Set BufferUsage in dxgi_swapchain_GetDesc().
by Henri Verbeet Sept. 14, 2015

Sept. 14, 2015

Not that DXGI_USAGE_RENDER_TARGET_OUTPUT would necessarily be a bad default, but it's probably better to either just store a copy of the original DXGI_SWAP_CHAIN_DESC structure in the swapchain, and read it again here, or to pass the additional fields to wined3d somehow.

1 0

Re: [PATCH 1/2] user32: Implement semi-stub for FlashWindowEx. (resend)
by Marvin Sept. 14, 2015

Sept. 14, 2015

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=16701 Your paranoid android. === w8 (32 bit win) === win.c:3278: Test failed: message 0118 available === w864 (32 bit win) === win.c:3417: Test failed: hwnd 0006012C message 0118 === w1064 (32 bit win) === win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1010000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x81c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x40000/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1050000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1410000: window rect 0,0-1024,768 === wvistau64 (64 bit win) === win.c:7539: Test failed: transparent window didn't get WM_NCHITTEST message win.c:7540: Test failed: button under static window didn't get WM_LBUTTONUP === w864 (64 bit win) === win.c:1210: Test failed: first call to SetShellWindow(hwnd1) win.c:1212: Test failed: wrong shell window: 0000000000020118 win.c:1249: Test failed: SetShellWindow(hwnd4) win.c:1251: Test failed: wrong shell window: 0000000000020118 - expected hwnd4 win.c:1254: Test failed: wrong next window for hwnd4: 000000000002010C - expected 0 win.c:1265: Test failed: wrong shell window: 0000000000020118 - expected hwnd4 win.c:1275: Test failed: wrong next window for hwnd4 after SetWindowPos(): 000000000002010C - expected 0 === w1064 (64 bit win) === win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1010000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x81c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x40000/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1050000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1410000: window rect 0,0-1024,768

1 0

Windows 10 available for testing on the WineTestBot
by Francois Gouget Sept. 14, 2015

Sept. 14, 2015

The WineTestBot now has two new VM hosts to compensate for running fewer tasks per host. More importantly it now has a Windows 10 Home 64 bit VM (w1064). You can submit jobs to it at any time and I made it a base VM so Wine patches that fail on Windows 10 are detected. However you will not find a Windows 10 column on test.winehq.org because about 68 failures and a 24MB report Windows 10 reports are getting thrown away. With over 200 000 lines, the ntdll:rtl failure below is responsible for most of the spam: rtl.c:879: Test failed: test: 0x000000231 RtlUniform(&seed (seed == 79ddd72)) returns b60129c, expected 62bb10ce So some effort will be needed to remedy the situation. As a starting point here is a full WineTest report I collected on a Windows 10 install running on real hardware and a list of the failing tests. http://fgouget.free.fr/tmp/winetest32.report 2 advapi32:security 2 failures 1 cmd:batch 3 crypt32:base64 1 crypt32:chain 1 d2d1:d2d1 8 d3d8:device 4 d3d9:d3d9ex 2 ddraw:ddraw2 2 ddraw:dsurface 8 ddraw:overlay 12 dssenh:dssenh 9 dxgi:device 4 hlink:hlink 28 ieframe:webbrowser 18 kernel32:console 12 kernel32:loader 7 kernel32:locale 1 kernel32:process 1 kernel32:thread 4 kernel32:toolhelp 2 kernel32:volume 5 mmdevapi:capture 6 mmdevapi:render 1 msctf:inputprocessor 30 mshtml:htmldoc 1 mshtml:htmllocation 1 urlmon:protocol 2 msvcrt:locale (English locale) 1 msxml3:httpreq 10 ntdll:pipe 200010 ntdll:rtl 39 ntdll:threadpool 39 ole32:marshal 2 oleaut32:olepicture 3 rpcrt4:server 65 rsaenh:rsaenh 2 secur32:schannel 1 setupapi:devinst 30 shell32:ebrowser 3 shell32:shelllink 7 shell32:shlexec 1 shell32:shlfolder 2 shlwapi:assoc 6 taskschd:scheduler 1 urlmon:misc 12 urlmon:protocol 19 urlmon:uri 27 user32:broadcast 1 user32:class 55 user32:cursoricon 2 user32:monitor 1 user32:dde 6 user32:msg 10 user32:win 15 usp10:usp10 16 wininet:http 4 wininet:internet 4 winmm:midi 2 wintrust:crypt 1 ws2_32:sock 2 wscript.exe:run -- Francois Gouget <fgouget(a)free.fr>

1 0

wined3d public api cleanup
by Riccardo Bortolato Sept. 14, 2015

Sept. 14, 2015

Here is a follow up on the small fixes I sent the other day. I'm storing the wined3d texture and sub level in the d3dX surfaces/volumes and this allows to go further with the removal of surfaces/volumes from the public api. With these commits I also introduce a temporary function to handle mapping for surfaces and volumes which I hope it will gradually handle more of that eventually delegating only bound checks (and maybe other minor things) to helper functions. Finally the remaining volume-related exported functions are removed. What to do with buffers is still unclear to me. Ciao, Riccardo

3 14

Re: [PATCH] riched20: Implement set all caps(Ctrl+Shift+A) shortcut key.
by Nikolay Sivov Sept. 14, 2015

Sept. 14, 2015

On 14.09.2015 12:25, Jactry Zeng wrote: > + for (i = 0; i < len; i++) > + { > + WCHAR tmp = bufferW[i]; > + > + if (isalphaW(tmp)) > + { > + if (editor->bCaps) > + bufferW[i] = toupperW(tmp); > + else > + bufferW[i] = tolowerW(tmp); > + } > + } Hi, won't struprW/strlwrW work here? I don't see why isalphaW check is important.

1 0

Re: [2/5](resend/rebased)hidclass.sys: Add USB Descriptor parsing
by Alexandre Julliard Sept. 14, 2015

Sept. 14, 2015

Aric Stewart <aric(a)codeweavers.com> writes: > + if (!caps->IsRange) > + { > + static char out[30]; > + unsigned int i; > + strcpy(out, "[ "); > + for (i = 0; i < caps->usage_count; i++) > + strcat(out, wine_dbg_sprintf("0x%x ", caps->u.NotRange.Usage[i])); > + strcat(out,"]"); > + return out; Having a static buffer defeats the purpose of using wine_dbg_sprintf. > +static void debug_feature(struct feature *feature) > +{ > + if (!feature) > + return; > + TRACE("[\n\t type %s [%i]; %s; %s; %s; %s; %s; %s; %s; %s; %s\n\t %s\n]\n", Please don't put \n in traces, that messes up the output. If you truly need multiple lines, use separate TRACE statements. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 10/10] dxgi/tests: Remove leftover debug comment.
by Marvin Sept. 14, 2015

Sept. 14, 2015

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=16696 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 09/10] dxgi/tests: Add missing DestroyWindow() call in test_createswapchain().
by Marvin Sept. 14, 2015

Sept. 14, 2015

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 Sept. 14, 2015

Sept. 14, 2015

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 Sept. 13, 2015

Sept. 13, 2015

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 Sept. 13, 2015

Sept. 13, 2015

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 Sept. 13, 2015

Sept. 13, 2015

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 Sept. 13, 2015

Sept. 13, 2015

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 Sept. 13, 2015

Sept. 13, 2015

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 Sept. 12, 2015

Sept. 12, 2015

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 Sept. 11, 2015

Sept. 11, 2015

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 Sept. 11, 2015

Sept. 11, 2015

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 Sept. 11, 2015

Sept. 11, 2015

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 Sept. 11, 2015

Sept. 11, 2015

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 Sept. 11, 2015

Sept. 11, 2015

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 Sept. 11, 2015

Sept. 11, 2015

> 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 Sept. 11, 2015

Sept. 11, 2015

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 Sept. 11, 2015

Sept. 11, 2015

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 Sept. 11, 2015

Sept. 11, 2015

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 Sept. 11, 2015

Sept. 11, 2015

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 Sept. 10, 2015

Sept. 10, 2015

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 Sept. 10, 2015

Sept. 10, 2015

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 Sept. 10, 2015

Sept. 10, 2015

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 Sept. 10, 2015

Sept. 10, 2015

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 Sept. 10, 2015

Sept. 10, 2015

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 Sept. 10, 2015

Sept. 10, 2015

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 Sept. 10, 2015

Sept. 10, 2015

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 Sept. 10, 2015

Sept. 10, 2015

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 Sept. 10, 2015

Sept. 10, 2015

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 Sept. 10, 2015

Sept. 10, 2015

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 Sept. 9, 2015

Sept. 9, 2015

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 Sept. 9, 2015

Sept. 9, 2015

-----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 Sept. 9, 2015

Sept. 9, 2015

-----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 Sept. 9, 2015

Sept. 9, 2015

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 Sept. 9, 2015

Sept. 9, 2015

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 Sept. 9, 2015

Sept. 9, 2015

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 Sept. 9, 2015

Sept. 9, 2015

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 Sept. 8, 2015

Sept. 8, 2015

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 Sept. 8, 2015

Sept. 8, 2015

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 Sept. 8, 2015

Sept. 8, 2015

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(a)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 Sept. 8, 2015

Sept. 8, 2015

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 Sept. 8, 2015

Sept. 8, 2015

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 Sept. 8, 2015

Sept. 8, 2015

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 Sept. 8, 2015

Sept. 8, 2015

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 Sept. 8, 2015

Sept. 8, 2015

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