hiya folks, well the saga continues with using python under wine - i thought i'd let you know the analysis and clues so far, in case it rings any bells with anyone, now or in the future. as you're probably aware, there's a limit in nt of 2048 file descriptors which has caused a large number of free software projects quite a lot of grief , e.g. this: http://bugs.mysql.com/bug.php?id=24509. it turns out that python is no different, and i'm just in the process of investigating whether compiling every single c-based module as a builtin saves me enough file handles to be able to not hit the 2048 handles limit. it's really quite stunning. even something as simple as running a single small test script can result in 1,400 file handles being used up. by the time you get to things like the popen-replacement (see msdn KB: Q190351 for a simple code example). anyway - what prompted me to write was that i ran the python.exe with msvcr80 on wine, and the popen-like code segfaulted. under win32 naitive (an actual XP qemu) it failed - gracefully. but, weirdly, python.exe _without_ msvcr80 did _not_ segfault, but, again, same code on XP qemu'd failed gracefully. so, matrix: wine xp-qemu'd vc80 segfault error vc71 ok error in other words, i'm beginning to suspect that the reason for that msvcr80 segfault i was investigating last week is because of running out of file handles, and wine doesn't _have_ that 2048 file descriptor limit that msvcr80 is assuming actually exists. either that, or when you _do_ reach that limit, it results in corruption that an app running msvcr71 doesn't notice. or something. the reason i haven't raised this as a bugreport is because i really don't exactly know what's going on - there are just rather a lot of empirical observations that are ... "out there" :) so i apologise for this being a bit long, and not very specific, and if ever i get anything specific i'll of course raise it as a bugreqeuest, but i didn't want to leave this undocumented. l.