wine-devel May 2014

wine-devel@winehq.org

64 participants
176 discussions

Re: wined3d: Add a registry setting, DisabledExtensions, to disable the use of OpenGL and WGL extensions.
by Henri Verbeet 06 May '14

06 May '14

On 6 May 2014 10:44, Ken Thomases <ken(a)codeweavers.com> wrote: > I'm inclined to say we don't really need this, but I'll leave that up to Alexandre. > + /* Second pass at disabling extensions. This (re)disables extensions that may > + be implied by the GL version or other extensions. */ Is this really a problem in practice? > + if (wined3d_settings.disabled_extensions) > + { > + parse_extension_string(gl_info, wined3d_settings.disabled_extensions, gl_extension_map, > + sizeof(gl_extension_map) / sizeof(*gl_extension_map), FALSE); > + if (WGL_Extensions) > + parse_extension_string(gl_info, wined3d_settings.disabled_extensions, wgl_extension_map, > + sizeof(wgl_extension_map) / sizeof(*wgl_extension_map), FALSE); > + } It may be nicer to just make parse_extension_string() handle a NULL "extensions" pointer, and skip all the conditionals here. > - gl_vendor = wined3d_guess_gl_vendor(gl_info, gl_vendor_str, gl_renderer_str); > - card_vendor = wined3d_guess_card_vendor(gl_vendor_str, gl_renderer_str); > - TRACE("Found GL_VENDOR (%s)->(0x%04x/0x%04x).\n", debugstr_a(gl_vendor_str), gl_vendor, card_vendor); > - > device = wined3d_guess_card(gl_info, gl_renderer_str, &gl_vendor, &card_vendor); > TRACE("Found (fake) card: 0x%x (vendor id), 0x%x (device id).\n", card_vendor, device); I guess this was broken up because of the extension checks in wined3d_guess_gl_vendor(). Is that really justified? Conceptually, if we really want the DisabledExtensions functionality in wined3d, I think it should behave like filtering the extension strings, as opposed to being some kind of generic way to disable specific wined3d code paths, but not others that depend on the same extensions.

1 0

Re: winex11: Silence a noisy winediag ERR in xrandr12_init_modes
by Henri Verbeet 06 May '14

06 May '14

On 5 May 2014 22:53, André Hentschel <nerv(a)dawncrow.de> wrote: > - ERR_(winediag)("Broken NVIDIA RandR detected, falling back to RandR 1.0. " > - "Please consider using the Nouveau driver instead.\n"); > + static int once; > + if (!once++) ERR_(winediag)("Broken NVIDIA RandR detected, falling back to RandR 1.0. " > + "Please consider using the Nouveau driver instead.\n"); Does this actually help? We really shouldn't be calling X11DRV_XRandR_Init() much more often than once per process.

1 0

Re: [PATCH 5/5] ws2_32: Add an interactive test for interface change notifications (resend).
by Marvin 06 May '14

06 May '14

1 0

Working on ATL, more real world test case needed
by Qian Hong 05 May '14

05 May '14

Hi all, I'm working on atl80/atl100 recently, particularly on AtlAxCreateControl{,Lic}{,Ex}, AtlAxAttachControl, AtlIPersistStreamInit_{Load,Save}, AtlIPersistPropertyBag_{Load,Save} The motivation to work on AtlAxCreateControl* and AtlAxAttachControl* is for AliWangwang [1]; the motivation to work on AtlIPersistPropertyBag_Load is for QQ[2]. I've already have solution for those apps, however, I have some trouble on them: 1. I have more and more test case for ATL, and found more and more difference behaviors between native AtlAxCreateControl/AtlAxAttachControl and buitin's, some of native behavior looks unreasonable to me so I doubt if we want to follow that. It would be nice to test more real world application before deciding what to do next. 2. I found the (seems) undocumented ATL_PROPMAP_ENTRY struct is different between atl80 and atl100 from my black box testing result. I know QQ use atl80.AtlIPersistPropertyBag_Load which receive a ATL_PROPMAP_ENTRY input parameter, but I don't have any real world app to test the atl100 version or any other version. I'm interesting to know more apps depends on any version (atl/atl80/atl90/atl100/atl110) of AtlIPersistStreamInit_*/AtlIPersistPropertyBag_* to see how they work. I really appreciate a lot if anyone can help report ATL related bugs and CC me, maybe someone remembers some Apps have bugs on atl* but haven't report to bugzilla yet - I don't know any good way to find real world test case, that's why I'm here :) I'd really be happy to get some surprise smart way to do it! In short, any ATL related bugs are welcome, particularly on AtlAxCreateControl*/AtlAxAttachControl/AtlIPersistPropertyBag*/AtlIPersistStreamInit* if you know that's the culprit, but never mind for other ATL related bugs. Note: if an app bugs can be workaround by winetricks -q vcrun2005 / winetricks -q vcrun2008 / winetricks -q 2010, even with msvc*.dll override set to builtin, only leave native atl*.dll, then it is possible a ATL bug. Here are a few known ATL bugs: http://bugs.winehq.org/buglist.cgi?cmdtype=runnamed&list_id=147507&namedcmd… Thank you a lot for any help! [1] http://bugs.winehq.org/show_bug.cgi?id=33724 [2] http://bugs.winehq.org/show_bug.cgi?id=33822 -- Regards, Qian Hong - http://www.winehq.org

2 4

Re: [PATCH 2/5] wined3d: Validate and handle query size parameter. (try 2)
by Henri Verbeet 05 May '14

05 May '14

On 2 May 2014 16:30, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > +static void fill_query_data(void *out, unsigned int out_size, const void *result, unsigned int result_size) > +{ > + unsigned int size = min(out_size, result_size); > + > + memcpy(out, result, size); > +} The extra "size" variable is perhaps a bit superfluous. Not sure if I care.

1 0

Re: [PATCH 1/5] d3d9/tests: Test GetData behavior with various size values. (try 2)
by Henri Verbeet 05 May '14

05 May '14

On 2 May 2014 16:30, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + memset(&data, 0xff, sizeof(data)); This is a bit of an odd way to write "data = ~0u;". > + ok(*(WORD *)&data == 1 || broken(*(WORD *)&data != 1), > + "Occlusion query returned an unexpected result (0x%.8x).\n", data); > + todo_wine ok(*((WORD *)&data + 1) == 0xffff, > + "data was modified outside of the expected size (0x%.8x).\n", data); I think this is a bit awkward, perhaps it makes more sense the declare "data" as something like "WORD data[4];". Also, can this really ever return 0 for the query data? Would it help to draw a different primitive type, instead of a tiny point? (Because, well, point rasterization is complicated.)

1 0

Re: [PATCH] setupapi: Implement a binary compatible string table
by Marvin 04 May '14

04 May '14

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=6812 Your paranoid android. === wvistau64 (64 bit stringtable) === stringtable.c:351: Test failed: got 128 stringtable.c:352: Test failed: got 0, thread lcid 1401 === w2008s64 (64 bit stringtable) === stringtable.c:351: Test failed: got 124 stringtable.c:352: Test failed: got 0, thread lcid 409

1 0

Use WINE API from ELF application.
by John Found 04 May '14

04 May '14

Is it possible to use the WINE functionality from inside regular ELF application. For example starting and debugging Windows application. Creating windows, etc. -- asm32.info <johnfound(a)asm32.info>

2 1

Re: Failing tests on testbots because of missing focus
by Francois Gouget 04 May '14

04 May '14

On Sat, 3 May 2014, Bernhard Übelacker wrote: [...] > In my opinion the reason is that these tests get executed from an > application which does not have the current input focus. On the WineTestBot the tests are being run from a console window which is iconized. On the fg-* VMs the mechanism is similar, though it's possible the command window is no iconized. [...] > Also because the newtb* machines showed this error only sometimes (at > least before the testbot changes lately) probably some other tests are > doing something to change focus situation, or are running long enough > and windows is changing its focus policy there. Some tests cause Windows to be opened and stay around. In particular I remember that WineTest.exe typically leaves an Explorer window behind, most likely triggered by a shell32 or shlwapi test. The rpcrt4 tests and others also leave firewall windows behind, asking whether to unblock various ports (these tests don't actually need the ports to be unblocked and thus are not impacted by the questions being unanswered [1]). So based on your description it's quite likely that one of these windows is the one with the focus. [...] > Because of this affecting more tests (and probably this fix could also affect > tests running after this one), I am not sure if this is the right way to fix it: > > - should the test rely on being started from an application which > had focus? (e.g. change testbot to start the tests by an cmd window > which has guaranteed focus) Tests that need focus for one of their window should set up the focus themselves [2]. More generally tests should not rely on anyone else setting things up for them as that would make them too brittle and hard for developers to run 'correctly'. [1] I assume these tests bind their socket to any address and that's why they get these firewall questions. But in fact they only get connections from localhost which is unaffected by the firewall so it's possible they could avoid these questions by only binding to localhost. It's not clear that it's worth the trouble though. [2] I'll leave checking the proposed code to do so to other, more capable, hands (or eyes, braaaains, as the case may be). -- Francois Gouget <fgouget(a)codeweavers.com>

1 0

Re: [PATCH] vbscript: Fixed CBool(try 3)
by Piotr Caban 03 May '14

03 May '14

On 05/02/14 06:22, Shuai Meng wrote: > testbot:https://newtestbot.winehq.org/JobDetails.pl?Key=6731 > > Changelog: > added more tests on object; > changed the implemention of some tests that caused "Err.number = 0" > rearranged the order of tests > --- > dlls/vbscript/global.c | 41 ++++++++++------------------------- > dlls/vbscript/tests/api.vbs | 53 > +++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 65 insertions(+), 29 deletions(-) > The tests are failing on wine on polish locale: LC_ALL=pl_PL make test ../../../tools/runtest -q -P wine -T ../../.. -M vbscript.dll -p vbscript_test.exe.so run && touch run.ok fixme:thread:GetThreadUILanguage : stub, returning default language. run.c:2102: Tests skipped: Skipping some tests in non-English locale fixme:vbscript:parse_script parser failed around L"<!--" fixme:vbscript:do_icall L"y" not found fixme:vbscript:DispatchEx_InvokeEx no letter/setter run.c:1917: Test failed: expected global_success_d run.c:1918: Test failed: expected global_success_i run.c:1920: Test failed: parse_script failed: 800a000d fixme:vbscript:ClassFactory_QueryInterface (0x7e2462ec)->({342d1ea0-ae25-11d1-89c5-006008c3fbfc} 0x33f7b0) fixme:vbscript:RegExp2_QueryInterface (0x130a88)->({fc4801a3-2ba9-11cf-a229-00aa003d7352} 0x33f74c) fixme:vbscript:interp_enumnext uninitialized fixme:vbscript:interp_newenum Unsupported for {VT_EMPTY} fixme:vbscript:interp_enumnext uninitialized fixme:vbscript:show_msgbox failed: 80004005 fixme:vbscript:show_msgbox blocked make: *** [run.ok] B³±d 3

2 6

Jump to page:

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 May 2014