October 2013 - Wine-Devel - list.winehq.org

Re: [2/4] dnsapi/tests: Compile with -D__WINESRC__.

by Marvin

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=2733 Your paranoid android. === wxppro (32 bit record) === record.c:46: Test failed: succeeded unexpectedly record.c:49: Test failed: succeeded unexpectedly === wvista (32 bit record) === record.c:46: Test failed: succeeded unexpectedly record.c:49: Test failed: succeeded unexpectedly === w2008s64 (32 bit record) === record.c:46: Test failed: succeeded unexpectedly record.c:49: Test failed: succeeded unexpectedly === w7pro64 (32 bit record) === record.c:46: Test failed: succeeded unexpectedly record.c:49: Test failed: succeeded unexpectedly === w864 (32 bit record) === record.c:46: Test failed: succeeded unexpectedly record.c:49: Test failed: succeeded unexpectedly === w2008s64 (64 bit record) === record.c:46: Test failed: succeeded unexpectedly record.c:49: Test failed: succeeded unexpectedly === w7pro64 (64 bit record) === record.c:46: Test failed: succeeded unexpectedly record.c:49: Test failed: succeeded unexpectedly === w864 (64 bit record) === record.c:46: Test failed: succeeded unexpectedly record.c:49: Test failed: succeeded unexpectedly

Oct. 14, 2013

Mono Update

by Alistair Leslie-Hughes

Hi, wine-mono hasn't been updated in nearly a year. Should it be time to consider a new release? Thoughts. Best Regards Alistair Leslie-Hughes

Oct. 14, 2013

Re: ntdll: Support pinning module refcount with LdrAddRefDll()

by Nikolay Sivov

On 10/14/2013 05:21, Dmitry Timoshkov wrote: > Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > >> + FreeLibrary(mod); > Please add the tests for FreeLibrary return value. > Makes sense, thanks.

Oct. 14, 2013

Re: ntdll: Support pinning module refcount with LdrAddRefDll()

by Dmitry Timoshkov

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > + FreeLibrary(mod); Please add the tests for FreeLibrary return value. -- Dmitry.

Oct. 14, 2013

Re: MSYS touch.exe timestamp resolution issue on Wine-1.6

by Peter Rosin

On 2013-10-12 23:28, Alan W. Irwin wrote: > Under MSYS bash.exe if I use the touch command I only get 1-second > resolution when reading the results. > > bash.exe-3.1$ touch touch1.test touch2.test > bash.exe-3.1$ ls --full-time touch*.test > -rw-r--r-- 1 wine 544 0 2013-10-12 13:57:58.000000000 -0700 touch1.test > -rw-r--r-- 1 wine 544 0 2013-10-12 13:57:58.000000000 -0700 touch2.test > > Would somebody be willing to make the above test for MSYS on > the Microsoft version of Windows (which I don't have access to) to see > if time stamps are being read with 1-second resolution as above. That test > should help distinguish whether this is a Wine issue or else an MSYS > issue. I tested this on Windows 7, with MSYS 1.0.18, and I get the exact same experience. ls --full-time has a one second resolution (on NTFS, I expect a two second resolution on FAT, at least for some FAT variations). > I have also done some tests with the MSYS find.exe and make.exe > commands, and in all cases touch2.test is not newer than touch1.text. > This can be an important issue for the make command where one-second > time resolution can potentially screw up file dependencies. > > If I use the equivalent Linux ls (and find and make) commands to read the > time stamps on the above files, then touch2.test is newer than touch1.text, > e.g., Same here if I use an equivalent Cygwin ls, i.e. the actual time stamps are more fine grained than MSYS is capable of detecting. > wine(a)raven> ls --full-time touch*.test > -rw-r--r-- 1 wine wine 0 2013-10-12 13:57:58.391000000 -0700 touch1.test > -rw-r--r-- 1 wine wine 0 2013-10-12 13:57:58.408000000 -0700 touch2.test > > So I think this implies the MSYS touch.exe command is writing > high-resolution (i.e., millisecond) time stamps, and it is only > reading that high-resolution time stamp that seems to be an > issue for MSYS on Wine. Indeed. Since Cygwin has a different view, the situation should improve with MSYS 2. Cheers, Peter

Oct. 13, 2013

RE: d3d11 patch

by Max .

Hum... WIR= When it's ready ??? Ok ok, i still wait > From: frederic.delanoy(a)gmail.com > Date: Sun, 13 Oct 2013 01:49:04 +0200 > Subject: Re: d3d11 patch > To: asnlien(a)hotmail.com > CC: wine-devel(a)winehq.org > > On Fri, Oct 11, 2013 at 7:20 PM, Max . <asnlien(a)hotmail.com> wrote: > > Hi, > > > > I would like to know when the first patchs for d3d11 will be introduce into > > wine ? > > Beginning of 2014 ? middle 2014 ? End 2014 ? > > > > Thanks, > > WIR

Oct. 13, 2013

Clang Static analysis

by C.W. Betts

I have been doing a Clang static analysis of Wine on OS X using the one provided at http://clang-analyzer.llvm.org and storing the results on my PogoPlug drive. If someone wants to see the results, please tell me and I'll set up your e-mail. You will need a free PogoPlug account to view them. While the contents are zipped, they expand to about 1.2 GB. They are displayed as basic HTML pages, so you don't need anything special other than a web browser to see the results. Or you could click on this link for the analysis of 1.7.4: http://ppl.ug/ND-7PZ3cSzM/

Oct. 13, 2013

Re: *** GMX Spamverdacht *** MSYS touch.exe timestamp resolution issue on Wine-1.6

by Thorsten Kani

Am 12.10.2013 23:28, schrieb Alan W. Irwin: > Under MSYS bash.exe if I use the touch command I only get 1-second > resolution when reading the results. > > bash.exe-3.1$ touch touch1.test touch2.test > bash.exe-3.1$ ls --full-time touch*.test > -rw-r--r-- 1 wine 544 0 2013-10-12 13:57:58.000000000 -0700 touch1.test > -rw-r--r-- 1 wine 544 0 2013-10-12 13:57:58.000000000 -0700 touch2.test > > Would somebody be willing to make the above test for MSYS on > the Microsoft version of Windows (which I don't have access to) to see > if time stamps are being read with 1-second resolution as above. That > test > should help distinguish whether this is a Wine issue or else an MSYS > issue. > > I have also done some tests with the MSYS find.exe and make.exe > commands, and in all cases touch2.test is not newer than touch1.text. > This can be an important issue for the make command where one-second > time resolution can potentially screw up file dependencies. > > If I use the equivalent Linux ls (and find and make) commands to read the > time stamps on the above files, then touch2.test is newer than > touch1.text, > e.g., > > wine(a)raven> ls --full-time touch*.test > -rw-r--r-- 1 wine wine 0 2013-10-12 13:57:58.391000000 -0700 touch1.test > -rw-r--r-- 1 wine wine 0 2013-10-12 13:57:58.408000000 -0700 touch2.test > > So I think this implies the MSYS touch.exe command is writing > high-resolution (i.e., millisecond) time stamps, and it is only > reading that high-resolution time stamp that seems to be an > issue for MSYS on Wine. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and > Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net) the Time > Ephemerides project (timeephem.sf.net) PLplot scientific plotting > software package (plplot.sf.net) the libLASi project > (unifont.org/lasi) the Loads of Linux Links project (loll.sf.net) > and the Linux Brochure Project (lbproject.sf.net) > __________________________ > > Linux-powered Science > _________________________ Sure -- seems to be a MSYS issue though: root(a)me ~ $ touch touch1 touch2 root(a)me ~ $ ls --full-time touch* -rw-r--r-- 1 root Administratoren 0 2013-10-13 13:33:47.000000000 +0000 touch1 -rw-r--r-- 1 root Administratoren 0 2013-10-13 13:33:47.000000000 +0000 touch2 root(a)me ~ $ uname MINGW32_NT-6.1 root(a)me ~ $ Have a nice Day ! Thorsten

Oct. 13, 2013

Re: mscoree: Add support for ICLRMetaHostPolicy interface

by Dmitry Timoshkov

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > +static HRESULT WINAPI metahostpolicy_QueryInterface(ICLRMetaHostPolicy *iface, REFIID riid, void **ppvObject) > +{ > + TRACE("%s %p\n", debugstr_guid(riid), ppvObject); > + > + if ( IsEqualGUID( riid, &IID_ICLRMetaHostPolicy ) || > + IsEqualGUID( riid, &IID_IUnknown ) ) > + { > + *ppvObject = iface; > + } > + else > + { > + FIXME("Unsupported interface %s\n", debugstr_guid(riid)); > + return E_NOINTERFACE; > + } > + > + ICLRMetaHostPolicy_AddRef( iface ); > + > + return S_OK; > +} I think that a common COM convention is to set the object pointer to NULL in case of an unsupported interface. Also you're doing pretty good job in avoiding hungarian notation except for ppvObject. Another nitpick is the choice for if/else construct (although I understand that other places also use this sub-optimal one). A more elegant way of implementing QueryInterface would be IMHO: static HRESULT WINAPI xxx_QueryInterface(IFace *iface, REFIID riid, void **object) { if (IsEqualGUID(riid, &IID_IUnknown) || IsEqualGUID(riid, &IID_IAnotherSupported) { xxx_AddRef(iface); *object = iface; return S_OK; } *object = NULL; return E_NOINTERFACE; } -- Dmitry.

Oct. 13, 2013

Re: d3d11 patch

by Frédéric Delanoy

On Fri, Oct 11, 2013 at 7:20 PM, Max . <asnlien(a)hotmail.com> wrote: > Hi, > > I would like to know when the first patchs for d3d11 will be introduce into > wine ? > Beginning of 2014 ? middle 2014 ? End 2014 ? > > Thanks, WIR

Oct. 12, 2013