Re: ws2/tests: Test AcceptEx with a deferred socket
Mike Kaplinskiy wrote: This tests the following AcceptEx scenario: WSAAccept-CF_DEFER-AcceptEx Windows seems to return the deferred socket with AcceptEx (verified on XP 2K3). Mike. Hi Mike, These new tests fail on all NT4 boxes (some 6 and 1 has 4000+ failures) and what looks like to be all Windows x64_64 systems. The strange thing (or maybe not) is that the errors are the same on all of these (one box has 4000+ failures but still has those same 6). See: http://test.winehq.org/data/tests/ws2_32:sock.html Could you have a look? I can do some tests if necessary on NT4, I don't have a Windows x86_64 system however. -- Cheers, Paul.
Re: Wine very very slow in Chinese language of Linux
On Tue, 14 Jul 2009, axel_...@sohu.com wrote: [...] 1). Reason: Wine uses traditional protocol for communication between client and server, and it seems that iptables is disabled in linux/wine. Action: execute command iptables -I INPUT -s 127.0.0.1 -j ACCEPT That does not sound plausible at all. If lo was firewalled by default, then a lot of non-Wine applications would not be working. Any X application in particular (unless DISPLAY=hostname:0.0 which would be a heresy for a local X display as it would expose it to hacking from the net). You could check the output of 'iptables -L INPUT -v -n' on the default configuration, and also check 'echo $DISPLAY'. 2). Reason: Locale problem, lots of Linux distrubitions use utf-8 for Chinese locale, and wine will firstly try to search/request the utf-8 font sets which do not exisit in ./wine/drive_c/windows/fonts. Then wine will request other font sets that suits other locale(language environment) one by one (image how many languages in the world). Action: Execute command env LANG=en_US wine your_program or env LANG=zh_CN wine your_program, to tell wine which language locale you want to use. (zh_CN is the Chinese locale in Linux) This does not really make sense to me either. My knowledge in this area is pretty superficial, but as far as I know there is no way Wine is enumerating all possible languages trying to match fonts to each language. Point me to the code if I'm wrong. Also, if LANG is not set then you default to the C locale (unless LC_ALL is set) which is the most basic English locale. So if the above was correct, everyone should be experiencing this slow font issue. I don't know enough about points 3 and 4 to comment. -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ If you think the whole world revolves around you, quit staring at the GPS display while driving.
Re: comctl32: Explicitly initialize visible order of a newly added item, force visible order recalculation on redraw.
On Thu, Jul 16, 2009 at 3:34 AM, Dmitry Timoshkovdmi...@codeweavers.com wrote: This patch should fix the regression reported in the bug 19338. --- dlls/comctl32/treeview.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Can you possibly add a testcase for this to prevent further regressions? -- -Austin
Re: comctl32: Explicitly initialize visible order of a newly added item, force visible order recalculation on redraw.
Austin English austinengl...@gmail.com wrote: Can you possibly add a testcase for this to prevent further regressions? As far as I can see that was an existing bug, and it only affects internal treeview item state. -- Dmitry.
Re: suggestions about MacOS DYLD_FALLBACK_LIBRARY_PATH patch
Le 15 juil. 09 à 20:06, Steven Edwards a écrit : On Wed, Jul 15, 2009 at 11:11 AM, Emmanuel Maillardmaha...@free.fr wrote: Since OS X does not provide some of the libraries that we need, should we have a dependency build script that installs those libraries to a standard location (so the users don't need to install MacPorts of Fink just to get Wine) or should we ask them to go mucking with the ~/.bashrc? If we want to provide a Winehq support Wine package for OS X we have to decide on a configuration that will work and be the least invasive to the users when they go to install. That was the goal of Wine.bundle in Darwine. Austin has updated the dependency build script and we've been using it on my box to build the required libraries but they are not together in a bundle, hence the need for the LD_LIBRARY_PATH or DYLD_FALLBACK_LIBRARY_PATH changes. What do you think is the best way to resolve this issue? My interest is that I'd like to provide binary packages of Winehq releases however this issue is a real pain. I suppose we could also provide a support package that is separate from the stock Wine package which would supply the missing libraries or whatnot. If you build your package in standard path (/usr/local for example) you may not need DYLD_FALLBACK_LIBRARY_PATH (see man dyld for default path). If you make a complete bundle for Wine, you'll need it, but it may be set dynamically, while initializing wine lib, see get_runtime_libdir. Now using a bundle or an installer for packing Wine ? IMHO bundles are more friendly to end users. Emmanuel Thanks -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Re: [winhttp] Fix a crash on Vista and higher
On Thu, Jul 16, 2009 at 3:48 PM, Paul Vrienspaul.vriens.w...@gmail.com wrote:
Changelog
Fix a crash on Vista and higher
--
Cheers,
Paul.
From b5e1d29ba2f5d5dd8a74c5b9abb301c0f81a5cb3 Mon Sep 17 00:00:00 2001
From: Paul Vriens paul.vriens.w...@gmail.com
Date: Thu, 16 Jul 2009 15:47:38 +0200
Subject: [PATCH] Fix a crash on Vista and higher
---
dlls/winhttp/tests/winhttp.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/dlls/winhttp/tests/winhttp.c b/dlls/winhttp/tests/winhttp.c
index 78c4777..bce91fe 100644
--- a/dlls/winhttp/tests/winhttp.c
+++ b/dlls/winhttp/tests/winhttp.c
@@ -905,10 +905,14 @@ static void test_set_default_proxy_config(void)
len = get_default_proxy_reg_value( saved_proxy_settings, len, type
);
}
- SetLastError(0xdeadbeef);
- ret = WinHttpSetDefaultProxyConfiguration(NULL);
- ok(!ret GetLastError() == ERROR_INVALID_PARAMETER,
- expected ERROR_INVALID_PARAMETER, got %d\n, GetLastError());
+ if (0)
+ {
+ /* Crashes on Vista and higher */
+ SetLastError(0xdeadbeef);
+ ret = WinHttpSetDefaultProxyConfiguration(NULL);
+ ok(!ret GetLastError() == ERROR_INVALID_PARAMETER,
+ expected ERROR_INVALID_PARAMETER, got %d\n, GetLastError());
+ }
/* test with invalid access type */
info.dwAccessType = 0xdeadbeef;
--
1.6.0.6
Maybe a stupid question, but why do you completely disable the test if
only Vista and up are affected?
Frédéric
Re: [2/3] gdi32/tests: Added tests for StretchBlt
Joel Holdsworth j...@airwebreathe.org.uk writes:
From a08096193c2593e8c99558814472e607696534f6 Mon Sep 17 00:00:00 2001
From: Joel Holdsworth j...@airwebreathe.org.uk
Date: Wed, 15 Jul 2009 22:16:31 +0100
Subject: [PATCH] Added tests for StretchBlt
It doesn't work here:
../../../tools/runtest -q -P wine -M gdi32.dll -T ../../.. -p gdi32_test.exe.so
bitmap.c touch bitmap.ok
bitmap.c:2348: Test succeeded inside todo block: StretchBlt with dwRop 1100A6.
Expected 0x, got 0x from line 2412
bitmap.c:2348: Test failed: StretchBlt with dwRop 5A0049. Expected 0x89D39BDB,
got 0x00D39BDB from line 2417
bitmap.c:2348: Test failed: StretchBlt with dwRop 550009. Expected 0x76543210,
got 0x00543210 from line 2418
bitmap.c:2348: Test failed: StretchBlt with dwRop FF0062. Expected 0x,
got 0x00FF from line 2420
bitmap.c:2361: Test failed: StretchBlt expected { CAFED00D, FEEDFACE, FEDCBA98,
76543210 } got { 00FED00D, 00EDFACE, 00DCBA98, 00543210 } stretching { 0, 0, 2,
2 } to { 0, 0, 2, 2 } from line 2432
bitmap.c:2361: Test failed: StretchBlt expected { CAFED00D, , ,
} got { 00FED00D, , , } stretching { 0, 0, 1,
1 } to { 0, 0, 1, 1 } from line 2437
bitmap.c:2361: Test failed: StretchBlt expected { , , ,
CAFED00D } got { , , , 00FED00D } stretching { 0, 0, 2,
2 } to { 1, 1, 2, 2 } from line 2473
bitmap.c:2361: Test failed: StretchBlt expected { FEDCBA98, 76543210, CAFED00D,
FEEDFACE } got { 00DCBA98, 00543210, 00FED00D, 00EDFACE } stretching { 0, 0, 2,
2 } to { 0, 0, 2, 2 } from line 2487
bitmap.c:2361: Test failed: StretchBlt expected { CAFED00D, FEEDFACE, FEDCBA98,
76543210 } got { 00FED00D, 00EDFACE, 00DCBA98, 00543210 } stretching { 0, 0, 2,
2 } to { 0, 0, 2, 2 } from line 2508
bitmap.c:2361: Test failed: StretchBlt expected { FEDCBA98, 76543210, CAFED00D,
FEEDFACE } got { 00DCBA98, 00543210, 00FED00D, 00EDFACE } stretching { 0, 0, 2,
2 } to { 0, 0, 2, 2 } from line 2527
make: *** [bitmap.ok] Error 10
--
Alexandre Julliard
julli...@winehq.org
Re: [1/2] ws2_32/tests: IPv6 tests for WSAAddressToStringW
Jeff Latimer l...@yless4u.com.au writes: @@ -1542,7 +1556,103 @@ static void test_WSAAddressToStringW(void) ok( !ret, WSAAddressToStringW() failed unexpectedly: %d\n, WSAGetLastError() ); ok( !lstrcmpW( address, expect4 ), Expected different address string\n ); -ok( len == sizeof( expect4 )/sizeof( WCHAR ), Got size %d\n, len); +ok( len == sizeof( expect4 )/sizeof( WCHAR ), Expected size to be %d, got %d\n, sizeof( expect4 )/sizeof( WCHAR ), len); Please don't use sizeof in traces. -- Alexandre Julliard julli...@winehq.org
Re: [winhttp] Fix a crash on Vista and higher
Frédéric Delanoy wrote:
On Thu, Jul 16, 2009 at 3:48 PM, Paul Vrienspaul.vriens.w...@gmail.com wrote:
Changelog
Fix a crash on Vista and higher
--
Cheers,
Paul.
From b5e1d29ba2f5d5dd8a74c5b9abb301c0f81a5cb3 Mon Sep 17 00:00:00 2001
From: Paul Vriens paul.vriens.w...@gmail.com
Date: Thu, 16 Jul 2009 15:47:38 +0200
Subject: [PATCH] Fix a crash on Vista and higher
---
dlls/winhttp/tests/winhttp.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/dlls/winhttp/tests/winhttp.c b/dlls/winhttp/tests/winhttp.c
index 78c4777..bce91fe 100644
--- a/dlls/winhttp/tests/winhttp.c
+++ b/dlls/winhttp/tests/winhttp.c
@@ -905,10 +905,14 @@ static void test_set_default_proxy_config(void)
len = get_default_proxy_reg_value( saved_proxy_settings, len, type
);
}
-SetLastError(0xdeadbeef);
-ret = WinHttpSetDefaultProxyConfiguration(NULL);
-ok(!ret GetLastError() == ERROR_INVALID_PARAMETER,
-expected ERROR_INVALID_PARAMETER, got %d\n, GetLastError());
+if (0)
+{
+/* Crashes on Vista and higher */
+SetLastError(0xdeadbeef);
+ret = WinHttpSetDefaultProxyConfiguration(NULL);
+ok(!ret GetLastError() == ERROR_INVALID_PARAMETER,
+expected ERROR_INVALID_PARAMETER, got %d\n, GetLastError());
+}
/* test with invalid access type */
info.dwAccessType = 0xdeadbeef;
--
1.6.0.6
Maybe a stupid question, but why do you completely disable the test if
only Vista and up are affected?
Frédéric
Sometimes it's easy to deduce the platform and act on it, sometimes it's
not.
I guess it also makes a difference if we are talking about older or
newer platforms. We tend to implement the latest functionality so we
should most of the time cater for differences with older platforms.
--
Cheers,
Paul.
Re: suggestions about MacOS DYLD_FALLBACK_LIBRARY_PATH patch
There's confusion here: The problem here is not with MacPorts or Fink. I have neither of them on my system. Just MacOS, some developer packages from Mac's install DVD, X11User.pkg from this DVD, XQuartz and Wine compiled myself (+ SuspiciousPackage.pkg, admitedly). That's all it takes to run into trouble. Then the issue is that these packages are installed in an appropriate location, one that is not searched when attempting to dynamically load them. This configuration error is not Wine's fault, and even if we worked around it other apps that attempted to load them dynamically would have the same problem. Note that I never said it was the user's fault, but that it's a configuration error. In my opinion the proper place to fix this is in the library installation itself, or in the distribution of Wine. Mike Kronenberg's package does that--cheers, Mike--but it's too different from mainline to be considered stock Wine. A MacOS bundle that addressed this but was built with no patches at all to git Wine would be a lot closer to what I want. --Juan
Re: suggestions about MacOS DYLD_FALLBACK_LIBRARY_PATH patch
On Thu, Jul 16, 2009 at 11:25 AM, Juan Langjuan.l...@gmail.com wrote: Note that I never said it was the user's fault, but that it's a configuration error. In my opinion the proper place to fix this is in the library installation itself, or in the distribution of Wine. Mike Kronenberg's package does that--cheers, Mike--but it's too different from mainline to be considered stock Wine. A MacOS bundle that addressed this but was built with no patches at all to git Wine would be a lot closer to what I want. If this would really be accepted by Winehq then we have that solution. The build script Austin has been developing on my box provides the missing libraries. If we can do releases with it and bundle the missing libraries in our package that will solve a lot of problems. -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
gdiplus errors - how to use a workaround
A few months ago I tried compiling wine without all the dependencies that are downloaded with apt-get build-dep wine. I just used a minimum, as wine asked for them. To my surprise, in Dragon NaturallySpeaking the DragonBar came up very crudely sketched, but all the buttons worked. That hasn't happened since. I was wondering if anyone knew which wine dependencies were responsible for this. As a wild guess, I would imagine that it involves compiling without support for the fancy functions of gdiplus. FYI -- using winetricks gdiplus does not work at all. it makes the program crash.
Re: suggestions about MacOS DYLD_FALLBACK_LIBRARY_PATH patch
On Thu, Jul 16, 2009 at 10:52 AM, Steven Edwardswinehac...@gmail.com wrote: On Thu, Jul 16, 2009 at 11:25 AM, Juan Langjuan.l...@gmail.com wrote: Note that I never said it was the user's fault, but that it's a configuration error. In my opinion the proper place to fix this is in the library installation itself, or in the distribution of Wine. Mike Kronenberg's package does that--cheers, Mike--but it's too different from mainline to be considered stock Wine. A MacOS bundle that addressed this but was built with no patches at all to git Wine would be a lot closer to what I want. If this would really be accepted by Winehq then we have that solution. The build script Austin has been developing on my box provides the missing libraries. If we can do releases with it and bundle the missing libraries in our package that will solve a lot of problems. Yes, bundling those packages should be pretty easy. Joerg pointed out to me privately that libpng and a few others should now fall back to OS X's preinstalled versions, so the script may need updating..I'm not sure what else OS X provides off hand. Of course, those dependencies may conflict with installed software, but without a mac, I can't tell for sure. -- -Austin
Re: New winetricks 20090716: new verbs droid, wenquanyi, dinput8
I have decided against responding to the chinese thread (so much mis-information, ignorance and wrongful entitlement in it, and little substance), but I like to point out that the wenquanyi fonts are shipped with fedora 11. Not sure about fedora 10, but he just needs to upgrade his OS (apparently he is on fedora 10?) to get it, no need to badger the wine people or winetricks. Ubuntu/suse people please comment. --- On Thu, 16/7/09, Dan Kegel d...@kegel.com wrote: Another fortnight, another winetricks. Three new verbs: two fonts (droid, wenquanyi), and one library (dinput8). (dinput8 is a subset of d3dx9 which is a subset of directx9. The fewer native dlls one installs, the better.) Online as always at http://kegel.com/wine/winetricks or http://winezeug.googlecode.com (Bug reports to the issue tracker at the above URL.) Changes since 20090705: r576 | daniel.r.kegel | 2009-07-15 21:42:37 -0700 (Wed, 15 Jul 2009) | 2 lines Release version 20090716. r575 | daniel.r.kegel | 2009-07-15 21:32:32 -0700 (Wed, 15 Jul 2009) | 4 lines Added Droid verb to install Droid fonts. Don't forget to register Wan Quan Yi font. r574 | austinenglish | 2009-07-15 13:30:56 -0700 (Wed, 15 Jul 2009) | 1 line winetricks: Correctly invoke the Shockwave Player installer with msiexec - Patch by Andrew Nguyen r573 | daniel.r.kegel | 2009-07-15 09:00:12 -0700 (Wed, 15 Jul 2009) | 2 lines Added wenquanyi font (requested by Axel Xia) r558 | austinenglish | 2009-07-10 09:25:22 -0700 (Fri, 10 Jul 2009) | 1 line winetricks: add dinput8 verb (Patch by Erik Inge Bolsø) r548 | austinenglish | 2009-07-06 15:40:32 -0700 (Mon, 06 Jul 2009) | 2 lines winetricks: update AutoHotKey to latest version
suggestions about MacOS DYLD_FALLBACK_LIBRARY_PATH patch
Juan Lang wrote: Another way of looking at the error is that MacPorts (and fink, I presume) install libraries to a path that's not searched by default. Perhaps this is what you want, and perhaps not, but that's up to you, not up to Wine. There's confusion here: The problem here is not with MacPorts or Fink. I have neither of them on my system. Just MacOS, some developer packages from Mac's install DVD, X11User.pkg from this DVD, XQuartz and Wine compiled myself (+ SuspiciousPackage.pkg, admitedly). That's all it takes to run into trouble. Kronenberg and MacPorts set DYLD_FALLBACK_*, Fink sets LD_LIBRARY_PATH to work around the issue. it's just an error in your configuration. I strongly disagree. Points can be made that it's either an error A) in Wine or B) at the system level. But it's never C) the user's. Here are the arguments: A) An application whose ./configure manages to detect and use X/FreeType/png, should ensure that those detected paths also work at run-time. Maybe autoconf needs a patch? Maybe there's a need for a winewrapper.in to get filled with the X_LIBS path? B) The Mac must ensure that all X apps work fine at system level - for all users. Not including /usr/X11/lib into the default path looks like a major goof from Apple. Or they should provide means to remember default path (e.g. on Solaris, -Lpath for shared libraries is not only a link-time indication, it's remembered for run-time). I'll look into B) should this issue persist after I'll be back from vacation. Regards, Jörg Höhle
suggestions about MacOS DYLD_FALLBACK_LIBRARY_PATH patch
Juan Lang wrote: Note that I never said it was the user's fault, but that it's a configuration error. In my opinion the proper place to fix this is in the library installation itself, or in the distribution of Wine. Mike Kronenberg's package does that--cheers, Mike-- Note that Mike does it exactly by wrapping the winewrapper in yet another shell script wrapper. My patch aimed at eliminating that wrapper, in order to reduce the diffs between Mike, MacPorts, Fink and stock Git. A MacOS bundle that addressed this but was built with no patches at all to git Wine would be a lot closer to what I want. Emmanuel's post shows that indeed, a solution exist as far as GUI-invocation goes, using this bundle concept. But from what I understand, you'll again run into trouble as soon as you want to use wine the UNIX way: from the command line (e.g. when running automated tests) -- unless one invokes that wrapper, which then calls the official WineHQ winewrapper. Well enough said, I'll study manpages once more after my vacation, and see if there's some system level solution. Regards, Jörg Höhle.
Re: New winetricks 20090716: new verbs droid, wenquanyi, dinput8
2009/7/16 Dan Kegel d...@kegel.com: Another fortnight, another winetricks. Three new verbs: two fonts (droid, wenquanyi), and one library (dinput8). (dinput8 is a subset of d3dx9 which is a subset of directx9. The fewer native dlls one installs, the better.) Wait, does the d3dx9 verb install dinput8? I don't think it should do that.
Re: New winetricks 20090716: new verbs droid, wenquanyi, dinput8
2009/7/16 Hin-Tak Leung hintak_le...@yahoo.co.uk: I have decided against responding to the chinese thread (so much mis-information, ignorance and wrongful entitlement in it, and little substance), but I like to point out that the wenquanyi fonts are shipped with fedora 11. Not sure about fedora 10, but he just needs to upgrade his OS (apparently he is on fedora 10?) to get it, no need to badger the wine people or winetricks. Ubuntu/suse people please comment. On Debian unstable (amd64): $ apt-cache search wenquanyi ttf-wqy-microhei - A droid derived Sans-Seri style CJK font ttf-wqy-zenhei - WenQuanYi Zen Hei A Hei-Ti Style (sans-serif) Chinese font xfonts-wqy - WenQuanYi Bitmap Song CJK font for X
Re: New winetricks 20090716: new verbs droid, wenquanyi, dinput8
(to the list this time) On Fri, Jul 17, 2009 at 1:54 AM, Ben Kleinshackl...@gmail.com wrote: 2009/7/16 Hin-Tak Leung hintak_le...@yahoo.co.uk: I have decided against responding to the chinese thread (so much mis-information, ignorance and wrongful entitlement in it, and little substance), but I like to point out that the wenquanyi fonts are shipped with fedora 11. Not sure about fedora 10, but he just needs to upgrade his OS (apparently he is on fedora 10?) to get it, no need to badger the wine people or winetricks. Ubuntu/suse people please comment. On Debian unstable (amd64): $ apt-cache search wenquanyi ttf-wqy-microhei - A droid derived Sans-Seri style CJK font ttf-wqy-zenhei - WenQuanYi Zen Hei A Hei-Ti Style (sans-serif) Chinese font xfonts-wqy - WenQuanYi Bitmap Song CJK font for X Same on latest (K)unbuntu: $ apt-cache search wenquanyi ttf-wqy-zenhei - WenQuanYi Zen Hei A Hei-Ti Style (sans-serif) Chinese font xfonts-wqy - WenQuanYi Bitmap Song CJK font for X ttf-wqy-microhei - A droid derived Sans-Seri style CJK font Though, only ttf-wgy-zenhei was installed by default on my machine.
Request: Packaging component (or product) for Bugzilla
Alexandre and I were talking on IRC today about what to do with bugs caused by packaging issues. Most of these are bugs in the packages provided by WineHQ.org and not by the distributions proper (who instead ship stable Wine versions). Consequently, users expect to file the bugs in our bug tracker since there's no where else for them to go. However, non-packager Wine developers don't want to see these bugs, as they're frequently just noise and not their problem. But closing them invalid doesn't quite help, since otherwise the problem might not be fixed. That's where the packaging component (or product) comes in - once an issue is deduced to be a packaging error (say, a missing build dep), then it can just be reassigned and the relevant packager auto-subscribed. Thanks, Scott Ritchie
Re: ws2/tests: Test AcceptEx with a deferred socket
Paul,
Does the attached fix test failures on at least NT4? The 4000 test
failures is ok, it's just 3999 of the same failure. The failures are
the same because of a mistake on my part.
I didn't get a chance to test this since my virtualbox is down until a
2.6.31-compatible version of their kernel module is out.
Mike.
On Thu, Jul 16, 2009 at 3:40 AM, Paul Vrienspaul.vriens.w...@gmail.com wrote:
Mike Kaplinskiy wrote:
This tests the following AcceptEx scenario:
WSAAccept-CF_DEFER-AcceptEx
Windows seems to return the deferred socket with AcceptEx (verified on
XP 2K3).
Mike.
Hi Mike,
These new tests fail on all NT4 boxes (some 6 and 1 has 4000+ failures) and
what looks like to be all Windows x64_64 systems. The strange thing (or
maybe not) is that the errors are the same on all of these (one box has
4000+ failures but still has those same 6).
See:
http://test.winehq.org/data/tests/ws2_32:sock.html
Could you have a look?
I can do some tests if necessary on NT4, I don't have a Windows x86_64
system however.
--
Cheers,
Paul.
diff --git a/dlls/ws2_32/tests/sock.c b/dlls/ws2_32/tests/sock.c
index 672c96e..d50eaa0 100644
--- a/dlls/ws2_32/tests/sock.c
+++ b/dlls/ws2_32/tests/sock.c
@@ -2756,8 +2756,7 @@ static void test_AcceptEx(void)
/* Connect socket #1 */
iret = connect(connector, (struct sockaddr*)bindAddress, sizeof(bindAddress));
-ok(iret == 0 ||
-(iret == SOCKET_ERROR WSAGetLastError() == WSAEWOULDBLOCK), connecting to accepting socket failed, error %d\n, WSAGetLastError());
+ok(iret == SOCKET_ERROR WSAGetLastError() == WSAEWOULDBLOCK, connecting to accepting socket failed, error %d\n, WSAGetLastError());
FD_ZERO ( fds_accept );
FD_ZERO ( fds_send );
@@ -2771,15 +2770,17 @@ static void test_AcceptEx(void)
for (i = 0; i 4000; ++i)
{
-wsa_ok ( ( select ( 0, fds_accept, fds_send, NULL, timeout ) ), SOCKET_ERROR !=,
-select_server (%x): select() failed: %d\n );
+fd_set fds_openaccept = fds_accept, fds_opensend = fds_send;
+
+wsa_ok ( ( select ( 0, fds_openaccept, fds_opensend, NULL, timeout ) ), SOCKET_ERROR !=,
+acceptex test(%d): could not select on socket, errno %d\n );
/* check for incoming requests */
-if ( FD_ISSET ( listener, fds_accept ) ) {
+if ( FD_ISSET ( listener, fds_openaccept ) ) {
got++;
if (got == 1) {
SOCKET tmp = WSAAccept(listener, NULL, NULL, (LPCONDITIONPROC) AlwaysDeferConditionFunc, 0);
-ok(tmp == INVALID_SOCKET WSAGetLastError() == WSATRY_AGAIN, Failed to defer connection\n);
+ok(tmp == INVALID_SOCKET WSAGetLastError() == WSATRY_AGAIN, Failed to defer connection, %d\n, WSAGetLastError());
bret = pAcceptEx(listener, acceptor, buffer, 0,
sizeof(struct sockaddr_in) + 16, sizeof(struct sockaddr_in) + 16,
bytesReturned, overlapped);
@@ -2795,14 +2796,14 @@ static void test_AcceptEx(void)
ok(FALSE, Got more than 2 connections?\n);
}
}
-if ( conn1 FD_ISSET ( connector2, fds_send ) ) {
+if ( conn1 FD_ISSET ( connector2, fds_opensend ) ) {
/* Send data on second socket, and stop */
send(connector2, 2, 1, 0);
FD_CLR ( connector2, fds_send );
break;
}
-if ( FD_ISSET ( connector, fds_send ) ) {
+if ( FD_ISSET ( connector, fds_opensend ) ) {
/* Once #1 is connected, allow #2 to connect */
conn1 = 1;
@@ -2810,13 +2811,12 @@ static void test_AcceptEx(void)
FD_CLR ( connector, fds_send );
iret = connect(connector2, (struct sockaddr*)bindAddress, sizeof(bindAddress));
-ok(iret == 0 ||
-(iret == SOCKET_ERROR WSAGetLastError() == WSAEWOULDBLOCK), connecting to accepting socket failed, error %d\n, WSAGetLastError());
+ok(iret == SOCKET_ERROR WSAGetLastError() == WSAEWOULDBLOCK, connecting to accepting socket failed, error %d\n, WSAGetLastError());
FD_SET ( connector2, fds_send );
}
}
-ok (got == 2, Did not get both connections\n);
+ok (got == 2, Did not get both connections, got %d\n, got);
dwret = WaitForSingleObject(overlapped.hEvent, 0);
ok(dwret == WAIT_OBJECT_0, Waiting for accept event failed with %d + errno %d\n, dwret, GetLastError());
@@ -2827,7 +2827,7 @@ static void test_AcceptEx(void)
set_blocking(acceptor, TRUE);
iret = recv( acceptor, buffer, 2, 0);
-ok(iret == 1, Failed to get data, %d\n, iret);
+ok(iret == 1, Failed to get data, %d, errno: %d\n, iret, WSAGetLastError());
ok(buffer[0] == '1', The wrong first client was accepted by acceptex: %c != 1\n, buffer[0]);
