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

Re: configure.ac: Fix breakage caused by -Werror=unused-variable
by Alexandre Julliard Sept. 8, 2015

Sept. 8, 2015

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

Sept. 7, 2015

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

Sept. 7, 2015

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

Sept. 6, 2015

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

Sept. 6, 2015

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

Sept. 6, 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=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 Sept. 5, 2015

Sept. 5, 2015

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

Re: po: German translation: Fix grammar errors
by Julian Rüger Sept. 4, 2015

Sept. 4, 2015

> #: oleview.rc:110 > msgid "Quit the application. Prompts to save changes" > -msgstr "Anwendung beenden. Frag ob Änderungen zu speichern sind" > +msgstr "Anwendung beenden. Fragt ob Änderungen zu speichern sind" "Fragt, ob ..." There should really be a full stop at the as well. Generally, you're right in not adding it when it's not there in the original, but I wonder why it was left out. Maybe we should add it to both. #: wineconsole.rc:44 msgid "wineconsole: Couldn't parse event id\n" -msgstr "wineconsole: Ereignis-ID konnte nicht geparsed werden\n" +msgstr "wineconsole: Ereignis-ID konnte nicht geparset werden\n" I'm never sure what to do in these cases. Correct German grammar would be "geparst", but that looks just awful... My personal preference is the pretty, but grammatically wrong English ending. I guess my OCD has to live with the pain ;) Let's use the correct case. Agreed?

2 2

d3d8/9 swapchain flip
by Stefan Dösinger Sept. 4, 2015

Sept. 4, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Henri, I'm sending my current swapchain flipping patches for you to look at in case you have any comments. A few notes: *) It doesn't involve the front buffer yet, it only cycles through the back buffers. Patch 8 has a few comments about that. *) The first interesting patch is patch 4. I am updating the wined3d_surface pointers in each d3d9_surface in the swapchain and adjust the d3d9 surface's parents. *) The other interesting parts are patch 7 and 8. If a view is created for a swapchain texture I'm storing the swapchain + buffer index in the view. When the view is used the texture is fetched from the swapchain. Alternatively I could maintain a list of views that are created for each texture and modify the views in present. With the current way we don't have to worry about how many views there are, but it makes looking up the actual texture slightly more expensive. So far this is only implemented for render target views, but the same approach should work for shader resource views. Before sending this I'm going to remove the back buffer type from the wined3d interface. It's not used anywhere according to MSDN, and none of the stereo hacks out there (occulus rift, ati quad buffer, nvidia 3d vision) use it. Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJV6dE/AAoJEN0/YqbEcdMwZQ4P+weZy8ymZAp8pHgMztjuQRIC dUXaVO3hhoj6l6q/a2l27VDPnON81FBUADHG/Mk00MNOi0K/7IlHvKW5cEx54hV6 HsmRdtq1Kp9HLhgDTGJqy2yMhg9K9ugg5+u0ouQUxxxFdhDxhwlwDlfOGQvUkXL8 +SqAM5lB6wnDxVQ5OOlip2yJDEXYimL2e6QQOXaRpyWnciKUqd9Rs1RrFObLCnBK OC7rGpkCg0jmI6cKCsNEUrA+3ihz+zl+E7XU+W/g454oGTO3dKRI68iqrfN1wNB5 JfOzwIyHIdHTZOuuXZ+66Z8qqSxx8XcvyjEiKuN/bnvVCjGB+zLnqi10sKHD8yJv 2FE9AKFb6Kwyty9zLw2AMC/8Ch/Fh0s75TzhDm0cywORDwx94ApSDCF0R+ryQ+h8 QYhTpj187lQum1Egmti7PlHQRVCDv+sblyssdGvwDIYqmyfSoBARCILO08bKSGsd 9teITH2yfYYiChbf05n1aDzYyTwNRf52/p7xSHtfzaSR/U7G/tO7nvpXUuQjoPso je87AM2WJk0JSlfifCUn6qQ4j+aXLftUzzvqPSNRTmhw4uuO7Y1cxg7kp0ORwpC7 nEFrR/AaPJyGg/Hcy69LsNwokv/qlT1FgFrhnZrI2Rauop3dt4rZQSou2id2fo+J OQG8vE6dUux/GGHPIPIk =W1o8 -----END PGP SIGNATURE-----

1 0

Re: wineps.drv: Add glyph names for PostScript Format 1 glyphs (try 2).
by Nikolay Sivov Sept. 4, 2015

Sept. 4, 2015

> +void get_glyph_name(HDC hdc, UINT flags, WORD index, char *name) > { > - /* FIXME */ > + BOOL bIsGlyphIndex = ((flags & ETO_GLYPH_INDEX) == 0); > + > + if (bIsGlyphIndex && index < 258) This is essentially the same as it was on try 1. I still think we shouldn't rely on glyph indices mapped to some specific code range, I don't see any documentation that says it should be mapped like that. I think what we want is to map from WCHAR string to such glyph names directly, and that's why ETO_GLYPH_INDEX case is important - if you get index array initially you fallback to generic glyph names, if you got string then for codepoints that have defined glyphs in your names array you use those, for the rest of codepoints fallback again to generic name. This way we could also extend this lookup when it's decided how to deal with licensed glyph list data.

3 8

Re: reg: Implement binary data add operation
by Alexandre Julliard Sept. 4, 2015

Sept. 4, 2015

Thomas Faller <tfaller1(a)gmx.de> writes: > +static inline BOOL is_xp_or_older(void) > +{ > + DWORD version = GetVersion(); > + if(version < 0x80000000){ > + /* compare major */ > + return (DWORD)(LOBYTE(LOWORD(version))) < 6; > + } > + return TRUE; > +} Do you actually have an app that depends on such a version check? -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH 1/2] reg: simplify root key search
by Stefan Dösinger Sept. 3, 2015

Sept. 3, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This patch still fails to apply with the same error: stefan(a)retina ~/src/wine $ git am /dev/shm/\[PATCH\ 1_2\]\ reg\:\ simplify\ root\ key\ search.eml Applying: reg: simplify root key search /home/stefan/src/wine/.git/rebase-apply/patch:14: trailing whitespace. static const WCHAR short_hklm[] = {'H','K','L','M',0}; /home/stefan/src/wine/.git/rebase-apply/patch:15: trailing whitespace. static const WCHAR short_hkcu[] = {'H','K','C','U',0}; /home/stefan/src/wine/.git/rebase-apply/patch:16: trailing whitespace. static const WCHAR short_hkcr[] = {'H','K','C','R',0}; /home/stefan/src/wine/.git/rebase-apply/patch:17: trailing whitespace. static const WCHAR short_hku[] = {'H','K','U',0}; /home/stefan/src/wine/.git/rebase-apply/patch:18: trailing whitespace. static const WCHAR short_hkcc[] = {'H','K','C','C',0}; error: patch failed: programs/reg/reg.c:22 error: programs/reg/reg.c: patch does not apply Patch failed at 0001 reg: simplify root key search The copy of the patch that failed is found in: /home/stefan/src/wine/.git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". Stefan Am 2015-08-31 um 22:09 schrieb Michel Zou: > Split patch from Jonathan Vollebregt: > https://github.com/jnvsor/wine/commit/ea0e2fc70db6ce4904655ea4a27ee34531d96… > > - --- > programs/reg/reg.c | 85 > +++++++++++++++++++++++++++--------------------------- 1 file > changed, 43 insertions(+), 42 deletions(-) > > > > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJV6Bl1AAoJEN0/YqbEcdMwf+sQAI7u19WiDrPOtniTS00sJZeS mrBSZHvhKlDujZ4iCr4VHyycBzhCmg8peflfgEHRyF9xGx6duy/mzh0JHN3qJFlM r7zbm9wbhFCaH7i4d1JD2a7l9hthow+N3PuPKWk5ox+T+Pe9HaXTQwxUmgB/6YjR xXjkHDEc5GtyBeqxpiskw2W92GWubrMrEJmfmlQQSWfcIZjkUM0MmKCEUCibMu3O bLPOsx1AjD3aQ+S0R50D3s1W1u/yO0tfKa0pGki2pqZRL/72UcbBWNow6F9tZIeD qXaAgNhvn0rc66nMVb7yc//9nN4oN2prBNtrpCtSCCfSgd/Xh47xoq8g3HQUXjHd nNbfSuePuNLvNzu5XhNb0yP5cGCZedU8q7cYcPURn376t25xw22daigpdId3kaS0 KN+gwb2M1PSazPwkjRy94qIX9Kl0NIsJT8dLHZgV0TM7ZrRBy0sa2baqH5jvL+4h pCn9+Kcuyv5jC7Oj/ewNx+9EIRmUf7wOJvgdNocUqwSyHPf7bJwZOysAm4ltk8pq A7RA2qiyicANi34Yf1e8zKG1Fv1M/uYwvjc3Sd8jrTpkn0z9mzijll4R+bcThAXA jdZjA3HTyvoaaENxmKJngb7Xz2o0WBV1WUEjIIUos+md8IV7bCnH0dbCDtE3AQKl u/eABCeasbpTQJ61px7N =V5u2 -----END PGP SIGNATURE-----

2 1

Re: [4/13](try 3)hidclass.sys: Add USB Descriptor parsing
by Andrew Eikum Sept. 3, 2015

Sept. 3, 2015

Sorry for not noticing this before you resent, but you've got some C++ style comments in parse_io_feature. Andrew On Thu, Sep 03, 2015 at 11:19:31AM -0500, Aric Stewart wrote: > More good comments and changes from Henri Verbeet > > --- > dlls/hidclass.sys/Makefile.in | 1 + > dlls/hidclass.sys/descriptor.c | 1163 ++++++++++++++++++++++++++++++++++++++++ > dlls/hidclass.sys/hid.h | 3 + > dlls/hidclass.sys/pnp.c | 37 ++ > 4 files changed, 1204 insertions(+) > create mode 100644 dlls/hidclass.sys/descriptor.c

2 1

Idea of fixing SHFileOperation(FO_MOVE)
by Zhenbo Li Sept. 3, 2015

Sept. 3, 2015

Hello, As I'm working on bug 25207, I found that previous test code (test_move() in shlfileop.c) had some disadvantages 1. Duplicate tests 2. Legacy test code (for Win98 or NT4) 3. Lack of test for Vista or later Windows Versions As more applications are depending on the new behaviours introduced in Vista, IMHO, we should focus on Vista's new behaviour. So I rewrote test_move() to remove code for win98, mark xp behaviour as broken, and expect Vista's behaviour. My next step is to re-implement FO_MOVE operation of SHFileOperation to fix bug 25207. Any suggestion for this? Thank you. -- Have a nice day! Zhenbo Li

2 3

Re: quartz: Simplify a loop and make the code more robust
by Bruno Jesus Sept. 3, 2015

Sept. 3, 2015

On Thu, Sep 3, 2015 at 9:06 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > Sorry, ignore this patch. Current quartz behavior is wrong and should be fixed instead of reinforced.

1 0

Re: [4/13](resend)hidclass.sys: Add USB Descriptor parsing
by Andrew Eikum Sept. 3, 2015

Sept. 3, 2015

A couple small notes inline below. On Wed, Sep 02, 2015 at 07:01:51AM -0500, Aric Stewart wrote: > diff --git a/dlls/hidclass.sys/Makefile.in b/dlls/hidclass.sys/Makefile.in > index 8ed51e6..6e79486 100644 > --- a/dlls/hidclass.sys/Makefile.in > +++ b/dlls/hidclass.sys/Makefile.in > @@ -5,6 +5,7 @@ DELAYIMPORTS = setupapi hid > > C_SRCS = \ > buffer.c \ > + descriptor.c \ > device.c \ > main.c \ > pnp.c > diff --git a/dlls/hidclass.sys/descriptor.c b/dlls/hidclass.sys/descriptor.c > new file mode 100644 > index 0000000..c277dec > --- /dev/null > +++ b/dlls/hidclass.sys/descriptor.c > @@ -0,0 +1,1106 @@ > +/* > + * HID descriptor parsing > + * > + * Copyright (C) 2015 Aric Stewart > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > + */ > + > +#include "config.h" > + > +#include <stdarg.h> > +#include <stdlib.h> > +#define NONAMELESSUNION > +#include "hid.h" > + > +#include "wine/debug.h" > +#include "wine/list.h" > + > +WINE_DEFAULT_DEBUG_CHANNEL(hid); > + > +#define USAGE_MAX 10 > + > +static const char* feature_string[] = > + { "Input", "Output", "Feature" }; > + > +struct caps { > + USAGE UsagePage; > + LONG LogicalMin; > + LONG LogicalMax; > + LONG PhysicalMin; > + LONG PhysicalMax; > + ULONG UnitsExp; > + ULONG Units; > + USHORT BitSize; > + UCHAR ReportID; > + USHORT ReportCount; > + > + BOOLEAN IsRange; > + BOOLEAN IsStringRange; > + BOOLEAN IsDesignatorRange; > + int usage_count; > + union { > + struct { > + USAGE UsageMin; > + USAGE UsageMax; > + USHORT StringMin; > + USHORT StringMax; > + USHORT DesignatorMin; > + USHORT DesignatorMax; > + } Range; > + struct { > + USAGE Usage[USAGE_MAX]; > + USAGE Reserved1; > + USHORT StringIndex; > + USHORT Reserved2; > + USHORT DesignatorIndex; > + USHORT Reserved3; > + } NotRange; > + } DUMMYUNIONNAME; > + > + int Delim; > +}; > + > +struct feature { > + struct list entry; > + struct list col_entry; > + struct caps caps; > + > + HIDP_REPORT_TYPE type; > + BOOLEAN isData; > + BOOLEAN isArray; > + BOOLEAN IsAbsolute; > + BOOLEAN Wrap; > + BOOLEAN Linear; > + BOOLEAN prefState; > + BOOLEAN HasNull; > + BOOLEAN Volatile; > + BOOLEAN BitField; > + > + int index; > + struct collection *collection; > +}; > + > +static const char* collection_string[] = { > + "Physical", > + "Application", > + "Logical", > + "Report", > + "Named Array", > + "Usage Switch", > + "Usage Modifier", > +}; > + > +struct collection { > + struct list entry; > + struct caps caps; > + int index; > + int type; > + struct collection *parent; > + struct list features; > + struct list collections; > +}; > + > +static const char* debugstr_usages(struct caps *caps) > +{ > + if (!caps->IsRange) > + { > + static char out[30]; > + int i; > + strcpy(out, "[ "); > + for (i = 0; i < caps->usage_count; i++) > + strcat(out, wine_dbg_sprintf("%x ", caps->u.NotRange.Usage[i])); > + strcat(out,"]"); > + return out; > + } > + else > + return wine_dbg_sprintf("[%x - %x]", caps->u.Range.UsageMin, caps->u.Range.UsageMax); > +} > + > +static const char* debugstr_stringindex(struct caps *caps) > +{ > + if (!caps->IsStringRange) > + return wine_dbg_sprintf("%i", caps->u.NotRange.StringIndex); > + else > + return wine_dbg_sprintf("[%i - %i]", caps->u.Range.StringMin, caps->u.Range.StringMax); > +} > + > +static const char* debugstr_designatorindex(struct caps *caps) > +{ > + if (!caps->IsDesignatorRange) > + return wine_dbg_sprintf("%i", caps->u.NotRange.DesignatorIndex); > + else > + return wine_dbg_sprintf("[%i - %i]", caps->u.Range.DesignatorMin, caps->u.Range.DesignatorMax); > +} > + > +static const char* debugstr_caps(struct caps *caps) > +{ > + if (!caps) > + return ""; > + return wine_dbg_sprintf("(UsagePage %x; LogicalMin %i; LogicalMax %i; PhysicalMin %i; PhysicalMax %i; UnitsExp %i; Units %i; BitSize %i; ReportID %i; ReportCount %i; Usage %s; StringIndex %s; DesignatorIndex %s; Delim %i;)", > + caps->UsagePage, > + caps->LogicalMin, > + caps->LogicalMax, > + caps->PhysicalMin, > + caps->PhysicalMax, > + caps->UnitsExp, > + caps->Units, > + caps->BitSize, > + caps->ReportID, > + caps->ReportCount, > + debugstr_usages(caps), > + debugstr_stringindex(caps), > + debugstr_designatorindex(caps), > + caps->Delim); > +} > + > +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", > + feature_string[feature->type], > + feature->index, > + (feature->isData)?"Data":"Const", > + (feature->isArray)?"Array":"Var", > + (feature->IsAbsolute)?"Abs":"Rel", > + (feature->Wrap)?"Wrap":"NoWrap", > + (feature->Linear)?"Linear":"NonLinear", > + (feature->prefState)?"PrefStat":"NoPrefState", > + (feature->HasNull)?"HasNull":"NoNull", > + (feature->Volatile)?"Volatile":"NonVolatile", > + (feature->BitField)?"BitField":"Buffered", > + debugstr_caps(&feature->caps)); > +} > + > +static void debug_collection(struct collection *collection) > +{ > + struct feature *fentry; > + struct collection *centry; > + if (TRACE_ON(hid)) > + { > + TRACE("{ %s[%i], %p, %i features, %i collections\n\t %s\n", collection_string[collection->type], collection->index, collection->parent, list_count(&collection->features), list_count(&collection->collections), debugstr_caps(&collection->caps)); > + LIST_FOR_EACH_ENTRY(fentry, &collection->features, struct feature, col_entry) > + debug_feature(fentry); > + LIST_FOR_EACH_ENTRY(centry, &collection->collections, struct collection, entry) > + debug_collection(centry); > + TRACE("}\n"); > + } > +} > + > +static void debug_print_button_cap(const CHAR * type, WINE_HID_ELEMENT *wine_element) > +{ > + if (!wine_element->caps.button.IsRange) > + TRACE("%s Button: %x/%04x: ReportId %i, startBit %i/1\n" , type, > + wine_element->caps.button.UsagePage, > + wine_element->caps.button.u.NotRange.Usage, > + wine_element->caps.value.ReportID, > + wine_element->valueStartBit); > + else > + TRACE("%s Button: %x/[%04x-%04x]: ReportId %i, startBit %i/%i\n" ,type, > + wine_element->caps.button.UsagePage, > + wine_element->caps.button.u.Range.UsageMin, > + wine_element->caps.button.u.Range.UsageMax, > + wine_element->caps.value.ReportID, > + wine_element->valueStartBit, > + wine_element->bitCount); > +} > + > +static void debug_print_value_cap(const CHAR * type, WINE_HID_ELEMENT *wine_element) > +{ > + TRACE("%s Value: %x/%x: ReportId %i, IsAbsolute %i, HasNull %i, " > + "Bit Size %i, ReportCount %i, UnitsExp %i, Units %i, " > + "LogicalMin %i, Logical Max %i, PhysicalMin %i, " > + "PhysicalMax %i -- StartBit %i/%i\n", type, > + wine_element->caps.value.UsagePage, > + wine_element->caps.value.u.NotRange.Usage, > + wine_element->caps.value.ReportID, > + wine_element->caps.value.IsAbsolute, > + wine_element->caps.value.HasNull, > + wine_element->caps.value.BitSize, > + wine_element->caps.value.ReportCount, > + wine_element->caps.value.UnitsExp, > + wine_element->caps.value.Units, > + wine_element->caps.value.LogicalMin, > + wine_element->caps.value.LogicalMax, > + wine_element->caps.value.PhysicalMin, > + wine_element->caps.value.PhysicalMax, > + wine_element->valueStartBit, > + wine_element->bitCount); > +} > + > +static void debug_print_element(const CHAR* type, WINE_HID_ELEMENT *wine_element) > +{ > + if (wine_element->ElementType == ButtonElement) > + debug_print_button_cap(type, wine_element); > + else if (wine_element->ElementType == ValueElement) > + debug_print_value_cap(type, wine_element); > + else > + TRACE("%s: UNKNOWN\n", type); > +} > + > +static void debug_print_report(const char* type, WINE_HID_REPORT *report) > +{ > + int i; > + TRACE("%s REPORT:\n" > + "\tReportID: %i\n" > + "\tdwSize: %i\n" > + "\telementCount: %i\n", > + type, > + report->reportID, > + report->dwSize, > + report->elementCount); > + for (i = 0; i < report->elementCount; i++) > + debug_print_element(type, &report->Elements[i]); > +} > + > +static void debug_print_preparsed(WINE_HIDP_PREPARSED_DATA *data) > +{ > + int i; > + WINE_HID_REPORT *r; > + if (TRACE_ON(hid)) > + { > + TRACE("PREPARSED Data:\n" > + "\tdwSize: %i\n" > + "\tCaps:\n" > + "\t\tUsage: %i\n" > + "\t\tUsagePage: %i\n" > + "\t\tInputReportByteLength: %i\n" > + "\t\tOutputReportByteLength: %i\n" > + "\t\tFeatureReportByteLength: %i\n" > + "\t\tNumberLinkCollectionNodes: %i\n" > + "\t\tNumberInputButtonCaps: %i\n" > + "\t\tNumberInputValueCaps: %i\n" > + "\t\tNumberInputDataIndices: %i\n" > + "\t\tNumberOutputButtonCaps: %i\n" > + "\t\tNumberOutputValueCaps: %i\n" > + "\t\tNumberOutputDataIndices: %i\n" > + "\t\tNumberFeatureButtonCaps: %i\n" > + "\t\tNumberFeatureValueCaps: %i\n" > + "\t\tNumberFeatureDataIndices: %i\n" > + "\tdwInputReportCount: %i\n" > + "\tdwOutputReportCount: %i\n" > + "\tdwFeatureReportCount: %i\n" > + "\tdwOutputReportOffset: %i\n" > + "\tdwFeatureReportOffset: %i\n", > + data->dwSize, > + data->caps.Usage, > + data->caps.UsagePage, > + data->caps.InputReportByteLength, > + data->caps.OutputReportByteLength, > + data->caps.FeatureReportByteLength, > + data->caps.NumberLinkCollectionNodes, > + data->caps.NumberInputButtonCaps, > + data->caps.NumberInputValueCaps, > + data->caps.NumberInputDataIndices, > + data->caps.NumberOutputButtonCaps, > + data->caps.NumberOutputValueCaps, > + data->caps.NumberOutputDataIndices, > + data->caps.NumberFeatureButtonCaps, > + data->caps.NumberFeatureValueCaps, > + data->caps.NumberFeatureDataIndices, > + data->dwInputReportCount, > + data->dwOutputReportCount, > + data->dwFeatureReportCount, > + data->dwOutputReportOffset, > + data->dwFeatureReportOffset); > + > + r = HID_INPUT_REPORTS(data); > + for (i = 0; i < data->dwInputReportCount; i++) > + { > + debug_print_report("INPUT", r); > + r = HID_NEXT_REPORT(data, r); > + } > + r = HID_OUTPUT_REPORTS(data); > + for (i = 0; i < data->dwOutputReportCount; i++) > + { > + debug_print_report("OUTPUT", r); > + r = HID_NEXT_REPORT(data, r); > + } > + r = HID_FEATURE_REPORTS(data); > + for (i = 0; i < data->dwFeatureReportCount; i++) > + { > + debug_print_report("FEATURE", r); > + r = HID_NEXT_REPORT(data, r); > + } > + } > +} > + > +static int getValue(int bsize, int source) > +{ > + int mask = 0xff; > + int negative = 0x80; > + int outofrange = 0x100; > + int value; > + int i; > + > + if (bsize == 4) > + return source; > + > + for (i = 1; i < bsize; i++) > + { > + mask = (mask<<8) + 0xff; > + negative = (negative<<8); > + outofrange = (outofrange<<8); > + } > + value = (source&mask); > + if (value&negative) > + value = -1 * (outofrange - value); > + return value; > +} > + > +void parse_io_feature(int bSize, int itemVal, int bTag, int *feature_index, struct feature *feature) > +{ > + if (bSize <= 0) > + { > + return; > + } > + else > + { > + if ((itemVal & 0x01) == 0) > + feature->isData = TRUE; > + else > + feature->isData = FALSE; //Const > + if ((itemVal & 0x02) == 0) > + feature->isArray= TRUE; > + else > + feature->isArray= TRUE; //Var > + if ((itemVal & 0x04) == 0) > + feature->IsAbsolute = TRUE; > + else > + feature->IsAbsolute = FALSE; //Rel > + if ((itemVal & 0x08) == 0) > + feature->Wrap = FALSE; > + else > + feature->Wrap = TRUE; > + if ((itemVal & 0x10) == 0) > + feature->Linear = TRUE; > + else > + feature->Linear = FALSE; > + if ((itemVal & 0x20) == 0) > + feature->prefState = TRUE; > + else > + feature->prefState = FALSE; > + if ((itemVal & 0x40) == 0) > + feature->HasNull = FALSE; > + else > + feature->HasNull = TRUE; > + > + if (bTag != 0x08) > + { > + if ((itemVal & 0x80) == 0) > + feature->Volatile = FALSE; > + else > + feature->Volatile = TRUE; > + } > + if (bSize > 1) > + { > + if ((itemVal & 0x100) == 0) > + feature->BitField = TRUE; > + else > + feature->BitField = FALSE; //Buffered Bytes > + } > + feature->index = *feature_index; > + *feature_index = *feature_index + 1; > + } > +} > + > +void parse_collection(int bSize, int itemVal, struct collection *collection) > +{ > + if (bSize <= 0) > + return; > + else > + { > + collection->type = itemVal; > + > + if (itemVal >= 0x07 && itemVal <= 0x7F) { > + ERR(" (Reserved %x )\n", itemVal); > + } > + else if (itemVal >= 0x80 && itemVal <= 0xFF) { > + ERR(" (Vendor Defined %x )\n", itemVal); > + } > + } > +} > + > +static void new_caps(struct caps *caps) > +{ > + caps->IsRange = 0; > + caps->IsStringRange = 0; > + caps->IsDesignatorRange = 0; > + caps->usage_count = 0; > +} > + > +int parse_descriptor(BYTE *descriptor, INT index, INT length, INT *feature_index, INT *collection_index, struct collection *collection, struct caps *caps, struct list *features) > +{ > + int i; > + for (i = index; i < length;) > + { > + BYTE b0 = descriptor[i++]; > + int bSize = b0 & 0x03; > + int bType = (b0 >> 2) & 0x03; > + int bTag = (b0 >> 4) & 0x0F; > + > + bSize = (bSize == 3) ? 4 : bSize; > + if (bType == 0x03 && bTag == 0x0F && bSize == 2 && i + 2 < length) > + { > + /* Long data items: Should be unused */ > + ERR("Long Data Item, should be unused\n"); This confused me. Is this a malformed report from the HID or something Wine doesn't yet support? > + } > + else > + { > + int bSizeActual = 0; > + int itemVal = 0; > + int j; > + > + for (j = 0; j < bSize; j++) > + { > + if (i + j < length) > + { > + itemVal += descriptor[i + j] << (8 * j); > + bSizeActual++; > + } > + } > + TRACE(" %x[%i], type %i , tag %i, size %i, val %i\n",b0,i-1,bType, bTag, bSize, itemVal ); > + > + if (bType == 0x00) > + { > + struct feature *feature; > + switch(bTag) > + { > + case 0x08: Here and elsewhere, there's a lot of magic numbers. Do these have names in the standard? Could you make up names for them? TAG_INPUT or something. Or is it more useful to have the raw numbers? > + feature = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*feature)); > + list_add_tail(&collection->features, &feature->col_entry); > + list_add_tail(features, &feature->entry); > + feature->type = HidP_Input; > + parse_io_feature(bSize, itemVal, bTag, feature_index, feature); > + feature->caps = *caps; > + feature->collection = collection; > + new_caps(caps); > + break; > + case 0x09: > + feature = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*feature)); > + list_add_tail(&collection->features, &feature->col_entry); > + list_add_tail(features, &feature->entry); > + feature->type = HidP_Output; > + parse_io_feature(bSize, itemVal, bTag, feature_index, feature); > + feature->caps = *caps; > + feature->collection = collection; > + new_caps(caps); > + break; > + case 0x0B: > + feature = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*feature)); > + list_add_tail(&collection->features, &feature->col_entry); > + list_add_tail(features, &feature->entry); > + feature->type = HidP_Feature; > + parse_io_feature(bSize, itemVal, bTag, feature_index, feature); > + feature->caps = *caps; > + feature->collection = collection; > + new_caps(caps); > + break; > + case 0x0A: Here, the cases are in a different order. That wouldn't matter with symbols, but it struck me with the raw numbers. > + { > + struct collection *subcollection = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(struct collection)); > + list_add_tail(&collection->collections, &subcollection->entry); > + subcollection->parent = collection; > + /* Only set our collection once... > + We do not properly handle composite devices yet. */ > + if (*collection_index == 0) > + collection->caps = *caps; > + subcollection->caps = *caps; > + subcollection->index = *collection_index; > + *collection_index = *collection_index + 1; > + list_init(&subcollection->features); > + list_init(&subcollection->collections); > + new_caps(caps); > + > + parse_collection(bSize, itemVal, subcollection); > + > + i = parse_descriptor(descriptor, i+1, length, feature_index, collection_index, subcollection, caps, features); > + continue; > + } > + case 0x0C: > + return i; > + default: > + ERR("Unknown Tag\n"); Would it be useful to print the tag value here? > + } > + } > + else if (bType == 0x01) > + { > + switch(bTag) > + { > + case 0x00: > + caps->UsagePage = getValue(bSize, itemVal); > + break; > + case 0x01: > + caps->LogicalMin = getValue(bSize, itemVal); > + break; > + case 0x02: > + caps->LogicalMax = getValue(bSize, itemVal); > + break; > + case 0x03: > + caps->PhysicalMin = getValue(bSize, itemVal); > + break; > + case 0x04: > + caps->PhysicalMax = getValue(bSize, itemVal); > + break; > + case 0x05: > + caps->UnitsExp = getValue(bSize, itemVal); > + break; > + case 0x06: > + caps->Units = getValue(bSize, itemVal); > + break; > + case 0x07: > + caps->BitSize = getValue(bSize, itemVal); > + break; > + case 0x08: > + caps->ReportID = getValue(bSize, itemVal); > + break; > + case 0x09: > + caps->ReportCount = getValue(bSize, itemVal); > + break; > + case 0x0A: > + ERR("Push\n"); > + break; > + case 0x0B: > + ERR("Pop\n"); > + break; Are these invalid messages from the HID device, or things wine doesn't yet support? Should they be FIXMEs? > + default: > + ERR("Unknown (bTag: %x, bType: %x)\n", bTag, bType); > + } > + } > + else if (bType == 0x02) > + { > + switch(bTag) > + { > + case 0x00: > + if (caps->usage_count >= USAGE_MAX) > + FIXME("More than %i individual usages defined\n",USAGE_MAX); > + else > + { > + caps->u.NotRange.Usage[caps->usage_count++] = getValue(bSize, itemVal); > + caps->IsRange = FALSE; > + } > + break; > + case 0x01: > + caps->usage_count = 1; > + caps->u.Range.UsageMin = getValue(bSize, itemVal); > + caps->IsRange = TRUE; > + break; > + case 0x02: > + caps->usage_count = 1; > + caps->u.Range.UsageMax = getValue(bSize, itemVal); > + caps->IsRange = TRUE; > + break; > + case 0x03: > + caps->u.NotRange.DesignatorIndex = getValue(bSize, itemVal); > + caps->IsDesignatorRange = FALSE; > + break; > + case 0x04: > + caps->u.Range.DesignatorMin = getValue(bSize, itemVal); > + caps->IsDesignatorRange = TRUE; > + break; > + case 0x05: > + caps->u.Range.DesignatorMax = getValue(bSize, itemVal); > + caps->IsDesignatorRange = TRUE; > + break; > + case 0x07: > + caps->u.NotRange.StringIndex = getValue(bSize, itemVal); > + caps->IsStringRange = FALSE; > + break; > + case 0x08: > + caps->u.Range.StringMin = getValue(bSize, itemVal); > + caps->IsStringRange = TRUE; > + break; > + case 0x09: > + caps->u.Range.StringMax = getValue(bSize, itemVal); > + caps->IsStringRange = TRUE; > + break; > + case 0x0A: > + caps->Delim = getValue(bSize, itemVal); > + break; > + default: > + ERR("Unknown (bTag: %x, bType: %x)\n", bTag, bType); > + } > + } > + else > + ERR("Unknown (bTag: %x, bType: %x)\n", bTag, bType); > + > + i += bSize; > + } > + } > + return i; > +} > + > +static inline void new_report(WINE_HID_REPORT *wine_report, struct feature* feature) > +{ > + wine_report->reportID = feature->caps.ReportID; > + wine_report->dwSize = sizeof(*wine_report) - sizeof(WINE_HID_ELEMENT); > + wine_report->elementCount = 0; > +} > + > +static void build_elements(WINE_HID_REPORT *wine_report, struct feature* feature, DWORD *bitOffset) > +{ > + int i; > + > + if (!feature->isData) > + { > + *bitOffset = *bitOffset + (feature->caps.BitSize * feature->caps.ReportCount); > + return; > + } > + > + for (i = 0; i < feature->caps.usage_count; i++) > + { > + WINE_HID_ELEMENT *wine_element = &wine_report->Elements[wine_report->elementCount]; > + > + wine_element->valueStartBit = *bitOffset; > + if (feature->caps.UsagePage == HID_USAGE_PAGE_BUTTON) > + { > + wine_element->ElementType = ButtonElement; > + wine_element->caps.button.UsagePage = feature->caps.UsagePage; > + wine_element->caps.button.ReportID = feature->caps.ReportID; > + wine_element->caps.button.BitField = feature->BitField; > + wine_element->caps.button.IsRange = feature->caps.IsRange; > + wine_element->caps.button.IsStringRange = feature->caps.IsStringRange; > + wine_element->caps.button.IsDesignatorRange = feature->caps.IsDesignatorRange; > + wine_element->caps.button.IsAbsolute = feature->IsAbsolute; > + if (wine_element->caps.button.IsRange) > + { > + wine_element->bitCount = (feature->caps.u.Range.UsageMax - feature->caps.u.Range.UsageMin) + 1; > + *bitOffset = *bitOffset + wine_element->bitCount; > + wine_element->caps.button.u.Range.UsageMin = feature->caps.u.Range.UsageMin; > + wine_element->caps.button.u.Range.UsageMax = feature->caps.u.Range.UsageMax; > + wine_element->caps.button.u.Range.StringMin = feature->caps.u.Range.StringMin; > + wine_element->caps.button.u.Range.StringMax = feature->caps.u.Range.StringMax; > + wine_element->caps.button.u.Range.DesignatorMin = feature->caps.u.Range.DesignatorMin; > + wine_element->caps.button.u.Range.DesignatorMax = feature->caps.u.Range.DesignatorMax; > + } > + else > + { > + *bitOffset = *bitOffset + 1; > + wine_element->bitCount = 1; > + wine_element->caps.button.u.NotRange.Usage = feature->caps.u.NotRange.Usage[i]; > + wine_element->caps.button.u.NotRange.StringIndex = feature->caps.u.NotRange.StringIndex; > + wine_element->caps.button.u.NotRange.DesignatorIndex = feature->caps.u.NotRange.DesignatorIndex; > + } > + } > + else > + { > + wine_element->ElementType = ValueElement; > + wine_element->caps.value.UsagePage = feature->caps.UsagePage; > + wine_element->caps.value.ReportID = feature->caps.ReportID; > + wine_element->caps.value.BitField = feature->BitField; > + wine_element->caps.value.IsRange = feature->caps.IsRange; > + wine_element->caps.value.IsStringRange = feature->caps.IsStringRange; > + wine_element->caps.value.IsDesignatorRange = feature->caps.IsDesignatorRange; > + wine_element->caps.value.IsAbsolute = feature->IsAbsolute; > + wine_element->caps.value.HasNull = feature->HasNull; > + wine_element->caps.value.BitSize = feature->caps.BitSize; > + if (feature->caps.usage_count > 1) > + wine_element->caps.value.ReportCount = 1; > + else > + wine_element->caps.value.ReportCount = feature->caps.ReportCount; > + wine_element->bitCount = (feature->caps.BitSize * wine_element->caps.value.ReportCount); > + *bitOffset = *bitOffset + wine_element->bitCount; > + wine_element->caps.value.UnitsExp = feature->caps.UnitsExp; > + wine_element->caps.value.Units = feature->caps.Units; > + wine_element->caps.value.LogicalMin = feature->caps.LogicalMin; > + wine_element->caps.value.LogicalMax = feature->caps.LogicalMax; > + wine_element->caps.value.PhysicalMin = feature->caps.PhysicalMin; > + wine_element->caps.value.PhysicalMax = feature->caps.PhysicalMax; > + if (wine_element->caps.value.IsRange) > + { > + wine_element->caps.value.u.Range.UsageMin = feature->caps.u.Range.UsageMin; > + wine_element->caps.value.u.Range.UsageMax = feature->caps.u.Range.UsageMax; > + wine_element->caps.value.u.Range.StringMin = feature->caps.u.Range.StringMin; > + wine_element->caps.value.u.Range.StringMax = feature->caps.u.Range.StringMax; > + wine_element->caps.value.u.Range.DesignatorMin = feature->caps.u.Range.DesignatorMin; > + wine_element->caps.value.u.Range.DesignatorMax = feature->caps.u.Range.DesignatorMax; > + } > + else > + { > + wine_element->caps.value.u.NotRange.Usage = feature->caps.u.NotRange.Usage[i]; > + wine_element->caps.value.u.NotRange.StringIndex = feature->caps.u.NotRange.StringIndex; > + wine_element->caps.value.u.NotRange.DesignatorIndex = feature->caps.u.NotRange.DesignatorIndex; > + } > + } > + > + wine_report->elementCount++; > + } > +} > + > +static void count_elements(struct feature* feature, USHORT *buttons, USHORT *values) > +{ > + if (feature->caps.UsagePage == HID_USAGE_PAGE_BUTTON) > + { > + if (feature->caps.IsRange) > + *buttons = *buttons + 1; > + else > + *buttons = *buttons + feature->caps.usage_count; > + } > + else > + { > + if (feature->caps.IsRange) > + *values = *values + 1; > + else > + *values = *values + feature->caps.usage_count; > + } > +} > + > +WINE_HIDP_PREPARSED_DATA* build_PreparseData( > + struct feature **features, int feature_count, > + struct feature **input_features, int i_count, > + struct feature **output_features, int o_count, > + struct feature **feature_features, int f_count, > + struct collection *base_collection) > +{ > + WINE_HIDP_PREPARSED_DATA *data; > + WINE_HID_REPORT *wine_report = NULL; > + DWORD bitOffset, bitLength; > + int report_count = 1; > + int i; > + int element_count; > + int size = 0; > + > + if (features[0]->caps.ReportID != 0) > + { > + int *report_ids; > + int cnt = max(i_count, o_count); > + cnt = max(cnt, f_count); > + report_ids = HeapAlloc(GetProcessHeap(), 0 , sizeof(*report_ids) * cnt); > + > + if (i_count) > + { > + report_ids[0] = input_features[0]->caps.ReportID; > + for (i = 1; i < i_count; i++) > + { > + int j; > + int found = FALSE; > + for (j = 0; !found && j < i_count; j++) > + { > + if (report_ids[j] == input_features[i]->caps.ReportID) > + found = TRUE; > + } > + if (!found) > + { > + report_ids[report_count] = input_features[i]->caps.ReportID; > + report_count++; > + } > + } > + } > + if (o_count) > + { > + report_count++; > + report_ids[0] = output_features[0]->caps.ReportID; > + for (i = 1; i < o_count; i++) > + { > + int j; > + int found = FALSE; > + for (j = 0; !found && j < o_count; j++) > + { > + if (report_ids[j] == output_features[i]->caps.ReportID) > + found = TRUE; > + } > + if (!found) > + { > + report_ids[report_count] = output_features[i]->caps.ReportID; > + report_count++; > + } > + } > + } > + if (f_count) > + { > + report_count++; > + report_ids[0] = feature_features[0]->caps.ReportID; > + for (i = 1; i < f_count; i++) > + { > + int j; > + int found = FALSE; > + for (j = 0; !found && j < f_count; j++) > + { > + if (report_ids[j] == feature_features[i]->caps.ReportID) > + found = TRUE; > + } > + if (!found) > + { > + report_ids[report_count] = feature_features[i]->caps.ReportID; > + report_count++; > + } > + } > + } > + HeapFree(GetProcessHeap(), 0, report_ids); > + } > + else > + { > + if (o_count) report_count++; > + if (f_count) report_count++; > + } > + > + element_count = 0; > + for (i = 0; i < feature_count; i++) > + element_count += features[i]->caps.usage_count; > + > + size = sizeof(WINE_HIDP_PREPARSED_DATA) + > + (element_count * sizeof(WINE_HID_ELEMENT)) + > + (report_count * sizeof(WINE_HID_REPORT)); > + > + TRACE("%i reports %i elements -> size %i\n",report_count, element_count, size); > + > + data = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, size); > + data->magic = HID_MAGIC; > + data->dwSize = size; > + data->caps.Usage = base_collection->caps.u.NotRange.Usage[0]; > + data->caps.UsagePage = base_collection->caps.UsagePage; > + > + wine_report = data->InputReports; > + if (i_count) > + { > + bitLength = 0; > + new_report(wine_report, input_features[0]); > + data->dwInputReportCount ++; > + > + if (input_features[0]->caps.ReportID != 0) > + bitOffset = 8; > + else > + bitOffset = 0; > + > + for (i = 0; i < i_count; i++) > + { > + if (input_features[i]->caps.ReportID != wine_report->reportID) > + { > + wine_report->dwSize += (sizeof(WINE_HID_ELEMENT) * wine_report->elementCount); > + wine_report = (WINE_HID_REPORT*)(((BYTE*)wine_report)+wine_report->dwSize); > + new_report(wine_report, input_features[i]); > + data->dwInputReportCount ++; > + bitLength = max(bitOffset, bitLength); > + if (input_features[i]->caps.ReportID != 0) > + bitOffset = 8; > + else > + bitOffset = 0; > + } > + build_elements(wine_report, input_features[i], &bitOffset); > + count_elements(input_features[i], &data->caps.NumberInputButtonCaps, > + &data->caps.NumberInputValueCaps); > + } > + wine_report->dwSize += (sizeof(WINE_HID_ELEMENT) * wine_report->elementCount); > + bitLength = max(bitOffset, bitLength); > + data->caps.InputReportByteLength = ((bitLength + 7) & ~7)/8; > + } > + > + if (o_count) > + { > + bitLength = 0; > + wine_report = (WINE_HID_REPORT*)(((BYTE*)wine_report)+wine_report->dwSize); > + data->dwOutputReportOffset = (BYTE*)wine_report - (BYTE*)data->InputReports; > + new_report(wine_report, output_features[0]); > + data->dwOutputReportCount ++; > + if (output_features[0]->caps.ReportID != 0) > + bitOffset = 8; > + else > + bitOffset = 0; > + > + for (i = 0; i < o_count; i++) > + { > + if (output_features[i]->caps.ReportID != wine_report->reportID) > + { > + wine_report->dwSize += (sizeof(WINE_HID_ELEMENT) * wine_report->elementCount); > + wine_report = (WINE_HID_REPORT*)(((BYTE*)wine_report)+wine_report->dwSize); > + new_report(wine_report, output_features[i]); > + data->dwOutputReportCount ++; > + bitLength = max(bitOffset, bitLength); > + if (output_features[0]->caps.ReportID != 0) > + bitOffset = 8; > + else > + bitOffset = 0; > + } > + build_elements(wine_report, output_features[i], &bitOffset); > + count_elements(output_features[i], &data->caps.NumberOutputButtonCaps, > + &data->caps.NumberOutputValueCaps); > + } > + wine_report->dwSize += (sizeof(WINE_HID_ELEMENT) * wine_report->elementCount); > + bitLength = max(bitOffset, bitLength); > + data->caps.OutputReportByteLength = ((bitLength + 7) & ~7)/8; > + } > + > + if (f_count) > + { > + bitLength = 0; > + wine_report = (WINE_HID_REPORT*)(((BYTE*)wine_report)+wine_report->dwSize); > + data->dwFeatureReportOffset = (BYTE*)wine_report - (BYTE*)data->InputReports; > + new_report(wine_report, feature_features[0]); > + data->dwFeatureReportCount ++; > + if (feature_features[0]->caps.ReportID != 0) > + bitOffset = 8; > + else > + bitOffset = 0; > + > + for (i = 0; i < f_count; i++) > + { > + if (feature_features[i]->caps.ReportID != wine_report->reportID) > + { > + wine_report->dwSize += (sizeof(WINE_HID_ELEMENT) * wine_report->elementCount); > + wine_report = (WINE_HID_REPORT*)((BYTE*)wine_report)+wine_report->dwSize; > + new_report(wine_report, feature_features[i]); > + data->dwFeatureReportCount ++; > + bitLength = max(bitOffset, bitLength); > + if (feature_features[0]->caps.ReportID != 0) > + bitOffset = 8; > + else > + bitOffset = 0; > + } > + build_elements(wine_report, feature_features[i], &bitOffset); > + count_elements(feature_features[i], &data->caps.NumberFeatureButtonCaps, > + &data->caps.NumberFeatureValueCaps); > + } > + bitLength = max(bitOffset, bitLength); > + data->caps.FeatureReportByteLength = ((bitLength + 7) & ~7)/8; > + } > + > + return data; > +} > + > +static void free_collection(struct collection *collection) > +{ > + struct feature *fentry, *fnext; > + struct collection *centry, *cnext; > + LIST_FOR_EACH_ENTRY_SAFE(centry, cnext, &collection->collections, struct collection, entry) > + { > + list_remove(&centry->entry); > + free_collection(centry); > + } > + LIST_FOR_EACH_ENTRY_SAFE(fentry, fnext, &collection->features, struct feature, col_entry) > + { > + list_remove(&fentry->col_entry); > + HeapFree(GetProcessHeap(), 0, fentry); > + } > + HeapFree(GetProcessHeap(), 0, collection); > +} > + > +static int compare_reports(const void *a, const void* b) > +{ > + struct feature *f1 = *(struct feature **)a; > + struct feature *f2 = *(struct feature **)b; > + int c = (f1->caps.ReportID - f2->caps.ReportID); > + if (c) return c; > + return (f1->index - f2->index); > +} > + > +WINE_HIDP_PREPARSED_DATA* ParseDescriptor(BYTE *descriptor, INT length) > +{ > + WINE_HIDP_PREPARSED_DATA *data = NULL; > + struct collection *base; > + struct caps caps; > + > + struct list features; > + > + int feature_count = 0; > + int cidx; > + > + if (TRACE_ON(hid)) > + { > + TRACE("Descriptor[%i]: ", length); > + for (cidx = 0; cidx < length; cidx++) > + TRACE("%x ",descriptor[cidx]); > + TRACE("\n"); > + } > + > + list_init(&features); > + > + base = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*base)); > + base->index = 1; > + list_init(&base->features); > + list_init(&base->collections); > + memset(&caps, 0, sizeof(caps)); > + > + cidx = 0; > + parse_descriptor(descriptor, 0, length, &feature_count, &cidx, base, &caps, &features); > + > + debug_collection(base); > + > + cidx = 2; > + if (feature_count) > + { > + struct feature *entry; > + struct feature** sorted_features; > + struct feature** input_features; > + struct feature** output_features; > + struct feature** feature_features; > + int i_count, o_count, f_count; > + int i; > + > + i_count = o_count = f_count = 0; > + > + sorted_features = HeapAlloc(GetProcessHeap(), 0, sizeof(*sorted_features) * feature_count); > + input_features = HeapAlloc(GetProcessHeap(), 0, sizeof(*input_features) * feature_count); > + output_features = HeapAlloc(GetProcessHeap(), 0, sizeof(*output_features) * feature_count); > + feature_features = HeapAlloc(GetProcessHeap(), 0, sizeof(*feature_features) * feature_count); > + > + i = 0; > + LIST_FOR_EACH_ENTRY(entry, &features, struct feature, entry) > + sorted_features[i++] = entry; > + > + /* Sort features base on report if there are multiple reports */ > + if (sorted_features[0]->caps.ReportID != 0) > + qsort(sorted_features, feature_count, sizeof(struct feature*), compare_reports); > + > + for (i = 0; i < feature_count; i++) > + { > + switch (sorted_features[i]->type) > + { > + case HidP_Input: > + input_features[i_count] = sorted_features[i]; > + i_count++; > + break; > + case HidP_Output: > + output_features[o_count] = sorted_features[i]; > + o_count++; > + break; > + case HidP_Feature: > + feature_features[f_count] = sorted_features[i]; > + f_count++; > + break; > + default: > + ERR("Unknown type %i\n",sorted_features[i]->type); > + } > + } > + > + if (TRACE_ON(hid)) > + { > + TRACE("DUMP FEATURES:\n"); > + TRACE("----INPUT----\n"); > + for (cidx = 0; cidx < i_count; cidx++) > + debug_feature(input_features[cidx]); > + TRACE("----OUTPUT----\n"); > + for (cidx = 0; cidx < o_count; cidx++) > + debug_feature(output_features[cidx]); > + TRACE("----FEATURE----\n"); > + for (cidx = 0; cidx < f_count; cidx++) > + debug_feature(feature_features[cidx]); > + } > + > + data = build_PreparseData(sorted_features, feature_count, input_features, i_count, output_features, o_count, feature_features, f_count, base); > + > + debug_print_preparsed(data); > + > + HeapFree(GetProcessHeap(), 0, sorted_features); > + HeapFree(GetProcessHeap(), 0, input_features); > + HeapFree(GetProcessHeap(), 0, output_features); > + HeapFree(GetProcessHeap(), 0, feature_features); > + } > + > + free_collection(base); > + /* We do not have to free the list as free_collection does all the work */ > + > + return data; > +} > diff --git a/dlls/hidclass.sys/hid.h b/dlls/hidclass.sys/hid.h > index 8f9e56f..c8cee69 100644 > --- a/dlls/hidclass.sys/hid.h > +++ b/dlls/hidclass.sys/hid.h > @@ -81,3 +81,6 @@ void HID_DeleteDevice(HID_MINIDRIVER_REGISTRATION *driver, DEVICE_OBJECT *device > /* Pseudo-Plug and Play support*/ > NTSTATUS WINAPI PNP_AddDevice(DRIVER_OBJECT *driver, void* native) DECLSPEC_HIDDEN; > void PNP_CleanupPNP() DECLSPEC_HIDDEN; > + > +/* Parsing HID Report Descriptors into preparsed data */ > +WINE_HIDP_PREPARSED_DATA* ParseDescriptor(BYTE *descriptor, INT length) DECLSPEC_HIDDEN; > diff --git a/dlls/hidclass.sys/pnp.c b/dlls/hidclass.sys/pnp.c > index ca85cb7..5694b8a 100644 > --- a/dlls/hidclass.sys/pnp.c > +++ b/dlls/hidclass.sys/pnp.c > @@ -53,6 +53,9 @@ NTSTATUS WINAPI PNP_AddDevice(DRIVER_OBJECT *driver, void *native) > DWORD index = HID_STRING_ID_ISERIALNUMBER; > NATIVE_DEVICE *tracked_device, *ptr; > INT interface_index = 1; > + HID_DESCRIPTOR descriptor; > + BYTE *reportDescriptor; > + INT i; > > static const WCHAR ig_fmtW[] = {'I','G','_','%','i',0}; > static const WCHAR im_fmtW[] = {'I','M','_','%','i',0}; > @@ -104,6 +107,40 @@ NTSTATUS WINAPI PNP_AddDevice(DRIVER_OBJECT *driver, void *native) > > list_add_tail(&tracked_devices, &tracked_device->entry); > > + status = call_minidriver(IOCTL_HID_GET_DEVICE_DESCRIPTOR, device, NULL, 0, > + &descriptor, sizeof(descriptor)); > + if (status != STATUS_SUCCESS) > + { > + ERR("Cannot get Device Descriptor(%x)\n",status); > + HID_DeleteDevice(&minidriver->minidriver, device); > + return status; > + } > + for (i = 0; i < descriptor.bNumDescriptors; i++) > + if (descriptor.DescriptorList[i].bReportType == HID_REPORT_DESCRIPTOR_TYPE) > + break; > + > + if (i >= descriptor.bNumDescriptors) > + { > + ERR("No Report Descriptor found in reply\n"); > + HID_DeleteDevice(&minidriver->minidriver, device); > + return status; > + } > + > + reportDescriptor = HeapAlloc(GetProcessHeap(), 0, descriptor.DescriptorList[i].wReportLength); > + status = call_minidriver(IOCTL_HID_GET_REPORT_DESCRIPTOR, device, NULL, 0, > + reportDescriptor, descriptor.DescriptorList[i].wReportLength); > + if (status != STATUS_SUCCESS) > + { > + ERR("Cannot get Report Descriptor(%x)\n",status); > + HID_DeleteDevice(&minidriver->minidriver, device); > + HeapFree(GetProcessHeap(), 0, reportDescriptor); > + return status; > + } > + > + ext->preparseData = ParseDescriptor(reportDescriptor, descriptor.DescriptorList[0].wReportLength); > + ext->information.DescriptorSize = ext->preparseData->dwSize; > + HeapFree(GetProcessHeap(), 0, reportDescriptor); > + > status = call_minidriver(IOCTL_HID_GET_STRING, device, > (void*)index, sizeof(DWORD), serial, sizeof(serial)); > > >

3 2

Re: [8/13](resend)hidclass.sys: Add a processing thread for HID devices
by Andrew Eikum Sept. 3, 2015

Sept. 3, 2015

On Wed, Sep 02, 2015 at 07:02:18AM -0500, Aric Stewart wrote: > --- > dlls/hidclass.sys/buffer.c | 21 ++++++ > dlls/hidclass.sys/device.c | 175 +++++++++++++++++++++++++++++++++++++++++++++ > dlls/hidclass.sys/hid.h | 2 + > dlls/hidclass.sys/pnp.c | 2 + > 4 files changed, 200 insertions(+) > > > diff --git a/dlls/hidclass.sys/buffer.c b/dlls/hidclass.sys/buffer.c > index 6f09393..94e3372 100644 > --- a/dlls/hidclass.sys/buffer.c > +++ b/dlls/hidclass.sys/buffer.c > @@ -140,3 +140,24 @@ void RingBuffer_RemovePointer(struct ReportRingBuffer *ring, UINT index) > ring->pointers[index] = 0xffffffff; > LeaveCriticalSection(&ring->lock); > } > + > +void RingBuffer_Write(struct ReportRingBuffer *ring, void *data) > +{ > + UINT i; > + > + EnterCriticalSection(&ring->lock); > + memcpy(&ring->buffer[ring->end * ring->buffer_size], data, ring->buffer_size); > + ring->end++; > + if (ring->end == ring->size) > + ring->end = 0; > + if (ring->start == ring->end) > + { > + ring->start++; > + if (ring->start == ring->size) > + ring->start = 0; > + } > + for (i = 0; i < ring->pointer_alloc; i++) > + if (ring->pointers[i] == ring->end) > + ring->pointers[i] = ring->start; > + LeaveCriticalSection(&ring->lock); > +} > diff --git a/dlls/hidclass.sys/device.c b/dlls/hidclass.sys/device.c > index 326c994..e09a96c 100644 > --- a/dlls/hidclass.sys/device.c > +++ b/dlls/hidclass.sys/device.c > @@ -198,6 +198,181 @@ void HID_DeleteDevice(HID_MINIDRIVER_REGISTRATION *driver, DEVICE_OBJECT *device > IoDeleteDevice(device); > } > > +static void HID_Device_processQueue(DEVICE_OBJECT *device) > +{ > + LIST_ENTRY *entry; > + IRP *irp; > + BASE_DEVICE_EXTENSION *ext = device->DeviceExtension; > + UINT buffer_size = RingBuffer_GetBufferSize(ext->ring_buffer); > + HID_XFER_PACKET *packet; > + > + packet = HeapAlloc(GetProcessHeap(), 0, buffer_size); > + > + entry = RemoveHeadList(&ext->irp_queue); > + while(entry != &ext->irp_queue) > + { > + int ptr; > + irp = CONTAINING_RECORD(entry, IRP, Tail.Overlay.ListEntry); > + ptr = (int)irp->Tail.Overlay.OriginalFileObject->FsContext; > + > + buffer_size = RingBuffer_GetBufferSize(ext->ring_buffer); > + RingBuffer_Read(ext->ring_buffer, ptr, packet, &buffer_size); > + if (buffer_size) > + { > + IO_STACK_LOCATION *irpsp = IoGetCurrentIrpStackLocation(irp); > + TRACE_(hid_report)("Processing Request (%i)\n",ptr); > + if (irpsp->Parameters.Read.Length >= packet->reportBufferLen) > + { > + memcpy(irp->AssociatedIrp.SystemBuffer, packet->reportBuffer, packet->reportBufferLen); > + irp->IoStatus.Information = packet->reportBufferLen; > + irp->IoStatus.u.Status = STATUS_SUCCESS; > + } > + else > + { > + irp->IoStatus.Information = 0; > + irp->IoStatus.u.Status = STATUS_BUFFER_OVERFLOW; > + } > + } > + else > + { > + irp->IoStatus.Information = 0; > + irp->IoStatus.u.Status = STATUS_UNSUCCESSFUL; > + } > + IoCompleteRequest( irp, IO_NO_INCREMENT ); > + entry = RemoveHeadList(&ext->irp_queue); > + } > + HeapFree(GetProcessHeap(), 0, packet); > +} > + > +static NTSTATUS WINAPI read_Completion(DEVICE_OBJECT *deviceObject, IRP *irp, void *context ) > +{ > + SetEvent(irp->UserEvent); > + return STATUS_MORE_PROCESSING_REQUIRED; > +} > + > +static DWORD CALLBACK hid_device_thread(void *args) > +{ > + DEVICE_OBJECT *device = (DEVICE_OBJECT*)args; > + > + IRP *irp; > + IO_STATUS_BLOCK irp_status; > + IO_STACK_LOCATION *irpsp; > + DWORD rc; > + HANDLE events[2]; > + NTSTATUS ntrc; > + > + BASE_DEVICE_EXTENSION *ext = device->DeviceExtension; > + events[0] = CreateEventA(NULL, FALSE, FALSE, NULL); > + events[1] = ext->halt_event; > + > + if (ext->information.Polled) > + { > + while(1) > + { > + HID_XFER_PACKET *packet; > + ResetEvent(events[0]); > + > + packet = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*packet) + ext->preparseData->caps.InputReportByteLength); > + packet->reportBufferLen = ext->preparseData->caps.InputReportByteLength; > + packet->reportBuffer = ((BYTE*)packet) + sizeof(*packet); > + packet->reportId = 0; > + > + irp = IoBuildDeviceIoControlRequest(IOCTL_HID_GET_INPUT_REPORT, > + device, NULL, 0, packet, sizeof(packet), TRUE, events[0], > + &irp_status); > + > + irpsp = IoGetNextIrpStackLocation(irp); > + irpsp->CompletionRoutine = read_Completion; > + irpsp->Control = SL_INVOKE_ON_SUCCESS | SL_INVOKE_ON_ERROR; > + > + ntrc = IoCallDriver(device, irp); > + > + if (ntrc == STATUS_PENDING) > + rc = WaitForMultipleObjects(2, events, FALSE, INFINITE); > + > + if (irp->IoStatus.u.Status == STATUS_SUCCESS) > + { > + RingBuffer_Write(ext->ring_buffer, packet); I'm not opposed to what you have here, but a get-buffer/commit-buffer model would avoid an allocation and a memcpy. Although this would complicate simultaneous writes, if that's a concern.

2 1

Re: [7/13](resend)hidclass.sys: Implement IRP_MJ_READ for HID Devices
by Andrew Eikum Sept. 3, 2015

Sept. 3, 2015

On Wed, Sep 02, 2015 at 07:02:11AM -0500, Aric Stewart wrote: > diff --git a/dlls/hidclass.sys/buffer.c b/dlls/hidclass.sys/buffer.c > index 2561235..6f09393 100644 > --- a/dlls/hidclass.sys/buffer.c > +++ b/dlls/hidclass.sys/buffer.c > @@ -80,6 +80,39 @@ void RingBuffer_Destroy(struct ReportRingBuffer *ring) > HeapFree(GetProcessHeap(), 0, ring); > } > > +UINT RingBuffer_GetBufferSize(struct ReportRingBuffer *ring) > +{ > + return ring->buffer_size; > +} > + > +void RingBuffer_Read(struct ReportRingBuffer *ring, UINT index, void *output, UINT *size) > +{ > + void *ret = NULL; > + > + EnterCriticalSection(&ring->lock); > + if (index >= ring->pointer_alloc || ring->pointers[index] == 0xffffffff) > + { > + LeaveCriticalSection(&ring->lock); > + *size = 0; > + return; > + } > + if (ring->pointers[index] == ring->end) > + { > + LeaveCriticalSection(&ring->lock); > + *size = 0; > + } > + else > + { > + ret = &ring->buffer[ring->pointers[index] * ring->buffer_size]; > + memcpy(output, ret, ring->buffer_size); Is it necessary to make a copy of the data in the ring buffer? Seems like returning a raw pointer would be more efficient. I flipped through the rest of the patch sequence and all uses of RingBuffer_Read seemed to be read-only. > + ring->pointers[index]++; > + if (ring->pointers[index] == ring->size) > + ring->pointers[index] = 0; > + LeaveCriticalSection(&ring->lock); > + *size = ring->buffer_size; > + } > +} > + > UINT RingBuffer_AddPointer(struct ReportRingBuffer *ring) > { > UINT idx; > diff --git a/dlls/hidclass.sys/device.c b/dlls/hidclass.sys/device.c > index a6660db..326c994 100644 > --- a/dlls/hidclass.sys/device.c > +++ b/dlls/hidclass.sys/device.c > @@ -36,6 +36,7 @@ > #include "devguid.h" > > WINE_DEFAULT_DEBUG_CHANNEL(hid); > +WINE_DECLARE_DEBUG_CHANNEL(hid_report); > > static const WCHAR device_name_fmtW[] = {'\\','D','e','v','i','c','e', > '\\','H','I','D','#','%','p','&','%','p',0}; > @@ -353,6 +354,48 @@ NTSTATUS WINAPI HID_Device_ioctl(DEVICE_OBJECT *device, IRP *irp) > return rc; > } > > +NTSTATUS WINAPI HID_Device_read(DEVICE_OBJECT *device, IRP *irp) > +{ > + HID_XFER_PACKET *packet; > + BASE_DEVICE_EXTENSION *ext = device->DeviceExtension; > + UINT buffer_size = RingBuffer_GetBufferSize(ext->ring_buffer); > + NTSTATUS rc = STATUS_SUCCESS; > + int ptr = -1; > + > + packet = HeapAlloc(GetProcessHeap(), 0, buffer_size); > + ptr = (int)irp->Tail.Overlay.OriginalFileObject->FsContext; > + > + irp->IoStatus.Information = 0; > + RingBuffer_Read(ext->ring_buffer, ptr, packet, &buffer_size); > + > + if (buffer_size) > + { > + IO_STACK_LOCATION *irpsp = IoGetCurrentIrpStackLocation( irp ); > + TRACE_(hid_report)("Got Packet %p %i\n", packet->reportBuffer, packet->reportBufferLen); > + if (irpsp->Parameters.Read.Length >= packet->reportBufferLen) > + { > + memcpy(irp->AssociatedIrp.SystemBuffer, packet->reportBuffer, packet->reportBufferLen); > + irp->IoStatus.Information = packet->reportBufferLen; > + irp->IoStatus.u.Status = STATUS_SUCCESS; > + } > + else > + { > + irp->IoStatus.Information = 0; > + irp->IoStatus.u.Status = STATUS_BUFFER_OVERFLOW; > + } > + IoCompleteRequest( irp, IO_NO_INCREMENT ); > + } > + else > + { > + TRACE_(hid_report)("Queue irp\n"); > + InsertTailList(&ext->irp_queue, &irp->Tail.Overlay.ListEntry); > + rc = STATUS_PENDING; > + } > + HeapFree(GetProcessHeap(), 0, packet); > + > + return rc; > +} > + > NTSTATUS WINAPI HID_Device_create(DEVICE_OBJECT *device, IRP *irp) > { > BASE_DEVICE_EXTENSION *ext = device->DeviceExtension; > diff --git a/dlls/hidclass.sys/hid.h b/dlls/hidclass.sys/hid.h > index c9bc338..34ec241 100644 > --- a/dlls/hidclass.sys/hid.h > +++ b/dlls/hidclass.sys/hid.h > @@ -58,6 +58,8 @@ typedef struct _BASE_DEVICE_EXTENSTION { > > UINT RingBuffer_AddPointer(struct ReportRingBuffer *buffer) DECLSPEC_HIDDEN; > void RingBuffer_RemovePointer(struct ReportRingBuffer *ring, UINT index) DECLSPEC_HIDDEN; > +void RingBuffer_Read(struct ReportRingBuffer *buffer, UINT index, void *output, UINT *size) DECLSPEC_HIDDEN; > +UINT RingBuffer_GetBufferSize(struct ReportRingBuffer *buffer) DECLSPEC_HIDDEN; > void RingBuffer_Destroy(struct ReportRingBuffer *buffer) DECLSPEC_HIDDEN; > struct ReportRingBuffer* RingBuffer_Create(UINT buffer_size) DECLSPEC_HIDDEN; > > @@ -81,6 +83,7 @@ NTSTATUS HID_LinkDevice(DEVICE_OBJECT *device, LPCWSTR serial, LPCWSTR index) DE > void HID_DeleteDevice(HID_MINIDRIVER_REGISTRATION *driver, DEVICE_OBJECT *device) DECLSPEC_HIDDEN; > > NTSTATUS WINAPI HID_Device_ioctl(DEVICE_OBJECT *device, IRP *irp) DECLSPEC_HIDDEN; > +NTSTATUS WINAPI HID_Device_read(DEVICE_OBJECT *device, IRP *irp) DECLSPEC_HIDDEN; > NTSTATUS WINAPI HID_Device_create(DEVICE_OBJECT *device, IRP *irp) DECLSPEC_HIDDEN; > NTSTATUS WINAPI HID_Device_close(DEVICE_OBJECT *device, IRP *irp) DECLSPEC_HIDDEN; > > diff --git a/dlls/hidclass.sys/main.c b/dlls/hidclass.sys/main.c > index 1e0e802..4be4409 100644 > --- a/dlls/hidclass.sys/main.c > +++ b/dlls/hidclass.sys/main.c > @@ -69,6 +69,7 @@ NTSTATUS WINAPI HidRegisterMinidriver(HID_MINIDRIVER_REGISTRATION *registration) > registration->DriverObject->DriverUnload = UnloadDriver; > > registration->DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = HID_Device_ioctl; > + registration->DriverObject->MajorFunction[IRP_MJ_READ] = HID_Device_read; > registration->DriverObject->MajorFunction[IRP_MJ_CREATE] = HID_Device_create; > registration->DriverObject->MajorFunction[IRP_MJ_CLOSE] = HID_Device_close; > > >

3 2

Re: [PATCH 5/6] wined3d: Return a texture from the swapchain resource creation callback.
by Henri Verbeet Sept. 3, 2015

Sept. 3, 2015

On 3 September 2015 at 12:52, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -3034,32 +3034,29 @@ static HRESULT CDECL device_parent_volume_created(struct wined3d_device_parent * > return D3D_OK; > } > > -static HRESULT CDECL device_parent_create_swapchain_surface(struct wined3d_device_parent *device_parent, > - void *container_parent, const struct wined3d_resource_desc *desc, struct wined3d_surface **surface) > +static HRESULT CDECL device_parent_create_swapchain_texture(struct wined3d_device_parent *device_parent, > + void *container_parent, const struct wined3d_resource_desc *desc, struct wined3d_texture **texture) > { > struct d3d8_device *device = device_from_device_parent(device_parent); > struct wined3d_resource_desc texture_desc; > + struct wined3d_surface *surface; > struct d3d8_surface *d3d_surface; > - struct wined3d_texture *texture; > HRESULT hr; > > - TRACE("device_parent %p, container_parent %p, desc %p, surface %p.\n", > - device_parent, container_parent, desc, surface); > + TRACE("device_parent %p, container_parent %p, desc %p, texture %p.\n", > + device_parent, container_parent, desc, texture); > > texture_desc = *desc; > texture_desc.resource_type = WINED3D_RTYPE_TEXTURE; Now that you're creating a texture, you don't need to change the resource type anymore. You should just be able to pass "desc" to wined3d_texture_create(). > - *surface = wined3d_surface_from_resource(wined3d_texture_get_sub_resource(texture, 0)); > - wined3d_surface_incref(*surface); > - wined3d_texture_decref(texture); > - > - d3d_surface = wined3d_surface_get_parent(*surface); > + surface = wined3d_surface_from_resource(wined3d_texture_get_sub_resource(*texture, 0)); > + d3d_surface = wined3d_surface_get_parent(surface); wined3d_resource_get_parent(). > diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c > index 765af0d..d50cd84 100644 > --- a/dlls/wined3d/device.c > +++ b/dlls/wined3d/device.c > @@ -4685,32 +4685,37 @@ HRESULT CDECL wined3d_device_reset(struct wined3d_device *device, > } > if (swapchain->desc.enable_auto_depth_stencil) > { > - struct wined3d_resource_desc surface_desc; > - struct wined3d_surface *surface; > + struct wined3d_resource_desc texture_desc; > + struct wined3d_texture *texture; > + struct wined3d_rendertarget_view_desc view_desc; > > TRACE("Creating the depth stencil buffer\n"); > > - surface_desc.resource_type = WINED3D_RTYPE_SURFACE; > - surface_desc.format = swapchain->desc.auto_depth_stencil_format; > - surface_desc.multisample_type = swapchain->desc.multisample_type; > - surface_desc.multisample_quality = swapchain->desc.multisample_quality; > - surface_desc.usage = WINED3DUSAGE_DEPTHSTENCIL; > - surface_desc.pool = WINED3D_POOL_DEFAULT; > - surface_desc.width = swapchain->desc.backbuffer_width; > - surface_desc.height = swapchain->desc.backbuffer_height; > - surface_desc.depth = 1; > - surface_desc.size = 0; > - > - if (FAILED(hr = device->device_parent->ops->create_swapchain_surface(device->device_parent, > - device->device_parent, &surface_desc, &surface))) > + texture_desc.resource_type = WINED3D_RTYPE_SURFACE; This looks wrong. It probably works anyway because you overwrite the resource type in the create_swapchain_texture() implementations.

1 0

Re: [2/4] user32: Add test case for DeferWindowPos() with invalid HWND (try 2)
by Marvin Sept. 2, 2015

Sept. 2, 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=16475 Your paranoid android. === w8 (32 bit win) === win.c:3417: Test failed: hwnd 000300F6 message 0118

1 0

Re: [1/4] user32: Add test case for basic {Begin, , End}DeferWindowPos() (try 2)
by Marvin Sept. 2, 2015

Sept. 2, 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=16474 Your paranoid android. === w7u (32 bit win) === win.c:3297: Test failed: hwnd 00060134 message 0200 win.c:3299: Test failed: message 0100 available

1 0

Re: [PATCH 2/2] ole32: Catch crashes in stub object destructors when destroying stub manager.
by Marvin Sept. 2, 2015

Sept. 2, 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=16468 Your paranoid android. === w8 (32 bit marshal) === marshal.c:3390: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3391: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3407: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3408: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3445: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3446: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3463: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3464: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3427: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3428: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3390: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3391: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3407: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3408: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3445: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3446: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3463: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3464: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3427: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3428: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3390: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3391: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3407: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3408: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3445: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3446: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3463: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3464: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3427: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3428: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4

1 0

Re: [PATCH 1/2] ole32: Quote executable name in CreateProcess call.
by Marvin Sept. 2, 2015

Sept. 2, 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=16467 Your paranoid android. === w8 (32 bit marshal) === marshal.c:3315: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3316: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3332: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3333: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3370: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3371: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3388: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3389: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3352: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3353: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3315: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3316: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3332: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3333: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3370: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3371: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3388: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3389: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3352: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3353: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3315: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3316: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3332: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3333: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3370: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3371: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3388: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3389: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3352: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3353: Test failed: info->dwServerPid was 0x920 instead of 0xfd4

1 0

Re: wineps.drv: Add glyph names for PostScript Format 1 glyphs.
by Nikolay Sivov Sept. 2, 2015

Sept. 2, 2015

On 01.09.2015 19:21, Erich E. Hoover wrote: > + /* These PostScript Format 1 glyph names are stored by glyph index, do not reorder them. */ > + const char *glyph_table[] = { > + ".notdef", > + ".null", > + "nonmarkingreturn", > + "space", I don't think it can work like that for anything except .notdef. If I understand it correctly one of wineps.drv tasks is to generate Type1/Type42 font description from currently selected font, including converting outline data and metrics to proper format, and that selected font could be anything scalable. get_glyph_name() operates on glyph index, and ttf/otf formats are free to map codepoints to any index, so mapping you implemented will only work in case when currently selected font has 'post' table in Format 1. So if you really need adobe glyph name you have to use unicode-value-to-name lookup based on [1] probably (comes under Apache 2.0 license, no idea if it's usable in Wine). But even that won't always work I think, because we have to support ETO_GLYPH_INDEX case too where you have indices as input. [1] https://github.com/adobe-type-tools/agl-aglfn/blob/master/glyphlist.txt

3 3

Re: [2/13]hidclass.sys: Add Plug-and-play and AddDevice
by Alexandre Julliard Sept. 2, 2015

Sept. 2, 2015

Aric Stewart <aric(a)codeweavers.com> writes: > @@ -57,9 +57,18 @@ typedef struct _minidriver > HID_MINIDRIVER_REGISTRATION minidriver; > > PDRIVER_UNLOAD DriverUnload; > + > + void *AddDevice; Please use the correct callback type and remove the corresponding casts. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: oleaut32: Implement CreateTypeLib
by Nikolay Sivov Sept. 2, 2015

Sept. 2, 2015

This is wrong as CreateTypeLib() is supposed to create SLTG typelib. For https://bugs.winehq.org/show_bug.cgi?id=8780 preferred way is to fix vbscript/jscript so you don't have to switch to native. In any case you don't need separate QI call.

1 0

Re: user32: Hide horizontal Listbox scroll bar if no horizontal extent is set. (try 2)
by Joachim Priesner Sept. 1, 2015

Sept. 1, 2015

Hi, I was wondering about the status of this patch I sent over a month ago. Anything I can do to improve it and get it reviewed? Joachim Am Samstag, 25. Juli 2015 schrieb Joachim Priesner: > According to https://msdn.microsoft.com/en-us/library/ms997541.aspx , a > horizontal scroll bar is shown iff the WS_HSCROLL style is set and > > a) the LBS_MULTICOLUMN style is set and there are too many items or > b) the LBS_MULTICOLUMN style is not set and a horizontal extent is > specified. > > Before this patch, the default scroll info min=0, max=100 would be set > even if no horizontal extent was specified. This led to WS_HSCROLL > list boxes that were less than 100 pixels wide to erroneously have > a horizontal scroll bar. > > Try 2 because I noted a minor formatting error in the first iteration of the patch. > --- > dlls/user32/listbox.c | 20 ++++++++- > dlls/user32/tests/listbox.c | 103 ++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 122 insertions(+), 1 deletion(-) > > diff --git a/dlls/user32/listbox.c b/dlls/user32/listbox.c > index 2902ac9..f4d890b 100644 > --- a/dlls/user32/listbox.c > +++ b/dlls/user32/listbox.c > @@ -265,7 +265,7 @@ static void LISTBOX_UpdateScroll( LB_DESCR *descr ) > if (descr->style & WS_VSCROLL) > SetScrollInfo( descr->self, SB_VERT, &info, TRUE ); > > - if (descr->style & WS_HSCROLL) > + if ((descr->style & WS_HSCROLL) && descr->horz_extent) > { > info.nPos = descr->horz_pos; > info.nPage = descr->width; > @@ -274,6 +274,20 @@ static void LISTBOX_UpdateScroll( LB_DESCR *descr ) > info.fMask |= SIF_DISABLENOSCROLL; > SetScrollInfo( descr->self, SB_HORZ, &info, TRUE ); > } > + else > + { > + if (descr->style & LBS_DISABLENOSCROLL) > + { > + info.nMin = 0; > + info.nMax = 0; > + info.fMask = SIF_RANGE | SIF_DISABLENOSCROLL; > + SetScrollInfo( descr->self, SB_HORZ, &info, TRUE ); > + } > + else > + { > + ShowScrollBar( descr->self, SB_HORZ, FALSE ); > + } > + } > } > } > > @@ -1248,6 +1262,8 @@ static LRESULT LISTBOX_SetHorizontalExtent( LB_DESCR *descr, INT extent ) > info.nMin = 0; > info.nMax = descr->horz_extent ? descr->horz_extent - 1 : 0; > info.fMask = SIF_RANGE; > + if (descr->style & LBS_DISABLENOSCROLL) > + info.fMask |= SIF_DISABLENOSCROLL; > SetScrollInfo( descr->self, SB_HORZ, &info, TRUE ); > } > if (descr->horz_pos > extent - descr->width) > @@ -2537,6 +2553,8 @@ static BOOL LISTBOX_Create( HWND hwnd, LPHEADCOMBO lphc ) > } > } > > + LISTBOX_UpdateScroll(descr); > + > TRACE("owner: %p, style: %08x, width: %d, height: %d\n", descr->owner, descr->style, descr->width, descr->height); > return TRUE; > } > diff --git a/dlls/user32/tests/listbox.c b/dlls/user32/tests/listbox.c > index 79d18e7..9380457 100644 > --- a/dlls/user32/tests/listbox.c > +++ b/dlls/user32/tests/listbox.c > @@ -1665,7 +1665,10 @@ static void test_extents(void) > ok(br == TRUE, "GetScrollInfo failed\n"); > ok(sinfo.nMin == 0, "got wrong min: %u\n", sinfo.nMin); > ok(sinfo.nMax == 100, "got wrong max: %u\n", sinfo.nMax); > + ok((GetWindowLongA(listbox, GWL_STYLE) & WS_HSCROLL) == 0, > + "List box should not have a horizontal scroll bar\n"); > > + /* horizontal extent < width */ > SendMessageA(listbox, LB_SETHORIZONTALEXTENT, 64, 0); > > res = SendMessageA(listbox, LB_GETHORIZONTALEXTENT, 0, 0); > @@ -1677,6 +1680,23 @@ static void test_extents(void) > ok(br == TRUE, "GetScrollInfo failed\n"); > ok(sinfo.nMin == 0, "got wrong min: %u\n", sinfo.nMin); > ok(sinfo.nMax == 100, "got wrong max: %u\n", sinfo.nMax); > + ok((GetWindowLongA(listbox, GWL_STYLE) & WS_HSCROLL) == 0, > + "List box should not have a horizontal scroll bar\n"); > + > + /* horizontal extent > width */ > + SendMessageA(listbox, LB_SETHORIZONTALEXTENT, 184, 0); > + > + res = SendMessageA(listbox, LB_GETHORIZONTALEXTENT, 0, 0); > + ok(res == 184, "Got wrong horizontal extent: %u\n", res); > + > + sinfo.cbSize = sizeof(sinfo); > + sinfo.fMask = SIF_RANGE; > + br = GetScrollInfo(listbox, SB_HORZ, &sinfo); > + ok(br == TRUE, "GetScrollInfo failed\n"); > + ok(sinfo.nMin == 0, "got wrong min: %u\n", sinfo.nMin); > + ok(sinfo.nMax == 100, "got wrong max: %u\n", sinfo.nMax); > + ok((GetWindowLongA(listbox, GWL_STYLE) & WS_HSCROLL) == 0, > + "List box should not have a horizontal scroll bar\n"); > > DestroyWindow(listbox); > > @@ -1692,7 +1712,71 @@ static void test_extents(void) > ok(br == TRUE, "GetScrollInfo failed\n"); > ok(sinfo.nMin == 0, "got wrong min: %u\n", sinfo.nMin); > ok(sinfo.nMax == 100, "got wrong max: %u\n", sinfo.nMax); > + ok((GetWindowLongA(listbox, GWL_STYLE) & WS_HSCROLL) == 0, > + "List box should not have a horizontal scroll bar\n"); > + > + /* horizontal extent < width */ > + SendMessageA(listbox, LB_SETHORIZONTALEXTENT, 64, 0); > + > + res = SendMessageA(listbox, LB_GETHORIZONTALEXTENT, 0, 0); > + ok(res == 64, "Got wrong horizontal extent: %u\n", res); > + > + sinfo.cbSize = sizeof(sinfo); > + sinfo.fMask = SIF_RANGE; > + br = GetScrollInfo(listbox, SB_HORZ, &sinfo); > + ok(br == TRUE, "GetScrollInfo failed\n"); > + ok(sinfo.nMin == 0, "got wrong min: %u\n", sinfo.nMin); > + ok(sinfo.nMax == 63, "got wrong max: %u\n", sinfo.nMax); > + ok((GetWindowLongA(listbox, GWL_STYLE) & WS_HSCROLL) == 0, > + "List box should not have a horizontal scroll bar\n"); > + > + /* horizontal extent > width */ > + SendMessageA(listbox, LB_SETHORIZONTALEXTENT, 184, 0); > + > + res = SendMessageA(listbox, LB_GETHORIZONTALEXTENT, 0, 0); > + ok(res == 184, "Got wrong horizontal extent: %u\n", res); > + > + sinfo.cbSize = sizeof(sinfo); > + sinfo.fMask = SIF_RANGE; > + br = GetScrollInfo(listbox, SB_HORZ, &sinfo); > + ok(br == TRUE, "GetScrollInfo failed\n"); > + ok(sinfo.nMin == 0, "got wrong min: %u\n", sinfo.nMin); > + ok(sinfo.nMax == 183, "got wrong max: %u\n", sinfo.nMax); > + ok((GetWindowLongA(listbox, GWL_STYLE) & WS_HSCROLL) != 0, > + "List box should have a horizontal scroll bar\n"); > + > + SendMessageA(listbox, LB_SETHORIZONTALEXTENT, 0, 0); > > + res = SendMessageA(listbox, LB_GETHORIZONTALEXTENT, 0, 0); > + ok(res == 0, "Got wrong horizontal extent: %u\n", res); > + > + sinfo.cbSize = sizeof(sinfo); > + sinfo.fMask = SIF_RANGE; > + br = GetScrollInfo(listbox, SB_HORZ, &sinfo); > + ok(br == TRUE, "GetScrollInfo failed\n"); > + ok(sinfo.nMin == 0, "got wrong min: %u\n", sinfo.nMin); > + ok(sinfo.nMax == 0, "got wrong max: %u\n", sinfo.nMax); > + ok((GetWindowLongA(listbox, GWL_STYLE) & WS_HSCROLL) == 0, > + "List box should not have a horizontal scroll bar\n"); > + > + DestroyWindow(listbox); > + > + > + listbox = create_listbox(WS_CHILD | WS_VISIBLE | WS_HSCROLL | LBS_DISABLENOSCROLL, parent); > + > + res = SendMessageA(listbox, LB_GETHORIZONTALEXTENT, 0, 0); > + ok(res == 0, "Got wrong initial horizontal extent: %u\n", res); > + > + sinfo.cbSize = sizeof(sinfo); > + sinfo.fMask = SIF_RANGE; > + br = GetScrollInfo(listbox, SB_HORZ, &sinfo); > + ok(br == TRUE, "GetScrollInfo failed\n"); > + ok(sinfo.nMin == 0, "got wrong min: %u\n", sinfo.nMin); > + ok(sinfo.nMax == 0, "got wrong max: %u\n", sinfo.nMax); > + ok((GetWindowLongA(listbox, GWL_STYLE) & WS_HSCROLL) != 0, > + "List box should have a horizontal scroll bar\n"); > + > + /* horizontal extent < width */ > SendMessageA(listbox, LB_SETHORIZONTALEXTENT, 64, 0); > > res = SendMessageA(listbox, LB_GETHORIZONTALEXTENT, 0, 0); > @@ -1704,6 +1788,23 @@ static void test_extents(void) > ok(br == TRUE, "GetScrollInfo failed\n"); > ok(sinfo.nMin == 0, "got wrong min: %u\n", sinfo.nMin); > ok(sinfo.nMax == 63, "got wrong max: %u\n", sinfo.nMax); > + ok((GetWindowLongA(listbox, GWL_STYLE) & WS_HSCROLL) != 0, > + "List box should have a horizontal scroll bar\n"); > + > + /* horizontal extent > width */ > + SendMessageA(listbox, LB_SETHORIZONTALEXTENT, 184, 0); > + > + res = SendMessageA(listbox, LB_GETHORIZONTALEXTENT, 0, 0); > + ok(res == 184, "Got wrong horizontal extent: %u\n", res); > + > + sinfo.cbSize = sizeof(sinfo); > + sinfo.fMask = SIF_RANGE; > + br = GetScrollInfo(listbox, SB_HORZ, &sinfo); > + ok(br == TRUE, "GetScrollInfo failed\n"); > + ok(sinfo.nMin == 0, "got wrong min: %u\n", sinfo.nMin); > + ok(sinfo.nMax == 183, "got wrong max: %u\n", sinfo.nMax); > + ok((GetWindowLongA(listbox, GWL_STYLE) & WS_HSCROLL) != 0, > + "List box should have a horizontal scroll bar\n"); > > SendMessageA(listbox, LB_SETHORIZONTALEXTENT, 0, 0); > > @@ -1716,6 +1817,8 @@ static void test_extents(void) > ok(br == TRUE, "GetScrollInfo failed\n"); > ok(sinfo.nMin == 0, "got wrong min: %u\n", sinfo.nMin); > ok(sinfo.nMax == 0, "got wrong max: %u\n", sinfo.nMax); > + ok((GetWindowLongA(listbox, GWL_STYLE) & WS_HSCROLL) != 0, > + "List box should have a horizontal scroll bar\n"); > > DestroyWindow(listbox); > >

1 0

Re: [PATCH] Fix performance problem in debug tracing
by Alexandre Julliard Sept. 1, 2015

Sept. 1, 2015

Daniel Santos <daniel.santos(a)pobox.com> writes: > Currently, if any classes are passed to WINEDEBUG (nb_debug_options > 0) then > the initial lazy-init call to __wine_dbg_get_channel_flags() never sets the > flags in the struct __wine_debug_channel in the object file, resulting in all > 45k trace calls in wine making a function call, running bsearch on > debug_options with string compare, etc. Not really. Only the channel that is actually enabled will make repeated function calls. This is done on purpose so that you can toggle it on and off for a given process from the task manager. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 3/7] d3d11: Add ID3D11Texture3D interface stub.
by Henri Verbeet Sept. 1, 2015

Sept. 1, 2015

On 1 September 2015 at 00:27, Józef Kucia <jkucia(a)codeweavers.com> wrote: > + else if (IsEqualGUID(riid, &IID_ID3D10Texture3D) > + || IsEqualGUID(riid, &IID_ID3D10Resource) > + || IsEqualGUID(riid, &IID_ID3D10DeviceChild)) > + { > + IUnknown_AddRef(iface); > + *object = &texture->ID3D10Texture3D_iface; For what it's worth, this works here because the d3d10 and d3d11 interfaces share the reference count, but in general you should AddRef() the actual interface you're returning.

2 2

Re: [PATCH 1/2] vcruntime140: Add the new MSVC 2015 compiler specific DLL.
by Alexandre Julliard Sept. 1, 2015

Sept. 1, 2015

Martin Storsjo <martin(a)martin.st> writes: > Since MSVC 2015/Windows 10, the C runtime has now been split into two > parts, ucrtbase, which is the generic C runtime which is now considered > a system component, and vcruntimeX which is specific to the compiler > version. > > Even if this DLL only has a fraction of the functions of the full > msvcrt/ucrtbase, it still requires almost all the object files from > msvcrt. It would be better to isolate the corresponding code so that we don't need all the files. -- Alexandre Julliard julliard(a)winehq.org

2 2