[issue13374] Deprecate usage of the Windows ANSI API in the nt module

[sbt]

sbt <shibturn at gmail.com> added the comment:

I notice that the patch changes rename() and link() to use
win32_decode_filename() to coerce the filename to unicode before using
the "wide" win32 api.  (Previously, rename() first tried the wide api,
falling back to narrow if that failed; link() used wide if the args were
both unicode, narrow otherwise.  Some other functions like symlink()
already only use the wide api.)

Is this approach of coercing to unicode and only using the wide api
"blessed"?  I certainly think it should be.  If so then one can get
rid lots windows specific code.

And are we able to assume that on Windows we have access to wide libc
functions?  _wcsicmp(), _snwprintf(), _wputenv() are all used already,
so I guess we already make that assumption.  It looks like a lot of the
windows specific code attempts to reimplement basic libc functions using
the win32 api just to support unicode - presumably there was a time when
we could not assume that wide libc functions would be available.  Other functions like execv() and spawnv() were never given unicode support.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13374>
_______________________________________