Character Sets


While 8-bit character strings in Windows usually use one of the ANSI character sets (code pages) according to your locale, console output functions using 8-bit strings normally assume use of an OEM character set, as used by DOS.


That is, while the statement MSGBOX CHR$(192) will print an accented capital A (ANSI Western character set), ConPrint CHR$(192), or PRINT CHR$(192) under PB/CC, will print a box-corner character (OEM character set).


Under PB/Win 10, ConPrint (and any other console output command) accepts a 16-bit character unicode string (UTF-16) parameter, for compatibility with the PRINT statement of PB/CC 6. Thus, the full range of unicode characters can be displayed on the console. However, there is a compatibility issue with programs written for older compilers.


As part of the automatic transparent compatibility mechanism for programs written for 8-bit strings, if ConPrint is used with an 8-bit string expression, the PB/Win 10 compiler automatically converts the string parameter to UTF-16 before calling ConPrint. The PB/CC 6 compiler does the same thing for PRINT used with an 8-bit string parameter.


However, in converting the 8-bit string expression to a 16-bit string, the PB compiler (both PB/Win and PB/CC) will assume that the 8-bit string uses the locale-specific ANSI character set, not the OEM character set.


Thus, under PB/Win 10, ConPrint CHR$(192) (or PRINT CHR$(192) under PB/CC 6) will print an accented capital A, not the box-corner character.


There is another issue. The word "expression" is emphasized above because it was discovered in testing that PB will convert a string expression which contains an 8-bit string when used as a parameter to a procedure that is expecting a 16-bit string (such as ConPrint under PB/Win 10), but not a simple variable. Thus:


ConPrint stText + $CRLF


or even:


ConPrint stText + ""


will compile correctly and with no error, but:


ConPrint stText


will fail to compile with a "parameter mismatches definition" error.


This is only an issue with user-written procedures, like ConPrint. It is not an issue with PRINT under PB/CC 6.


Note that StdOutPrint and StdErrPrint remain as 8-bit string commands under PB/Win 10. If these streams are directed to the console (the default in the absence of any redirection), Windows (not PB) will perform the 8-bit to 16-bit conversion, and it will assume that the 8-bit string is using the OEM character set.