This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eckhardt
Recipients eckhardt
Date 2008-10-06.10:28:42
SpamBayes Score 1.4653151e-10
Marked as misclassified No
Message-id <1223288926.88.0.428745871562.issue4051@psf.upfronthosting.co.za>
In-reply-to
Content
In several places, Python is using TCHAR-based win32 APIs which has 
several consequences:
1. The actually used function depends on the _UNICODE macro, while the 
using code often assumes that this macro is not defined. That means 
that not only the code changes when the macro is defined but that it 
simply breaks.
2. Using the ANSI-variants of functions causes overhead when a Unicode 
string has to be transcoded and possibly data loss, because the ANSI 
encoding can't represent the full Unicode range. Note that I'm 
assuming an NT based system (i.e. NT, win2k etc), because the systems 
where the ANSI encoding is native (win9x, ME(?) etc) have been dropped 
from the supported platforms.
3. The main reason for me wanting a build independent of TCHAR is a 
port to MS Windows CE, which doesn't support the ANSI encoding at all. 
This means that a TCHAR-clean build for desktop win32 is a necessary 
part of the port to CE, but even without the port it would be useful 
to skip the conversion overhead and at the same time gain 
functionality. Concerning the CE port, see this thread as a reference:
http://mail.python.org/pipermail/python-dev/2008-September/082529.html

Note: I'm adding this tracker item mainly in order to attach patches 
for review, so they don't get lost like it's possible on the 
mailinglist.
History
Date User Action Args
2008-10-06 10:28:47eckhardtsetrecipients: + eckhardt
2008-10-06 10:28:46eckhardtsetmessageid: <1223288926.88.0.428745871562.issue4051@psf.upfronthosting.co.za>
2008-10-06 10:28:45eckhardtlinkissue4051 messages
2008-10-06 10:28:43eckhardtcreate