wine-devel June 2012

wine-devel@winehq.org

80 participants
224 discussions

Wine automated testing update
by Jeremy White 06 Aug '12

06 Aug '12

Hi Folks, At the last Wine conference, I volunteered to find a home for the WineTestBot that Ge's brother has been hosting, and to take over the Buildbot that Dan and Austin have been so diligently maintaining. This is an update on that project, mostly to help keep my procrastinating self moving it along. First, we have a lovely set of hardware; 4 servers, in a dedicated rack, with a dedicated static ip to the outside world. One server is the gateway, 2 are dedicated Linux test systems (with nice fast processor + gpus), and one is a beefy system capable of running many VMs. The plan was to move the existing VMWare based WineTestBot to this hardware and simply get the existing system up and running on the new hardware. Here we hit our first snag; the VMWare folks are not willing to provide a permanent license for VMWare to us. So, we've shifted gears, and are exploring whether something like qemu + kvm would be a sufficient alternate. I've done a little of this work, and Maarten is hopefully going to help me try converting the existing VMs to see if we can save any hassle by doing a conversion. In parallel, I learned a great deal about buildbot and the buildbot system that Dan has built. There are two especially valuable and useful functions provided by this buildbot: the first is essentially a patch watcher; a process that catches simple mistakes (e.g. build errors on different architectures, and so on). The second is more powerful and is encapsulated by the 'dotests.sh' shell script. The dotests.sh script does a good job of basically running make test and noticing any test failures outside of 'the usual ones'. There is an infrastructure for Buildbot is a good tool, and I invested a lot of energy into it (as have Dan and Austin). However, Alexandre has persuaded me that we should first explore integrating the dotest.sh functionality into the existing WineTestBot, as that would allow us to have a very simple clean web page, and would also allow us to integrate most cleanly with Alexandre's back end tools. Of course, WineTestBot is Perl code, and my Perl fu is low. So I have recently asked Francois to help with that effort as well. So the basic plan is as follows: 1. Test qemu/kvm with a few Windows versions to see if it'll work. 2. If so, modify WineTestBot to use qemu instead of vmware. (This is 'easy' because the WineTestBot code nicely isolates the VM functions, but 'hard', because VMWare provides some APIs that may have to be replicated). 3. Migrate WineTestBot to the new hardware stack 4. Write new code to run 'dotests.sh' as part of WineTestBot Cheers, Jeremy

9 11

Re: include: fix mingw64 build
by Nicolas Le Cam 30 Jul '12

30 Jul '12

2012/6/29 Austin English <austinenglish(a)gmail.com>: > Fixes http://bugs.winehq.org/show_bug.cgi?id=30980 > > -- > -Austin > > > Hi Austin, I already tried to fix it on Wine side, see [1], but Alexandre told me on IRC that the bug needs to be fixed in mingw-w64, as it shouldn't include crtdefs.h by default. BTW, won't that break mingw32 build ? [1] http://source.winehq.org/patches/data/84070 -- Nicolas Le Cam

4 13

Wine's support for reporting calling conventions
by Roger Cruz 26 Jul '12

26 Jul '12

In dlls/dbghelp/dwarf.c, there is this snippet of code which appears to hard-code the calling convention to CALL_FAR_C. Does Wine not support reporting a function's calling convention correctly then? Is it a limitation of DWARF or just that it is not implemented? I can see that DWARF has a DW_AT_calling_convention field but when I examine a Wine DLL with objdump, it does not show this field in use. /* FIXME: assuming C source code */ sig_type = symt_new_function_signature(ctx->module, ret_type, CV_CALL_FAR_C); Thanks Roger

3 5

A copyright question to wine developpers
by Christophe-Marie Duquesne 26 Jul '12

26 Jul '12

Hi, To my understanding, wine is a reimplementation of the MS system. As far as I understand, you take MS public headers and reimplement their functions. If that is how it works, then how do you deal with copyright? The MS headers certainly come with a copyright clause: how is it possible to redistribute these headers with wine? The reason why I ask this: I just rewrote an opensource implementation of a closed-source library. This opensource implementation is meant to be fully compatible with the closed source one: I reimplemented all the functions provided by their header, and anyone using the closed source one should be able to use my library as a replacement. My problem, though, is with the distribution of the header: Since I want to be fully compatible with the closed-source implementation, I have to, somehow, use the same header. I could probably modify it so that is *looks* different, but for the compiler, the API *needs* to be the same. Since you seem to have the same problem with wine (and you probably dealt with it succesfully), I wanted to ask you how you are solving this problem. Do you "rewrite" the headers? Do you copy them "raw"? Thank you, Christophe-Marie Duquesne

5 7

Rethinking WineConf
by Jeremy White 26 Jul '12

26 Jul '12

Hi All, This past Wine conference, while great fun as always, was not as well attended as Wine conferences in the past. So I would like to stir up trouble by suggesting we rethink WineConf. For those that have not attended, the Wine conference has been a mostly annual affair since 2002. It is open to all, but is advertised as being aimed at Wine developers. About 35 people attend each year. It's been in Minnesota about every 3rd year, and is otherwise 'normally' somewhere in Europe. I see the primary goal as creating human bonds between otherwise anonymous people (aka going to the pub). It's a bonus if it also spurs resolution to tricky issues, or motivates people to get more done. So I'd like to ask folks to brain storm with me. How could Wineconf be different? If you've never been, what would encourage you to come? If you've been to a technical conference recently that you thought was well done, what did they do well? Anything we could emulate? Any other ideas, or suggestions? Cheers, Jeremy

17 25

Re: mshtml: Set outgoing pass-by-address variable in an error case case within confirm_safety_load.
by Jacek Caban 18 Jul '12

18 Jul '12

Hi Gerald, On 03/07/12 23:35, Gerald Pfeifer wrote: > I noticed we return in this case, without initializing this variable. > Visual inspection indicates we do not seem to access the variable in > this error case, but a) better safe than sorry, and b) GCC 4.8 currently > warns about it. > > Not sure URLPOLICY_DISALLOW is the best return value, open for better > alternatives. I generally don't think this patch makes things any better (or worse). If we return an error, the caller should not expect this value to be sane. What's the GCC 4.8 warning? Jacek

2 4

mshtml: Always set the URL policy in the error cases?
by Francois Gouget 16 Jul '12

16 Jul '12

gcc 4.7 is complaining that policy may be used uninitialized in InternetHostSecurityManager_QueryCustomPolicy() and indeed there are many error cases in confirm_safety_load() and confirm_safety() where the policy is not set. The patch belowe seems to plug all these holes but I don't know if it really makes sense. diff --git a/dlls/mshtml/secmgr.c b/dlls/mshtml/secmgr.c index ff349ac..3f64a42 100644 --- a/dlls/mshtml/secmgr.c +++ b/dlls/mshtml/secmgr.c @@ -104,10 +104,9 @@ static HRESULT confirm_safety_load(HTMLDocumentNode *This, struct CONFIRMSAFETY CATID init_catid = CATID_SafeForInitializing; hres = ICatInformation_IsClassOfCategories(This->catmgr, &cs->clsid, 1, &init_catid, 0, NULL); + *ret = hres == S_OK ? URLPOLICY_ALLOW : URLPOLICY_DISALLOW; if(FAILED(hres)) return hres; - - *ret = hres == S_OK ? URLPOLICY_ALLOW : URLPOLICY_DISALLOW; } return S_OK; @@ -157,13 +156,17 @@ static HRESULT confirm_safety(HTMLDocumentNode *This, const WCHAR *url, struct C if(!This->catmgr) { hres = CoCreateInstance(&CLSID_StdComponentCategoriesMgr, NULL, CLSCTX_INPROC_SERVER, &IID_ICatInformation, (void**)&This->catmgr); - if(FAILED(hres)) + if(FAILED(hres)) { + *ret = URLPOLICY_DISALLOW; return hres; + } } hres = ICatInformation_IsClassOfCategories(This->catmgr, &cs->clsid, 1, &scripting_catid, 0, NULL); - if(FAILED(hres)) + if(FAILED(hres)) { + *ret = URLPOLICY_DISALLOW; return hres; + } if(hres != S_OK) { *ret = URLPOLICY_DISALLOW; -- 1.7.10

2 3

Re: [2/2] msxml3: Support xmlns[:*] attribute nodes intelligently.
by Nikolay Sivov 08 Jul '12

08 Jul '12

On 6/12/2012 11:55, Ulrik Dickow wrote: > Patch 2 of 2 from http://bugs.winehq.org/show_bug.cgi?id=26226 . > > > > + /* Emit appropriate fixme or warning in case of unsupported or invalid namespace. > + * The W3C spec would like us to exit earlier for attempts to redefine the namespace for > + * the reserved "xmlns" attribute or prefix (http://www.w3.org/TR/xml-names/#ns-decl), > + * likehttp://gdome2.cs.unibo.it/gtk-doc/gdome2-gdomeelement.html#GDOME-EL-SETATTRIBUTENS, > + * but since native msxml3 accepts anything here, it's safest to just continue with warning. > + */ The question is more like what libxml2 thinks about that. If it follows w3c here which is likely the question will be - won't it break somewhere internally in libxml2 code if we hack it that way? > + if(namespaceURI && namespaceURI[0] && node_type != NODE_ELEMENT) > + { > + if(node_type == NODE_ATTRIBUTE) > + switch((!strcmpW(name, xmlnsW) || > + !strncmpW(name, xmlnscW, sizeof(xmlnscW)/sizeof(WCHAR))) + > + !strcmpW(namespaceURI, w3xmlns)) Could you please simplify that, it's a bit hard to read. > + * Note: We would be more in line with the native msxml if we only detected a > + * redundancy/conflict for prefixes existing on the element itself (in element->ns > + * or in the linked list element->nsDef). But as long as our *_get_xml() doesn't > + * eliminate redundant namespace definitions in children, this behaviour may be > + * an advantage in some cases. As disadvantage is that we incorrectly regard the > + * redefinition in element 'b' in '<a xmlns="x"><b xmlns="y"/></a>' as a conflict. > + * Libxml2 currently doesn't have a function or option to only search for namespaces > + * on the current node; but it would be easy to make a reduced version of xmlSearchNs > + * (currently defined inhttp://git.gnome.org/browse/libxml2/tree/tree.c#n5871). > + * However, most apps probably set the ns to y on node b creation, so no conflict here. > + * I don't think it's better to potentially break one thing while fixing the other. And I guess I like a thought on making xmlSearchNs version that will do what we want from it. Just to clarify - is that right that libxml2 problem here is a lack of some checks that lead to duplication and conflicts later? (that are visible in doc dumps too) > +/* Convenient helper function for creating an attribute node in a given namespace. > + * Note: CHECK_HR() should not be here, but in caller, to give optimal line number info. > + */ You mean EXPECT_HR here I guess. > +static HRESULT create_attribute_ns( > + IXMLDOMDocument *doc, > + const char *attr_name, > + const char *nsURI, > + IXMLDOMAttribute **attr_ptr) > +{ > + HRESULT hr; > + VARIANT var; > + IXMLDOMNode *node; > + > + V_VT(&var) = VT_I1; > + V_I1(&var) = NODE_ATTRIBUTE; > + > + hr = IXMLDOMDocument_createNode(doc, var,_bstr_(attr_name),_bstr_(nsURI), &node); > + if (hr == S_OK) > + { > + IXMLDOMNode_QueryInterface(node, &IID_IXMLDOMAttribute, (void**) attr_ptr); > + IXMLDOMNode_Release(node); > + } > + return hr; > +} Please null out pointer in case of failure, or better always before createNode().

2 4

winebuild port to ARM?
by Roger Cruz 07 Jul '12

07 Jul '12

Has anyone worked or is currently working on porting the x86 specific code in Winebuild to ARM? Specifically the relay.c file? Thanks Roger R. Cruz

2 9

[PATCH] winepulse.drv: Add PulseAudio driver
by Joerg-Cyril.Hoehle＠t-systems.com 04 Jul '12

04 Jul '12

Hi, >If you don't paste all the mmdevapi tests with the fix in my git tree, it's a >regression. I don't want to see held_Frames because it's a shadow buffer. >If winmm and dsound don't work without it, they're wrong, fix those. I won't comment on the two individual pulseaudio drivers. Unfortunately, none of the two authors bothered to point me to a verbose log of the mmdevapi tests for my scrutiny. The tests should pass like they do on native. Regarding latency, I'm not aware of a flaw in Wine's winmm. HOWEVER, Wine's DSound needs a patch. Here the reason. To recap, latency is somehow related to the "distance" between what one hears and the PCM frames sent to the device. GetPosition is the only API call in that area in both winmm and mmdevapi. Buffer size is a completely different thing. I find it useful to have in mind a cascade of audio filters performing some buffering each. Then it's obvious that an app only sees the frontmost buffer size and knows nothing about the others. High latencies imply that there must be some large buffer space(s), somewhere. Period is an artificial entity related to how often the frontmost buffer is drained to feed the next buffer in the chain, in case that happens regularly. This is not guaranteed nor necessarily documented. You get the idea: regardless of arbitrary (front) buffer sizes and periods not worth this name, try and send a stable flow of data to play music without glitches and let explosions be heard ASAP. So far the situation, now the issue. It appears easier to write code that provides (frontmost) buffer space behaviour similar to native than one that provides similar latency. Alas, behaviour observable on MS-Windows differs from what we get with PulseAudio and some ALSA devices. Tests seem to indicate a latency of around 30-70ms from mmdevapi with MS-Windows. That good enough for games. OTOH if ALSA or PA gives us 2 seconds on Linux, that's a big cause of trouble. The authors of MS apps could never test them in an environment with such high latency. What happens with software not tested? It happens not to work. Two solutions: - Reduce actual latency or - lie about latency. Lying about latency causes apps to loose the ability to sync audio and video. However, given a choice between loss of lip sync and possible crashes or other weird behaviour because an app is executed in a environment that its developers never experienced, I consider the loss of lip sync to be less worrying. We designed the winealsa driver to accomodate an arbitrary latency and accept a large variation of periods. (Some bug report from Jack users seem to imply that it should accept even larger periods, e.g. 150ms, yet still pretend to use 10ms on the mmdevapi side). We choose to have the winealsa driver not lie about latency. That should be left to high level APIs. DirectSound is built around the "Direct" HW (lack of) abstraction: a circular buffer of samples is played by a DAC. The converted signal is immediately sent to the speaker. Hence: 1. GetPosition information in the DSound abstraction translates to a "playpos" -- well known. 2. No provision is made for additional buffering. The playpos must lie within the circular buffer. The reported free (writable) space shall never cross the playpos -- with subtle consequences. Wine's DSound needs a patch to ensure this second property. Given a 80ms primary buffer, Wine's DSound must not pretend its playpos is 2 seconds late! I think Wine should try and reduce latency but lie if that does not suffice. What's needed? 1. Have DSound always use a buffer large enough for typical situations (I believe 100-200ms). 2. Clamp the reported position such that it won't leave the (virtual) primary buffer. As a result, DSound must pretend to play even when Wine is solely pumping the huge 2s of cascading SW audio buffers. 3. Work on reducing the latency of the cascading audio filters. That device-level work is independent on the DSound one. Native's 30-70ms has the benefit that it nicely fits within typical DSound primary buffer sizes. PulseAudio's 2s does not (yet). I believe a total 80ms latency would be acceptable with games. Further areas of investigation and effort: - Maybe clamp latency in the mmdevapi drivers after all? After all, huge latencies are known to cause dead-locks in apps and we don't know what all apps or libraries built atop mmdevapi or winmm expect. (If yes, to what value? 150% buffer size?) - Try and find MS setups with huge latencies. USB headphones are said to be candidates, but I've yet to see an excellent and trustworthy report about what happens in that case. - Work on reducing the cascades of audio buffers - Work on further decoupling mmdevapi periods from UNIX audio API ones - Research the trade-off between glitch free playback and buffering in UNIX. The current settings in Wine's audio are IMHO not good enough yet. Regards, Jörg Höhle

2 1

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 June 2012