> I couldn't found where python C-code use so called "TCHAR meaning" and
> the first sentence from comment in Ulrich patch looks irrelevant to the
> issue.

I was confused by Ulrich's terminology at first, also (claiming that
Python doesn't use TCHAR, so how could it depend on it); I now think
Ulrich is nearly correct. E.g. in 2.6, we call, in posixmodule.c,
CreateProcess. Now, CreateProcess is defined in the SDK as

#ifdef UNICODE
#define CreateProcess  CreateProcessW
#else
#define CreateProcess  CreateProcessA
#endif // !UNICODE

However, it is *documented* as

BOOL WINAPI CreateProcess(
  __in_opt     LPCTSTR lpApplicationName,
  __inout_opt  LPTSTR lpCommandLine,
  __in_opt     LPSECURITY_ATTRIBUTES lpProcessAttributes,
  __in_opt     LPSECURITY_ATTRIBUTES lpThreadAttributes,
  __in         BOOL bInheritHandles,
  __in         DWORD dwCreationFlags,
  __in_opt     LPVOID lpEnvironment,
  __in_opt     LPCTSTR lpCurrentDirectory,
  __in         LPSTARTUPINFO lpStartupInfo,
  __out        LPPROCESS_INFORMATION lpProcessInformation
);

So according to the documentation, this is a function that takes TCHAR
parameters, hence it is a "TCHAR-based (windows) API". The fact that the
Windows SDK actually defines it differently is a technical hack; for all
practical purposes, it behaves as if it really was a TCHAR API.

> Also Ulrich patch is far from complete "TCHAR" implementation in python.

See msg74386.

> May be issue title has to be changed to address more precise problem.

Certainly.