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 amaury.forgeotdarc, eckhardt, loewis, rpetrov
Date 2008-10-09.09:18:24
SpamBayes Score 1.6764368e-14
Marked as misclassified No
Message-id <1223543906.76.0.688737803235.issue4075@psf.upfronthosting.co.za>
In-reply-to
Content
Roumen, just and explanation on the TCHAR/WCHAR/CHAR issue under win32...

In the old days, DOS/Windows was built with 8-bit characters using
codepages. So functions like CreateFile() took a char string that used
the current local codepage as encoding. Now, since NT 4 (maybe even 3)
the internally used char type is a 16-bit type. In order to ease
conversion, the function CreateFile() was removed (it still exists in
oldnames.lib) and replaced with CreateFileW() and CreateFileA(), which
explicitly take either a codepage-encoded 8-bit string or a UCS2/UTF-16
16-bit string. Under win9x, CreateFileW() actually tried to convert to
the internally used 8-bit character type, while under NT, CreateFileA()
converted from the codepage to the UTF-16 character type.

Now, under CE, which is an embedded OS, neither the
(legacy/obsolete/deprecated) codepages nor the according CreateFileA()
functions exist. They simply have been removed to save space and because
they are of limited functionality anyway.

Which CE version? All of them, since at least CE3 (CE6 is current). Why
not treat all strings as wide string? Because that would actually change
the existing meaning of them and make it harder to impossible to create
code that is portable.
History
Date User Action Args
2008-10-09 09:18:26eckhardtsetrecipients: + eckhardt, loewis, amaury.forgeotdarc, rpetrov
2008-10-09 09:18:26eckhardtsetmessageid: <1223543906.76.0.688737803235.issue4075@psf.upfronthosting.co.za>
2008-10-09 09:18:26eckhardtlinkissue4075 messages
2008-10-09 09:18:24eckhardtcreate