wine-devel January 2016

wine-devel@winehq.org

71 participants
267 discussions

Re: shell32/tests: Fix a couple of okChildPath()/okChildString() mixups.
by Marvin 27 Jan '16

27 Jan '16

1 0

Re: shell32/tests: Show that verbs and classes override ShellExecute()'s normal handling of executables.
by Marvin 27 Jan '16

27 Jan '16

1 0

Re: shell32/tests: Test handling of nonexistent verbs in ShellExecute() & co.
by Marvin 27 Jan '16

27 Jan '16

1 0

Re: [PATCH 5/8] wined3d: Fail texture creation when invalid multisample settings are specified.
by Henri Verbeet 27 Jan '16

27 Jan '16

On 26 January 2016 at 22:51, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > @@ -1137,6 +1137,8 @@ static HRESULT d3d9_device_create_surface(struct d3d9_device *device, UINT width > { > wined3d_mutex_unlock(); > WARN("Failed to create texture, hr %#x.\n", hr); > + if (hr == D3DERR_NOTAVAILABLE) > + hr = D3DERR_INVALIDCALL; That should check for WINED3DERR_NOTAVAILABLE.

1 0

Re: [PATCH v3 4/8] wined3d: Add a real implementation of wined3d_check_device_multisample_type().
by Henri Verbeet 27 Jan '16

27 Jan '16

On 26 January 2016 at 22:51, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + if (format->glInternal > + && (format->flags[WINED3D_GL_RES_TYPE_RB] & WINED3DFMT_FLAG_RENDERTARGET > + || format->flags[WINED3D_GL_RES_TYPE_RB] & WINED3DFMT_FLAG_DEPTH > + || format->flags[WINED3D_GL_RES_TYPE_RB] & WINED3DFMT_FLAG_STENCIL)) It's not the worst thing in the world, but I think you meant "format->flags[WINED3D_GL_RES_TYPE_RB] & (WINED3DFMT_FLAG_RENDERTARGET | WINED3DFMT_FLAG_DEPTH | WINED3DFMT_FLAG_STENCIL)"?

1 0

Re: [PATCH 2/2] kernel32/tests: Add tests for the TRUE pathway of GetCurrentConsoleFont
by Marvin 27 Jan '16

27 Jan '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=19992 Your paranoid android. === w8 (32 bit console) === console.c:1445: Test failed: [13] Expected output count to be 0, got 1210300685 console.c:1445: Test failed: [15] Expected output count to be 0, got 1210300685 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 1210300685 console.c:1689: Test failed: [13] Expected output count to be 0, got 1210300685 console.c:1689: Test failed: [15] Expected output count to be 0, got 1210300685 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 1210300685 === w864 (32 bit console) === console.c:1445: Test failed: [13] Expected output count to be 0, got 3069051044 console.c:1445: Test failed: [15] Expected output count to be 0, got 3069051044 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 3069051044 console.c:1689: Test failed: [13] Expected output count to be 0, got 3069051044 console.c:1689: Test failed: [15] Expected output count to be 0, got 3069051044 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 3069051044 === w1064 (32 bit console) === console.c:2567: Test failed: expected ERROR_INVALID_HANDLE, got 1 console.c:2573: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2580: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2587: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:1270: Test failed: expected VerifyConsoleIoHandle to succeed console.c:1445: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [13] Expected output count to be 0, got 3792776332 console.c:1445: Test failed: [15] Expected output count to be 0, got 3792776332 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 3792776332 console.c:1689: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [13] Expected output count to be 0, got 3792776332 console.c:1689: Test failed: [15] Expected output count to be 0, got 3792776332 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 3792776332 console.c:2148: Test failed: [7] Expected count to be 0, got 1 console.c:2214: Test failed: [7] Expected count to be 0, got 1 console.c:2280: Test failed: [7] Expected count to be 0, got 1 === w1064 (64 bit console) === console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 0

2 1

calling dll native entry point for mixed assemblies
by Paul Gofman 26 Jan '16

26 Jan '16

Hi Vincent, thank you for your help so far and sorry for disturbing you with my patches again so soon. While looking a bit further into my app under Wine I found out that some mixed assemblies are completely broken under Wine/Mono due to the fact that native entry point is not called at all. It relates to both 32 bit and 64 bit. 32 bit works fine under native MS .Net which apparently does call the entry point. The entry point address is present in IMAGE_COR20_HEADER (when appropriate flag is set in Flags member). It is DllMain-type entry point having the same parameters. This entry point does static initialization, e. g. calls all the constructors for static classes. I am attaching preliminary patch to illustrate what I am talking about. It would be great if you could give some high level feedback on whether you like the idea of doing this in general before I will be spamming it to wine-patches. The potential issue which I can imagine with it is that if there are some old apps (built with VS 2003) which called CLR code in native init but by chance worked if native init was not called at all, may stop working. MSDN says that such apps could non-deterministically deadlock when loaded; with Wine/Mono they will lock deterministically I think ( https://msdn.microsoft.com/en-us/library/ms173266.aspx). Still I suppose the issue with entry point should be addressed somehow since it affects "normal" newer applications. Regards, Paul.

2 6

Re: include: Create todo_wine_if.
by Sebastian Lackner 26 Jan '16

26 Jan '16

On 26.01.2016 18:06, Bernhard Übelacker wrote: > Currently list based tests, where just some elements are todo_wine, need > the same ok()-line twice, one without and one with todo_wine. > (e.g. dlls/msvcr120/tests/msvcr120.c line 243) > > This patch makes it possible to use a single ok()-line > prefixed with a todo_wine_if(condition). > e.g.: > todo_wine_if(tests[i].todo) > ok(...); > > Questions: > - Is "todo_level" ever supposed to have a value greater than 1? I don't know if its used in practice anywhere, but the old way handling of nested todo_wines was definitely more clear than your new proposed method. I would suggest to keep this "feature", even when its probably not used in the Wine source. The first idea which comes to my mind would be to store it in a bitmask (which allows at least up to 32 bit nested todos when declaring todo_level as unsigned integer value). For example: start: todo_level = (todo_level << 1) | (is_todo != 0); testing: if (todo_level != 0) end: todo_level >>= 1; > > Changes: > 2016-01-26: > - Give parameter is_todo just to *start_dodo. > - Decrement in *end_todo just when todo_level > 0. > > 2016-01-22: > - First version > (Thanks to Sebastian Lackner for review.) > Comments: https://www.winehq.org/pipermail/wine-devel/2016-January/111386.html > --- > include/wine/test.h | 21 ++++++++++++--------- > 1 file changed, 12 insertions(+), 9 deletions(-) >

1 0

Re: [PATCH 2/2] wpcap: Fix crash on pcap_loop
by André Hentschel 26 Jan '16

26 Jan '16

Hi, Could you please explain what is happing that causes the crash? Also you should move "res" into the right scope, then you also don't need to initialize it. Am 07.01.2016 um 09:49 schrieb Jianqiu Zhang: > From 064be8949c53e43ba56a586d30d2186e5da8cb06 Mon Sep 17 00:00:00 2001 > From: Jianqiu Zhang <zhangjianqiu_133(a)yeah.net> > Date: Tue, 5 Jan 2016 09:12:42 +0800 > Subject: [PATCH 2/2] wpcap: Fix crash on pcap_loop > > Signed-off-by: Jianqiu Zhang <zhangjianqiu_133(a)yeah.net> > --- > dlls/wpcap/wpcap.c | 11 ++++++++--- > 1 file changed, 8 insertions(+), 3 deletions(-) > > diff --git a/dlls/wpcap/wpcap.c b/dlls/wpcap/wpcap.c > index da911c7..0c725a4 100644 > --- a/dlls/wpcap/wpcap.c > +++ b/dlls/wpcap/wpcap.c > @@ -95,7 +95,6 @@ static void pcap_handler_callback(u_char *user_data, const struct pcap_pkthdr *h > TRACE("(%p %p %p)\n", user_data, h, p); > pcb = (PCAP_HANDLER_CALLBACK *)user_data; > pcb->pfn_cb(pcb->user_data, h, p); > - HeapFree(GetProcessHeap(), 0, pcb); > TRACE("Callback COMPLETED\n"); > } > > @@ -103,6 +102,7 @@ int CDECL wine_pcap_dispatch(pcap_t *p, int cnt, > void (CALLBACK *callback)(u_char *, const struct pcap_pkthdr *, const u_char *), > unsigned char *user) > { > + int res = 0; > TRACE("(%p %i %p %p)\n", p, cnt, callback, user); > > if (callback) > @@ -111,7 +111,9 @@ int CDECL wine_pcap_dispatch(pcap_t *p, int cnt, > pcb = HeapAlloc(GetProcessHeap(), 0, sizeof(PCAP_HANDLER_CALLBACK)); > pcb->pfn_cb = callback; > pcb->user_data = user; > - return pcap_dispatch(p, cnt, pcap_handler_callback, (unsigned char*)pcb); > + res = pcap_dispatch(p, cnt, pcap_handler_callback, (unsigned char *)pcb); > + HeapFree(GetProcessHeap(), 0, pcb); > + return res; > } > > return pcap_dispatch(p, cnt, NULL, user); > @@ -196,6 +198,7 @@ int CDECL wine_pcap_loop(pcap_t *p, int cnt, > void (CALLBACK *callback)(u_char *, const struct pcap_pkthdr *, const u_char *), > unsigned char *user) > { > + int res = 0; > TRACE("(%p %i %p %p)\n", p, cnt, callback, user); > > if (callback) > @@ -204,7 +207,9 @@ int CDECL wine_pcap_loop(pcap_t *p, int cnt, > pcb = HeapAlloc(GetProcessHeap(), 0, sizeof(PCAP_HANDLER_CALLBACK)); > pcb->pfn_cb = callback; > pcb->user_data = user; > - return pcap_loop(p, cnt, pcap_handler_callback, (unsigned char*)pcb); > + res = pcap_loop(p, cnt, pcap_handler_callback, (unsigned char *)pcb); > + HeapFree(GetProcessHeap(), 0, pcb); > + return res; > } > > return pcap_loop(p, cnt, NULL, user); > -- > 2.6.4 > > >

2 2

Re: Revert "winex11.drv: Fix IME status handling."
by Aric Stewart 26 Jan '16

26 Jan '16

Sorry, I missed I was assigned to this. I dont know if reverting right away is the right path, did you explore adding XIMStatusCallbacks to the XCreateIC call? If not, then is there a way to detect that XNPreeditStartCallback is not being utilized? Maybe have a flag or something that gets set in addition to the IME_SetOpenStatus call, then if we go straight into XIMPreEditStartCallback without having seen the PreeditStartCallback we do the opening automatically, like we did before, but without the revert? -aric

2 2

← Newer
1
2
3
4
5
6
7
8
9
...
27
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel January 2016