[issue4075] Use WCHAR variant of OutputDebugString

Martin v. Löwis added the comment: Thanks for the patch. Committed as r68172. -- status: open -> closed ___ Python tracker ___ ___ Pyt

[issue4075] Use WCHAR variant of OutputDebugString

Changes by Martin v. Löwis : -- assignee: -> loewis priority: -> high ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubs

[issue4075] Use WCHAR variant of OutputDebugString

Changes by Martin v. Löwis : -- stage: -> commit review ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://

[issue4075] Use WCHAR variant of OutputDebugString

Changes by Martin v. Löwis : -- resolution: -> accepted ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://

[issue4075] Use WCHAR variant of OutputDebugString

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > May be OutputDebugStringA has to be part of "wince-port" library but if > is fine all win platforms to call *W what about patch to use function > MultiByteToWideChar() ? Is there a problem with the proposed patch?

[issue4075] Use WCHAR variant of OutputDebugString

Roumen Petrov <[EMAIL PROTECTED]> added the comment: May be OutputDebugStringA has to be part of "wince-port" library but if is fine all win platforms to call *W what about patch to use function MultiByteToWideChar() ? ___ Python tracker <[EMAIL PROTECTED]>

[issue4075] Use WCHAR variant of OutputDebugString

Ulrich Eckhardt <[EMAIL PROTECTED]> added the comment: "If this patch required for CE 5.0?" The patch I created is required for all CEs that I know of. I have personally worked with 4.20, 5 and now 6, and had some exchange with others who worked on 3.x variants to get STLport (C++ stdlibrary imp

[issue4075] Use WCHAR variant of OutputDebugString

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > If the python switch to W functions then the issue will be resolved. Python should use the *W functions wherever possible. > Without general switch to W functions and to wide strings we need to > convert every time from single chat to wid

[issue4075] Use WCHAR variant of OutputDebugString

Changes by Thomas Heller <[EMAIL PROTECTED]>: -- nosy: +theller ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mailing

[issue4075] Use WCHAR variant of OutputDebugString

Roumen Petrov <[EMAIL PROTECTED]> added the comment: I couldn't find in MSDN flags for Windows CE compilers similar to the GCC compiler that change representation of strings in C-code. The Microsoft recommend so called TCHAR technology that depend from UNICODE define I answer itself. >From MSDN

[issue4075] Use WCHAR variant of OutputDebugString

Ulrich Eckhardt <[EMAIL PROTECTED]> added the comment: "PythonCE project use xxxA functions for CE .NET 4.20 platform." Look again. The PythonCE project adds a header and sourcefile (wince_compatibility.h/c) which adds these functions. In other words, it doesn't use the xxxA functions of the win

[issue4075] Use WCHAR variant of OutputDebugString

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > "Pointless" question is for compiler flags and is not related with the OS. I don't think the compiler has any such flag that you might consider useful. Do you have a specific flag in mind? ___ Python tr

[issue4075] Use WCHAR variant of OutputDebugString

Roumen Petrov <[EMAIL PROTECTED]> added the comment: My experience with windows CE ends with version about 3.1X. I couldn't remember wide character support on this version. PythonCE project use xxxA functions for CE .NET 4.20 platform. "Pointless" question is for compiler flags and is not relat

[issue4075] Use WCHAR variant of OutputDebugString

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > If the CE can't work with char why the compiler don't threat strings as > wide characters always ? I think this question is pointless - we don't have the power to change how CE works. You might question whether Ulrich's analysis of the iss

[issue4075] Use WCHAR variant of OutputDebugString

Ulrich Eckhardt <[EMAIL PROTECTED]> added the comment: Actually, even _Py_NegativeRefcount() passes a statically sized buffer with 300 chars. Other than that, there is get_ref_type() which uses one with 350 chars, but AFAICT, that's the largest one. Attached accordingly modified patch. _

[issue4075] Use WCHAR variant of OutputDebugString

Ulrich Eckhardt <[EMAIL PROTECTED]> added the comment: 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

[issue4075] Use WCHAR variant of OutputDebugString

Roumen Petrov <[EMAIL PROTECTED]> added the comment: Which CE version ? Is the patch required for previous/next CE version ? If the CE can't work with char why the compiler don't threat strings as wide characters always ? -- nosy: +rpetrov ___ Python

[issue4075] Use WCHAR variant of OutputDebugString

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: I agree that a static buffer should be used. I think calling it in a loop is overkill. Instead, if an overrun occurs, adding "(truncated)" should be good enough. I could find only a single caller that doesn't pass a static string (_Py_Negativ

[issue4075] Use WCHAR variant of OutputDebugString

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: The alloca() function should be avoided here: the function may be called in extreme conditions, like stack overflow. I suggest to use a small static buffer (50 chars?), and call OutputDebugStringW in a loop. -- nosy: +amaury.fo

[issue4075] Use WCHAR variant of OutputDebugString

New submission from Ulrich Eckhardt <[EMAIL PROTECTED]>: The attached patch converts the call to OutputDebugString() with a 'TCHAR' parameter (which boils down to a 'char') to one using a 'WCHAR' parameter, allowing the code to be compiled under MS Windows CE, which doesn't have the 'char' versio