Python trunk, compiled with VS2005 SP1, release build on Windows 2000:
>>> import os
>>> fd = os.open("t", 0)
>>> os.close(fd)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 9] Bad file descriptor

The _PyVerify_fd() returned False for the given fd!
Needless to say that there are many other similar failures. For example,
subprocess does not work.

Digging inside assembly code, I noticed that the __pioinfo structure
compiled inside msvcr80.dll has a sizeof==64 (asssembly code multiplies
by 64 when doing pointer arithmetic); in Debug mode, sizeof==56.
in posixmodule.c, _PyVerify_fd() uses a sizeof of 56...

It appears that Windows 2000 picks the first msvcr80.dll it finds on the
PATH. So I played with copying various versions of it in the target
directory. Here are the results, as reported by Visual Studio in the
"Modules" pane.

fails: C:\WINNT\system32\msvcr80.dll		8.00.50727.1433
fails: C:\python\trunk\PC\VS8.0\msvcr80.dll	8.00.50727.1433
works: C:\python\trunk\PC\VS8.0\msvcr80.dll	8.00.50727.762	
fails: C:\python\trunk\PC\VS8.0\msvcr80.dll	8.00.50727.163	
fails: C:\python\trunk\PC\VS8.0\msvcr80.dll	8.00.50727.42
works: C:\WINNT\system32\msvcr80d.dll	8.00.50727.762

DLL hell...

The manifest embedded inside python27.dll contains
version="8.0.50727.762", which is the only working version.
So the problem will likely not happen on Windows XP, which enforces
manifests.

Is there a way to enforce the manifest information on Windows 2000 as well?
If not, there may be several solutions:
- disable the _PyVerify_fd() stuff on Windows 2000.
- write clever code to detect the real sizeof(ioinfo) (for example:
_get_osfhandle(1) returns __pioinfo[0][1]->osfhnd, which is a file
opened for writing)