September 2011 - Wine-Devel

Re: [PATCH] comdlg32: Initialize 2 RECT to 0 (Coverity)

by Andrew Talbot

Marcus Meissner wrote: > Hi, > > If the filename and toolbar field are not present, we will be using > uninitialized RECTs, so initialize them. > > CID 5033, 5034 > > Ciao, Marcus > --- > dlls/comdlg32/itemdlg.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/dlls/comdlg32/itemdlg.c b/dlls/comdlg32/itemdlg.c > index bc309c9..d9756c0 100644 > --- a/dlls/comdlg32/itemdlg.c > +++ b/dlls/comdlg32/itemdlg.c > @@ -1106,6 +1106,8 @@ static SIZE update_layout(FileDialogImpl *This) > SIZE ret; > > GetClientRect(This->dlg_hwnd, &dialog_rc); > + memset (&toolbar_rc, 0, sizeof(toolbar_rc)); > + memset (&filename_rc, 0, sizeof(filename_rc)); > > missing_width = max(0, 320 - dialog_rc.right); > missing_height = max(0, 200 - dialog_rc.bottom); Hi Marcus, Instead of using memset(), would it not be better to initialise the RECTs to zero when declaring them, as follows? RECT toolbar_rc = { 0 }; RECT filename_rc = { 0 }; -- Andy.

Sept. 23, 2011

Re: hhctrl.ocx: Don't show unimplemented buttons.

by Owen Rudge

> Could you point me to a link on this behavior? I'm pretty sure that > many of these buttons send a signal that applications can hook into > and override the default (do-nothing) behavior. The documentation for those specific values appears to be non-existent - the latest (as far as I'm aware) HTML Help documentation can be found here: http://www.microsoft.com/download/en/details.aspx?id=21138 Additionally, as Francois mentioned, the HTML Help header files do include some references to unimplemented functionality. -- Owen Rudge http://www.owenrudge.net/

Sept. 23, 2011

Re: hhctrl.ocx: Don't show unimplemented buttons.

by Erich Hoover

> + case IDTB_NOTES: > + case IDTB_CONTENTS: > + case IDTB_INDEX: > + case IDTB_SEARCH: > + case IDTB_HISTORY: > + case IDTB_FAVORITES: > + /* These are officially unimplemented as of the Windows 7 SDK */ > + break; Could you point me to a link on this behavior? I'm pretty sure that many of these buttons send a signal that applications can hook into and override the default (do-nothing) behavior. Erich Hoover ehoover(a)mines.edu

Sept. 23, 2011

Re: [PATCH] comdlg32: Initialize 2 RECT to 0 (Coverity)

by Alexandre Julliard

Marcus Meissner <meissner(a)suse.de> writes: > Hi, > > If the filename and toolbar field are not present, we will be using > uninitialized RECTs, so initialize them. It's not clear that 0 is much better. If there's really a possibility for these things to be missing the layout should take that into account. -- Alexandre Julliard julliard(a)winehq.org

Sept. 23, 2011

Re: dpnet: return a TCP/IP provider in IDirectPlay8PeerImpl_EnumServiceProviders (try 3, resend)

by Bruno Jesus

On Fri, Sep 23, 2011 at 07:50, Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote: > Note: the 2 failing tests on test-bot that this patch will produce, are not real failures as winnt and win2000 will not run the test because of missing dpnet > > try 3: rewrote patch in a more straightforward way > > this makes previously sent tests pass, and fixes crash in bug http://bugs.winehq.org/show_bug.cgi?id=28008 Use the broken macro to skip or expect a different return from the tests that crash in NT and add a comment there. Example: http://source.winehq.org/source/dlls/ole32/tests/usrmarshal.c#L103 Best wishes, Bruno -- universe* god::bigbang (void); //and then it all began...

Sept. 23, 2011

Re: dpnet: return a TCP/IP provider in IDirectPlay8PeerImpl_EnumServiceProviders (try 3, resend)

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 http://testbot.winehq.org/JobDetails.pl?Key=14466 Your paranoid android. === WNT4WSSP6 (32 bit peer) === peer.c:52: Test failed: CoCreateInstance failed with 0x80040154 peer: unhandled exception c0000005 at 004013BC === W2KPROSP4 (32 bit peer) === peer.c:52: Test failed: CoCreateInstance failed with 0x80040154 peer: unhandled exception c0000005 at 004013BC

Sept. 23, 2011

Re: mshtml: Add IHTMLCurrentStyle2/3/4 support

by Alexandre Julliard

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > diff --git a/dlls/mshtml/Makefile.in b/dlls/mshtml/Makefile.in > index 3933645..62a2d6f 100644 > --- a/dlls/mshtml/Makefile.in > +++ b/dlls/mshtml/Makefile.in > @@ -14,6 +14,7 @@ C_SRCS = \ > htmlbody.c \ > htmlcomment.c \ > htmlcurstyle.c \ > + htmlcurstyle2.c \ Please add this to the existing file. There are already way too many source files in this dll. -- Alexandre Julliard julliard(a)winehq.org

Sept. 23, 2011

Re: RFC: Highlighting Fall-throughs

by Michael Stefaniuc

Andrew Talbot wrote: > Andrew Talbot wrote: > >> Alex Bradbury wrote: >> >>> Marking fall through cases sounds reasonable on the face of it to me. >>> I question the necessity of adding 'unaudited' comments though. I'd >>> imagine lint or one of the more sophisticated static analysis tools >>> could pretty easily give you a list of cases with fall-through without >>> a comment marking it as intentional. >>> >>> Alex > > On further reflection, I think you are right. The single comment is enough > on its own. Yes, because you do audit the code when you add it ;) Marcus added a few of those too and fixed some others where the fall through was a bug. bye michael

Sept. 23, 2011

Re: RFC: Highlighting Fall-throughs

by Andrew Talbot

Andrew Talbot wrote: > Alex Bradbury wrote: > >> Marking fall through cases sounds reasonable on the face of it to me. >> I question the necessity of adding 'unaudited' comments though. I'd >> imagine lint or one of the more sophisticated static analysis tools >> could pretty easily give you a list of cases with fall-through without >> a comment marking it as intentional. >> >> Alex > On further reflection, I think you are right. The single comment is enough on its own. Thanks, Alex. -- Andy.

Sept. 23, 2011

Re: RFC: Highlighting Fall-throughs

by Andrew Talbot

Alex Bradbury wrote: > Marking fall through cases sounds reasonable on the face of it to me. > I question the necessity of adding 'unaudited' comments though. I'd > imagine lint or one of the more sophisticated static analysis tools > could pretty easily give you a list of cases with fall-through without > a comment marking it as intentional. > > Alex I wondered if people seeing just a plain fall-through comment would assume that it had been placed there by someone familiar with the code to indicate that it was intentional and correct. Whereas, I may have placed it there not necessarily knowing, or being able to discern, whether the programmer had intended that behaviour or not. (Indeed, the absence of a comment in the first place might be indicative of an oversight.) So I thought that marking it as unverified in some way might be helpful. -- Andy.

Sept. 22, 2011

Re: RFC: Highlighting Fall-throughs

by Alex Bradbury

On 22 September 2011 22:20, Andrew Talbot <Andrew.Talbot(a)talbotville.com> wrote: > I therefore propose to mark each new point with two comments (maybe > separate, maybe combined): one to state that fall-through occurs and the > other to point out that the validity of this particular fall-through has not > yet been checked, maybe something like: Marking fall through cases sounds reasonable on the face of it to me. I question the necessity of adding 'unaudited' comments though. I'd imagine lint or one of the more sophisticated static analysis tools could pretty easily give you a list of cases with fall-through without a comment marking it as intentional. Alex

Sept. 22, 2011

RFC: Highlighting Fall-throughs

by Andrew Talbot

Hi All, I am thinking of marking any unmarked places in switch statements where fall-through occurs. However, simply to do so would be to ignore the question of whether each fall-through is intentional or an oversight. I therefore propose to mark each new point with two comments (maybe separate, maybe combined): one to state that fall-through occurs and the other to point out that the validity of this particular fall-through has not yet been checked, maybe something like: select(x) { case 1: foo(); break; case 2: bar(); /* fall through */ /* unaudited */ default: baz(); } Is this all good, or is there a better way? Thanks, -- Andy.

Sept. 22, 2011

Re: comctl32: Fix going to today with multiple calenders

by Nikolay Sivov

On 9/23/2011 00:22, André Hentschel wrote: > Am 22.09.2011 22:17, schrieb Nikolay Sivov: >> On 9/23/2011 00:03, André Hentschel wrote: >>> --- >>> dlls/comctl32/monthcal.c | 4 +--- >>> 1 files changed, 1 insertions(+), 3 deletions(-) >>> >>> diff --git a/dlls/comctl32/monthcal.c b/dlls/comctl32/monthcal.c >>> index 5f8a36c..b330871 100644 >>> --- a/dlls/comctl32/monthcal.c >>> +++ b/dlls/comctl32/monthcal.c >>> @@ -1970,9 +1970,7 @@ MONTHCAL_RButtonUp(MONTHCAL_INFO *infoPtr, LPARAM lParam) >>> if( TrackPopupMenu(hMenu, TPM_RIGHTBUTTON | TPM_NONOTIFY | TPM_RETURNCMD, >>> menupoint.x, menupoint.y, 0, infoPtr->hwndSelf, NULL)) >>> { >>> - infoPtr->calendars[0].month = infoPtr->todaysDate; >>> - infoPtr->minSel = infoPtr->todaysDate; >>> - infoPtr->maxSel = infoPtr->todaysDate; >>> + MONTHCAL_SetCurSel(infoPtr,&infoPtr->todaysDate); >>> InvalidateRect(infoPtr->hwndSelf, NULL, FALSE); >>> } >>> >> This is wrong, it lacks notification calls and you have unneeded invalidate call left. Also similar case remains to be fixed. >> Actually I planned to work on this tomorrow, including some other issues I just spotted. >> >> > i just thought i give multi monthcal a try and spottet that. the fix didn't broke the tests so i didn't thought about notification calls and i resent a fix for the invalidaterect right after try 1... > If you already have plans for that i'll be fine. > No, I'm all for test it as hard as possible, I just want send a bunch before a weekend. If you find something else please contact me.

Sept. 22, 2011

Re: comctl32: Fix going to today with multiple calenders

by André Hentschel

Am 22.09.2011 22:17, schrieb Nikolay Sivov: > On 9/23/2011 00:03, André Hentschel wrote: >> --- >> dlls/comctl32/monthcal.c | 4 +--- >> 1 files changed, 1 insertions(+), 3 deletions(-) >> >> diff --git a/dlls/comctl32/monthcal.c b/dlls/comctl32/monthcal.c >> index 5f8a36c..b330871 100644 >> --- a/dlls/comctl32/monthcal.c >> +++ b/dlls/comctl32/monthcal.c >> @@ -1970,9 +1970,7 @@ MONTHCAL_RButtonUp(MONTHCAL_INFO *infoPtr, LPARAM lParam) >> if( TrackPopupMenu(hMenu, TPM_RIGHTBUTTON | TPM_NONOTIFY | TPM_RETURNCMD, >> menupoint.x, menupoint.y, 0, infoPtr->hwndSelf, NULL)) >> { >> - infoPtr->calendars[0].month = infoPtr->todaysDate; >> - infoPtr->minSel = infoPtr->todaysDate; >> - infoPtr->maxSel = infoPtr->todaysDate; >> + MONTHCAL_SetCurSel(infoPtr,&infoPtr->todaysDate); >> InvalidateRect(infoPtr->hwndSelf, NULL, FALSE); >> } >> > This is wrong, it lacks notification calls and you have unneeded invalidate call left. Also similar case remains to be fixed. > Actually I planned to work on this tomorrow, including some other issues I just spotted. > > i just thought i give multi monthcal a try and spottet that. the fix didn't broke the tests so i didn't thought about notification calls and i resent a fix for the invalidaterect right after try 1... If you already have plans for that i'll be fine. -- Best Regards, André Hentschel

Sept. 22, 2011

Re: comctl32: Fix going to today with multiple calenders

by Nikolay Sivov

On 9/23/2011 00:03, André Hentschel wrote: > --- > dlls/comctl32/monthcal.c | 4 +--- > 1 files changed, 1 insertions(+), 3 deletions(-) > > diff --git a/dlls/comctl32/monthcal.c b/dlls/comctl32/monthcal.c > index 5f8a36c..b330871 100644 > --- a/dlls/comctl32/monthcal.c > +++ b/dlls/comctl32/monthcal.c > @@ -1970,9 +1970,7 @@ MONTHCAL_RButtonUp(MONTHCAL_INFO *infoPtr, LPARAM lParam) > if( TrackPopupMenu(hMenu, TPM_RIGHTBUTTON | TPM_NONOTIFY | TPM_RETURNCMD, > menupoint.x, menupoint.y, 0, infoPtr->hwndSelf, NULL)) > { > - infoPtr->calendars[0].month = infoPtr->todaysDate; > - infoPtr->minSel = infoPtr->todaysDate; > - infoPtr->maxSel = infoPtr->todaysDate; > + MONTHCAL_SetCurSel(infoPtr,&infoPtr->todaysDate); > InvalidateRect(infoPtr->hwndSelf, NULL, FALSE); > } > This is wrong, it lacks notification calls and you have unneeded invalidate call left. Also similar case remains to be fixed. Actually I planned to work on this tomorrow, including some other issues I just spotted.

Sept. 22, 2011

Re: Fwd: 79194: [PATCH 10/13] vbscript: Added CreateObject implementation

by Jacek Caban

On 9/22/11 6:47 PM, Dan Kegel wrote: > Didn't build here, did you forget to add dependency on ole32? > Yes, I did. Sorry about that and thanks for the report. Jacek

Sept. 22, 2011

Fwd: 79194: [PATCH 10/13] vbscript: Added CreateObject implementation

by Dan Kegel

Didn't build here, did you forget to add dependency on ole32? ccache gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O0 -Werror -Wno-unused-but-set-variable -Wno-unused-but-set-parameter -o vwin32.o vwin32.c global.o: In function `create_object': /home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/vbscript/global.c:74: undefined reference to `CLSIDFromProgID' /home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/vbscript/global.c:92: undefined reference to `CoGetClassObject' /home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/vbscript/global.c:114: undefined reference to `CoTaskMemFree' collect2: ld returned 1 exit status winegcc: ccache failed make[1]: *** [vbscript.dll.so] Error 2 ---------- Forwarded message ---------- From: <buildbot(a)kegel.com> Date: Thu, Sep 22, 2011 at 8:01 AM Subject: Re: 79194: [PATCH 10/13] vbscript: Added CreateObject implementation To: dank(a)kegel.com This is an experimental automated build and test service. Please feel free to ignore this email while we work the kinks out. For more info about this message, see http://wiki.winehq.org/BuildBot The Buildbot has detected a failed build on builder runtests-default while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests-default/builds/26 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) BUILD FAILED: failed shell_2 Errors: make: *** [dlls/vbscript] Error 2

Sept. 22, 2011

Re: IPv6 issue on TestBot?

by Maarten Lankhorst

Hey, On 09/22/2011 04:54 PM, Michael Stefaniuc wrote: > Per Johansson wrote: >> 22 sep 2011 kl. 12:14 skrev Michael Stefaniuc: >> >>> Wow! /66? And that works? While the standard allows for that you "should >>> use /64" which everybody and his dog read it as that is the only thing >>> that needs to work and the only thing that get tested. IPv6 brings back >>> the class-full thinking which everybody has to painfully unlearn once >>> IPv6 catches on... >>> >>> "Safe" prefix length (especially if involving client devices) are: >>> /64 - LAN >>> /126 and /127 - point to point >>> /128 - host routes >> RFC3513 is quite more strict than "should": > Which is obsoleted by RFC4291, but that seems to have kept this > paragraph. Anyway the correct RFC term to make it mandatory is "must". > And it isn't a "must". Also the RFC4291 is from 2006 which is *old*. > >> All global unicast addresses other than those that start with binary >> 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as >> described in section 2.5.1. Global unicast addresses that start with >> binary 000 have no such constraint on the size or structure of the >> interface ID field. >> >> (2001:: has the binary prefix 001). So this might very well be the problem. > The same RFC4291 says: > Except for the knowledge of the subnet boundary discussed in the > previous paragraphs, nodes should not make any assumptions about the > structure of an IPv6 address. > > It might be the problem but not because of the RFC; it just might be a > typo as it is a manually set IP. > >> I've heard the reason for 64 bits is that it's what currently fits in most computer registers, but I don't know if it's true. > What really helps to understand IPv6 is: > - IPv6 is an old protocol >15 years. That predates the Internet taking over. > - IPv6 was designed based on the assumption that it will make the > Internet again a friendly, warm and cozy place; a big any to any network > without barriers/firewalls. > - IPv6 isn't better than IPv4, it is different. > - IPv4 still outperforms IPv6 in the new feature development. IPv6 is > trying to play catch up. A few things that were long ago deprecated in > IPv4 are still mandatory for IPv6 to be "standards compliant". > - Don't assume that if the IPv6 standard says something the > implementations really follow that. Test, test, test. > > So no, the /64 host part has nothing to do with current hosts having > 64bit registers now. I'm pretty sure that they were hoping to have > 128bit computers by now. It had more to do with thinking that a globally > unique identifier for the host is a good think to have and the MAC > address already provided that with 48bits. But 48 isn't a nice number so > it was rounded up to 64 which makes for a nice "design" as it is half of > the IPv6 address. > Discussion aside, seems that using /64 works, so I'm keeping that. With the change testbot.winehq.org works again when using ipv6. I am not sure why it was set to /66, so I just hope nothing breaks as a result of this change. ~Maarten

Sept. 22, 2011

Re: [PATCH 12/13] vbscript: Added CreateObject tests (based on jscript ActiveXObject tests)

by Jacek Caban

> === WNT4WSSP6 (32 bit createobj) === > createobj.c:734: Test failed: CoCreateInstance failed: 80040154 > createobj: unhandled exception c0000005 at 00402A21 These tests fail because testbot runs them regardless that vbscript.dll is not present on the machine. Jacek

Sept. 22, 2011

Re: IPv6 issue on TestBot?

by Michael Stefaniuc

Per Johansson wrote: > 22 sep 2011 kl. 12:14 skrev Michael Stefaniuc: > >> Wow! /66? And that works? While the standard allows for that you "should >> use /64" which everybody and his dog read it as that is the only thing >> that needs to work and the only thing that get tested. IPv6 brings back >> the class-full thinking which everybody has to painfully unlearn once >> IPv6 catches on... >> >> "Safe" prefix length (especially if involving client devices) are: >> /64 - LAN >> /126 and /127 - point to point >> /128 - host routes > > RFC3513 is quite more strict than "should": Which is obsoleted by RFC4291, but that seems to have kept this paragraph. Anyway the correct RFC term to make it mandatory is "must". And it isn't a "must". Also the RFC4291 is from 2006 which is *old*. > All global unicast addresses other than those that start with binary > 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as > described in section 2.5.1. Global unicast addresses that start with > binary 000 have no such constraint on the size or structure of the > interface ID field. > > (2001:: has the binary prefix 001). So this might very well be the problem. The same RFC4291 says: Except for the knowledge of the subnet boundary discussed in the previous paragraphs, nodes should not make any assumptions about the structure of an IPv6 address. It might be the problem but not because of the RFC; it just might be a typo as it is a manually set IP. > I've heard the reason for 64 bits is that it's what currently fits in most computer registers, but I don't know if it's true. What really helps to understand IPv6 is: - IPv6 is an old protocol >15 years. That predates the Internet taking over. - IPv6 was designed based on the assumption that it will make the Internet again a friendly, warm and cozy place; a big any to any network without barriers/firewalls. - IPv6 isn't better than IPv4, it is different. - IPv4 still outperforms IPv6 in the new feature development. IPv6 is trying to play catch up. A few things that were long ago deprecated in IPv4 are still mandatory for IPv6 to be "standards compliant". - Don't assume that if the IPv6 standard says something the implementations really follow that. Test, test, test. So no, the /64 host part has nothing to do with current hosts having 64bit registers now. I'm pretty sure that they were hoping to have 128bit computers by now. It had more to do with thinking that a globally unique identifier for the host is a good think to have and the MAC address already provided that with 48bits. But 48 isn't a nice number so it was rounded up to 64 which makes for a nice "design" as it is half of the IPv6 address. bye michael

Sept. 22, 2011

Re: IPv6 issue on TestBot?

by Ben Peddell

On 22/09/2011 9:43 PM, Per Johansson wrote: > > 22 sep 2011 kl. 12:14 skrev Michael Stefaniuc: > >> Wow! /66? And that works? While the standard allows for that you "should >> use /64" which everybody and his dog read it as that is the only thing >> that needs to work and the only thing that get tested. IPv6 brings back >> the class-full thinking which everybody has to painfully unlearn once >> IPv6 catches on... >> >> "Safe" prefix length (especially if involving client devices) are: >> /64 - LAN >> /126 and /127 - point to point >> /128 - host routes > > RFC3513 is quite more strict than "should": > > All global unicast addresses other than those that start with binary > 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as > described in section 2.5.1. Global unicast addresses that start with > binary 000 have no such constraint on the size or structure of the > interface ID field. > > (2001:: has the binary prefix 001). So this might very well be the problem. If I understand that correctly, if the interface has a hardware address (48-bit MAC or 64-bit EUI), then the interface ID should be constructed from that address. Of course, if you are the administrator of the 2001:888:2000:38::/64 block, then you can assign Scope-Local Interface IDs as you see fit, just as everyone else does, and as allowed in RFC3513 2.5.1 - however, the RFCs say the subnet mask needs to be /64. -- Ben Peddell IT Support Bowen, Collinsville, Proserpine and Home Hill Catholic schools http://klightspeed.killerwolves.net/

Sept. 22, 2011

Re: Tests failing on OSX

by Ken Thomases

On Sep 22, 2011, at 4:49 AM, Francois Gouget wrote: > On Wed, 21 Sep 2011, Charles Davis wrote: > [...] >>> I also wondered if Xquartz brings it's own X11 headers and libraries. I >>> haven't found any, so I'm still using /usr/X11/include and /usr/X11/bin. >> Xquartz puts its include and lib files in /opt/X11/include and /opt/X11/lib, respectively. > > That does not sound right. I have installed XQuartz 2.6.1 on my Leopard > machine and I have no /opt/X11 directory. In fact I don't really know > where XQuartz installed itself. I suspect it overwrote the files in > /usr/X11. XQuartz installs differently on Leopard vs. later versions of the OS. On Leopard, it was considered the upgrade path for the built-in X11, so it does replace it. On later versions of the OS, the built-in X11 is considered a system component which is only upgraded by Software Update, and then only rarely for things like security updates. It's intended to be a stable component of the system. XQuartz installs in a separate location, /opt/X11, so as not to interfere with the built-in X11 or anything which relies on it. -Ken

Sept. 22, 2011

Re: [PATCH 12/13] vbscript: Added CreateObject tests (based on jscript ActiveXObject tests)

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 http://testbot.winehq.org/JobDetails.pl?Key=14455 Your paranoid android. === WNT4WSSP6 (32 bit createobj) === createobj.c:734: Test failed: CoCreateInstance failed: 80040154 createobj: unhandled exception c0000005 at 00402A21

Sept. 22, 2011

Re: [PATCH 07/13] vbscript: Added exit for statement support

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 http://testbot.winehq.org/JobDetails.pl?Key=14454 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

Sept. 22, 2011

Re: [PATCH 06/13] vbscript: Added for..in statement tests

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 http://testbot.winehq.org/JobDetails.pl?Key=14453 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

Sept. 22, 2011