Support of DBCS in eComStation
C functions work without problems
C functions (strcmp) work without problems
The standard library string functions operate on a per-byte
level; they neither know nor care how many displayable characters those
bytes represent.
In C, at least, little if any special effort is required to support DBCS
text processing. The same goes for text and PM output -- the system
codepage support takes care of the display issues.
(thx Alex Taylor)
Compiling code with DBCS strings
Where you can run into trouble is in compiling code with DBCS strings in
it. This depends on the compiler and other tools used.
The main worry is in dealing with double-byte characters that contain a
backslash \ as the second byte. C compilers (and runtimes) all seem to be
smart enough to recognize them, so you don't have to escape them...
NORMALLY.
(\ will never occur as a leading byte, and of course you must always escape
single-byte \ characters.)
However, some versions of the IBM Resource Compiler don't seem to be able
to handle backslashes like this, in some (and only some) circumstances.
Unfortunately, I've never quite figured out the rule. Going largely from
memory, I think STRINGTABLE resources have to escape their secondary-byte
backslashes but all other items (e.g. MENUITEMS, dialog strings, etc) must
not. (Unless I have that backwards... like I said, this is from memory.)
I had a lot of grief getting the Japanese XWorkplace DLL working properly.
Some backslashes had to be escaped, others had to be left unescaped. And
it didn't really compile reliably unless I was actually running under
codepage 932 (Japanese), regardless of the command-line switches I used.
So basically, if you have DBCS strings containing \ as a secondary byte,
double-check them all to make sure they display correctly when the program
is run. Then go in and escape the ones that don't display correctly.
(thx Alex Taylor)
Additional information
General information about the DBCS languages
|