Re: Fixing the conformance tests
On Saturday 06 September 2008 22:21:15 James Hawkins wrote: Tests that fail on Windows and succeed on Wine == - ws2_32:sock has 1 consistent failure on all Windows boxes but not on Wine Last attempt got no comments: http://winehq.org/pipermail/wine-patches/2008-May/054547.html Actually, Alexandre commented on this on IRC. I don't really recall his comment, but he didn't like the approach. I'll have some time to look into this again tomorrow, but I remember I quit posting new patches to this as I was out of ideas on how to fix it. A couple of bug reports seem to be related to this, I need to dig around some more. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: crypt32: fixed the testGetCertChain tests on Vista.
On Mon, Sep 8, 2008 at 4:41 AM, James Hawkins [EMAIL PROTECTED] wrote: On Mon, Sep 8, 2008 at 4:38 AM, Markus Hitter [EMAIL PROTECTED] wrote: Am 08.09.2008 um 01:30 schrieb James Hawkins: For example, the following is significantly easier to read: ok(result == ERROR_BUFFER_TOO_SMALL || result == ERROR_INVALID_USER_BUFFER || /* win98 */ result == ERROR_INVALID_DATA, /* Vista */ Expected ERROR_BUFFER_TOO_SMALL, got %08d\n, result); Wouldn't it be even better to print the expected number in the same format as the actually received result? Yes, the %08d should just be %dI just copied the first example I could find in my git log. I'm sorry, I thought you were asking about the %08d i.e. the format of the value. My answer to your actual question is no as explained in my previous email. -- James Hawkins
Re: winemenubuilder: eliminate wineshelllink
Francois Gouget [EMAIL PROTECTED] writes: What is the rational for eliminating wineshelllink? It seems to me that by eliminating it we are losing a lot of flexibility for handling special setups (and there are a lot of these in menuing systems). We don't gain much flexibility by splitting functionality in a C half and a shell half, but it adds a lot of complexity and an ill-defined interface. The original design was to do everything in shell but that turns out to not be possible, so doing everything in C is the next best choice. -- Alexandre Julliard [EMAIL PROTECTED]
Re: dsound: fix a few failing tests and a crash on 2008
On Mon, Sep 8, 2008 at 5:22 PM, Paul Vriens [EMAIL PROTECTED] wrote: Jeff Zaroyko wrote: I found more or less the same thing for Vista a few days ago. Doing a IDirectSoundBuffer_Release sets the reference counter to zero but doesn't clear secondary. Is this something worthwhile to add a comment for (or a test)? It does seem important as it's a change of behavior starting with Vista? -- Cheers, Paul. I've tested this on 95, 2003 and 2008 none of them appear to clear secondary on Release. The crash occurs on 2008 when the tests that are expected to fail on other platforms succeed, since secondary is not NULL in the next check to see if the buffer needs to be released it attempts to release an already released buffer. Initializing secondary to NULL before each test gives some consistency. I don't think any further comment or test case is necessary. Jeff
Re: user32: Resend Check for NULL pData in DdeClientTransAction expectingto be passed a handle
Dmitry Timoshkov wrote:
+if (pData == NULL)
+{
+if (cbData == (DWORD)-1)
+pConv-instance-lastError = DMLERR_INVALIDPARAMETER;
+else
+pConv-instance-lastError = DMLERR_MEMORY_ERROR;
+return NULL;
+}
Alexandre suggested to use the existing 'if (cbData == (DWORD)-1)' block,
not introduce a new one.
True, though when looking how we handle invalid parameters in most other
code, the check is upfront where possible and return is as quickly as
possible. In this case it looks a lot cleaner and more understandable
to put in the extra block rather than to work it into the logic. It
looks like more elses and I would have to handle the
WDML_AllocTransaction as it is not be needed if pData was NULL. It
seems to complicate the logic and I don't see the benefit.
The formatting of the above block is strange. Set the tab size in your
editor to 8 and you will see the mess.
True, I generally use 4 for the tabstop but I can fix that.
Jeff
Re: crypt32: fixed the testGetCertChain tests on Vista.
Am 08.09.2008 um 01:30 schrieb James Hawkins: For example, the following is significantly easier to read: ok(result == ERROR_BUFFER_TOO_SMALL || result == ERROR_INVALID_USER_BUFFER || /* win98 */ result == ERROR_INVALID_DATA, /* Vista */ Expected ERROR_BUFFER_TOO_SMALL, got %08d\n, result); Wouldn't it be even better to print the expected number in the same format as the actually received result? ... Expected ERROR_BUFFER_TOO_SMALL (%08d), got %08d\n, ERROR_BUFFER_TOO_SMALL, result); This should ease log reading as well. MarKus
Re: crypt32: fixed the testGetCertChain tests on Vista.
On Mon, Sep 8, 2008 at 4:38 AM, Markus Hitter [EMAIL PROTECTED] wrote: Am 08.09.2008 um 01:30 schrieb James Hawkins: For example, the following is significantly easier to read: ok(result == ERROR_BUFFER_TOO_SMALL || result == ERROR_INVALID_USER_BUFFER || /* win98 */ result == ERROR_INVALID_DATA, /* Vista */ Expected ERROR_BUFFER_TOO_SMALL, got %08d\n, result); Wouldn't it be even better to print the expected number in the same format as the actually received result? Yes, the %08d should just be %dI just copied the first example I could find in my git log. ... Expected ERROR_BUFFER_TOO_SMALL (%08d), got %08d\n, ERROR_BUFFER_TOO_SMALL, result); This should ease log reading as well. I don't see how that would help. The decimal values of error constants aren't related in a meaningful way. If you want to know the decimal value of ERROR_BUFFER_TOO_SMALL, grep include/winerror.h. -- James Hawkins
Re: imm32: Improve ImmGetCompositionString.
So I have been banging my head against this test for a few weeks now. There are just so many variables, what IME is on the windows box, what locale is set, and such. This all changes the behavior in a way that it is a headache to write a test that will demonstrate the behavior this fixes and also work on all the boxes (windows and wine) out there. I can write a test that will already pass for almost everyone except for those people in a multibyte locale that demonstrates the issue (such as Japanese). Would that be an acceptable test? Then the patch will correct the issue for those locales as it should. -aric Paul Vriens wrote: Aric Stewart wrote: It should return number of copied bytes. But it always returns required buffer size to receive all information. (originally by Kusanagi Kouichi ([EMAIL PROTECTED]) ) --- dlls/imm32/imm.c | 207 ++ 1 files changed, 130 insertions(+), 77 deletions(-) Shouldn't patches like these be accompanied by tests? It changes the behavior after all.
Peb-BeingDebugged and a debugger messing up
Hello all, after wrestling severals days with Wine's debugging capabilities I think I need some advice. First, regardless wether my app (Catia) is launched with wine or winedbg, Peb-BeingDebugged is always False. To the best of my efforts I can't find the code snippet which sets this variable or does some sort of probing for the correct value. Oddly enough, the app breaks into the debugger after creation of a new process, anyways. As the app uses a launcher, I have the chance to set BeingDebugged explicitely to True. Some time later, after the app created a few threads, it's back to False. Are there applications out there setting this flag to what they think is best? Any other possible reasons for going BeingDebugged back to False while running in winedbg? None of the functions Wine provides and handles this variable appears to be called by the application. Third thing is, Wine's attempt to auto-launch the debugger messes up. Not only if BeingDebugged is reported wrongly, it obviously runs in conflicts if launched due to a exception stack overflow. Is it really wise to launch it by triggering an interrupt in DbgBreakPoint()? Short of better suggestions, I'd try to make debugger launching independent from Peb-BeingDebugged (server/kernel should know better), try to get rid of the interrupt in DbgBreakPoint() and/or make debugger autolaunching optional (at compile time). What do you think? Thanks, MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: wined3d: Add support for updating part of a compressed surface.
Thanks for the input, I really should have realised my approach was incorrect as soon as I saw that DXT textures are in blocks. I'm not quite sure how to go about writing a test case, would I just have to create and update surface(s) and check that the resulting surface(s) have been updated correctly? also, there is another patch coming that can be ignored (I missed some variable name changes that caused my patch to fail to compile), not sure why my mails are showing up late on the mailing list (I am subscribed). Henri Verbeet wrote: 2008/9/5 Christof Sigel [EMAIL PROTECTED]: +/* since DXT compressed formats are specified in 4x4 pixel blocks devide pitch by 4 */ +int srcPitch=srcLockedRect.Pitch2; +int destPitch=destLockedRect.Pitch2; That will break with DXT1 surfaces. All the DXT formats are specified in 4x4 blocks, but for DXT1 a 4x4 block is 8 bytes, while for the other DXT formats a block is 16 bytes. This also has implications for how you should handle copying row by row, since each row is 4 pixels high. Strictly speaking you should also verify that the pitch exactly corresponds to the surface width before using the single memcpy path, since theory the surface layout in memory could look like this: |width---| |---pitch| |--| | | | | |surface | | | | | | | |--| In other words, for a DXT1 surface with height h, width w and pitch p, you should copy h/4 rows of w*2 bytes, where each row starts at pBits+p*row. For DXT2/3/4/5 you'd copy w*4 bytes for each row. A test for this code would be appreciated.
Re: wined3d: Add support for updating part of a compressed surface.
2008/9/6 Christof Sigel [EMAIL PROTECTED]: Thanks for the input, I really should have realised my approach was incorrect as soon as I saw that DXT textures are in blocks. I'm not quite sure how to go about writing a test case, would I just have to create and update surface(s) and check that the resulting surface(s) have been updated correctly? Pretty much.
Wine mouse input: Fwd: [RFC] Preliminary XI 2 feature list
Hi all, Today Peter Hutterer posted a preliminary feature list of Xinput 2. I have forwarded the email to here so that Vitaly and others can check it out and see if it offers what we need in Wine. If you have comments I would send them to the xorg list. Regards, Roderick Colenbrander --- Xorg mail --- Subject: [RFC] Preliminary XI 2 feature list Following XDS, various notes, the discussions and preliminary executive decisions by me, here's a first draft of XI2 features. If you have anything to add, please speak up. Time-line: I'd like to get it into server 1.6 but it doesn't look particularly likely. 7.5 is more likely. - Compatibility with XI 1.x, although some requests will be deactivated or of limited functionality. - 16 bit device IDs - All events available as XGE events. - Event selection through event masks (instead or in addition to the event classes). i.e. the common cases of select from all devices and select from all master devices will be simplified. - Devices may have relative + absolute axes simultaneously, and change the mode on any of these axes at runtime. - Relative coordinates as a separate event. - 32 bit keycodes (reliant on XKB2) - ListInputDevices will include the currently attached Slave - Axis and button labelling through device properties. - subpixel resolution (from relative devices) available to clients. i.e. you get the data in screen coordinates, but with subpixel resolution available as fixed floating point. - no window access protocol, this will be thrown out. - dynamic device classes - device may add/remove classes at runtime. - aspect-ratio scaling of valuators. Probable implementation details: - libXi: namespacing: i.e. Xdosomething will be XIdosomething - server-internal use of XGE events, XI 1.x events emulated when needed. - some standardisation on axis label Atom names. - Clients have to announce XI2 support, otherwise they will be treated as XI 1.x clients. Once the feature discussion is complete, I'll get a protocol spec out. Cheers, Peter ___ xorg mailing list [EMAIL PROTECTED] http://lists.freedesktop.org/mailman/listinfo/xorg -- Pt! Schon das coole Video vom GMX MultiMessenger gesehen? Der Eine für Alle: http://www.gmx.net/de/go/messenger03
Patchwatcher security improvements
Hi, I've abandoned my chroot aproach to improving security in patchwatcher. Instead I've implemented the ability to run untrusted code as a user different than the one running patchwatcher. This is because creating a chroot where Wine could be compiled and tested proved to be too difficult and platform-dependent. I've also added external time limits for running untrusted code. This as a whole should help prevent individual patches from stalling the patch watching process. It very easy to set up. All you need is a low-privileged user (but enough to run the tests, e.g. audio, video groups) and an empty folder where you can write but this user can only read (not your home folder, it shouldn't have access there anyway). To use it, start with a clean patchwatcher and adjust the variables in the patchwatcher.sh, then run patchwatcher.sh intialize. It will instruct you to run some commands as root (setuid the wrapper). Run initialize again and it should build wine and run baseline tests. Then you can test it by putting a patch in patches/ and issuing the try_one_patch command. To start watching use the continuous_build command. Patch is attached. patchwatcher-crossuser10.patch.bz2 Description: application/bzip
Re: [1/5] secur32: Require gnutls for schannel
On Mon, Sep 08, 2008 at 11:10:11PM +0200, Henri Verbeet wrote: From cb10664e7d7526951d97f6d9ba2f7429d20b69d4 Mon Sep 17 00:00:00 2001 From: Henri Verbeet [EMAIL PROTECTED] Date: Mon, 8 Sep 2008 22:39:11 +0200 Subject: secur32: Require gnutls for schannel +AC_ARG_WITH(gnutls,AS_HELP_STRING([--without-gnutls],[do not use GnuTLS (schannel support)])) Hmm, I really do not think gnutls will have a long feature, NSS seems to be the future choice of crypto frameworks :/ Ciao, Marcus
Re: [1/5] secur32: Require gnutls for schannel
On Mon, Sep 8, 2008 at 2:26 PM, Marcus Meissner [EMAIL PROTECTED] wrote: On Mon, Sep 08, 2008 at 11:10:11PM +0200, Henri Verbeet wrote: From cb10664e7d7526951d97f6d9ba2f7429d20b69d4 Mon Sep 17 00:00:00 2001 From: Henri Verbeet [EMAIL PROTECTED] Date: Mon, 8 Sep 2008 22:39:11 +0200 Subject: secur32: Require gnutls for schannel +AC_ARG_WITH(gnutls,AS_HELP_STRING([--without-gnutls],[do not use GnuTLS (schannel support)])) Hmm, I really do not think gnutls will have a long feature, NSS seems to be the future choice of crypto frameworks :/ Ciao, Marcus s/feature/future/ ?
Re: [1/5] secur32: Require gnutls for schannel
2008/9/8 Marcus Meissner [EMAIL PROTECTED]: Hmm, I really do not think gnutls will have a long feature, NSS seems to be the future choice of crypto frameworks :/ Ciao, Marcus I did have a look at NSS, but didn't see a way to make it work with a simple buffer, which makes in impractical to use for schannel. Perhaps I missed something there though. Another option would of course be to implement TLS ourselves, it's not all that complicated actually.
Re: [1/5] secur32: Require gnutls for schannel
On Mon, Sep 08, 2008 at 02:36:36PM -0700, Lei Zhang wrote: On Mon, Sep 8, 2008 at 2:26 PM, Marcus Meissner [EMAIL PROTECTED] wrote: On Mon, Sep 08, 2008 at 11:10:11PM +0200, Henri Verbeet wrote: From cb10664e7d7526951d97f6d9ba2f7429d20b69d4 Mon Sep 17 00:00:00 2001 From: Henri Verbeet [EMAIL PROTECTED] Date: Mon, 8 Sep 2008 22:39:11 +0200 Subject: secur32: Require gnutls for schannel +AC_ARG_WITH(gnutls,AS_HELP_STRING([--without-gnutls],[do not use GnuTLS (schannel support)])) Hmm, I really do not think gnutls will have a long feature, NSS seems to be the future choice of crypto frameworks :/ Ciao, Marcus s/feature/future/ ? future, yes. But in the end ... well, we will see what wins ;) Ciao, Marcus
Re: [1/5] secur32: Require gnutls for schannel
On Mon, Sep 08, 2008 at 11:37:39PM +0200, Henri Verbeet wrote: 2008/9/8 Marcus Meissner [EMAIL PROTECTED]: Hmm, I really do not think gnutls will have a long feature, NSS seems to be the future choice of crypto frameworks :/ Ciao, Marcus I did have a look at NSS, but didn't see a way to make it work with a simple buffer, which makes in impractical to use for schannel. Perhaps I missed something there though. Another option would of course be to implement TLS ourselves, it's not all that complicated actually. Hmm. The security guy in me says do not reimplement ;) If its easier with gnutls, please use it. (It will not go away due to lots of software requiring it). Ciao, Marcus
winhttp test failures
Hi Hans, Tests you added to the file dlls/winhttp/tests/notification.c are causing several test failures across all platforms. Can you please have a look at this? Thanks, James Hawkins
Re: wininet: InternetQueryOption return size when buffer too small
On Mon, Sep 8, 2008 at 5:01 PM, Rotem Zach [EMAIL PROTECTED] wrote: + + internetQWCheckOption(NULL,INTERNET_OPTION_MAX_CONNS_PER_SERVER,(WCHAR*)Open: INTERNET_OPTION_MAX_CONNS_PER_SERVER Got wrong length %d instead of %d\n,sizeof(ULONG)); + internetQWCheckErr(ERROR_INSUFFICIENT_BUFFER,(WCHAR*)Open: INTERNET_OPTION_MAX_CONNS_PER_SERVER Wrong Error %d Expecting %d\n); + + internetQWCheckOption(NULL,INTERNET_OPTION_MAX_CONNS_PER_1_0_SERVER,(WCHAR*)Open: INTERNET_OPTION_MAX_CONNS_PER_1_0_SERVER Got wrong length %d instead of %d\n,sizeof(ULONG)); + internetQWCheckErr(ERROR_INSUFFICIENT_BUFFER,(WCHAR*)Open: INTERNET_OPTION_MAX_CONNS_PER_1_0_SERVER Wrong Error %d Expecting %d\n); + All of these lines are way too long. Please stick close to an 80-col line limit. -- James Hawkins
Re: user32.dll: Add stub for LockWorkStation
2008/9/8 Paul Chitescu [EMAIL PROTECTED]: /*** + *LockWorkStation (USER32.@) + */ +BOOL WINAPI LockWorkStation() This is the right place to put it be the above should be LockWorkStation(void) not LockWorkStation(). -- Rob Shearman
Re: user32.dll: Add stub for LockWorkStation
On Mon, Sep 8, 2008 at 2:32 PM, Paul Chitescu [EMAIL PROTECTED] wrote: Changelog: user32.dll: Stub for LockWorkStation() Not sure if user_main.c is the right place but I put it together with ExitWindowsEx. Would you mind taking a shot at implementing this properly? It was on my TODO but I most likely will never get back to it. Here is my patch from before which was wrong. http://www.winehq.org/pipermail/wine-patches/2007-May/039240.html What we need to do is use SendMessage to talk to the existing explorer.exe process and have it do the locking. Feel free to use what i have to make a patch if your interested. -- 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: Patchwatcher security improvements
Interesting.One of my goals is to support Solaris and BSD; have you tried your stuff there? I'm currently refactoring patchwatcher.sh; I've pulled the generic stuff out into libpatchwatcher.sh and the wine-specific stuff into wine-slave.sh. Your changes will fit nicely into wine-slave.sh, I hope. I'm surprised you had to give up on the chroot... I was planning on trying to run just wine-slave.sh in a chroot jail, since it's the only part that would actually try to run any part of the wine build system. - Dan
re: [1/5] secur32: Require gnutls for schannel
If its easier with gnutls, please use it. +1 I also agree that nss is likely to replace openssl as the toolkit of choice. But if depending on gnutls is the easiest path to a working schannel, that's the right thing to do. We can always change later if a compelling reason arises. - Dan
re: Patchwatcher security improvements
Interesting.One of my goals is to support Solaris and BSD; have you tried your stuff there? Not yet, but that stuff is pretty generic, so it shouldn't be hard to get it to work. I'm surprised you had to give up on the chroot... I was planning on trying to run just wine-slave.sh in a chroot jail, since it's the only part that would actually try to run any part of the wine build system. Creating the chroot itself is really hard and has to be done for each platform separately. The basic system and also all development tools and Wine dependencies have to be copied properly. And there are the tests with their own bunch of requirements. In the end you would end up with a chroot that is not much different from the base system itself. And it doesn't really bring many security benefits. Many potentially insecure interfaces have to be exposed anyway (/proc, X server with OpenGL, sound hardware). If a clean and dedicated system is used and permissions are properly configured, running stuff on the base system shouldn't really be a problem. Furthermore, using some advanced access control system (like SELinux) would probably be easier to configure and more efficient.
Re: Patchwatcher security improvements
Also, it's possible some of your changes won't be needed after the refactoring... I plan to run wine-slave as a different user anyway... That doesn't solve much; although in may look clean, it is not secure. The user should have a limited amount of resources to work with. Your way, for example, it can write the whole master Wine tree. With my patches, the master tree is read-only for the user, and it only has its own copy to work with which is never used again. I plan to further improve things. In particular, killing stall processes is not implemented securely now. As I have already mentioned, additional access control is needed to produce a fully solid system. For example, disk access should be limited (think about world-writable folders and stuff like ~/.bashrc), and memory usage should be limited as well (could patchwatcher get killed when the patch starts consuming memory?). Considering the refactoring, I see you are just some moving stuff into its own file; I can easily adjust my code.
Debugging applications running on wine
Is winedbg the only method of debugging applications being developed for Windows on Wine? For instance, assume a program developed with Visual Studio in C or C++, and I needed to debug it on Linux? Thanks, Kevin
re: Debugging applications running on wine
Kevin K wrote: Is winedbg the only method of debugging applications being developed for Windows on Wine? For instance, assume a program developed with Visual Studio in C or C++, and I needed to debug it on Linux? If winedbg doesn't work for you, we should fix it. Same goes for other debuggers. For instance, ollydbg seems to work http://appdb.winehq.org/objectManager.php?sClass=applicationiId=2619 Visual C++ 6's debugger seems to work at least a little, too: http://appdb.winehq.org/objectManager.php?sClass=versioniId=31 Please file bugs for any problems you run into. - Dan
socket errors...
I started narrowing down some information in debugging a winemm issue and noticed the following in my logs... trace:winsock:WSARecvFrom socket 00e8, wsabuf 0x33f638, nbufs 1, flags 0, from 0x33f67c, fromlen 16, ovl (nil), func (nil) trace:winsock:WSARecvFrom fd=51, options=0 warn:winsock:WSARecvFrom - ERROR 10035 The 10035 is a buffer overflow error (I think) and I don't know much if at all how this set of code is supposed to work... anyone else getting this with the latest git tree? and any help on figuring out why the buffer is getting this error... thanks Chris
Re: socket errors...
On Mon, Sep 8, 2008 at 10:03 PM, Chris Ahrendt [EMAIL PROTECTED] wrote: I started narrowing down some information in debugging a winemm issue and noticed the following in my logs... trace:winsock:WSARecvFrom socket 00e8, wsabuf 0x33f638, nbufs 1, flags 0, from 0x33f67c, fromlen 16, ovl (nil), func (nil) trace:winsock:WSARecvFrom fd=51, options=0 warn:winsock:WSARecvFrom - ERROR 10035 The 10035 is a buffer overflow error (I think) and I don't know much if at all how this set of code is supposed to work... anyone else getting this with the latest git tree? and any help on figuring out why the buffer is getting this error... A little context might help...I, for one, have no idea what you're talking about. -- James Hawkins
Re: socket errors...
James Hawkins wrote: On Mon, Sep 8, 2008 at 10:03 PM, Chris Ahrendt [EMAIL PROTECTED] wrote: I started narrowing down some information in debugging a winemm issue and noticed the following in my logs... trace:winsock:WSARecvFrom socket 00e8, wsabuf 0x33f638, nbufs 1, flags 0, from 0x33f67c, fromlen 16, ovl (nil), func (nil) trace:winsock:WSARecvFrom fd=51, options=0 warn:winsock:WSARecvFrom - ERROR 10035 The 10035 is a buffer overflow error (I think) and I don't know much if at all how this set of code is supposed to work... anyone else getting this with the latest git tree? and any help on figuring out why the buffer is getting this error... A little context might help...I, for one, have no idea what you're talking about. ok context.. I turned on tracing for winsock while trying to narrow down another issue I am working on. When I did... I started seeing these errors in my output where I had not before... (IE turn +winsock off does not output the above) Chris
Re: Patchwatcher security improvements
On Mon, Sep 8, 2008 at 6:06 PM, Dan Kegel [EMAIL PROTECTED] wrote: Interesting.One of my goals is to support Solaris and BSD; have you tried your stuff there? What about OS X?
Re: socket errors...
On Tue, Sep 9, 2008 at 5:03 AM, Chris Ahrendt [EMAIL PROTECTED] wrote: I started narrowing down some information in debugging a winemm issue and noticed the following in my logs... trace:winsock:WSARecvFrom socket 00e8, wsabuf 0x33f638, nbufs 1, flags 0, from 0x33f67c, fromlen 16, ovl (nil), func (nil) trace:winsock:WSARecvFrom fd=51, options=0 warn:winsock:WSARecvFrom - ERROR 10035 The 10035 is a buffer overflow error (I think) No, 10035 is WSAEWOULDBLOCK, which is normal for WSARecvFrom() on non-blocking sockets that currently have no data in the receive buffer. and I don't know much if at all how this set of code is supposed to work... anyone else getting this with the latest git tree? and any help on figuring out why the buffer is getting this error... I'd be more worried if it wasn't :-). thanks Chris Bye Damjan
