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