- wine-devel - winehq.org

Re: ntdll: Implement job objects. (try 3)
by Alexandre Julliard 07 Sep '13

07 Sep '13

Andrew Cook <ariscop(a)gmail.com> writes: > This will be my last submission for this piece of code, i want to work > on other things and it's been almost 2 weeks with zero comments on my > previous submission. It's clearly not ready, and you already know that since you've added TODOs all over the place. -- Alexandre Julliard julliard(a)winehq.org

1 0

RFC: Completely revised SIO_ADDRESS_LIST_CHANGE patches
by Erich E. Hoover 06 Sep '13

06 Sep '13

As some of you know I've been working on fixing SIO_ADDRESS_LIST_CHANGE in order to fix some problems with Silverlight on a variety of streaming sites. Due to some feedback I've received I've gone to the effort to completely revise these patches to work inside of the server instead of using iphlpapi. Any and all feedback is appreciated, special thanks go to Sebastian Lackner for looking over these patches ahead of time. Design considerations: 0001) This patch was modeled after similar behavior for unimplemented ioctl() calls in ntdll 0002) The implementation uses a per-socket queue so that when a socket is destroyed prior to a notification event then that socket's async operations are all appropriately woken up. Only one interface change notification object exists at a time, so the object is destroyed whenever there are no sockets expecting events and is then re-created as needed. 0003) This patch is a simple test case with the rest of the socket tests #ifdef'd out for your convenience Looking forward to hearing back! Best, Erich

1 0

Re: aclui: Remove some unneeded header inclusions. (IWYU)
by Alexandre Julliard 06 Sep '13

06 Sep '13

Amine Khaldi <amine.khaldi(a)reactos.org> writes: > @@ -18,15 +18,7 @@ > * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > */ > > -#include "config.h" > - > -#include <stdarg.h> > - > #include "initguid.h" > -#include "windef.h" > -#include "winbase.h" > -#include "winuser.h" > -#include "winnt.h" > #include "aclui.h" That's not useful. The headers will be included anyway. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [2/6] ntdll: Add support to NtWriteFile for special offset -1.
by Alexandre Julliard 06 Sep '13

06 Sep '13

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > --- > dlls/ntdll/file.c | 3 +++ > dlls/ntdll/tests/file.c | 15 --------------- > 2 files changed, 3 insertions(+), 15 deletions(-) > > diff --git a/dlls/ntdll/file.c b/dlls/ntdll/file.c > index 9420df5..9d5b02a 100644 > --- a/dlls/ntdll/file.c > +++ b/dlls/ntdll/file.c > @@ -967,6 +967,9 @@ NTSTATUS WINAPI NtWriteFile(HANDLE hFile, HANDLE hEvent, > goto done; > } > > + if (offset && offset->QuadPart == (LONGLONG)-1 /* FILE_WRITE_TO_END_OF_FILE */) > + offset->QuadPart = lseek( unix_handle, 0, SEEK_END ); > + This looks very wrong, offset belongs to the caller. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 2/3] ws2_32: Implement get socket option SO_PROTOCOL_INFO (try 3)
by Alexandre Julliard 06 Sep '13

06 Sep '13

Bruno Jesus <00cpxxx(a)gmail.com> writes: > +static int ws_protocol_info(SOCKET s, int unicode, WSAPROTOCOL_INFOW *buffer) > +{ > + int size; > + union _info > + { > + WSAPROTOCOL_INFOA *a; > + WSAPROTOCOL_INFOW *w; > + } info; > + info.w = buffer; > + > + size = unicode ? sizeof(WSAPROTOCOL_INFOW) : sizeof(WSAPROTOCOL_INFOA); > + memset(buffer, 0, size); > + info.w->iAddressFamily = WS_AF_UNSPEC; > + > + SERVER_START_REQ( get_socket_info ) > + { > + req->handle = wine_server_obj_handle( SOCKET2HANDLE(s) ); > + wine_server_call( req ); > + info.w->iAddressFamily = convert_af_u2w(reply->family); > + info.w->iSocketType = convert_socktype_u2w(reply->type); > + info.w->iProtocol = convert_proto_u2w(reply->protocol); > + } > + SERVER_END_REQ; You need to check the server return status and set the correct error code. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: D3D command stream patches for testing
by LOMBARD Maxime 06 Sep '13

06 Sep '13

Hi Stefan, I've tested two games "FarCry3" and "Splinter Cell Blacklist" with : - Wine 1.7.1 + CS patch + CSMT On/Off - Wine 1.7.1 clean - CSMT On = CSMT enabled + StrictDrawOrdering disabled - CSMT Off = CSMT disabled + StrictDrawOrdering enabled I run the game by *WINEDEBUG=fps,err-all,fixme-all primusrun /home/berillions/Desktop/Build/32/wine-1.7.1-{clean/csmt}/wine "$1" 2>&1 | tee /dev/stderr | grep --line-buffered "^trace:fps:" | osd_cat -c white -s 1 -l2;* ## My Laptop ## - Nvidia GTX670MX - Intel I5-3230M - Debian Sid 64-bits - Nvidia drivers 325.15 ## FarCry 3 tests ## Graphic options : - Texture : High - Ambient Lighting : High - Shadow : Ultra - Post Fx : Ultra - Geometry : Ultra - Vegetation : Very High - Terrain : High - Water : Very High - Environment : High Wine 1.7.1 clean : - Main Menu : ~35 fps - In-game (move or static camera) : ~12 fps average Wine 1.7.1 + CS patch + CSMT Off : - Main Menu : ~45fps - In-game : ~14 fps average Wine 1.7.1 + CS patch + CSMT On : - Main Menu : ~45fps - In-game : ~18 fps average ## Splinter Cell Blacklist ## Graphic Options : - Texture detail : Ultra - Shadow Quality : High - Parallax : On - Tesselation : Off - Texture Filtering : Anisotropic 4x - V-Sync : On - Dynamic ambient Occlusion : Field AO - Anti-Aliasing : FXAA - Directx : Dx9 Wine 1.7.1 clean : - In-game : ~15 fps average Wine 1.7.1 + CS patch + CSMT Off : - In-game : ~15 fps average Wine 1.7.1 + CS patch + CSMT On : - In-game : ~3 fps average In resume, CS patch works for FarCry 3, +6fps but cause a very low fps for SC Blacklist, divide by 5 the fps in game. Max

1 0

Re: crypt32 patch review
by Juan Lang 06 Sep '13

06 Sep '13

[+wine-devel] Hi Jacek, I've added the list so the discussion can take place in public. On Tue, Sep 3, 2013 at 8:50 AM, Jacek Caban <jacek(a)codeweavers.com> wrote: > I have a patch for crypt32. I'd appreciate your review before I submit > it to Wine. It has high potential to be insecure... This should fix Wine bug 28004 as well as some websites that don't send full cert chain in > SSL/TLS handshake, but instead just their own certs. For that we need > two changes. First, we need to look for issuers in global stores (as in > those that are not passed to CertGetCertificateChain). When I did that, > I don't really see a security issue here. The global stores are implicitly trusted, so neglecting to check them was probably an oversight on my part. Your tests imply something is missing. My only real question here is whether the test results are in any way impacted by some unknown caching happening in Windows. Has this chain been verified prior to running the test? I'm going to guess that the test bot machines are "clean" prior to running the tests, but if they download their test executables from winehq.org, that won't be the case. > it came out that it's not enough for intermediate issuers. Those have to > be downloaded if we have information about their location stored in > validated cert. That's easy using cryptnet. Could you please review the > attached patch? > + for(i=0; i < info->cAccDescr; i++) { + if(!strcmp(szOID_PKIX_CA_ISSUERS, info->rgAccDescr[i].pszAccessMethod) + && info->rgAccDescr[i].AccessLocation.dwAltNameChoice == CERT_ALT_NAME_URL) { You explicitly make use of the AIA extension to find the location of intermediate certs. This is reasonable, and it gets your test case to pass, but it won't cover end certs that don't make use of the AIA extension. As I said above, I wonder whether caching is impacting the test results. More: The thing that would be also nice to have as follow up is to cache > downloaded URLs. They are already cached in URL cache, but I believe > that they should be also cached in some place like world collection or > something like that. I'm not sure what would be appropriate. Do you have > a suggestion? > Yes. I suspect the most relevant bug is actually 27168. 28004 is probably a dupe of it, except that I'm not certain that PartyPoker uses chromium. In brief, Microsoft's crypt32 appears to cache intermediate certs in a PCCERT_CONTEXT's hCertStore. What I should be doing in crypt32, but am not, is to have certs ref count the stores they're in, such that the last cert to be closed causes its store to be freed, if the store is closed prior to the cert being freed. This, combined with certificate chains being cached in Microsoft's implementation, would allow intermediate certs to be found without explicitly checking the AIA. You can see how the certificate chain engine ought to support caching on MSDN: http://msdn.microsoft.com/en-us/library/windows/desktop/aa377184(v=vs.85).a… I never implemented chain caching, as I expected it'd be a performance optimization and could be addressed at a later time, and never got back to it. In addition to bug 27168, you can see how Chromium is making use of crypt32's certificate caching in net::X509Certificate::CreateOSCertChainForCert, both its comments and implementation: http://src.chromium.org/viewvc/chrome/trunk/src/net/cert/x509_certificate.h http://src.chromium.org/viewvc/chrome/trunk/src/net/cert/x509_certificate_w… Back to your patch: I'm not entirely opposed to the explicit AIA approach, but I think it's worth at least thinking about other methods. And, I'd prefer to see the code block more explicitly separated from the surrounding code, with either a comment or a clear function name to indicate what's going on. As it is, one has to read quite a bit of CRYPT_FindIssuer to realize that it's really looking for an AIA extension to find intermediate issuers. Last thing on the patch, some style nits. (You already remarked that it needs splitting, and I agree.) + if(issuer) { Elsewhere in crypt32 I indent prior to open parentheses, so I worry this will make it a little harder to maintain a consistent style. Please observe the existing style, here and elsewhere. - issuer = CertFindCertificateInStore(store, - subject->dwCertEncodingType, 0, CERT_FIND_SUBJECT_NAME, - &subject->pCertInfo->Issuer, prevIssuer); + issuer = CRYPT_FindIssuer(engine, subject, store, CERT_FIND_SUBJECT_NAME, + &subject->pCertInfo->Issuer, flags, prevIssuer); It might not be easy to guess my indenting style for continuation lines, but I use a single additional space to indicate continuation through crypt32. I'd appreciate observing the same style. - hAdditionalStore, &chain); + hAdditionalStore, dwFlags, &chain); Likewise, the indentation change here doesn't seem necessary. Thanks very much for working on this. Hope my comments are helpful, let me know if I can be of further assistance. --Juan

2 1

Re: ntdll/tests: Add tests for job objects. (try 2)
by Frédéric Delanoy 06 Sep '13

06 Sep '13

On Fri, Sep 6, 2013 at 5:41 AM, Andrew Cook <ariscop(a)gmail.com> wrote: > --- > dlls/ntdll/tests/Makefile.in | 1 + > dlls/ntdll/tests/job.c | 151 > +++++++++++++++++++++++++++++++++++++++++++ > include/winnt.h | 5 ++ > 3 files changed, 157 insertions(+) > create mode 100644 dlls/ntdll/tests/job.c + if(pNtIsProcessInJob) + todo_wine todo_wine ok(pNtIsProcessInJob(pi[0].hProcess, JobObject) == STATUS_PROCESS_NOT_IN_JOB, + "NtIsProcessInJob: expected STATUS_PROCESS_NOT_IN_JOB, got %x\n", ret); Is that double todo_wine intended? It seems weird... -- Frédéric Delanoy

2 1

Re: [PATCH 1/3] riched20: Use codepage in ME_ToUnicode. (try 2)
by Nikolay Sivov 06 Sep '13

06 Sep '13

On 9/4/2013 07:17, Jactry Zeng wrote: > - ME_EndToUnicode(unicode, wszText); > + ME_EndToUnicode(unicode ? 1200 : CP_ACP, wszText); It's still ugly to use magic numbers like that, in a similar situation I had some time ago I use ~0 to mark WCHAR data encoding that does need special handling. Even with a value like ~0 it needs to be documented in code comments.

2 2

Re: [PATCH 2/3] ws2_32: Implement get socket option SO_PROTOCOL_INFO (try 3)
by Marvin 06 Sep '13

06 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2035 Your paranoid android. === wxppro (32 bit sock) === sock.c:519: Test failed: oob_server (b8): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 00000000

1 0

D3D command stream patches for testing
by Pierre Franco 05 Sep '13

05 Sep '13

I've tested some games (wine 1.7.1 64-bit for Guild Wars 2 and SCII, 32-bit for Skyrim, no wined3d/d3d patch except the patchset for CSMT). I have a GTX660 (slightly overclocked, +10 Mhz or so) with the 325.15 Nvidia blob and an Intel i5 2500K (overclocked to 4.2 Ghz). #Guild Wars 2(in the Lion's Arch with ~75-100 players, always from the same spot): Quality Options: -Fullscreen Mode -1600x1200 -Animation: High -Anti-aliasing: FXAA -Environment: High -LOD: Excellent -Textures: High -Reflections: Land and Sky(causes high frame rate drops when moving the camera) -Render Sampling: Supersampling -Shadows: High -Shaders: High -Post-processing: High(absolutely doesn't influence frame rate) -No High Res Character Textures -Character model limit/Character model quality: Medium -VSyng: Off -Optimal Texture Filtering: Off(no real effect except reducing the FPS) Without -dx9single(it should use more than one core and DX10 then): -With __GL_THREADED_OPTIMIZATIONS: 30-45 FPS in the login screen, 8-10 FPS when not moving the camera, 3-5 FPS when moving it. -Without __GL_THREADED_OPTIMIZATIONS: 60 FPS in the login screen, 18-20 FPS when not moving the camera, 5-10 FPS when moving it. With -dx9single(the game is far more quicker to load with it): -With __GL_THREADED_OPTIMIZATIONS: >60 FPS in the login screen, 23-24 FPS when not moving the camera, 5-20 FPS when moving it. -Without __GL_THREADED_OPTIMIZATIONS: >60 FPS in the login screen, 23-24 FPS when not moving the camera, 20 FPS when moving it. Conclusion: -dx9single is GOOD and __GL_THREADED_OPTIMIZATIONS is BAD. #Starcraft II Quality Options: Ultra(default mode, also for the textures). The game claims 50-70 FPS, but it seems to lag when moving the camera and the output is only trash (I need to change a graphical setting to be able to see anything). With __GL_THREADED_OPTIMIZATIONS, it's even more laggy and the FPS drop below 40. #Skyrim Quality Options: Very High. I can't see the FPS of the game, but it was running smoothly and is still running smoothly with the patchset. I didn't tried with __GL_THREADED_OPTIMIZATIONS(well, I tried long ago, and that was horribly slow). I also want to say that wine is spamming "Waiting for the cs" in the console (I assume it's nothing really important as the project seems to be WIP, why asking for tester otherwise?) and wgl errors (err:wgl:wglFlush wglFlush). Cordially. P.S. : Sorry for my English, I am still learning it. -- Pierre Franco nob.dir.info(a)gmail.com

1 0

Re: [PATCH 6/6] kernel32/tests: remove several todos in test_waittxempty
by Marvin 05 Sep '13

05 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2023 Your paranoid android. === w7pro64 (32 bit comm) === comm.c:856: Test failed: WaitCommEvent failed with a timeout comm.c:868: recovering after WAIT_TIMEOUT... comm.c:879: Test failed: WaitCommEvent error 0 comm.c:880: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:884: WaitCommEvent for EV_TXEMPTY took 2137 ms (timeout 2133) comm.c:885: Test failed: WaitCommEvent used 2137 ms for waiting comm.c:919: Test failed: WaitCommEvent error 87 comm.c:921: Test failed: WaitCommEvent failed with a timeout comm.c:932: recovering after WAIT_TIMEOUT... comm.c:938: Test failed: WaitCommEvent failed with a timeout comm.c:943: Test failed: WaitCommEvent error 0 comm.c:944: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:948: WaitCommEvent for EV_TXEMPTY took 3151 ms (timeout 2133) comm.c:949: Test failed: WaitCommEvent used 3151 ms for waiting comm.c:1617: test_AbortWaitCts timeout 500 handle 00000130 comm.c:1584: Changing CommMask on the fly for handle 00000130 after timeout 500

1 0

Re: [PATCH 2/5] wait until all data from earlier test has been written in test_waittxempty
by Dmitry Timoshkov 05 Sep '13

05 Sep '13

Wolfgang Walter <wine(a)stwm.de> wrote: > > > > > With my patches 1/2 and 2/2 I get: > > > > > > > > > > fixme:iphlpapi:NotifyAddrChange (Handle 0x10ee8e0, overlapped > > > > > 0x10ee8ec): > > > > > stub wine: configuration in '/home/walterw/.wine' has been updated. > > > > > fixme:comm:set_queue_size insize 1024 outsize 1024 unimplemented stub > > > > > comm.c:857: Test succeeded inside todo block: WaitCommEvent failed > > > > > with a > > > > > timeout comm.c:881: Test succeeded inside todo block: WaitCommEvent > > > > > error > > > > > 997 comm.c:883: Test succeeded inside todo block: WaitCommEvent: > > > > > expected > > > > > EV_TXEMPTY, got 0x4 comm.c:889: Test succeeded inside todo block: > > > > > WaitCommEvent used 1141 ms for waiting err:comm:set_line_control > > > > > ByteSize > > > > > fixme:ntdll:server_ioctl_file Unsupported ioctl 1b000c (device=1b > > > > > access=0 > > > > > func=3 method=0) comm.c:2036: Tests skipped: interactive tests (set > > > > > WINETEST_INTERACTIVE=1) > > > > > > > > Successes inside of todo_wine blocks are treated as failres. > > > > > > So you think I should remove the wine_todos already here? > > > > No, the source of the failures is still there. > > What do you mean with that? The tests indeed do succeed now and there is a > reason they do: when you call WaitCommEvent() while the tx buffer is not empty > yet the wine code will detect that EV_TXEMPTY correctly: The tests must pass under Wine without any additional "fixes" as they do currently under Windows. If you add some code to the tests which suddenly makes them pass under Wine - that's not a fix, Wine implementation should be fixed instead. -- Dmitry.

3 6

Re: iphlpapi: Add AllocateAndGetTcpExTableFromStack() (try 6)
by Alexandre Julliard 05 Sep '13

05 Sep '13

Ralf Habacker <ralf.habacker(a)freenet.de> writes: > +/****************************************************************** > + * test api function AllocateAndGetTcpExTableFromStack() > + * > + * Only specific tests required because the function is based > + * on build_tcp_table() which is covered by test_GetExtendedTcpTable() > + */ The tests are supposed to test the behavior on Windows. The details of the Wine implementation are irrelevant. You can't assume that the functions share an implementation. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ntdll/tests: Add tests for job objects.
by Alexandre Julliard 05 Sep '13

05 Sep '13

Andrew Cook <ariscop(a)gmail.com> writes: > diff --git a/dlls/ntdll/tests/Makefile.in b/dlls/ntdll/tests/Makefile.in > index 10d6674..1903d10 100644 > --- a/dlls/ntdll/tests/Makefile.in > +++ b/dlls/ntdll/tests/Makefile.in > @@ -11,6 +11,7 @@ C_SRCS = \ > file.c \ > generated.c \ > info.c \ > + job.c \ Please put this in an existing file, like om.c > +static DWORD getProcess(PHANDLE handle) { > + STARTUPINFO startup = {}; > + PROCESS_INFORMATION info = {}; > + > + if(!CreateProcessA(NULL, GetCommandLine(), NULL, NULL, FALSE, 0, NULL, NULL, &startup, &info)) { > + ok(FALSE, "CreateProcess: %x\n", GetLastError()); > + return 0; > + } > + > + CloseHandle(info.hThread); > + *handle = info.hProcess; > + > + return info.dwProcessId; > +} You should use the existing winetest support for creating child processes. > + ok(TerminateProcess(hprocess[0], 1), "TerminateProcess: %x\n", GetLastError()); > + Sleep(1000); > + ok(TerminateProcess(hprocess[1], 2), "TerminateProcess: %x\n", GetLastError()); > + Sleep(1000); Don't add sleeps when not necessary. > +static void is_zombie(void) > +{ > + WCHAR val[32] = {0}; > + static const WCHAR envName[] = { 'T','E','S','T',0 }; > + static const WCHAR envVal[] = { 'J','o','b','O','b','j','e','c','t',0 }; > + > + GetEnvironmentVariableW(envName, val, 32); > + > + if(lstrcmpW(envVal, val) == 0) > + /* Wait forever, we've been created for a process handle */ > + while(1) Sleep(INFINITE); > + > + SetEnvironmentVariableW(envName, envVal); > +} That's ugly. Again, check how child processes are handled in other tests. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ws2_32: Cope with invalid protocols in WSAEnumProtocols
by Dmitry Timoshkov 05 Sep '13

05 Sep '13

Bruno Jesus <00cpxxx(a)gmail.com> wrote: > +INT validprotocols[] = { WS_IPPROTO_TCP, > + WS_IPPROTO_UDP, > + NSPROTO_IPX, > + NSPROTO_SPX, > + NSPROTO_SPXII, > + 0 }; This should be 'static const'. -- Dmitry.

2 1

Re: [PATCH 5/5] ddraw: Enumerate DXT2 and DXT4
by Henri Verbeet 05 Sep '13

05 Sep '13

On 5 September 2013 10:42, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Yes, we don't actually support those, but that's wined3d's problem, not > ddraw's. We do. The difference between DXT2/DXT3 and DXT4/DXT5 is just a convention wrt. storing pre-multiplied alpha or not, there's no difference in the actual encoding.

2 1

Re: [PATCH 5/5] kernel32/tests: remove several todos in test_waittxempty
by Dmitry Timoshkov 05 Sep '13

05 Sep '13

Wolfgang Walter <wine(a)stwm.de> wrote: > - ok(!res && GetLastError() == ERROR_IO_PENDING, "%d: WaitCommEvent error %d\n", i, GetLastError()); > + ok(res || (!res && GetLastError() == ERROR_IO_PENDING), "%d: WaitCommEvent error %d\n", i, GetLastError()); This change looks spurious and unrelated. Also todos must be removed in the patch that fixes appropriate behaviour. -- Dmitry.

2 6

Re: [PATCH 3/5] ddraw/tests: Test DDCAPS2_TEXTUREMANAGE compatibility with other flags
by Henri Verbeet 05 Sep '13

05 Sep '13

On 5 September 2013 10:42, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + if(DDSD->ddsCaps.dwCaps2 & DDSCAPS2_TEXTUREMANAGE) Minor formatting error here.

2 1

Re: [PATCH 3/5] ddraw/tests: Test DDCAPS2_TEXTUREMANAGE compatibility with other flags
by Marvin 05 Sep '13

05 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2016 Your paranoid android. === wxppro (32 bit ddraw7) === ddraw7.c:3694: Test failed: Got unexpected, hr 0x8876014a, case 3. === wvista (32 bit ddraw7) === ddraw7.c:3694: Test failed: Got unexpected, hr 0x88760233, case 3. ddraw7.c:3694: Test failed: Got unexpected, hr 0x88760233, case 8. === w7pro64 (32 bit ddraw7) === ddraw7.c:3694: Test failed: Got unexpected, hr 0x88760233, case 3. ddraw7.c:3694: Test failed: Got unexpected, hr 0x88760233, case 8. === w7pro64 (64 bit ddraw7) === ddraw7.c:3694: Test failed: Got unexpected, hr 0x80004002, case 2. ddraw7.c:3694: Test failed: Got unexpected, hr 0x88760233, case 3. ddraw7.c:3694: Test failed: Got unexpected, hr 0x80004002, case 4. ddraw7.c:3694: Test failed: Got unexpected, hr 0x88760233, case 8. === wxppro (32 bit ddraw4) === ddraw4.c:3880: Test failed: Got unexpected, hr 0x8876014a, case 3. === wvista (32 bit ddraw4) === ddraw4.c:3880: Test failed: Got unexpected, hr 0x88760233, case 3. ddraw4.c:3880: Test failed: Got unexpected, hr 0x88760233, case 8. === w7pro64 (32 bit ddraw4) === ddraw4.c:3880: Test failed: Got unexpected, hr 0x88760233, case 3. ddraw4.c:3880: Test failed: Got unexpected, hr 0x88760233, case 8. === w7pro64 (64 bit ddraw4) === ddraw4.c:3880: Test failed: Got unexpected, hr 0x88760233, case 3. ddraw4.c:3880: Test failed: Got unexpected, hr 0x88760233, case 8.

1 0

Re: [PATCH 1/5] use a correct timeout in test_waittxempty
by Dmitry Timoshkov 05 Sep '13

05 Sep '13

Wolfgang Walter <wine(a)stwm.de> wrote: > When we send 17 bytes with 150 baud, no parity, one stop bit then > we need to wait at least 17*10/150 seconds > 1000 ms Under Windows with both real COM-port and USB-serial cable this test takes no longer than 890 ms, usually it's even shorter like 875 ms. Testbot VMs also don't fail this test. If under Wine it takes > 1000 ms for you then probably there is a bug somewhere. -- Dmitry.

2 3

Re: D3D command stream patches for testing
by Prot Secret 05 Sep '13

05 Sep '13

Hi, I am interested in your work, but after patching wine171 of this patch and enabled csmt, i have seen this in SC2 http://postimg.org/gallery/1w8y6jbg I use nvidia GTX 680 with proprietary i386 nvidia driver 319.49. Where I could be wrong, or what else can be set that would be normalized image using the patch? Thanks!

2 1

RE: D3D command stream patches for testing
by Vedran Rodic 04 Sep '13

04 Sep '13

Hello, I was not subscribed to wine-devel, so I can't reply to Stefan's mail directly, but here are some of my observations with Dota 2 on an Intel HD4000 GPU. Intel Mesa driver doesn't seem to like glBufferSubData in a way this patchset uses it. I get many many messages like these per frame when I enable INTEL_DEBUG=perf performance feedback of the Intel Mesa driver: Using a blit copy to avoid stalling on 588b glBufferSubData() to a busy buffer object. Using a blit copy to avoid stalling on 480b glBufferSubData() to a busy buffer object. Using a blit copy to avoid stalling on 480b glBufferSubData() to a busy buffer object. Using a blit copy to avoid stalling on 1104b glBufferSubData() to a busy buffer object. Using a blit copy to avoid stalling on 252b glBufferSubData() to a busy buffer object. Using a blit copy to avoid stalling on 204b glBufferSubData() to a busy buffer object. Using a blit copy to avoid stalling on 192b glBufferSubData() to a busy buffer object. Using a blit copy to avoid stalling on 192b glBufferSubData() to a busy buffer object. Using a blit copy to avoid stalling on 12b glBufferSubData() to a busy buffer object. Using a blit copy to avoid stalling on 12b glBufferSubData() to a busy buffer object. I'm not sure how much this really impacts performance, but even with my Dota 2 wine perf hacks [1] it's not faster than current Wine git (performance is very similar). On what hardware did you test this patchset? [1]: http://vrodic.blogspot.com/2013/08/dota-2-wine-optimization-for-intel-gpus.…

2 1

Re: [PATCH 3/5] wined3d: Don't set WINED3DUSAGE_RENDERTARGET on the front buffer.
by Stefan Dösinger 04 Sep '13

04 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2013-09-04 08:56, schrieb Henri Verbeet: > We never render directly to the front buffer, and in case of e.g. a > P8 front buffer, we would fail surface creation if we were to > enforce format restrictions. This patch uncovers a problem I am not quite sure how to solve. We set the frontbuffer as render target in wined3d_device_init_3d if there's no backbuffer, i.e., when ddraw is used. In theory this doesn't matter because we're not rendering to it, just blitting. Similarly, dlls/ddraw/device.c calls set_render_target to set the ddraw frontbuffer on release. The call fails now, but that doesn't cause any visible problems yet. There is a zombie wined3d surface left, but it goes away on ddraw shutdown or when a new ddraw IDirect3DDevice is created. However, when we create wined3d textures for standalone surfaces, the ddraw surface isn't destroyed until the wined3d surface goes away because we're waiting for the callback. This keeps the ddraw surface alive as well. The ddraw tests notice this because keeping the IDirectDrawSurface alive means keeping an IDirect3DDevice1 alive as well. The device holds a reference to the attached viewport(s), which triggers a failure in the ddraw1 tests. The test failure was lingering before, I fixed this by adding a similar set_render_target call to ddraw_surface_release_iface_destroy. See the attached patches for reference. The easiest solution seems to create a separate dummy render target that ddraw can use to unset application targets. That still leaves the problem that we're initializing wined3d with an invalid render target now. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSJ6NiAAoJEN0/YqbEcdMwqEsP/3We5UyaUsuUmh8DuqpUDozy OPFdfg0defIGBB3xdcRPYtwz265jsThxK8ek/vb24E1fJXJsm7zE1CJq1jUh/Beo X1zkewvL29WpriNvh11AW0+FIrE2XMwmr/5ekHQMXM4Evv2aRWG6zmWj0Wv1zR+x EcFgHE7J6boOIHtogPoge8KHiVULjxm91Dpnariab0YzUNDUfaHUXopWH0N4hb3T W5ds4cnHLOapOk8ihDfyAcBXOH4JlvConKKG4zDtbcuovp01yLR+eF03m/eBqt5m 0x3VpPyyaIJpFtOERAi9CqbN0Xuy3wOLmtgHsjy8Qh1wKr/I+DmkuakcsJYELmrY Ou7n+fDRceJyxdqP8vGtwlsP7Skkyxet/KYt7xbWsMcIcMjFDv6KW6YMyOGg2aJM O4o8gEFH3zgBQqLBsOf+O85GbQ2ZTLFoRaWkbRYFYYBaypd+S4TBRn9i0gL0Qw/q KImvYV47HcBK0uTuuV0dG/2YzUs/JraKGMU0sVmUNiDqfOm7+R+NAlU86jQ4PNo+ G0cV2IpEt9Bk/06XmSWI944X7NTe/ZDXs8Fa5MveLk87wETzg54F3RK2AoyHPY59 UK/3nisrRmUDeRZHiRp53E6eSW7VSXoHUgqeHt04fvLheMXpAnuibKJcKGTYqYMe kfkNuq73chpb9uZhe0EJ =PCrO -----END PGP SIGNATURE-----

2 1

Re: oledb32: Implement IDataSourceLocator get/put hWnd
by Alexandre Julliard 04 Sep '13

04 Sep '13

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > Hi, > > > Changelog: > oledb32: Implement IDataSourceLocator get/put hWnd It doesn't work here: ../../../tools/runtest -q -P wine -M oledb32.dll -T ../../.. -p oledb32_test.exe.so database.c && touch database.ok database.c:252: Test failed: got 80040154 make[1]: *** [database.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] wined3d: Fix per-stage constant in GLSL fixed function pipeline + add tests. (try 2)
by Matteo Bruni 04 Sep '13

04 Sep '13

2013/9/4 Christian Costa <titan.costa(a)gmail.com>: > This patch fixes part of bug 33606 and 31918. > > The current code generates shaders that support per-stage constant but does not declare the variables used causing thus compilation failures. > With this patch, these variables are declared and updated when needed. Tests are also added. > > Thanks to Matteo Bruni for review and support. > > Try 2: > - update with latest git Hi, I have a few small nits still, please bear with me... > --- > dlls/d3d9/tests/visual.c | 80 ++++++++++++++++++++++++++++++++++++++++++++ > dlls/wined3d/glsl_shader.c | 34 ++++++++++++++++++- > 2 files changed, 112 insertions(+), 2 deletions(-) > > diff --git a/dlls/d3d9/tests/visual.c b/dlls/d3d9/tests/visual.c > index b856c93..6072c23 100644 > --- a/dlls/d3d9/tests/visual.c > +++ b/dlls/d3d9/tests/visual.c > @@ -10742,6 +10742,85 @@ static void dp3_alpha_test(IDirect3DDevice9 *device) { > ok(hr == D3D_OK, "IDirect3DDevice9_SetTextureStageState failed with 0x%08x\n", hr); > } > > +static void perstage_constant_test(IDirect3DDevice9 *device) > +{ > + HRESULT hr; > + D3DCAPS9 caps; > + DWORD color; > + struct vertex quad[] = { > + { -1.0, -1.0, 0.1, 0x408080c0 }, > + { 1.0, -1.0, 0.1, 0x408080c0 }, > + { -1.0, 1.0, 0.1, 0x408080c0 }, > + { 1.0, 1.0, 0.1, 0x408080c0 }, > + }; > + Can you please make quad[] static const? Also, add the 'f' suffix to the float constants and move the opening brace to newline. > + memset(&caps, 0, sizeof(caps)); > + hr = IDirect3DDevice9_GetDeviceCaps(device, &caps); > + ok(SUCCEEDED(hr), "GetDeviceCaps failed with 0x%08x\n", hr); > + if (!(caps.PrimitiveMiscCaps & D3DPMISCCAPS_PERSTAGECONSTANT)) > + { > + skip("D3DPMISCCAPS_PERSTAGECONSTANT not supported\n"); Please put a '.' at the end of the message. Same for the following prints. > + return; > + } > + > + hr = IDirect3DDevice9_SetFVF(device, D3DFVF_XYZ | D3DFVF_DIFFUSE); > + ok(hr == D3D_OK, "IDirect3DDevice9_SetFVF failed with 0x%08x\n", hr); > + > + hr = IDirect3DDevice9_SetTextureStageState(device, 0, D3DTSS_CONSTANT, 0x80a1b2c3); > + ok(hr == D3D_OK, "IDirect3DDevice9_SetTextureStageState failed with 0x%08x\n", hr); > + > + /* Check color values */ > + hr = IDirect3DDevice9_SetTextureStageState(device, 0, D3DTSS_COLOROP, D3DTOP_SELECTARG1); > + ok(hr == D3D_OK, "IDirect3DDevice9_SetTextureStageState failed with 0x%08x\n", hr); > + hr = IDirect3DDevice9_SetTextureStageState(device, 0, D3DTSS_COLORARG1, D3DTA_CONSTANT); > + ok(hr == D3D_OK, "IDirect3DDevice9_SetTextureStageState failed with 0x%08x\n", hr); > + Although you don't strictly need it here, I'd explicitly set D3DTSS_COLOROP for stage 1 to D3DTOP_DISABLE. Also maybe set D3DTSS_ALPHAOP for stage 0 to disabled? > + hr = IDirect3DDevice9_Clear(device, 0, NULL, D3DCLEAR_TARGET | D3DCLEAR_ZBUFFER, 0x00000000, 1.0f, 0); > + ok(hr == D3D_OK, "IDirect3DDevice9_Clear failed with 0x%08x\n", hr); > + > + hr = IDirect3DDevice9_BeginScene(device); > + ok(hr == D3D_OK, "IDirect3DDevice9_BeginScene failed with 0x%08x\n", hr); > + hr = IDirect3DDevice9_DrawPrimitiveUP(device, D3DPT_TRIANGLESTRIP, 2, quad, sizeof(*quad)); > + ok(SUCCEEDED(hr), "DrawPrimitiveUP failed with 0x%08x\n", hr); > + hr = IDirect3DDevice9_EndScene(device); > + ok(hr == D3D_OK, "IDirect3DDevice9_EndScene failed with 0x%08x\n", hr); > + > + color = getPixelColor(device, 320, 240); > + ok(color_match(color, 0x00a1b2c3, 4), "perstage constant test 0x%08x, expected 0x00a1b2c3\n", color); > + hr = IDirect3DDevice9_Present(device, NULL, NULL, NULL, NULL); > + ok(SUCCEEDED(hr), "IDirect3DDevice9_Present failed with 0x%08x\n", hr); > + > + /* Check alpha value */ > + hr = IDirect3DDevice9_SetTextureStageState(device, 0, D3DTSS_COLOROP, D3DTOP_SELECTARG1); > + ok(hr == D3D_OK, "IDirect3DDevice9_SetTextureStageState failed with 0x%08x\n", hr); > + hr = IDirect3DDevice9_SetTextureStageState(device, 0, D3DTSS_COLORARG1, D3DTA_CONSTANT | D3DTA_ALPHAREPLICATE); > + ok(hr == D3D_OK, "IDirect3DDevice9_SetTextureStageState failed with 0x%08x\n", hr); > + hr = IDirect3DDevice9_SetTextureStageState(device, 0, D3DTSS_ALPHAOP, D3DTOP_SELECTARG1); > + ok(hr == D3D_OK, "IDirect3DDevice9_SetTextureStageState failed with 0x%08x\n", hr); > + hr = IDirect3DDevice9_SetTextureStageState(device, 0, D3DTSS_ALPHAARG1, D3DTA_CONSTANT); > + ok(hr == D3D_OK, "IDirect3DDevice9_SetTextureStageState failed with 0x%08x\n", hr); > + > + hr = IDirect3DDevice9_Clear(device, 0, NULL, D3DCLEAR_TARGET | D3DCLEAR_ZBUFFER, 0x00000000, 1.0f, 0); > + ok(hr == D3D_OK, "IDirect3DDevice9_Clear failed with 0x%08x\n", hr); > + > + hr = IDirect3DDevice9_BeginScene(device); > + ok(hr == D3D_OK, "IDirect3DDevice9_BeginScene failed with 0x%08x\n", hr); > + hr = IDirect3DDevice9_DrawPrimitiveUP(device, D3DPT_TRIANGLESTRIP, 2, quad, sizeof(*quad)); > + ok(SUCCEEDED(hr), "DrawPrimitiveUP failed with 0x%08x\n", hr); > + hr = IDirect3DDevice9_EndScene(device); > + ok(hr == D3D_OK, "IDirect3DDevice9_EndScene failed with 0x%08x\n", hr); > + > + color = getPixelColor(device, 320, 240); > + ok(color_match(color, 0x00808080, 4), "perstage constant test 0x%08x, expected 0x00808080\n", color); > + hr = IDirect3DDevice9_Present(device, NULL, NULL, NULL, NULL); > + ok(SUCCEEDED(hr), "IDirect3DDevice9_Present failed with 0x%08x\n", hr); > + > + hr = IDirect3DDevice9_SetTextureStageState(device, 0, D3DTSS_COLOROP, D3DTOP_DISABLE); > + ok(hr == D3D_OK, "IDirect3DDevice9_SetTextureStageState failed with 0x%08x\n", hr); > + hr = IDirect3DDevice9_SetTextureStageState(device, 0, D3DTSS_ALPHAOP, D3DTOP_DISABLE); > + ok(hr == D3D_OK, "IDirect3DDevice9_SetTextureStageState failed with 0x%08x\n", hr); I'd move those to the test which actually requires it (which is depth_buffer2_test IIUC). It could be a separate patch. The other option would be to move this new test out of the way (e.g. by executing it next to resz_test(), thus using a separate device). I don't have a strong opinion in that regard though. > +} > + > static void zwriteenable_test(IDirect3DDevice9 *device) { > HRESULT hr; > DWORD color; > @@ -14811,6 +14890,7 @@ START_TEST(visual) > texop_range_test(device_ptr); > alphareplicate_test(device_ptr); > dp3_alpha_test(device_ptr); > + perstage_constant_test(device_ptr); > depth_buffer_test(device_ptr); > depth_buffer2_test(device_ptr); > depth_blit_test(device_ptr); > diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c > index 740e100..2b8041a 100644 > --- a/dlls/wined3d/glsl_shader.c > +++ b/dlls/wined3d/glsl_shader.c > @@ -132,6 +132,7 @@ struct glsl_ps_program > GLint bumpenv_mat_location[MAX_TEXTURES]; > GLint bumpenv_lum_scale_location[MAX_TEXTURES]; > GLint bumpenv_lum_offset_location[MAX_TEXTURES]; > + GLint const_location[MAX_TEXTURES]; > GLint tex_factor_location; > GLint specular_enable_location; > GLint ycorrection_location; > @@ -918,6 +919,15 @@ static void shader_glsl_load_constants(void *shader_priv, struct wined3d_context > else > GL_EXTCALL(glUniform4fARB(prog->ps.specular_enable_location, 0.0f, 0.0f, 0.0f, 0.0f)); > > + for (i = 0; i < MAX_TEXTURES; ++i) > + { > + if (prog->ps.const_location[i] != -1) > + { > + D3DCOLORTOGLFLOAT4(state->texture_states[i][WINED3D_TSS_CONSTANT], col); > + GL_EXTCALL(glUniform4fARB(prog->ps.const_location[i], col[0], col[1], col[2], col[3])); > + } > + } > + > checkGLcall("fixed function uniforms"); > } > Like I already mentioned privately, this could have its own WINED3D_SHADER_CONST_* flag but I'm not sure it would be worth it. Comments? > @@ -5167,7 +5177,6 @@ static const char *shader_glsl_get_ffp_fragment_op_arg(struct wined3d_shader_buf > break; > > case WINED3DTA_CONSTANT: > - FIXME("Per-stage constants not implemented.\n"); > switch (stage) > { > case 0: ret = "const0"; break; > @@ -5447,6 +5456,16 @@ static GLuint shader_glsl_generate_ffp_fragment_shader(struct wined3d_shader_buf > > for (stage = 0; stage < MAX_TEXTURES; ++stage) > { > + if ((settings->op[stage].carg0 == WINED3DTA_CONSTANT) > + || (settings->op[stage].carg1 == WINED3DTA_CONSTANT) > + || (settings->op[stage].carg2 == WINED3DTA_CONSTANT) > + || (settings->op[stage].aarg0 == WINED3DTA_CONSTANT) > + || (settings->op[stage].aarg1 == WINED3DTA_CONSTANT) > + || (settings->op[stage].aarg2 == WINED3DTA_CONSTANT)) > + { > + shader_addline(buffer, "uniform vec4 const%d;", stage); > + } > + > if (!(tex_map & (1 << stage))) > continue; > > @@ -5803,6 +5822,8 @@ static void shader_glsl_init_ps_uniform_locations(const struct wined3d_gl_info * > ps->bumpenv_lum_scale_location[i] = GL_EXTCALL(glGetUniformLocationARB(program_id, name)); > snprintf(name, sizeof(name), "bumpenv_lum_offset%u", i); > ps->bumpenv_lum_offset_location[i] = GL_EXTCALL(glGetUniformLocationARB(program_id, name)); > + snprintf(name, sizeof(name), "const%u", i); > + ps->const_location[i] = GL_EXTCALL(glGetUniformLocationARB(program_id, name)); > } > > ps->tex_factor_location = GL_EXTCALL(glGetUniformLocationARB(program_id, "tex_factor")); > @@ -7106,7 +7127,8 @@ static void glsl_fragment_pipe_get_caps(const struct wined3d_gl_info *gl_info, s > { > caps->wined3d_caps = WINED3D_FRAGMENT_CAP_PROJ_CONTROL > | WINED3D_FRAGMENT_CAP_SRGB_WRITE; > - caps->PrimitiveMiscCaps = WINED3DPMISCCAPS_TSSARGTEMP; > + caps->PrimitiveMiscCaps = WINED3DPMISCCAPS_TSSARGTEMP > + | WINED3DPMISCCAPS_PERSTAGECONSTANT; > caps->TextureOpCaps = WINED3DTEXOPCAPS_DISABLE > | WINED3DTEXOPCAPS_SELECTARG1 > | WINED3DTEXOPCAPS_SELECTARG2 > @@ -7251,6 +7273,7 @@ static const struct StateEntryTemplate glsl_fragment_pipe_state_template[] = > {STATE_TEXTURESTAGE(0, WINED3D_TSS_ALPHA_ARG2), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(0, WINED3D_TSS_ALPHA_ARG0), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(0, WINED3D_TSS_RESULT_ARG), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > + {STATE_TEXTURESTAGE(0, WINED3D_TSS_CONSTANT), {STATE_TEXTURESTAGE(0, WINED3D_TSS_CONSTANT), glsl_fragment_pipe_invalidate_constants}, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(1, WINED3D_TSS_COLOR_OP), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(1, WINED3D_TSS_COLOR_ARG1), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(1, WINED3D_TSS_COLOR_ARG2), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > @@ -7260,6 +7283,7 @@ static const struct StateEntryTemplate glsl_fragment_pipe_state_template[] = > {STATE_TEXTURESTAGE(1, WINED3D_TSS_ALPHA_ARG2), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(1, WINED3D_TSS_ALPHA_ARG0), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(1, WINED3D_TSS_RESULT_ARG), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > + {STATE_TEXTURESTAGE(1, WINED3D_TSS_CONSTANT), {STATE_TEXTURESTAGE(1, WINED3D_TSS_CONSTANT), glsl_fragment_pipe_invalidate_constants}, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(2, WINED3D_TSS_COLOR_OP), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(2, WINED3D_TSS_COLOR_ARG1), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(2, WINED3D_TSS_COLOR_ARG2), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > @@ -7269,6 +7293,7 @@ static const struct StateEntryTemplate glsl_fragment_pipe_state_template[] = > {STATE_TEXTURESTAGE(2, WINED3D_TSS_ALPHA_ARG2), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(2, WINED3D_TSS_ALPHA_ARG0), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(2, WINED3D_TSS_RESULT_ARG), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > + {STATE_TEXTURESTAGE(2, WINED3D_TSS_CONSTANT), {STATE_TEXTURESTAGE(2, WINED3D_TSS_CONSTANT), glsl_fragment_pipe_invalidate_constants}, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(3, WINED3D_TSS_COLOR_OP), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(3, WINED3D_TSS_COLOR_ARG1), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(3, WINED3D_TSS_COLOR_ARG2), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > @@ -7278,6 +7303,7 @@ static const struct StateEntryTemplate glsl_fragment_pipe_state_template[] = > {STATE_TEXTURESTAGE(3, WINED3D_TSS_ALPHA_ARG2), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(3, WINED3D_TSS_ALPHA_ARG0), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(3, WINED3D_TSS_RESULT_ARG), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > + {STATE_TEXTURESTAGE(3, WINED3D_TSS_CONSTANT), {STATE_TEXTURESTAGE(3, WINED3D_TSS_CONSTANT), glsl_fragment_pipe_invalidate_constants}, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(4, WINED3D_TSS_COLOR_OP), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(4, WINED3D_TSS_COLOR_ARG1), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(4, WINED3D_TSS_COLOR_ARG2), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > @@ -7287,6 +7313,7 @@ static const struct StateEntryTemplate glsl_fragment_pipe_state_template[] = > {STATE_TEXTURESTAGE(4, WINED3D_TSS_ALPHA_ARG2), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(4, WINED3D_TSS_ALPHA_ARG0), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(4, WINED3D_TSS_RESULT_ARG), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > + {STATE_TEXTURESTAGE(4, WINED3D_TSS_CONSTANT), {STATE_TEXTURESTAGE(4, WINED3D_TSS_CONSTANT), glsl_fragment_pipe_invalidate_constants}, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(5, WINED3D_TSS_COLOR_OP), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(5, WINED3D_TSS_COLOR_ARG1), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(5, WINED3D_TSS_COLOR_ARG2), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > @@ -7296,6 +7323,7 @@ static const struct StateEntryTemplate glsl_fragment_pipe_state_template[] = > {STATE_TEXTURESTAGE(5, WINED3D_TSS_ALPHA_ARG2), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(5, WINED3D_TSS_ALPHA_ARG0), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(5, WINED3D_TSS_RESULT_ARG), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > + {STATE_TEXTURESTAGE(5, WINED3D_TSS_CONSTANT), {STATE_TEXTURESTAGE(5, WINED3D_TSS_CONSTANT), glsl_fragment_pipe_invalidate_constants}, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(6, WINED3D_TSS_COLOR_OP), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(6, WINED3D_TSS_COLOR_ARG1), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(6, WINED3D_TSS_COLOR_ARG2), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > @@ -7305,6 +7333,7 @@ static const struct StateEntryTemplate glsl_fragment_pipe_state_template[] = > {STATE_TEXTURESTAGE(6, WINED3D_TSS_ALPHA_ARG2), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(6, WINED3D_TSS_ALPHA_ARG0), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(6, WINED3D_TSS_RESULT_ARG), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > + {STATE_TEXTURESTAGE(6, WINED3D_TSS_CONSTANT), {STATE_TEXTURESTAGE(6, WINED3D_TSS_CONSTANT), glsl_fragment_pipe_invalidate_constants}, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(7, WINED3D_TSS_COLOR_OP), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(7, WINED3D_TSS_COLOR_ARG1), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(7, WINED3D_TSS_COLOR_ARG2), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > @@ -7314,6 +7343,7 @@ static const struct StateEntryTemplate glsl_fragment_pipe_state_template[] = > {STATE_TEXTURESTAGE(7, WINED3D_TSS_ALPHA_ARG2), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(7, WINED3D_TSS_ALPHA_ARG0), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(7, WINED3D_TSS_RESULT_ARG), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > + {STATE_TEXTURESTAGE(7, WINED3D_TSS_CONSTANT), {STATE_TEXTURESTAGE(7, WINED3D_TSS_CONSTANT), glsl_fragment_pipe_invalidate_constants}, WINED3D_GL_EXT_NONE }, > {STATE_PIXELSHADER, {STATE_PIXELSHADER, glsl_fragment_pipe_shader }, WINED3D_GL_EXT_NONE }, > {STATE_RENDER(WINED3D_RS_FOGENABLE), {STATE_RENDER(WINED3D_RS_FOGENABLE), glsl_fragment_pipe_fog }, WINED3D_GL_EXT_NONE }, > {STATE_RENDER(WINED3D_RS_FOGTABLEMODE), {STATE_RENDER(WINED3D_RS_FOGENABLE), NULL }, WINED3D_GL_EXT_NONE }, > > > Cheers, Matteo.

1 0

Re: 0001-Fix-race-for-IOCTL_SERIAL_WAIT_ON_MASK.patch
by Alexandre Julliard 04 Sep '13

04 Sep '13

Wolfgang Walter <wine(a)stwm.de> writes: > @@ -1265,8 +1265,12 @@ static inline NTSTATUS io_control(HANDLE hDevice, > case IOCTL_SERIAL_WAIT_ON_MASK: > if (lpOutBuffer && nOutBufferSize == sizeof(DWORD)) > { > + piosb->u.Status = STATUS_PENDING; > + piosb->Information = 0; > if (!(status = wait_on(hDevice, fd, hEvent, piosb, lpOutBuffer))) > sz = sizeof(DWORD); > + else if (status == STATUS_PENDING) > + return status; Status is not supposed to be set until the operation is done. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [2/2] rpcrt4: Clear the connection pool when closing an http connection.
by Jacek Caban 04 Sep '13

04 Sep '13

On 09/04/13 15:01, Hans Leidekker wrote: > --- > dlls/rpcrt4/rpc_transport.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/dlls/rpcrt4/rpc_transport.c b/dlls/rpcrt4/rpc_transport.c > index d0857fa..1eb0151 100644 > --- a/dlls/rpcrt4/rpc_transport.c > +++ b/dlls/rpcrt4/rpc_transport.c > @@ -3234,6 +3234,8 @@ static int rpcrt4_ncacn_http_close(RpcConnection *Connection) > HeapFree(GetProcessHeap(), 0, httpc->servername); > httpc->servername = NULL; > > + /* don't allow this connection to be reused */ > + InternetSetOptionW(NULL, INTERNET_OPTION_SETTINGS_CHANGED, NULL, 0); There must be a better way to do that than removing all existing wininet cached connections to all hosts. Removing INTERNET_FLAG_KEEP_CONNECTION from HttpOpenRequest call would be a good start... Jacek

2 3

Re: [3/6] ntdll: NtWriteFile should fail for overlapped IO on files if offset is negative.
by Alexandre Julliard 04 Sep '13

04 Sep '13

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > diff --git a/dlls/ntdll/tests/file.c b/dlls/ntdll/tests/file.c > index cde299c..c802432 100644 > --- a/dlls/ntdll/tests/file.c > +++ b/dlls/ntdll/tests/file.c > @@ -2124,11 +2124,8 @@ todo_wine > iob.Information = -1; > offset.QuadPart = (LONGLONG)-2 /* FILE_USE_FILE_POINTER_POSITION */; > status = pNtWriteFile(hfile, 0, NULL, NULL, &iob, contents, sizeof(contents), &offset, NULL); > -todo_wine > ok(status == STATUS_INVALID_PARAMETER, "expected STATUS_INVALID_PARAMETER, got %#x\n", status); > -todo_wine > ok(iob.Status == -1, "expected -1, got %#x\n", iob.Status); > -todo_wine > ok(iob.Information == -1, "expected -1, got %ld\n", iob.Information); A test for a non-magic negative value would be a good idea. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] opencl/tests: Add initial tests
by Marvin 04 Sep '13

04 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2003 Your paranoid android. === build (build) === Unable to regenerate dlls/opencl/Makefile Recreation of tests/Makefile failed

1 0

Re: wininet: Don't start the next chunk if the read is satisfied.
by Jacek Caban 04 Sep '13

04 Sep '13

Hi Hans, On 09/04/13 09:22, Hans Leidekker wrote: > --- > dlls/wininet/http.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/wininet/http.c b/dlls/wininet/http.c > index 1832b4f..521e4aa 100644 > --- a/dlls/wininet/http.c > +++ b/dlls/wininet/http.c > @@ -2795,7 +2795,7 @@ static DWORD chunked_read(data_stream_t *stream, http_request_t *req, BYTE *buf, > chunked_stream_t *chunked_stream = (chunked_stream_t*)stream; > DWORD read_bytes = 0, ret_read = 0, res = ERROR_SUCCESS; > > - if(chunked_stream->chunk_size == ~0u) { > + if(!chunked_stream->chunk_size || chunked_stream->chunk_size == ~0u) { > res = start_next_chunk(chunked_stream, req); > if(res != ERROR_SUCCESS) > return res; > @@ -2835,7 +2835,7 @@ static DWORD chunked_read(data_stream_t *stream, http_request_t *req, BYTE *buf, > chunked_stream->chunk_size -= read_bytes; > size -= read_bytes; > ret_read += read_bytes; > - if(!chunked_stream->chunk_size) { > + if(size && !chunked_stream->chunk_size) { > assert(read_mode != READMODE_NOBLOCK); > res = start_next_chunk(chunked_stream, req); > if(res != ERROR_SUCCESS) This patch breaks two assumptions: - chunk_size outside chunked_read means the end of the stream - READMODE_SYNC should read as much data as possible There is longer story about the way it's implemented the way it is. Native IE in the past considered zero-length reporting data in INTERNET_STATUS_REQUEST_COMPLETE to be an error. If you stop reading in the end of chunk and the next chunk is the last one, then you will send such report asynchronously. That's why we read the whole chunk only if we can start reading the next one (and we can't if we don't want to block). Now I think that the failure could possibly be caused by a combination of returning zero size and some other bug and the behaviour that I described could just hide the problem. Commit 851866e22a731141da7e3cbd2550c67c59968959 fixed a problem that could potentially be the other one. This means that I'm not entirely sure that we really shouldn't report zero size data. This is illogical to begin with, but we even have tests for that: ok(!on_async, "Returned zero size in response to request complete\n"); I think we should try harder to have a test reporting zero size data (this may be tricky to write one for Wine tests, but if we could just observe such occasional notifications, that would be enough). And this would need more testing with native IE. This all means that intention of the patch may be right, but it needs more work. Thanks, Jacek

2 2

Re: iphlpapi: Add AllocateAndGetTcpExTableFromStack()
by Bruno Jesus 04 Sep '13

04 Sep '13

On Wed, Sep 4, 2013 at 8:02 AM, Ralf Habacker <ralf.habacker(a)freenet.de> wrote: > > - added test case (update) > > Signed-off-by: Ralf Habacker <ralf.habacker(a)freenet.de> > --- > dlls/iphlpapi/iphlpapi.spec | 1 + > dlls/iphlpapi/ipstats.c | 33 +++++++++++++++++++++++++++++++++ > dlls/iphlpapi/tests/iphlpapi.c | 32 ++++++++++++++++++++++++++++++++ > 3 Dateien geändert, 66 Zeilen hinzugefügt(+) > + // WinXP SP3 crashes on this test > + //ret = pAllocateAndGetTcpExTableFromStack( 0, FALSE, GetProcessHeap(), HEAP_ZERO_MEMORY, AF_INET ); > + //ok( ret == ERROR_INVALID_PARAMETER, "got %u\n", ret ); C++ comments are not allowed. You could use if(0) {} to make sure the code compiles. You are still missing the (try X) at the end of the email subject. Regards, Bruno

1 0

Re: atl90: Add new DLL
by Zhenbo Li 04 Sep '13

04 Sep '13

Sorry, I've made a typo. This patch is for bug 34432 2013/9/4 Zhenbo Li <litimetal(a)gmail.com> > This patch could fix bug 34431, which is caused by missing atl90.dll > > --- > configure | 1 + > configure.ac | 1 + > dlls/atl90/Makefile.in | 7 ++++ > dlls/atl90/atl90.c | 93 ++++++++++++++++++++++++++++++** > ++++++++++++++++++++ > dlls/atl90/atl90.spec | 52 ++++++++++++++++++++++++++++ > include/atlbase.h | 1 + > tools/make_specfiles | 1 + > 7 files changed, 156 insertions(+) > -- Have a nice day! Zhenbo Li

1 0

Re: iphlpapi: Add AllocateAndGetTcpExTableFromStack()
by Marvin 04 Sep '13

04 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=1995 Your paranoid android. === wxppro (32 bit iphlpapi) === iphlpapi: unhandled exception c0000005 at 76D6EFE7

1 0

Re: [PATCH 1/3] riched20: Use codepage in ME_ToUnicode.
by Phil Krylov 04 Sep '13

04 Sep '13

Hello, >- ME_EndToUnicode(unicode, wszText); >+ unicode ? ME_EndToUnicode(1200, wszText) : ME_EndToUnicode(CP_ACP, wszText); Personally I dislike this stuff in C code. Especially when you could make it shorter: ME_EndToUnicode(unicode ? 1200 : CP_ACP, wszText) -- Ph.

2 1

Adding an appcompat/appshim bugzilla keyword
by Austin English 04 Sep '13

04 Sep '13

Anastasius mentioned at http://bugs.winehq.org/show_bug.cgi?id=32673#c6 that a keyword for bugs that are caused by applications using broken/deprecated behavior might be useful. I'm in favor of it, but wanted some more opinions (and potentially a better naming scheme). Comments/opinions? -- -Austin

2 1

Re: [PATCH 2/5] d3d9: Check for support before creating textures
by Henri Verbeet 03 Sep '13

03 Sep '13

On 3 September 2013 14:07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > I'm checking this in d3d9/d3d8/ddraw because we create textures for > everything nowadays, even stand-alone surfaces. For ddraw that's not true yet, but I think my preferred way to handle this would be to introduce a WINED3DUSAGE_TEXTURE usage flag, and then handle the format restrictions in resource_init() in wined3d. Note that I have a couple of patches for enforcing render target and depth stencil format restrictions for bug 34284 that should go in later this week. It may be best to hold this of until after that's in.

2 3

Re: ws2_32: Implement get socket option SO_PROTOCOL_INFO (try 2)
by Alexandre Julliard 03 Sep '13

03 Sep '13

Bruno Jesus <00cpxxx(a)gmail.com> writes: > try 2: > Narrow the loop for the specified protocol > Add a new test for invalid sockets Considering what WSAEnumProtocols does, the loop doesn't seem necessary at all. -- Alexandre Julliard julliard(a)winehq.org

3 8

D3D command stream patches for testing
by Stefan Dösinger 03 Sep '13

03 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, In the past months I have been working on a command stream / worker thread for wined3d. It moves most OpenGL calls into a separate thread to improve performance (bug 11674) and fix some bugs that are otherwise hard to fix (24684). You can test the attached patches by applying them (git am /path/to/patches/*) and setting HKCU/Software/Wine/Direct3D/CSMT = "enabled". Make sure to disable StrictDrawOrdering. It is no longer required with those patches and will destroy any performance gains. (It might be useful for debugging though). The patches apply on top of Wine 1.7.1. Please test those patches with your games. I'm interested in any successes or failures and performance differences. Performance numbers with plain Wine 1.7.1, this patchset with CSMT off and on, and Wine 1.7.7 + bugzilla attachment 44420 and __GL_THREADED_OPTIMIZATIONS would be greatly appreciated. A notes for non-developers: *) GPU limited games don't see any improvement. If you're GPU limited heavilly depends on your hardware *) So far I have not tested anything but Nvidia hardware. It should work on all GPUs and drivers though. *) Yes, this is essentially the same as Nvidia's __GL_THREADED_OPTIMIZATIONS. Just driver independent, under our control, and thus easier to fix bugs. *) A lot of games see 50%-100% performance improvements and now run as fast as on Windows or even faster. Examples are Source-Engine based games, StarCraft 2, 3DMark 2001. *) Call of Duty Modern Warfare 2 is improved a lot because you no longer need StrictDrawOrdering. It's still not as good as it could be, because it uses dynamic surfaces, which aren't properly implemented in the patchset yet. *) Some games have CPU-side bottlenecks outside d3d. Mass Effect 2 seems to be one of those. *) Some games have CPU-side bottlenecks in the GL driver, and comparably little game logic on their own. I think this applies to Civ V, which doesn't see much improvement with those patches. Some implementation notes: *) One of the big design decisions is to do all OpenGL calls from one thread, including resource creation and buffer maps. This is faster than using glFlush calls to synchronize anything we do from the main thread, and easier than trying to sync everything in a performant fashion with ARB_sync. This means I need the priority command queue. This is not yet fully implemented though, so you see GL calls from the main thread as well. *) There seem to be driver bugs when calling into GL from two threads, even though those are two different contexts. Remember, we don't have the GL lock any longer. *) The other controversial design decision is that the command stream does not hold any references to objects stored in pending commands or its own state structure. This prevents the client libraries and applications from "seeing" the CS via delayed destruction of objects and freeing of application private data. *) Currently resource destruction waits for the CS to execute all pending commands. The goal is to handle private resources and removal from the device's resource list in the main thread and freeing of GL resources, freeing of resource->heap_memory and freeing of the main structure in the worker thread. *) A big issue that needs fixing is that there isn't a clear separation between functions that are called from the main thread and functions that are called from the worker thread. The plan is to introduce comments similar to those that clarify who is responsible for context activation. *) Buffers are double-buffered and use glBufferSubData when the multithreaded CS is in use. This is necessary because we can't draw from a mapped buffer. In the long run GL_ARB_buffer_storage should be able to fix this. *) You can roughly see how surface and volume handling is going to work in the volume code. I am not entirely happy with the code yet, I hacked it together in the past few days... *) The plan behind wined3d_device_get_bo and wined3d_device_release_bo is to cache created GL BOs. Before I do that I have to write a benchmark for dynamic volumes to verify that this is really a performance improvement. *) Before this can be merged, surfaces need a cleanup similar to volumes. It's going to be a lot trickier though. *) The tests should run with the single-threaded and multi-threaded command stream. *) There should not be any temporary regressions with the single-threaded CS. If something's broken, git bisect should work with CSMT off. *) With CSMT on, there are a few known regressions and test failures. The d3d9 and ddraw tests fail between patch 18 and 71. Occlusion queries are broken between 22 and 108. In general nothing's working right between 80 and 99. Some of those problems can be fixed or their impact reduced, but I will not be able to completely avoid them. The ddraw test failure is a driver bug and GL occlusion queries break by design when used from a different thread. So if you try to bisect a regression in this patch series with CSMT on YMMV. *) This work was originally started by Henri. Some patches in the series are from him and either unmodified or with minor adjustments. Some patches are based on his work, but with heavy modifications. Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSJJjDAAoJEN0/YqbEcdMw1VMP/i4OvTg/HT+jJhZFDzbmtB8o aHIFslhkH9CJDCTGzZExGnPoM+0gLokzzk6ppodQiyC0bJ4jLzeulIhfaUs0sgxy srWpryXYfpeoG/A/MJQlbUQEiMpqdKLvM1j3UupjMY2IsGbECronAYdUi0PTh0Oo RqlWQ64bTARpFXtywO22goNfi57e3UKf2r8Q3Q4f20eH0CwvvVC1YU/sAZ2iyvbR c0fcfergDsPSRQsw+EgEwD4N11/Z+At2XfTeXMC9MyHlZR7bfJfOYMiu6AXfy9gB uFKLgNrXXJho5UsPLjcsCw+UczR98dsyX7B5BZOfG9eyn1Du5YAAVEZ7QCHvUbLj 0WMR86q4GiCZVd5q7GZ7YH3wdNE3R1kEMQA3JRHTP7jLPpSfODUlTxP5NDk220OI +fiPSr5a0BpLqua+dNRjAQvW1Qhrk+7EgLqfwrq8632x/6sInSTnlE84UQ4FJiH6 Wql7PxPPfOJv2qG6l1nqffT7fCbiEHnemoF/4GEvG22MZbMXYTnpkLC6Y1aLUJN5 WXxAICXcy7S2dk5Io/t1IKUm4fwtWnI59MX5rPbfDpY3GGePnlo40pNLlGVv8lc8 ktDS4dvf1Lx/JKrLzu1G/1TYBePFHEVQRvJjzCw0YhNOW7sUOLbf5rgHmAeyOxvD Zdq+l22uJ1Se8m9iAbtF =lm4e -----END PGP SIGNATURE-----

2 3

Re: [PATCH 1/5] d3d8/tests: Add cnd instruction test.
by Henri Verbeet 03 Sep '13

03 Sep '13

On 2 September 2013 23:04, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + float quad1[] = { > + -1.0, -1.0, 0.1, 0.0, 0.0, 1.0, > + 0.0, -1.0, 0.1, 1.0, 0.0, 1.0, > + -1.0, 0.0, 0.1, 0.0, 1.0, 0.0, > + 0.0, 0.0, 0.1, 1.0, 1.0, 0.0 > + }; I think that should be static const, and could do with an 'f' suffix on the literals. > + ok(hr == D3D_OK, "IDirect3DDevice8_BeginScene returned %08x\n", hr); > + if(SUCCEEDED(hr)) > + { I think the if block is pointless. > + /* 1.1 shader. All 3 components get set, based on the .w comparison */ > + color = getPixelColor(device, 158, 358); > + ok(color == 0x00ffffff, "pixel 158, 358 has color %08x, expected 0x00ffffff\n", color); > + color = getPixelColor(device, 162, 358); > + ok( (((color & 0x00ff0000) >> 16) <= 0x01) && (((color & 0x0000ff00) >> 8) <= 0x01) && ((color & 0x000000ff) <= 0x01), > + "pixel 162, 358 has color %08x, expected 0x00000000\n", color); I think that should use color_match(). I realize those are all present in the original test, but that's more of a reason to fix the original instead of copying it.

2 1

Re: [PATCH 4/5] d3d9/tests: Test blocked texture creation restrictions
by Stefan Dösinger 03 Sep '13

03 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fwiw, d3d8, ddraw and volumes behave in the same way. I've attached the tests for reference. The volume and ddraw tests need a bit of preparation work in ddraw/wined3d and a little bit of work themselves. Am 2013-09-03 14:07, schrieb Stefan Dösinger: > --- dlls/d3d9/tests/device.c | 225 > +++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, > 210 insertions(+), 15 deletions(-) > > diff --git a/dlls/d3d9/tests/device.c b/dlls/d3d9/tests/device.c > index d705e3e..af39ffa 100644 --- a/dlls/d3d9/tests/device.c +++ > b/dlls/d3d9/tests/device.c @@ -5815,7 +5815,7 @@ static void > test_surface_double_unlock(void) DestroyWindow(window); } > > -static void test_surface_lockrect_blocks(void) +static void > test_surface_blocks(void) { static const struct { @@ -5824,20 > +5824,21 @@ static void test_surface_lockrect_blocks(void) > unsigned int block_width; unsigned int block_height; BOOL broken; > + BOOL create_size_checked, core_fmt; } formats[] = { - > {D3DFMT_DXT1, "D3DFMT_DXT1", 4, 4, FALSE}, - > {D3DFMT_DXT2, "D3DFMT_DXT2", 4, 4, FALSE}, - > {D3DFMT_DXT3, "D3DFMT_DXT3", 4, 4, FALSE}, - > {D3DFMT_DXT4, "D3DFMT_DXT4", 4, 4, FALSE}, - > {D3DFMT_DXT5, "D3DFMT_DXT5", 4, 4, FALSE}, + > {D3DFMT_DXT1, "D3DFMT_DXT1", 4, 4, FALSE, TRUE, > TRUE }, + {D3DFMT_DXT2, "D3DFMT_DXT2", 4, > 4, FALSE, TRUE, TRUE }, + {D3DFMT_DXT3, "D3DFMT_DXT3", 4, > 4, FALSE, TRUE, TRUE }, + {D3DFMT_DXT4, "D3DFMT_DXT4", 4, > 4, FALSE, TRUE, TRUE }, + {D3DFMT_DXT5, "D3DFMT_DXT5", 4, > 4, FALSE, TRUE, TRUE }, /* ATI2N has 2x2 blocks on all AMD cards > and Geforce 7 cards, * which doesn't match the format spec. On > newer Nvidia cards * it has the correct 4x4 block size */ - > {MAKEFOURCC('A','T','I','2'), "ATI2N", 4, 4, TRUE}, - > {D3DFMT_YUY2, "D3DFMT_YUY2", 2, 1, FALSE}, - > {D3DFMT_UYVY, "D3DFMT_UYVY", 2, 1, FALSE}, + > {MAKEFOURCC('A','T','I','2'), "ATI2N", 4, 4, TRUE, FALSE, > FALSE}, + {D3DFMT_YUY2, "D3DFMT_YUY2", 2, 1, FALSE, FALSE, > TRUE }, + {D3DFMT_UYVY, "D3DFMT_UYVY", 2, 1, FALSE, FALSE, > TRUE }, }; static const struct { @@ -5854,17 +5855,45 @@ static > void test_surface_lockrect_blocks(void) {D3DPOOL_SYSTEMMEM, > "D3DPOOL_SYSTEMMEM",TRUE}, {D3DPOOL_MANAGED, "D3DPOOL_MANAGED", > TRUE}, }; + static struct + { + D3DRESOURCETYPE rtype; + > const char *type_name; + D3DPOOL pool; + const char > *pool_name; + BOOL need_driver_support, > need_runtime_support; + } + create_tests[] = + { + > {D3DRTYPE_SURFACE, "D3DRTYPE_SURFACE", D3DPOOL_DEFAULT, > "D3DPOOL_DEFAULT", TRUE, FALSE}, + {D3DRTYPE_SURFACE, > "D3DRTYPE_SURFACE", D3DPOOL_SYSTEMMEM, "D3DPOOL_SYSTEMMEM", TRUE, > TRUE }, + /* Managed offscreen plain surfaces are not > supported */ + {D3DRTYPE_SURFACE, "D3DRTYPE_SURFACE", > D3DPOOL_SCRATCH, "D3DPOOL_SCRATCH", FALSE, TRUE }, + + > {D3DRTYPE_TEXTURE, "D3DRTYPE_TEXTURE", D3DPOOL_DEFAULT, > "D3DPOOL_DEFAULT", TRUE, FALSE}, + {D3DRTYPE_TEXTURE, > "D3DRTYPE_TEXTURE", D3DPOOL_SYSTEMMEM, "D3DPOOL_SYSTEMMEM", TRUE, > FALSE}, + {D3DRTYPE_TEXTURE, "D3DRTYPE_TEXTURE", > D3DPOOL_MANAGED, "D3DPOOL_MANAGED", TRUE, FALSE}, + > {D3DRTYPE_TEXTURE, "D3DRTYPE_TEXTURE", D3DPOOL_SCRATCH, > "D3DPOOL_SCRATCH", FALSE, TRUE }, + + > {D3DRTYPE_CUBETEXTURE, "D3DRTYPE_CUBETEXTURE", D3DPOOL_DEFAULT, > "D3DPOOL_DEFAULT", TRUE, FALSE}, + {D3DRTYPE_CUBETEXTURE, > "D3DRTYPE_CUBETEXTURE", D3DPOOL_SYSTEMMEM, "D3DPOOL_SYSTEMMEM", > TRUE, FALSE}, + {D3DRTYPE_CUBETEXTURE, > "D3DRTYPE_CUBETEXTURE", D3DPOOL_MANAGED, "D3DPOOL_MANAGED", TRUE, > FALSE}, + {D3DRTYPE_CUBETEXTURE, "D3DRTYPE_CUBETEXTURE", > D3DPOOL_SCRATCH, "D3DPOOL_SCRATCH", FALSE, TRUE }, + }; > IDirect3DTexture9 *texture; + IDirect3DCubeTexture9 *cube_texture; > IDirect3DSurface9 *surface; D3DLOCKED_RECT locked_rect; > IDirect3DDevice9 *device; - unsigned int i, j; + unsigned int > i, j, w, h; BOOL surface_only; IDirect3D9 *d3d; ULONG refcount; > HWND window; HRESULT hr; RECT rect; + BOOL tex_pow2, cube_pow2; > + D3DCAPS9 caps; > > if (!(d3d = pDirect3DCreate9(D3D_SDK_VERSION))) { @@ -5882,14 > +5911,142 @@ static void test_surface_lockrect_blocks(void) return; > } > > + hr = IDirect3DDevice9_GetDeviceCaps(device, &caps); + > ok(SUCCEEDED(hr), "Failed to get caps, hr %#x.\n", hr); + tex_pow2 > = !!(caps.TextureCaps & D3DPTEXTURECAPS_POW2); + if (tex_pow2) + > tex_pow2 = !(caps.TextureCaps & > D3DPTEXTURECAPS_NONPOW2CONDITIONAL); + cube_pow2 = > !!(caps.TextureCaps & D3DPTEXTURECAPS_CUBEMAP_POW2); + for (i = 0; > i < (sizeof(formats) / sizeof(*formats)); ++i) { + BOOL > tex_support, cube_support, surface_support, format_known, > dynamic_tex_support; + + hr = > IDirect3D9_CheckDeviceFormat(d3d, 0, D3DDEVTYPE_HAL, > D3DFMT_X8R8G8B8, + 0, D3DRTYPE_TEXTURE, > formats[i].fmt); + tex_support = SUCCEEDED(hr); + hr > = IDirect3D9_CheckDeviceFormat(d3d, 0, D3DDEVTYPE_HAL, > D3DFMT_X8R8G8B8, + 0, D3DRTYPE_CUBETEXTURE, > formats[i].fmt); + cube_support = SUCCEEDED(hr); + > hr = IDirect3D9_CheckDeviceFormat(d3d, 0, D3DDEVTYPE_HAL, > D3DFMT_X8R8G8B8, + 0, D3DRTYPE_SURFACE, > formats[i].fmt); + surface_support = SUCCEEDED(hr); + + /* > Scratch pool in general allows texture creation even if the driver > does + * not support the format. If the format is an > extension format that is not + * known to the runtime, > like ATI2N, some driver support is required for + * this > to work. + * + * It is also possible that Windows > Vista and Windows 7 d3d9 runtimes know + * about ATI2N. I > cannot check this because all my Vista+ machines support + * ATI2N > in hardware, but none of my WinXP machines do. */ + format_known = > tex_support || cube_support || surface_support; + + for (w = 1; w > <= 8; w++) + { + for (h = 1; h <= 8; h++) + > { + BOOL block_aligned = TRUE; + BOOL > size_is_pow2; + + if (w & (formats[i].block_width - > 1) || h & (formats[i].block_height - 1)) + > block_aligned = FALSE; + + size_is_pow2 = !(w & (w - 1) || h & (h - > 1)); + + for (j = 0; j < sizeof(create_tests) / > sizeof(*create_tests); j++) + { + > BOOL support, pow2; + HRESULT expect_hr; + BOOL > may_succeed = FALSE; + IUnknown **check_null; + + > if (!formats[i].core_fmt) + { + /* AMD warns > against creating ATI2N textures smaller than + * the block size > because the runtime cannot calculate the + * correct texture size. > Generalize this for all extension + * formats. */ + > if (w < formats[i].block_width || h < formats[i].block_height) + > continue; + } + + texture = > (IDirect3DTexture9 *)0xdeadbeef; + cube_texture > = (IDirect3DCubeTexture9 *)0xdeadbeef; + > surface = (IDirect3DSurface9 *)0xdeadbeef; + + > switch (create_tests[j].rtype) + { + case > D3DRTYPE_TEXTURE: + check_null = > (IUnknown **)&texture; + hr = > IDirect3DDevice9_CreateTexture(device, w, h, 1, 0, + > formats[i].fmt, create_tests[j].pool, &texture, NULL); + support = > tex_support; + pow2 = tex_pow2; + > break; + + case D3DRTYPE_CUBETEXTURE: + > if (w != h) + continue; + check_null > = (IUnknown **)&cube_texture; + hr = > IDirect3DDevice9_CreateCubeTexture(device, w, 1, 0, + > formats[i].fmt, create_tests[j].pool, &cube_texture, NULL); + > support = cube_support; + pow2 = > cube_pow2; + break; + + case > D3DRTYPE_SURFACE: + check_null = > (IUnknown **)&surface; + hr = > IDirect3DDevice9_CreateOffscreenPlainSurface(device, w, h, + > formats[i].fmt, create_tests[j].pool, &surface, NULL); + support = > surface_support; + pow2 = FALSE; + > break; + + default: + check_null = NULL; > + pow2 = FALSE; + support = FALSE; + > break; + } + + if > (create_tests[j].need_driver_support && !support) + expect_hr = > D3DERR_INVALIDCALL; + else if > (create_tests[j].need_runtime_support && !formats[i].core_fmt && > !format_known) + expect_hr = > D3DERR_INVALIDCALL; + else if > (formats[i].create_size_checked && !block_aligned) + expect_hr = > D3DERR_INVALIDCALL; + else if (pow2 && > !size_is_pow2 && create_tests[j].need_driver_support) + expect_hr = > D3DERR_INVALIDCALL; + else + expect_hr = D3D_OK; > + + /* Wine knows about ATI2N and happily > creates a scratch resource even if GL + * does not support it. > Accept scratch creation of extension formats on + > * Windows as well if it occurs. We don't really care if e.g. a > Windows 7 + * on an r200 GPU creates scratch > ATI2N texture even though the card doesn't + * support it. */ + > if (!formats[i].core_fmt && !format_known && FAILED(expect_hr)) + > may_succeed = TRUE; + + ok(hr == expect_hr || > ((SUCCEEDED(hr) && may_succeed)), + > "Got unexpected hr %#x for format %s, pool %s, type %s, size > %ux%u.\n", + hr, formats[i].name, > create_tests[j].pool_name, create_tests[j].type_name, w, h); + if > (FAILED(hr)) + ok(*check_null == NULL, "Got > object ptr %p, expected NULL.\n", *check_null); + else + > IUnknown_Release(*check_null); + } + } + } + > surface_only = FALSE; - if > (FAILED(IDirect3D9_CheckDeviceFormat(d3d, 0, D3DDEVTYPE_HAL, > D3DFMT_X8R8G8B8, - D3DUSAGE_DYNAMIC, > D3DRTYPE_TEXTURE, formats[i].fmt))) + hr = > IDirect3D9_CheckDeviceFormat(d3d, 0, D3DDEVTYPE_HAL, > D3DFMT_X8R8G8B8, + D3DUSAGE_DYNAMIC, > D3DRTYPE_TEXTURE, formats[i].fmt); + dynamic_tex_support = > SUCCEEDED(hr);; + if (!dynamic_tex_support) { - if > (FAILED(IDirect3D9_CheckDeviceFormat(d3d, 0, D3DDEVTYPE_HAL, > D3DFMT_X8R8G8B8, - 0, D3DRTYPE_SURFACE, > formats[i].fmt))) + if (!surface_support) { > skip("Format %s not supported, skipping lockrect offset tests.\n", > formats[i].name); continue; @@ -5997,6 +6154,44 @@ static void > test_surface_lockrect_blocks(void) > > IDirect3DSurface9_Release(surface); } + + if > (!dynamic_tex_support) + { + skip("Dynamic %s > textures not supported, skipping mipmap test.\n", formats[i].name); > + continue; + } + + if > (formats[i].block_width == 1 && formats[i].block_height == 1) + > continue; + if (!formats[i].core_fmt) + continue; + + > hr = IDirect3DDevice9_CreateTexture(device, formats[i].block_width, > formats[i].block_height, 2, + D3DUSAGE_DYNAMIC, formats[i].fmt, > D3DPOOL_DEFAULT, &texture, NULL); + ok(SUCCEEDED(hr), > "Failed to create texture, hr %#x, format %s.\n", hr, > formats[i].name); + + hr = > IDirect3DTexture9_LockRect(texture, 1, &locked_rect, NULL, 0); + > ok(SUCCEEDED(hr), "Failed lock texture, hr %#x.\n", hr); + hr = > IDirect3DTexture9_UnlockRect(texture, 1); + ok(SUCCEEDED(hr), > "Failed lock texture, hr %#x.\n", hr); + + rect.left = 0; + > rect.top = 0; + rect.right = formats[i].block_width == 1 ? 1 > : formats[i].block_width >> 1; + rect.bottom = > formats[i].block_height == 1 ? 1 : formats[i].block_height >> 1; + > hr = IDirect3DTexture9_LockRect(texture, 1, &locked_rect, &rect, > 0); + ok(SUCCEEDED(hr), "Failed lock texture, hr %#x.\n", hr); + hr > = IDirect3DTexture9_UnlockRect(texture, 1); + ok(SUCCEEDED(hr), > "Failed lock texture, hr %#x.\n", hr); + + rect.right = > formats[i].block_width; + rect.bottom = > formats[i].block_height; + hr = > IDirect3DTexture9_LockRect(texture, 1, &locked_rect, &rect, 0); + > todo_wine ok(hr == D3DERR_INVALIDCALL, "Got unexpected hr %#x.\n", > hr); + if (SUCCEEDED(hr)) + > IDirect3DTexture9_UnlockRect(texture, 1); + + > IDirect3DTexture9_Release(texture); } > > refcount = IDirect3DDevice9_Release(device); @@ -6779,7 +6974,7 @@ > START_TEST(device) test_surface_dimensions(); > test_surface_format_null(); test_surface_double_unlock(); - > test_surface_lockrect_blocks(); + test_surface_blocks(); > test_set_palette(); test_swvp_buffer(); test_rtpatch(); > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSJdJoAAoJEN0/YqbEcdMwkZkP/18bJEtlTuDSPlTg16mUVZn4 8XeOXELM/a+156LoBAyjy6XC6Mn4kO+fhuzdhKa846bjtL8L3A0HIbVWVw5VVbLi jV4pU7oXiKP2upSieDAro1IXQAgKabeLaKPYMz3dDJevXZoTglr8S7irzUy7WYhN /Pxj2vDvV6FDyonaHz/+odvBCnFmfD2FoqbgxWlTQ5fSt6iuCwXklJsmmOXTWjv7 6o4zFlvQ6Q42QSPDhHgDSoiXlpoK4mNfDPE6j1n3BdnCIbse5Peh5V8F1NGcjQJQ iV9t7gjruiEPhqG/W7zLoDVgRLZIsXiQNY5jNA8JJaGX5eWUrlRRPR1RsANKoaUU oltPEy3J9D/ILfRc1mK39NpvXuJWnNB8uDjMzGJurs6JCAMQHYaOoUKY7DkJqc9y n1CzmlDrMeDeverpRSLAXr8MtBPyGbg9NcTzzaLji+7DIyQJNMXU53Gj/heleurs 4ZVfxPaIr3ww2xOlC/tkhjZcy4F/Az48Py2EARRtLp8YMW9skej/U51jc2n32Akd m8zEdKdWgC0WdLtWEf4+u8O8azuhq4dPiw+iAUC2KNxhwtt0jjDPrV+LsrygRbNG iZvUgAZLga6X6Pk8vZPrT26nX2WfF1QEVKPAXwWmzd0beVNnGqEuEV24Vrd/RcL+ JicqI3oBax7saTMiRyni =6u3G -----END PGP SIGNATURE-----

1 0

Re: [PATCH 3/5] wined3d: Don't clamp texture lookups in the GLSL fixed function fragment pipe.
by Stefan Dösinger 03 Sep '13

03 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2013-09-03 09:47, schrieb Henri Verbeet: > This originally came from the ARB fragment program implementation, > but I don't see a justification for clamping there either. For the > texture formats typically used with the fixed function pipe > clamping wouldn't make a difference, and we don't have any tests > that say we need to clamp. The idea behind the clamps is that the fixed function pipeline is generally limited to the [0.0;1.0] range. bbf313e7 added a test for that, and there was e.g. 14706 (which doesn't contain much info tbh). Personally I'd keep the clamps in unless a test says otherwise or there's another compelling reason to remove them. But since it is quite unlikely to matter that's not a strong opinion. The ideal solution is of course to write a test. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSJciCAAoJEN0/YqbEcdMwQ2gP/Ayrnyv1b7VmviOCBLdKpW3P YjEgLSFtaiEMGjJ6DD3iTLTRBaMOWZIryKyXdE5QLecKx35xuk6GbC+OAXgCCZfU a558nJwymMtMpiU9Wa2nuUXF4p+KuC8CHkCgfOGF1D4wDZcQQxfEcvKcwAGPaZwV PWiKKI8SWO69XlawZHOLyWz97gghYpLrHIexOxbCVXGMXee7pqAQTSz2oRVppHot 39T2qbFo21qtoyK7sgqMgnRko52eiJGSBVHCfcfhhMPh+mksQvPoZDcdK/KSAl6r K5Py0kbVjBDjE9I6uCGO9+bt6a6RrJpC/6JGIOypDvicnjd/7X4LK8SYfGv3Cvr6 qejlsAouxrQgdYARrdjnoR4IEK8WviBzOZDnvxOS8dlEsJxjMjxIScnemdNacNKO QY3DJ/GmfnsnOXnrrvADKkLvCkeIUCE5v6U9Kv+S9GsMgNeJs1IEHzQpROBmt/iO ukUH+aOe4JReH1mtynrX+GsjwZkDPzatx48SxOOopWW5akiCbEsJNFirR4m1St9E 5+iOCkGQkjWVz95XgZt3VRpUBxx12JHsX1/UscBmprvkutmbUOYvRIpgqdTyZknD dW4x79KWQ6YUu3k8Lho8EfChR8rzPoDeaHwclY/WrwE+yuHugk+z0dv/gclC3eiL HAQ0T8GuuElJvdPfgE3F =8XAf -----END PGP SIGNATURE-----

2 2

Re: gdi32: Fixed Rectangle() rotation problem with GM_ADVANCED graphics mode.
by Alexandre Julliard 03 Sep '13

03 Sep '13

Ralf Habacker <ralf(a)habacker.de> writes: > see http://bugs.winehq.org/show_bug.cgi?id=34381 > --- > dlls/gdi32/painting.c | 18 ++++++++++++++++-- > 1 Datei geändert, 16 Zeilen hinzugefügt(+), 2 Zeilen entfernt(-) This would have to be done in the drivers. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: ws2_32: Implement get socket option SO_PROTOCOL_INFO (try 2)
by Marvin 03 Sep '13

03 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=1970 Your paranoid android. === wxppro (32 bit sock) === sock.c:519: Test failed: oob_server (23c): unexpectedly at the OOB mark: 0 === w7pro64 (32 bit sock) === sock.c:528: Test failed: oob_server (320): not at the OOB mark: 1

1 0

Re: Sort the AUTHORS file by their last names.
by André Hentschel 02 Sep '13

02 Sep '13

Am 02.09.2013 08:24, schrieb Tae Wong: > Add more authors from the GIT log. > > Commit this patch. > > > It seems you have some need to change the order of the AUTHORS file, but it's autogenerated, so you would need to fix the generation. And Michael already pointed out that this non-trivial problem can't be automated. If you simply want to get into wine development, you really should pick something else to start with. PS: It also seems it's not clear to you what a patch is, so you might want to read http://wiki.winehq.org/SubmittingPatches

2 1

Re: [docs 2/2] winedev: Don't recommend a preprocessor check to comment out code
by Frédéric Delanoy 02 Sep '13

02 Sep '13

On Mon, Sep 2, 2013 at 10:34 PM, André Hentschel <nerv(a)dawncrow.de> wrote: > --- > en/winedev-coding.sgml | 9 ++++----- > 1 file changed, 4 insertions(+), 5 deletions(-) There's a typo in - block of code. + block of code and it makes sure the code get's maintained. get's => gets -- Frédéric Delanoy

1 0

Re: [PATCH 3/3] ws2_32: Implement get socket option SO_PROTOCOL_INFO
by Alexandre Julliard 02 Sep '13

02 Sep '13

Bruno Jesus <00cpxxx(a)gmail.com> writes: > + items = WSAEnumProtocolsW(NULL, NULL, &listsize); > + if (items == SOCKET_ERROR && WSAGetLastError() == WSAENOBUFS && > + (buffer = HeapAlloc(GetProcessHeap(), 0, listsize))) > + { > + items = WSAEnumProtocolsW(NULL, buffer, &listsize); > + for (i = 0; i < items; i++) > + { > + if (buffer[i].iAddressFamily == info.a->iAddressFamily && > + buffer[i].iSocketType == info.a->iSocketType && > + buffer[i].iProtocol == info.a->iProtocol) > + { > + if (unicode) > + memcpy(info.w, &buffer[i], sz); > + else > + { > + /* convert the structure from W to A */ > + memcpy(info.a, &buffer[i], FIELD_OFFSET(WSAPROTOCOL_INFOA, szProtocol)); > + WideCharToMultiByte(CP_ACP, 0, buffer[i].szProtocol, -1, > + info.a->szProtocol, WSAPROTOCOL_LEN+1, NULL, NULL); > + } > + break; > + } > + } > + } There's no reason to enumerate the protocols since you already know the one you want. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [2/2] kernel32/tests: Add a test to show that WaitCommEvent should fail if there is a pending wait.
by Marvin 02 Sep '13

02 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=1957 Your paranoid android. === w7pro64 (32 bit comm) === comm.c:850: Test failed: WaitCommEvent failed with a timeout comm.c:862: recovering after WAIT_TIMEOUT... comm.c:874: Test failed: WaitCommEvent error 0 comm.c:876: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:880: WaitCommEvent for EV_TXEMPTY took 1014 ms (timeout 1000) comm.c:882: Test failed: WaitCommEvent used 1014 ms for waiting comm.c:970: recovering after WAIT_TIMEOUT... comm.c:1549: test_AbortWaitCts timeout 500 handle 00000130 comm.c:1516: Changing CommMask on the fly for handle 00000130 after timeout 500

2 1

Re: [2/3] d3d9: Partial implementation of IDirect3DSwapChain9Ex (try 2)
by Henri Verbeet 02 Sep '13

02 Sep '13

On 30 August 2013 17:09, Michael Müller <michael(a)fds-team.de> wrote: > +static HRESULT WINAPI d3d9_swapchain_GetLastPresentCount(IDirect3DSwapChain9Ex *iface, > + UINT *pLastPresentCount) > +{ > + FIXME("iface %p, pLastPresentCount %p, stub!\n", iface, pLastPresentCount); > + > + if(pLastPresentCount) > + *pLastPresentCount = 0; > + > + return D3D_OK; > +} Please use the same style as the rest of the code. E.g., "if (last_present_count)". > +static HRESULT WINAPI d3d9_swapchain_GetDisplayModeEx(IDirect3DSwapChain9Ex *iface, > + D3DDISPLAYMODEEX *pMode, D3DDISPLAYROTATION *pRotation) > +{ > + struct d3d9_swapchain *swapchain = impl_from_IDirect3DSwapChain9Ex(iface); > + struct wined3d_display_mode wined3d_mode; > + enum wined3d_display_rotation wined3d_rotation; > + HRESULT hr; > + > + TRACE("iface %p, pMode %p, pRotation %p.\n", iface, pMode, pRotation); > + > + wined3d_mutex_lock(); > + hr = wined3d_swapchain_get_display_mode(swapchain->wined3d_swapchain, &wined3d_mode, &wined3d_rotation); > + wined3d_mutex_unlock(); > + > + if (SUCCEEDED(hr)) > + { > + if(pMode) > + { > + pMode->Size = sizeof(D3DDISPLAYMODEEX); > + pMode->Width = wined3d_mode.width; > + pMode->Height = wined3d_mode.height; > + pMode->RefreshRate = wined3d_mode.refresh_rate; > + pMode->Format = d3dformat_from_wined3dformat(wined3d_mode.format_id); > + pMode->ScanLineOrdering = wined3d_mode.scanline_ordering; > + } > + > + if(pRotation) > + *pRotation = wined3d_rotation; > + > + } > + > + return hr; > +} This is different from d3d9_GetAdapterDisplayModeEx(). The way you handle "pMode->Size" looks suspicious, while the NULL checks on "pMode" and "pRotation" may make sense. Please add tests to show this is correct. (See also test_get_adapter_displaymode_ex(), although that test has some room for improvement itself.)

1 0

Re: [3/3] d3d9/tests: Test if IDirect3DSwapChain9Ex is available without IDirect3D9Ex
by Henri Verbeet 02 Sep '13

02 Sep '13

On 30 August 2013 17:09, Michael Müller <michael(a)fds-team.de> wrote: > > + /* Get the implicit swapchain */ > + hr = IDirect3DDevice9_GetSwapChain(device, 0, &swapchain); > + ok(SUCCEEDED(hr), "Failed to get the implicit swapchain (%08x)\n", hr); > + if (SUCCEEDED(hr)) > + { > + hr = IDirect3DSwapChain9_QueryInterface(swapchain, &IID_IDirect3DSwapChain9Ex, (void **) &swapchainEx); > + ok(hr == E_NOINTERFACE, > + "IDirect3DSwapChain9::QueryInterface for IID_IDirect3DSwapChain9Ex returned %08x, expected E_NOINTERFACE\n", > + hr); > + ok(swapchainEx == NULL, "QueryInterface returned interface %p, expected NULL\n", swapchainEx); > + if(swapchainEx) IDirect3DSwapChain9Ex_Release(swapchainEx); > + } > + if(swapchain) IDirect3DSwapChain9_Release(swapchain); It probably wouldn't hurt to have a test for the other case as well. I.e., that you can get an IDirect3DSwapChain9Ex interface from a device created from an IDirect3D9Ex interface.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel