New patch with all these comments uploaded:

***** posixmodule.c
-----
Call to GetVersion() in unicode_file_names() - added a comment:
+ 		/* As per doc for ::GetVersion(), this is the correct test for 
+ 		   the Windows NT family. */
----
We appear to have gone to great pain to prevent posix_1str() and posix_2str() 
from ever being called with non-NULL wformat and wfunc params when 
Py_WIN_WIDE_FILENAMES is not defined.  Added an assertion for
this fact, but this is largely untested as my Linux box was stolen :)

----
posix_2str() does not reset the Python error if Unicode arg parsing fails.
Fixed that in the same way all other functions do.

----
The following code is incorrect:

+ 		wchar_t wbuf[1026];
+ 		Py_BEGIN_ALLOW_THREADS
+ 		wres = _wgetcwd(wbuf, sizeof wbuf);

The second param is the number of *characters*, not bytes.  Changed it to read:

+ 		wres = _wgetcwd(wbuf, sizeof wbuf / sizeof wbuf[0]);

-----
I don't understand this loop:

+ 			for (i=0; wnamebuf[i]; i++) {
+ 				if (wnamebuf[i] == L'\0')
+ 					namebuf[i] = '\0';
+ 				else if (isascii(wnamebuf[i]))
+ 					namebuf[i] = (char)(wnamebuf[i]);
+ 				else 
+ 					namebuf[i] = '?';
+ 			}

I don't see how the first if block is ever entered, and therefore how namebuf 
is ever terminated.  The debugger supports my assertion that the third line
of the code snippet above is never hit.

For this reason, and for other bits of the code, I added a few new global 
error functions:
PyErr_SetFromErrnoWithUnicodeFilename(...)

etc.  Modified a number of places to use these new handlers.  Note that this
will mean Exception objects now have Unicode "filename" attributes if a 
Unicode filename was originally passed - this makes sense to me.

-----
There seems to be a few errors in the error handling for listdir():

+ 			if ((d = PyList_New(0)) == NULL)
+ 				return NULL;
+ 			hFindFile = FindFirstFileW(wnamebuf, &wFileData);
+ 			if (hFindFile == INVALID_HANDLE_VALUE) {
+ 				errno = GetLastError();
+ 				if (errno == ERROR_FILE_NOT_FOUND) {
+ 					return PyList_New(0);
XXX - 'd' leaks in the line above - return 'd' should be fine.
+ 				}
+ 				return win32_error("FindFirstFileW", namebuf);
XXX - 'd' leaks above - Py_DECREF(d) needed.

further in the same function:
+ 			if (FindClose(hFindFile) == FALSE)
+ 				return win32_error("FindClose", namebuf);
XXX - 'd' leaks above - Py_DECREF(d) needed.

I note that these exact errors also exist in the existing "narrow" code.
I have fixed both places.

-----
***** fileobject.c

+ #define WINDOWS_LEAN_AND_MEAN

Should be WIN32_LEAN_AND_MEAN
-----
Debug builds fail with an assertion.  open_the_file asserts:
	assert(name != NULL);

But this is not true for windows.  Further, code later attempts to pass this 
NULL filename to PyErr_SetFromErrnoWithFilename

Further, open() crashes if passed a bad filename - we then attempt to use the 'name' 
param which is NULL.

Finally, we *still* get a crash in test_unicode_file.py when passing a MBCS 
encoded string.  I've already butchered the patch enough - if everything I have
done is agreed with, I will tackle that next.

-----
test_pep277.py - added some tests for invalid filenames to
open() and stat().  These should be expanded to others.