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

Re: Wine Mono 4.5.0 Release

by Alistair Leslie-Hughes

Hi Vincent, Thanks for the update. Time to start breaking (fixing) things again. Best Regards Alistair Leslie-Hughes

Oct. 22, 2013

Wine Mono 4.5.0 Release

by Vincent Povirk

I have published version 4.5.0 of Wine Mono on sourceforge. It's been a little over a year since the last release, and I'm sorry I waited so long to do it. I have also changed the versioning scheme. The major and minor version numbers will now indicate the highest supported .NET runtime version. The source tarball is at https://sourceforge.net/projects/wine/files/Wine%20Mono/4.5.0/wine-mono-4.5… The binary is at https://sourceforge.net/projects/wine/files/Wine%20Mono/4.5.0/wine-mono-4.5… For developers, the source repository is at https://github.com/madewokherd/wine-mono Changes since 0.0.8: * Fixed build on machines using bash as their sh implementation. * .NET Framework directories now include mscorlib.dll (fixes wine bug #31888). * Fixed build on machines running Mac OS X. (Josh DuBois) * Added a security.config file to the .NET 2.0 directory. (Alistair Leslie-Hughes) * Microsoft's Managed C++ compiler sometimes generates broken IL code ending in an unreachable ret statement. This code would be accepted by the .NET runtime but rejected by Mono. Mono is correctly following the spec in this case, but since our goal is compatibility we now accept code that does this. * Building with the -t switch will now build runtime tests. Previously, it only built class library tests. * Added registry keys to indicate the presence of .NET 4.5. * Added user-agent strings to the registry, which allow javascript embedded in web pages to detect .NET. * Updated Mono from 2.11.4 to 3.2.3 plus some additional commits. I'm no longer using Mono's release tags, because they don't seem to help me find revisions that are stable or even buildable. Anyway, here are some highlights of the changes brought in from Mono: * The new 'sgen' garbage collector has been greatly improved and is now the default instead of the old 'boehm' gc, which in our case means it's the only one shipped. It is an improvement over boehm in many ways and should be generally more efficient. * Mono now has support for Portable Class Libraries. * Beginnings of support for System.Windows.Forms.AxHost. (Alistair Leslie-Hughes) * Added support for P/Invoke methods with the thiscall calling convention, which are used by Managed C++ assemblies. * Improved IDispatch interface on managed objects. (Alistair Leslie-Hughes)

Oct. 22, 2013

Re: Mono Update

by Alistair Leslie-Hughes

On 14/10/2013 7:57 PM, Alistair Leslie-Hughes wrote: > Hi, > > wine-mono hasn't been updated in nearly a year. Should it be time to > consider a new release? > Any update to getting a new release? Best Regards Alistair

Oct. 22, 2013

Re: [PATCH] user32/tests: Test SetUserObjectInformation for invisible winstation.

by Qian Hong

Hello, With Francois's great help, I've fixed most winstation failures. There are still some random failures which seems hard to fix, I think the tachyon modulation must be wrongly polarised. <grin> The random failures looks like relating to sleeping time, I'm working hard on designing a new kind of Time Machine to help me debug the winstation issue, well, it would take some time before the machine works... Could I ask for reviewing my later patches first, and fix the remaining random failures later? Thanks! (Seriously, I believe simply increasing the sleeping time would help for the random failures, but I want to either find a better way or find stronger evidence to convince you accept a patch which increasing sleeping time if that's hard to be accepted) On Sat, Oct 12, 2013 at 12:07 AM, Qian Hong <qhong(a)codeweavers.com> wrote: > Hmm... It still fails today. I have a better idea to fix it, will send > a patch tomorrow. Sorry for introducing the failures :( -- Regards, Qian Hong - http://www.codeweavers.com

Oct. 22, 2013

Re: server: Add support for pending write flag to the serial device. Take 2.

by Wolfgang Walter

Am Dienstag, 22. Oktober 2013, 16:55:51 schrieb Alexandre Julliard: > Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > > This patch makes WaitCommEvent(EV_TXEMPTY) work when a serial device > > reports that the out queue is empty even after a successful write() > > which is the case for real COM ports and as well as for serial-USB > > adapters. > > > > Take 2 removes special handling of FlushFileBuffers for a serial sevice, > > the tests show that it really should not reset the pending write state. > > > > I'd like to see some feedback for this patch. > > It doesn't work here: > > ../../../tools/runtest -q -P wine -T ../../.. -M kernel32.dll -p > kernel32_test.exe.so comm.c && touch comm.ok comm.c:860: Test failed: > WaitCommEvent failed with a timeout > comm.c:881: Test failed: WaitCommEvent error 997 > comm.c:882: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 > comm.c:887: Test failed: WaitCommEvent used 1003 ms for waiting > comm.c:2226: Tests skipped: interactive tests (set WINETEST_INTERACTIVE=1) > make: *** [comm.ok] Error 4 This is because the previous test fails: in the previous test wine actually write to the serial device and does not return with ERROR_INVALID_PARAMETER. These 17 bytes also need some time to be written and therefor this test fails with a timeout. I proposed to add a sleep(TIMEOUT) if the previous test does not pass that is the write actually returns success or with error ERROR_IO_PENDING: if (res || (!res && GetLastError() == ERROR_IO_PENDING)) /* if data has been sent: wait for termination */ Sleep(timeout); This has been rejected because then the test passes even without changing the EV_TXEMPTY handling at all. This is because calling WaitCommEvent() while there are still bytes in the tx queue already works. This does not mean that "Add support for pending write flag to the serial device" is not needed. It is needed to correctly signal EV_TXEMPTY if WaitCommEvent() is called later when the tx queue is already empty. I sent a patch (5 Sep) adding an additional test for this case (the patch was named [PATCH 3/6] add another test for waiting for EV_TXEMPTY with WaitCommEvent(), try 2 It was part of a series of patches which implemented someting similar to Dmitry's patch so I hope Dmitry's patch goes in as it actually fixes an important bug. Independently: TIMEOUT is to short anyway for (see my earlier emails and those of Francois Gouget, I attached the latter one). Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts

Oct. 22, 2013

Re: comctl32/tests: Preparation for switching __WINESRC__ on

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=2934 Your paranoid android. === wvista (32 bit listview) === listview.c:5043: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5048: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w2008s64 (32 bit listview) === listview.c:5043: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5048: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w7pro64 (32 bit listview) === listview.c:5043: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5048: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w864 (32 bit listview) === listview.c:5043: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5048: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w2008s64 (64 bit listview) === listview.c:5043: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5048: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w7pro64 (64 bit listview) === listview.c:5043: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5048: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000

Oct. 22, 2013

Re: server: Add support for pending write flag to the serial device. Take 2.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > This patch makes WaitCommEvent(EV_TXEMPTY) work when a serial device > reports that the out queue is empty even after a successful write() > which is the case for real COM ports and as well as for serial-USB > adapters. > > Take 2 removes special handling of FlushFileBuffers for a serial sevice, > the tests show that it really should not reset the pending write state. > > I'd like to see some feedback for this patch. It doesn't work here: ../../../tools/runtest -q -P wine -T ../../.. -M kernel32.dll -p kernel32_test.exe.so comm.c && touch comm.ok comm.c:860: Test failed: WaitCommEvent failed with a timeout comm.c:881: Test failed: WaitCommEvent error 997 comm.c:882: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:887: Test failed: WaitCommEvent used 1003 ms for waiting comm.c:2226: Tests skipped: interactive tests (set WINETEST_INTERACTIVE=1) make: *** [comm.ok] Error 4 -- Alexandre Julliard julliard(a)winehq.org

Oct. 22, 2013

Re: [PATCH 3/3] msvcrt: Don't output __ptr64 when UNDNAME_NO_MS_KEYWORDS is used

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=2929 Your paranoid android. === build (build) === Patch failed to apply

Oct. 22, 2013

Re: [PATCH 2/3] msvcrt: Output ptr64 when UNDNAME_NO_LEADING_UNDERSCORES flag is used

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=2928 Your paranoid android. === build (build) === Patch failed to apply

Oct. 22, 2013

Re: [PATCH 1/3] msvcrt: Add support for UNDNAME_NO_THISTYPE flag in __unDName

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=2927 Your paranoid android. === build (build) === Patch failed to apply

Oct. 22, 2013