September 2013 - Wine-Devel

riched20/tests: Add tests for ITextDocument_Save. (try 2)
by Jactry Zeng Sept. 11, 2013

Sept. 11, 2013

Update: Add todo_wine

1 0

Re: [PATCH 4/5] wined3d: Move the decoded stream info into the context.
by Henri Verbeet Sept. 11, 2013

Sept. 11, 2013

On 11 September 2013 11:31, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -1880,9 +1888,8 @@ struct wined3d_device > WORD d3d_initialized : 1; > WORD inScene : 1; /* A flag to check for proper BeginScene / EndScene call pairs */ > WORD softwareVertexProcessing : 1; /* process vertex shaders using software or hardware */ > - WORD useDrawStridedSlow : 1; > WORD filter_messages : 1; > - WORD padding : 8; > + WORD padding : 1; I don't think that's quite right.

2 2

Re: [PATCH 5/5] wined3d: Explicitly pass the state information to buffer_internal_preload
by Henri Verbeet Sept. 11, 2013

Sept. 11, 2013

On 11 September 2013 11:31, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > - /* Reading the declaration makes only sense if the stateblock is finalized and the buffer bound to a stream */ > - if (device->isInDraw && buffer->resource.bind_count > 0) > + /* Reading the declaration makes only sense if we have valid state information > + * (i.e., if this function is called during draws). */ > + if (state) Technically what needs to be valid is the stream info, although we probably don't care that much about the distinction.

1 0

Re: [PATCH 3/5] wined3d: Pass stream info and needed fixups to buffer_find_decl.
by Henri Verbeet Sept. 11, 2013

Sept. 11, 2013

On 11 September 2013 11:31, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -330,7 +331,7 @@ static BOOL buffer_find_decl(struct wined3d_buffer *This) > if(This->resource.usage & WINED3DUSAGE_STATICDECL) return FALSE; > } > > - if (use_vs(state)) > + if (fixup_flags & WINED3D_BUFFER_FIXUP_USE_SHADER) It can actually be a bit simpler than that. Note that all the texcoord checks are redundant when "support_d3dcolor" is true, because declaration_element_valid_ffp() already prevents D3DCOLOR elements from being used with texcoords. That then implies you can mostly just pass the fixup mask to buffer_check_attribute(), and check for an empty fixup mask instead of vertex shader usage here. (Although that means inverting the flags as you have them right now.)

1 0

Re: (resend) gdi32: abc values remain the same despite any changes in layout direction or Viewport
by Marvin Sept. 11, 2013

Sept. 11, 2013

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=2103 Your paranoid android. === wxppro (32 bit font) === font.c:1323: Test failed: abcB should be unchanged font.c:1323: Test failed: abcC should be unchanged font.c:1323: Test failed: abcfB should be unchanged font.c:1323: Test failed: abcfC should be unchanged font.c:1345: Test failed: abcB should be unchanged font.c:1345: Test failed: abcC should be unchanged font.c:1345: Test failed: abcfB should be unchanged font.c:1345: Test failed: abcfC should be unchanged

1 0

Re: po: Add English (Philippines) resource (resend)
by Alexandre Julliard Sept. 11, 2013

Sept. 11, 2013

Ken Sharp <kennybobs(a)o2.co.uk> writes: > @@ -111,6 +111,9 @@ filter: dummy > .svg.bmp: > CONVERT="$(CONVERT)" ICOTOOL="$(ICOTOOL)" RSVG="$(RSVG)" $(BUILDIMAGE) $< $@ > > +$(top_srcdir)/po/en_PH.po: $(top_srcdir)/po/en_US.po > + $(LN_S) -f en_US.po $@ > + You can't create links in the source tree, and in any case this should be done directly in wrc, with some sort of alias mechanism. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: (resend) [PATCH] serial: wait_for_event() must set Information in PIO_STATUS_BLOCK
by Dmitry Timoshkov Sept. 11, 2013

Sept. 11, 2013

Wolfgang Walter <wine(a)stwm.de> wrote: > - if (commio->iosb) commio->iosb->u.Status = *commio->events ? STATUS_SUCCESS : STATUS_CANCELLED; > + if (commio->iosb) { > + commio->iosb->u.Status = *commio->events ? STATUS_SUCCESS : STATUS_CANCELLED; > + if (*commio->events) > + commio->iosb->Information = sizeof(DWORD); > + } Did you run 'make test' with this change? Probably some todo_wine statements need to be removed. Also why 'Information' is set only in the case if events != 0? I'd guess that it should be set in any case since 'events' is always initialized. -- Dmitry.

1 0

Embedding a HWND window into an X11 window
by Alexandre Bique Sept. 10, 2013

Sept. 10, 2013

Hi, How could I embed a HWND window created with CreateWindow() into an X11 window? Thanks! :-) -- Alexandre Bique

5 8

RFC: HKCR merge implementation
by George Stephanos Sept. 10, 2013

Sept. 10, 2013

I'm proposing my HKEY_CLASSES_ROOT implementation patches for review. Feel free to comment. So far, I've written code for all functions except for the RegEnum family. General description: HKCR handles are special. All wine handles have the two lowest bits zero'd. HKCR handles are masked. 10b specifically. They have their own table separate from the generic handle table. An HKCR handle has an HKCU handle and an HKLM handle below it. Access mask and a string representing the path are also needed since the handle has to attempt to reopen previously failed openings at certain stages. First patch: specially handles HKCR handles WITHOUT affecting the general behavior. The end result is still the exact same. Patch provides a foundation for the rest. Second patch: added path management Third patch: added HKCU Here's a quick description of each function: create_hkcr_struct: allocates the memory needed for the struct, adds it to the table and gives back a pointer to it get_hkcr_path: given an HKCR handle and a subkey string, prepares a subkey string representing the same subkey rooted at HKLM/HKCU. create_hkcr: RegCreateKeyEx open_hkcr: RegOpenKeyEx resolve_hkcr: checks the HKCR handle, tries to reopen previously failed internal handles, gives back HKCU first if available then HKLM close_hkcr: deallocates path and struct, removes struct from table.

1 0

Re: winemac: Don't return characters for Ctrl-(non-letter symbol) keypresses from ToUnicodeEx() as X11 driver already does (try 2)
by Ken Thomases Sept. 10, 2013

Sept. 10, 2013

Hi, On Sep 9, 2013, at 7:38 PM, Phil Krylov wrote: > Sorry, my first try had wrong patch attached > > -- Ph. > <0001-winemac-Don-t-return-characters-for-Ctrl-non-letter-try2.patch.txt> Is there a specific problem that you're trying to fix? The Mac driver's ToUnicodeEx() implementation started out very similar to the X11 driver's. It was basically a copy that I hacked on. It originally had this same restriction. However, some testing revealed that this is not an absolute restriction on Windows. For example, in the Khmer keyboard layout, Control-<digit> produces characters for some digits. Given that some Windows keyboard layouts produce characters for Control-<digit>, I figured it was best left up to the Mac keyboard layout. Similarly for Control-<punctuation>. For example, the Windows Chinese keyboard layouts produce characters for some of those keystrokes. So does the Czech layout. It might still be possible to re-introduce this restriction if it can be justified based on broad breakage of apps. Although even then, I'd want to make it possible to override the restriction with a registry setting or something. You never know if the ability to enter characters using these key combinations might be crucial for certain Mac users because of the nature of their native keyboard layout. If a modification like this were justified, it should go earlier in macdrv_ToUnicodeEx(). There's a section at the top where I moved the checks for combinations that don't produce characters. Also, the check should test that Alt is _not_ pressed, since Control-Alt-<digit or punct> and Control-Alt-Shfit-<digit or punct> very commonly produce characters. Control-Alt is a synonym for the AltGr key on some keyboards (e.g. Swiss). Finally, if we're going to pursue this, there are some minor style issues I'd prefer be changed. So, check with me before resubmitting. Thanks and cheers, Ken

2 2

Re: ntdll: Try application manifest path when searching for dependent assemblies
by Alexandre Julliard Sept. 10, 2013

Sept. 10, 2013

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > @@ -2776,8 +2776,7 @@ static NTSTATUS lookup_assembly(struct actctx_loader* acl, > /* FIXME: add support for language specific lookup */ > > nameW.Buffer = NULL; > - if (!(buffer = RtlAllocateHeap( GetProcessHeap(), 0, > - (strlenW(acl->actctx->appdir.info) + 2 * strlenW(ai->name) + 2) * sizeof(WCHAR) + sizeof(dotManifestW) ))) > + if (!(buffer = RtlAllocateHeap( GetProcessHeap(), 0, MAX_PATH * sizeof(WCHAR) ))) Please try to allocate the correct size. If you want to use MAX_PATH you then have to check for overflow when building the string, which is probably worse. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [2/5] ntdll: Make NtWriteFile handle special offset -2 same way as -1. Resend.
by Alexandre Julliard Sept. 10, 2013

Sept. 10, 2013

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > --- > dlls/ntdll/file.c | 31 +++++++++++++++---------------- > 1 file changed, 15 insertions(+), 16 deletions(-) Why do you need that? It doesn't look to me like an improvement. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [2/2] oledb32: Implement IDataSourceLocator get/put hWnd (resend)
by Nikolay Sivov Sept. 10, 2013

Sept. 10, 2013

On 9/10/2013 13:30, Alistair Leslie-Hughes wrote: > Hi, > > > Changelog: > oledb32: Implement IDataSourceLocator get/put hWnd > > > Best Regards > Alistair Leslie-Hughes Hi, Alistair. This is wrong, interface definition should be fixed as well, HWND parameter can't be LONG: --- [id(0x60020000), propget] HRESULT hWnd([out, retval] long* phwndParent); [id(0x60020000), propput] HRESULT hWnd([in] long phwndParent); --- PSDK header has COMPATIBLE_LONG thing to make it work on win64.

1 0

Re: xcopy: Add an explicit check to avoid an out of array access. access. (RESEND)
by Alexandre Julliard Sept. 10, 2013

Sept. 10, 2013

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > On Sun, 24 Mar 2013, Gerald Pfeifer wrote: >> This _may_ not be necessary, strictly speaking, but new versions of >> GCC (GCC 4.8) complain about this. (And there might be a fringe case?) > > How about this patch? I see it was not applied, but also did not > see a response. It can't happen (and removing the last char unconditionally is broken anyway). -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/5] ntdll: Add support to NtWriteFile for special offset -1. Take 3.
by Alexandre Julliard Sept. 10, 2013

Sept. 10, 2013

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > @@ -961,16 +961,23 @@ NTSTATUS WINAPI NtWriteFile(HANDLE hFile, HANDLE hEvent, > > if (type == FD_TYPE_FILE) > { > + off_t off; > + > if (!(options & (FILE_SYNCHRONOUS_IO_ALERT | FILE_SYNCHRONOUS_IO_NONALERT)) && !offset) > { > status = STATUS_INVALID_PARAMETER; > goto done; > } > > - if (offset && offset->QuadPart != (LONGLONG)-2 /* FILE_USE_FILE_POINTER_POSITION */) > + off = offset ? offset->QuadPart : (off_t)-2 /* FILE_USE_FILE_POINTER_POSITION */; > + > + if (off == (off_t)-1 /* FILE_WRITE_TO_END_OF_FILE */) > + off = lseek( unix_handle, 0, SEEK_END ); You are not supposed to change the position for the asynchronous case. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ws2_32: Implement get socket option SO_PROTOCOL_INFO (try 5)
by Marvin Sept. 10, 2013

Sept. 10, 2013

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=2084 Your paranoid android. === wxppro (32 bit sock) === sock.c:509: Test failed: oob_server (b8): unexpectedly at the OOB mark: 0 sock.c:519: Test failed: oob_server (b8): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 71AB8D62 === w7pro64 (32 bit sock) === sock.c:528: Test failed: oob_server (138): not at the OOB mark: 1 === w7pro64 (64 bit sock) === sock.c:509: Test failed: oob_server (934): unexpectedly at the OOB mark: 0 sock.c:519: Test failed: oob_server (934): unexpectedly at the OOB mark: 0 sock.c:288: Test failed: do_synchronous_recv (934): error 10054: sock.c:534: Test failed: oob_server (934): not at the OOB mark: 1

1 0

Re: [1/5] ntdll: Add support to NtWriteFile for special offset -1. Take 2.
by Alexandre Julliard Sept. 9, 2013

Sept. 9, 2013

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > --- > dlls/ntdll/file.c | 13 ++++++++++--- > dlls/ntdll/tests/file.c | 15 --------------- > 2 files changed, 10 insertions(+), 18 deletions(-) This is causing test failures all over the place. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/5] wait until all data from earlier test has been written in test_waittxempty
by Dmitry Timoshkov Sept. 9, 2013

Sept. 9, 2013

Wolfgang Walter <wine(a)stwm.de> wrote: > + if (res || (!res && GetLastError() == ERROR_IO_PENDING)) > + /* if data has been sent: wait for termination */ > + Sleep(timeout); I don't see such a problem with real COM-port and serial-USB cable under Windows or Linux here and under testbot VMs. -- Dmitry.

3 12

Re: server: Add a serial event mask change counter.
by Alexandre Julliard Sept. 9, 2013

Sept. 9, 2013

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > @@ -209,7 +211,7 @@ DECL_HANDLER(get_serial_info) > reply->writemult = serial->writemult; > > /* event mask */ > - reply->eventmask = serial->eventmask; > + reply->eventmask = serial->eventmask | (serial->generation << 16); It would be better to return it as a separate field, particularly since eventmask is already an int. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 3/6] ws2_32: Fix parameters checking in WSADuplicateSocket
by Alexandre Julliard Sept. 9, 2013

Sept. 9, 2013

Bruno Jesus <00cpxxx(a)gmail.com> writes: > + fd = get_sock_fd( s, FILE_READ_DATA, NULL ); > + if (fd == -1) > + { > + SetLastError(WSAENOTSOCK); > + return SOCKET_ERROR; > + } > + release_sock_fd( s, fd ); You should avoid retrieving the fd if you are not using it. The handle should be checked at the point where you are doing something with it. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH 4/5] wined3d: Move the decoded stream info into the context
by Henri Verbeet Sept. 9, 2013

Sept. 9, 2013

On 9 September 2013 12:56, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > --- I think this patch does a couple of things at once, and would probably benefit from being broken up. > static struct arb_vs_compiled_shader *find_arb_vshader(struct wined3d_shader *shader, > - const struct arb_vs_compile_args *args, > + const struct wined3d_context *context, const struct arb_vs_compile_args *args, > const struct wined3d_shader_signature_element *ps_input_sig) I think it makes more sense to pass a wined3d_stream_info structure here instead of a context, or perhaps even just the use_map field. > -static BOOL buffer_find_decl(struct wined3d_buffer *This) > +static BOOL buffer_find_decl(struct wined3d_buffer *This, const struct wined3d_context *context) Same. > diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h > index 23d32c2..f7ded75 100644 > --- a/dlls/wined3d/wined3d_private.h > +++ b/dlls/wined3d/wined3d_private.h > @@ -1086,6 +1086,7 @@ struct wined3d_context > DWORD padding : 1; > DWORD texShaderBumpMap : 8; /* MAX_TEXTURES, 8 */ > DWORD lastWasPow2Texture : 8; /* MAX_TEXTURES, 8 */ > + DWORD use_draw_strided_slow : 1; > DWORD shader_update_mask; > DWORD constant_update_mask; > DWORD numbered_array_mask; I think that's an unfortunate place to insert the field, and you should update the padding. > @@ -1880,9 +1889,7 @@ struct wined3d_device > WORD d3d_initialized : 1; > WORD inScene : 1; /* A flag to check for proper BeginScene / EndScene call pairs */ > WORD softwareVertexProcessing : 1; /* process vertex shaders using software or hardware */ > - WORD useDrawStridedSlow : 1; > WORD filter_messages : 1; > - WORD padding : 8; Padding?

3 3

Re: [PATCH 5/5] wined3d: Explicitly pass the state information to buffer_internal_preload
by Henri Verbeet Sept. 9, 2013

Sept. 9, 2013

On 9 September 2013 12:56, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > -static BOOL buffer_find_decl(struct wined3d_buffer *This, const struct wined3d_context *context) > +static BOOL buffer_find_decl(struct wined3d_buffer *This, const struct wined3d_context *context, > + const struct wined3d_state *state) buffer_find_decl() doesn't really care about the context state, it's really just about determining what fixups it should check for, and should probably be passed a mask instead.

1 0

Re: [PATCH 1/5] wined3d: Don't mess with the device in buffer_create_buffer_object
by Henri Verbeet Sept. 9, 2013

Sept. 9, 2013

On 9 September 2013 12:56, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -148,7 +149,7 @@ static void buffer_create_buffer_object(struct wined3d_buffer *This, const struc > } > > if (This->buffer_type_hint == GL_ELEMENT_ARRAY_BUFFER_ARB) > - device_invalidate_state(This->resource.device, STATE_INDEXBUFFER); > + context_invalidate_state(context, STATE_INDEXBUFFER); > GL_EXTCALL(glBindBufferARB(This->buffer_type_hint, This->buffer_object)); > error = gl_info->gl_ops.gl.p_glGetError(); > if (error != GL_NO_ERROR) The patch is fine, although I probably would have preferred something along the lines of "Only invalidate STATE_INDEXBUFFER for the current context in buffer_create_buffer_object()." for the commit message.

1 0

Re: [PATCH 1/6] ws2_32: Mark WinNT result as broken
by Marvin Sept. 9, 2013

Sept. 9, 2013

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=2061 Your paranoid android. === wxppro (32 bit sock) === sock.c:519: Test failed: oob_server (7e0): unexpectedly at the OOB mark: 0

2 1

Re: [PATCH 6/6] ws2_32: Fill WSAPROTOCOL_INFO struct in WSADuplicateSocket
by Marvin Sept. 8, 2013

Sept. 8, 2013

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=2065 Your paranoid android. === wxppro (32 bit sock) === sock.c:509: Test failed: oob_server (f0): unexpectedly at the OOB mark: 0 sock.c:519: Test failed: oob_server (f0): unexpectedly at the OOB mark: 0

1 0

Implementation of ITextDocument_fnOpen needs some advice
by Jactry Zeng Sept. 8, 2013

Sept. 8, 2013

Hi folks, I need your advice or comment! Implement ITextDocument_fnOpen[0] (riched20) is a part of work to my GSoC. The 'pencils down' date is coming. And I think it is time to clear the code up. This series of patches is the implementation of ITextDocument_fnOpen. I would like to improve it to be enough good for sending to wine-patches and being accepted. I split the implementation into six patches: - patch 0001 is just a simple implementation; - patch 0002 added the creation mode to let it support these parameters: tomCreateNew, tomCreateAlways, tomOpenExisting, tomOpenAlways, tomTruncateExisting; - patch 0003 added the access mode to let support tomReadOnly and any combination of tomReadOnly and tomShareDenyRead, tomShareDenyWrite, tomPasteFile; - patch 0004 added the support of RTF - patch 0005 added tomPasteFile support - patch 0006 added a UTF-16 support, with this patch you can open a UTF-6 text file without dependence of the long CodePage parameter. If you want to open a utf-8 text file with it, you may need these patch to fix a bug of EM_SETTEXTEX: http://source.winehq.org/patches/data/98574 http://source.winehq.org/patches/data/98575 http://source.winehq.org/patches/data/98576 http://source.winehq.org/patches/data/98577 I appreciate for any comment! :) Thank you. ** Thanks my mentor Huw and Qian Hong for giving me a lot good advice. Thanks other people for help! ** [0] http://msdn.microsoft.com/en-us/library/windows/desktop/bb774093(v=vs.85).a… -- Regards, Jactry Zeng

1 0

Re: [PATCH 5/6] ws2_32: Implement get socket option SO_PROTOCOL_INFO (try 4)
by Marvin Sept. 8, 2013

Sept. 8, 2013

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=2064 Your paranoid android. === wxppro (32 bit sock) === sock.c:519: Test failed: oob_server (ec): unexpectedly at the OOB mark: 0 === w7pro64 (32 bit sock) === sock.c:528: Test failed: oob_server (3a4): not at the OOB mark: 1

1 0

Re: [PATCH 4/6] ws2_32: Add more WSADuplicateSocket tests
by Marvin Sept. 8, 2013

Sept. 8, 2013

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=2063 Your paranoid android. === wxppro (32 bit sock) === sock.c:519: Test failed: oob_server (b0): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 71AB8D62 === w7pro64 (32 bit sock) === sock.c:519: Test failed: oob_server (138): unexpectedly at the OOB mark: 0 sock.c:768: sock.c:288: Test failed: do_synchronous_recv (138): error 10054: sock.c:534: Test failed: oob_server (138): not at the OOB mark: 1 === w7pro64 (64 bit sock) === sock.c:528: Test failed: oob_server (ab8): not at the OOB mark: 1

1 0

Re: [PATCH 3/6] ws2_32: Fix parameters checking in WSADuplicateSocket
by Marvin Sept. 8, 2013

Sept. 8, 2013

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=2062 Your paranoid android. === wxppro (32 bit sock) === sock.c:509: Test failed: oob_server (b0): unexpectedly at the OOB mark: 0 sock.c:519: Test failed: oob_server (b0): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 71AB8D62

1 0

Patch for bug 34388
by Charles Davis Sept. 7, 2013

Sept. 7, 2013

Hi Juan, I need some advice. Attached is a patch to fix bug 34388, where an app that tries to verify its code signature fails because Wine, while parsing the certificates embedded within the signature, encounters an item in the CMS signer info (tag 0x31, i.e. ASN_UNIVERSAL | ASN_CONSTRUCTOR | 0x11), right before the HashEncryptionAlgorithm sequence item, that it doesn't yet know how to decode. This patch (which just skips the item in question) allows that app to successfully verify its code signature and run, but... My testing on Windows (cf. job 2037 on newtestbot) shows some interesting behavior. Windows will indeed accept this item, but only if the AuthAttrs item is also present and immediately precedes it in the sequence. (The other test bails out with CRYPT_E_ASN_BADTAG.) I don't quite know what to make of this. The odd thing is that the certificate in question doesn't have this optional AuthAttrs item, and yet (in most cases, at least) most people who run this particular app on Windows do not have this problem. I can't seem to find anything about this from reading the relevant RFCs. Is there something I'm missing? Thanks. Chip

2 5

Re: ntdll: Implement job objects. (try 3)
by Alexandre Julliard Sept. 7, 2013

Sept. 7, 2013

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

Sept. 6, 2013

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

Sept. 6, 2013

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

Sept. 6, 2013

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

Sept. 6, 2013

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

Sept. 6, 2013

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

Sept. 6, 2013

[+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 Sept. 6, 2013

Sept. 6, 2013

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

Sept. 6, 2013

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

Sept. 6, 2013

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 Sept. 5, 2013

Sept. 5, 2013

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 Sept. 5, 2013

Sept. 5, 2013

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 Sept. 5, 2013

Sept. 5, 2013

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 Sept. 5, 2013

Sept. 5, 2013

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 Sept. 5, 2013

Sept. 5, 2013

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 Sept. 5, 2013

Sept. 5, 2013

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 Sept. 5, 2013

Sept. 5, 2013

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 Sept. 5, 2013

Sept. 5, 2013

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 Sept. 5, 2013

Sept. 5, 2013

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 Sept. 5, 2013

Sept. 5, 2013

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 Sept. 5, 2013

Sept. 5, 2013

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 Sept. 5, 2013

Sept. 5, 2013

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 Sept. 4, 2013

Sept. 4, 2013

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 Sept. 4, 2013

Sept. 4, 2013

-----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 Sept. 4, 2013

Sept. 4, 2013

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 Sept. 4, 2013

Sept. 4, 2013

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 Sept. 4, 2013

Sept. 4, 2013

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 Sept. 4, 2013

Sept. 4, 2013

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 Sept. 4, 2013

Sept. 4, 2013

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 Sept. 4, 2013

Sept. 4, 2013

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 Sept. 4, 2013

Sept. 4, 2013

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 Sept. 4, 2013

Sept. 4, 2013

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 Sept. 4, 2013

Sept. 4, 2013

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 Sept. 4, 2013

Sept. 4, 2013

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 Sept. 4, 2013

Sept. 4, 2013

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 Sept. 4, 2013

Sept. 4, 2013

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 Sept. 3, 2013

Sept. 3, 2013

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 Sept. 3, 2013

Sept. 3, 2013

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 Sept. 3, 2013

Sept. 3, 2013

-----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 Sept. 3, 2013

Sept. 3, 2013

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 Sept. 3, 2013

Sept. 3, 2013

-----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 Sept. 3, 2013

Sept. 3, 2013

-----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 Sept. 3, 2013

Sept. 3, 2013

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 Sept. 3, 2013

Sept. 3, 2013

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 Sept. 2, 2013

Sept. 2, 2013

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 Sept. 2, 2013

Sept. 2, 2013

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 Sept. 2, 2013

Sept. 2, 2013

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 Sept. 2, 2013

Sept. 2, 2013

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 Sept. 2, 2013

Sept. 2, 2013

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 Sept. 2, 2013

Sept. 2, 2013

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